- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] forward engineering UML models into Smalltalk code

by HernÃ¡n Morales Durand

2011/8/9 <btc(a)openinworld.com> > ** > greetings all, > > What tools exist to assist with the forward engineering of UML diagrams > into Smalltalk code? > I have been searching for some time but my results are swamped by tools > that: > - reverse engineer Smalltalk code into UML diagrams > For example to draw UML of the Url hierarchy you may download the Moose environment (http://www.moosetechnology.org/) and evaluate | view | view := MOViewRenderer new. view shape: UMLClassDiagram new umlShape. view interaction popupText. view nodes: Url withAllSubclasses asArray. view shape: (MOArrowedOrthoVerticalLineShape new). view edgesFrom: #superclass. view layout: MOTreeLayout new. view open there are more examples in the Moose Easel window. > - implement new techniques moving beyond UML and MOF > > I am implementing the [electric power system] Common Information Model of > IEC 61970 in Smalltalk. This is defined as a UML Class Diagram (part of > which I have attached) maintained using Enterprise Architect, which can > export into XMI format. I hoped there might be a way to load the XMI > directly into Smalltalk classes. Manually implementing the inheritance > structure is straight forward, and I've developed a template for the > aggregate relationships but an automated function would help to assure > correctness, consistency and to track changes in the model. > > > > > > > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Aug. 9, 2011

Re: [Pharo-project] On the way to 1.3 Release: images

by Adrian Lienhard

Sure. I'll mail the Photoshop file to you privately. Adrian On Aug 9, 2011, at 13:12 , StÃ©phane Ducasse wrote: > adrian > > do you have the banner file formats so that we store them on svn? > > Stef > > On Aug 9, 2011, at 10:30 AM, Adrian Lienhard wrote: > >> Thanks, Marcus! >> >> On Aug 9, 2011, at 08:41 , Marcus Denker wrote: >> >> [...] >> >>> Next steps: >> >> [...] >> >>> -> change the links on pharo-project to point to these images for >>> http://www.pharo-project.org/pharo-download/stable >>> http://www.pharo-project.org/pharo-download/stable-core >> >> Done. >> >>> -> change the link >>> http://www.pharo-project.org/pharo-download/unstable(-core) >>> to point to the one jenkins build of 1.4 >> >> I changed /unstable-core to point to https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… >> >> I assume there is no /unstable build (yet)? >> >>> -> add a page or 1.3 on pharo-project.org >> >> I added a place holder with a link to the Wiki page http://www.pharo-project.org/pharo-download/release-1-3 >> >> It would be nice if we could move the text over and revise it a bit. Any taker? >> >>> >>> -> clean up a bit, no need to have pages for old .1 release. >> >> On pharo-project.org? >> >> >> Once we have the one-click image, we also need to update the download banner and the links on http://www.pharo-project.org/pharo-download >> >> Cheers, >> Adrian > >

Aug. 9, 2011

Re: [Pharo-project] On the way to 1.3 Release: images

by Adrian Lienhard

On Aug 9, 2011, at 10:48 , Marcus Denker wrote: > > Thanks! > >> >>> -> change the link >>> http://www.pharo-project.org/pharo-download/unstable(-core) >>> to point to the one jenkins build of 1.4 >> >> I changed /unstable-core to point to https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… >> >> I assume there is no /unstable build (yet)? >> > For 1.4, we want to not have multiple images anymore... this is really difficult to fix bugs in two images, it's hard to explain, Right, that's what I remembered too (there fore the "yet" ;). My question was more regarding what we do with those links since there probably are scripts that use the /unstable-core and /unstable URLs. For now I made both point to .../lastSuccessfulBuild/artifact/Pharo-1.4.zip. >>> -> clean up a bit, no need to have pages for old .1 release. >> >> On pharo-project.org? >> > yes... the page for 1.1.1 we should merge into the page for 1.1 (just to make it look cleaner) I would keep the old release pages for historic reasons, but move them out of the Download menu. We could add a page named "Previous releases" and link these pages from there. Then under "Download" in the menu, we only keep the most recent version. Adrian

Aug. 9, 2011

Re: [Pharo-project] Seaside on Pharo-Kernel

by Pavel Krivanek

OK, I will update the current. Even better is to create a Jenkins job ;-) https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Seas… -- Pavel On Tue, Aug 9, 2011 at 1:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Pavel > > could you create a page on the wiki about pharo-kernel? > Because like that it does not lost in our email flow. > > tx > > On Aug 9, 2011, at 12:45 PM, Pavel Krivanek wrote: > >> Hi, >> >> there's possible to load Seaside to the Pharo-Kernel. >> >> 1) Load PharoKernel-Gofer image from CI server >> (https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe…) >> >> 2) run the image with seaside.st script as an argument. That will >> create about 4.1 MB image with basic Seaside packages and basic >> examples. >> >> 3) run the image with run.st script (note that starting of the server >> in the seaside.st script will hang, currently I have no idea why). >> >> 4) see if everything works at http://localhost:8080/examples/examplebrowser >> >> Cheers, >> -- Pavel >> <run.st><seaside.st> > > >

Aug. 9, 2011

Re: [Pharo-project] GUI failing apart

by Igor Stasenko

On 9 August 2011 13:43, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/8/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>> OK, some clean up was required, but you see, you can make things worse >>> when cleaning... >> >> Yes but in average this is really not the case. >> >>> It's like Pharo cleaning removed the antidote, but forgot to remove >>> the poison... >> >> Ok that kinds of things happens in ugly, undocumented, obsolete systems. >> >>> Now, of course, instead of a local polishing, it would be possible to >>> rewrite all. >> >> I'm starting to write tests for the events. Now since you are at it, I guess that you read this wonderful code >> full of hypothesis and other subtle strange behavior. So I'm quite sure that they will be problems. >> But we will fix them. Else we should stop now and do Javascript because at least we will look cool. >> > > Oh, If your goal is to remain popular, then indeeed, you should keep > away from changing such parts of the system which are not shining ;). > The obvious reason is that multilayer hacks with obfuscated contracts > are not maintanable... > so it's inevitable to create bugs in the transition and harvest complaints... > > Of course, if your goal is to make the system more simple and > maintanable, I'm with you (and I know it is). > But don't forget to extract the positive part of complaints that will > help you making the system better. > > Personnally, the finite state machine logic in Squeak/MouseOverHandler > is well beyond my understanding. > So I could not clean it easily myself, > > A cosmetic cleaning was attempted in Pharo.I have nothing against that. > I just pointed a problem in current cleaning, so it just have to be finished. > The stincky ivar mutation already was in Squeak. > I just said that it should raise an alarm in coder's eyes in the > future and I hope this helps. > Otherwise I can also shut up. > > The second approach suggested by Igor is more involving, consist in a > full rewrite, probably with these stages: > - gather description of the features to be supported, > - an inventory of third party interested in this kind of features, > - and from there, decline a new definition of contracts. > >>> But please, don't do it blindly and loose 2 third of features like the >>> new implementors window :( >> >> We are not doing things blindly: >> >> Â Â Â Â First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI >> Â Â Â Â without a decent widgets set (because he fixed them also the multiselection and others). >> Â Â Â Â Benjamin I publicly thank you for all the good stuff you did!!!! >> >> >> Â Â Â Â Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap >> Â Â Â Â Please hightlight me. >> >> Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life >> a system full of shit. Shit that was accumulated and of course stable because it did not move since years. >> In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) >> better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system >> in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them. >> >> Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because >> Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets >> is not easy, nor it is to work on bootstrapping Pharo. >> >> Stef >> >> > > Sure, I don't want to restrain goodwill. > But as a user of the service I don't see all the sweat the hardworkers > put into the system, > I just see a regression that makes my life harder (I simply cannot > track the messages with the new windows). > And obviously, comparing the length of old menu with new one, two > third does not seem exagerated to me. > But maybe you don't work with those tools and install OB/RB after each update... > > Nicolas > Nicolas, it would help if you mention what exactly you missing instead of 2/3 :) -- Best regards, Igor Stasenko AKA sig.

Aug. 9, 2011

Re: [Pharo-project] On the way to 1.3 Release: images

by Marcus Denker

On Aug 9, 2011, at 1:34 PM, Sean P. DeNigris wrote: > > marcus.denker wrote: >> >> For 1.4, we want to not have multiple images anymore... >> > > Awesome! Fixing bugs will be much more fun with e.g. OB loaded :) The problem with multiple browsers is that we have to maintain right now two Browsers. The problem is that one can only use one, and than the other will degrade. Or the other way around. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 9, 2011

Re: [Pharo-project] On the way to 1.3 Release: images

by Sean P. DeNigris

marcus.denker wrote: > > on pharo-project.org... clean up a bit... > I clicked through the website a bit thinking from a new user perspective: * /Home -> Shortcuts section in center - Downloads: what is the difference between Pharo and PharoCore? It's not explained, but it'd probably be better to list only Pharo anyway. Anyone sophisticated enough to need Core/Unstable will figure out where to look. - the way "Downloads" is lined up with "External sites" links, makes it seem like they're related, especially since the above list is one list in two columns. I think it would be clearer to stack them vertically. * /pharo-download - there are two one-clicks, Cog and standard. Using the same reasoning as above, I think we should pick the one that we want newbies to use and put it there by itself (no choice = no error), and put the other in the "Custom Downloads" section below with a short description saying why someone would want to use it instead. Sean -- View this message in context: http://forum.world.st/On-the-way-to-1-3-Release-images-tp3729121p3729708.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2011

Re: [Pharo-project] GUI failing apart

by Nicolas Cellier

2011/8/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >> OK, some clean up was required, but you see, you can make things worse >> when cleaning... > > Yes but in average this is really not the case. > >> It's like Pharo cleaning removed the antidote, but forgot to remove >> the poison... > > Ok that kinds of things happens in ugly, undocumented, obsolete systems. > >> Now, of course, instead of a local polishing, it would be possible to >> rewrite all. > > I'm starting to write tests for the events. Now since you are at it, I guess that you read this wonderful code > full of hypothesis and other subtle strange behavior. So I'm quite sure that they will be problems. > But we will fix them. Else we should stop now and do Javascript because at least we will look cool. > Oh, If your goal is to remain popular, then indeeed, you should keep away from changing such parts of the system which are not shining ;). The obvious reason is that multilayer hacks with obfuscated contracts are not maintanable... so it's inevitable to create bugs in the transition and harvest complaints... Of course, if your goal is to make the system more simple and maintanable, I'm with you (and I know it is). But don't forget to extract the positive part of complaints that will help you making the system better. Personnally, the finite state machine logic in Squeak/MouseOverHandler is well beyond my understanding. So I could not clean it easily myself, A cosmetic cleaning was attempted in Pharo.I have nothing against that. I just pointed a problem in current cleaning, so it just have to be finished. The stincky ivar mutation already was in Squeak. I just said that it should raise an alarm in coder's eyes in the future and I hope this helps. Otherwise I can also shut up. The second approach suggested by Igor is more involving, consist in a full rewrite, probably with these stages: - gather description of the features to be supported, - an inventory of third party interested in this kind of features, - and from there, decline a new definition of contracts. >> But please, don't do it blindly and loose 2 third of features like the >> new implementors window :( > > We are not doing things blindly: > > Â Â Â Â First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI > Â Â Â Â without a decent widgets set (because he fixed them also the multiselection and others). > Â Â Â Â Benjamin I publicly thank you for all the good stuff you did!!!! > > > Â Â Â Â Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap > Â Â Â Â Please hightlight me. > > Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life > a system full of shit. Shit that was accumulated and of course stable because it did not move since years. > In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) > better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system > in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them. > > Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because > Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets > is not easy, nor it is to work on bootstrapping Pharo. > > Stef > > Sure, I don't want to restrain goodwill. But as a user of the service I don't see all the sweat the hardworkers put into the system, I just see a regression that makes my life harder (I simply cannot track the messages with the new windows). And obviously, comparing the length of old menu with new one, two third does not seem exagerated to me. But maybe you don't work with those tools and install OB/RB after each update... Nicolas >> >> Nicolas >> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > > >

Aug. 9, 2011

Re: [Pharo-project] On the way to 1.3 Release: images

by Sean P. DeNigris

marcus.denker wrote: > > For 1.4, we want to not have multiple images anymore... > Awesome! Fixing bugs will be much more fun with e.g. OB loaded :) -- View this message in context: http://forum.world.st/On-the-way-to-1-3-Release-images-tp3729121p3729679.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2011

[Pharo-project] Fwd: [squeak-dev] forward engineering UML models into Smalltalk code

by StÃ©phane Ducasse

> > > On Aug 9, 2011, at 9:50 AM, btc(a)openInWorld.com wrote: > >> greetings all, >> >> What tools exist to assist with the forward engineering of UML diagrams into Smalltalk code? >> I have been searching for some time but my results are swamped by tools that: >> - reverse engineer Smalltalk code into UML diagrams >> - implement new techniques moving beyond UML and MOF >> >> I am implementing the [electric power system] Common Information Model of IEC 61970 in Smalltalk. This is defined as a UML Class Diagram (part of which I have attached) maintained using Enterprise Architect, which can export into XMI format. I hoped there might be a way to load the XMI directly into Smalltalk classes. Manually implementing the inheritance structure is straight forward, and I've developed a template for the aggregate relationships but an automated function would help to assure correctness, consistency and to track changes in the model. >> >> <Mail Attachment.jpeg > > > Hi btc > > In Moose on VW long time ago we implemented everything to load XMI, we had an emof reader that (I'm not sure anymore) was generating FAMIX classes. > May be you should ask on the Moose mailing-list. I could check on our old store but I should find somewhere how to connect to it. > > Stef > >

Aug. 9, 2011