August 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] XML Parser, Monticello and unicode?

by Norbert Hartl

I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. How does monticello handle WideString instances when written to a file? Norbert

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Dale Henrichs

Javier, I agree with Stef, that duplication isn't an issue - the duplicated bits are static. An individual developer has many routes for building/configuring an application that runs on multiple versions/platforms, but the idea of "metacello universes" is aimed at helping _users_ figure out what configurations are "known to work in a particular version." The repository per release idea has very few moving parts, can be done now, and addresses the main problem, so it should be done. On the other hand, we shouldn't stop looking for better ways to "skin the cat":) Dale Javier PimÃ¡s wrote: > Maybe I saying nonsense, if that is the case just ignore me but... why > have many packages that do almost exactly the same? Aren't you going to > get a lot of repeated code lying around in different packages? ie. I > think most packages have almost exactly the same baselines for pharo1.x. > Maybe it's possible to call the methods baselineXXForPharoXX and let > them stay in the same class and package? Or maybe adding other pragma to > specify which pharo version each baseline/version describes. I'm sure > there could be other solutions. That way you'd have all the > configurations in the same place and also reuse code if needed instead > of duplicating it. > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > > Miguel, > > I think that this kind of approach makes lots of sense ... I've > toyed with the idea of a "white list" of configuration versions, but > someone would have to be responsible for maintaining the "white > list" and the users would have to responsible for using the "white > list" ... > > A repository per version is very simple and gives the maintainer > flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > > El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribiÃ³:> > Why there should be repository per release? As i know > MetacelloConfiguration already contains information about > compatible > Pharo versions. > > > Because is cleaner and as the releases of Pharo diverge a lot > more, the > code to install package becomes full of conditionals to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, > 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and > DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals an several > variations of preDoits and postDoits and test what version image is > ConfigurationOfMagma is being ran. After a couple of hours I > gave up. > > The correct solution is to have a specific ConfigurationOfMagma > for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update the > ConfigurationOfXXX without disturbing or broke the stable ones. > - It permits the ConfigurationOfXXX code to remain clean, without a > conditionals for every posible combination of release image > version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to decide > when to > stop supporting old version of a certain package by deleting the old > versionXX: methods of the ConfigurationOfXXX in the newer pharo > releases. Not always is good to be able to install each and every > version of a package in the newest release of pharo (maybe even old > versions won't work in the new releases, like the menu registration > issue or classes that doesn't belong to the core image) > - It permits to issue maintenance ConfigurationOfXXX releases for a > stable or "old-stable" image releases, without altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com > <mailto:miguel.coba@gmail.com>>: > > El miÃ©, 04-08-2010 a las 11:46 +0200, Torsten Bergmann > escribiÃ³: > > Hi Miguel, > > hey, nice! If we follow this convention then it is > easy to implement > a universe browser that selects the correct universe > repo and > displays all loadable versions. Loading stuff should > just be > a few clicks away - I personally hate all this > MC/Gofer typing ... > > Attached is a quick/simple implementation of such a > browser: > > Mann, Sie sind Ã¼ber schnell! > > I tested it in PharoCore 1.0 and worked after a few > changes, but the > interface is cool. +1 to aim it be the default universe > browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't register on menu > because of the > lacking pragmas) > - UniverseBrowser pharoUniverse returns PharoCore1.0 > instead of Pharo10 > to build the universe name. This could be changed in two > ways: > - Add a system property that states the image repository: > SystemVersion current universeName "Returns Pharo10 > for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the gofer package I > uploaded to > PharoInbox (if it is approved, so there is only a unique > source for > converting image version string to universe names) > > Other than that, I like the browser. > > > > - file in the attached changeset (I tried in Pharo > 1.2) > - open via World menu -> "Universe Browser" > - select the configuration you want and from the > context menu choose > -- "Load configuration" -> only > the config is loaded > -- "Load configuration and latest version" -> the > config and lates version is loaded > > Have fun! I used Pharo 1.2 - should work in Pharo > 1.0 and 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 04-08-2010 a las 23:32 -0300, Javier PimÃ¡s escribiÃ³: > Maybe I saying nonsense, if that is the case just ignore me but... why > have many packages that do almost exactly the same? Aren't you going > to get a lot of repeated code lying around in different packages? ie. > I think most packages have almost exactly the same baselines for > pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX > and let them stay in the same class and package? Or maybe adding other > pragma to specify which pharo version each baseline/version describes. > I'm sure there could be other solutions. That way you'd have all the > configurations in the same place and also reuse code if needed instead > of duplicating it. Clarity. As is very likely that different releases of a package will have distinct requirements in: - dependencies - preinstall/postinstall actions - registering with system services (menu, mail systems, sockets, startup/stop list) - number of monticello packages composing the package you're installing - use of system infraestructure (announcements, transcript, menus, help system) it will be a nightmare to have code to cope with all those conditions in a single monolithic giant metacello package, even if metacello is capable of do it. What if after 4 years of development the package has had 15 releases, that will means that you'll have possibly 15 baselines/predoits/postdoits all listing in the method pane of the browser. To someone trying to understand the configuration, it will be a lot of junk to discard before he understand only the bits that matter for the release he is interested in. So, it is healthy to have a distinct configuration in each release (even if in the current release started as a copy of the previous release configuration), to crop the things the _maintainer_ thinks are not needed anymore or simply that he doesn't want to maintain anymore. All the software has a lifetime and distinct repositories gives us the possibility to determine the time to end support for a given release Cheers > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com> > wrote: > Miguel, > > I think that this kind of approach makes lots of sense ... > I've toyed with the idea of a "white list" of configuration > versions, but someone would have to be responsible for > maintaining the "white list" and the users would have to > responsible for using the "white list" ... > > A repository per version is very simple and gives the > maintainer flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > > > El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov > escribiÃ³: > Why there should be repository per release? As > i know > MetacelloConfiguration already contains > information about compatible > Pharo versions. > > Because is cleaner and as the releases of Pharo > diverge a lot more, the > code to install package becomes full of conditionals > to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any > pharo 1.0, 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 > because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and > DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals > an several > variations of preDoits and postDoits and test what > version image is > ConfigurationOfMagma is being ran. After a couple of > hours I gave up. > > The correct solution is to have a specific > ConfigurationOfMagma for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update > the > ConfigurationOfXXX without disturbing or broke the > stable ones. > - It permits the ConfigurationOfXXX code to remain > clean, without a > conditionals for every posible combination of release > image version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to > decide when to > stop supporting old version of a certain package by > deleting the old > versionXX: methods of the ConfigurationOfXXX in the > newer pharo > releases. Not always is good to be able to install > each and every > version of a package in the newest release of pharo > (maybe even old > versions won't work in the new releases, like the menu > registration > issue or classes that doesn't belong to the core > image) > - It permits to issue maintenance ConfigurationOfXXX > releases for a > stable or "old-stable" image releases, without > altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez > <miguel.coba(a)gmail.com>: > El miÃ©, 04-08-2010 a las 11:46 +0200, > Torsten Bergmann escribiÃ³: > Hi Miguel, > > hey, nice! If we follow this > convention then it is easy to > implement > a universe browser that > selects the correct universe > repo and > displays all loadable > versions. Loading stuff should > just be > a few clicks away - I > personally hate all this > MC/Gofer typing ... > > Attached is a quick/simple > implementation of such a > browser: > > Mann, Sie sind Ã¼ber schnell! > > I tested it in PharoCore 1.0 and > worked after a few changes, but the > interface is cool. +1 to aim it be the > default universe browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't > register on menu because of the > lacking pragmas) > - UniverseBrowser pharoUniverse > returns PharoCore1.0 instead of > Pharo10 > to build the universe name. This could > be changed in two ways: > - Add a system property that states > the image repository: > SystemVersion current universeName > "Returns Pharo10 for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the > gofer package I uploaded to > PharoInbox (if it is approved, so > there is only a unique source for > converting image version string to > universe names) > > Other than that, I like the browser. > > > > - file in the attached > changeset (I tried in Pharo > 1.2) > - open via World menu -> > "Universe Browser" > - select the configuration > you want and from the context > menu choose > -- "Load configuration" > -> only the config is loaded > -- "Load configuration and > latest version" -> the config > and lates version is loaded > > Have fun! I used Pharo 1.2 - > should work in Pharo 1.0 and > 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 5, 2010

[Pharo-project] Analog to Dolphin's CompositePresenter

by Schwab,Wilhelm K

Gary, all, I am far from comfortable with Polymorph design and programming, but I have managed stick some controls on standard windows. Now I need to do something that would benefit from composition of an image and a selection mask into something that allows the mask to be edited while "scrubbing" over the image. Then those get paired, and then the pairs go into sequences. The pairing can be done with tabs, and maybe a "copy from peer" button. I think I can manage that. My question is on how to make what in Dolphin is called a CompositePresenter, which are useful critters. They are not directly tied to a top-level shell, but sending #show to them will create just that, mostly for testing purposes. Is there already something like this in Polymorph? ComposableMorph might be a place to start?? Is there a better way? Bill

Aug. 5, 2010

Re: [Pharo-project] Basic question about globals variables

by Lukas Renggli

On Thursday, August 5, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. I know this is a newbie question, but there is something I don't understand about globals. > > I am writing a piece of code, and I refer to "a class" that does exist. Suppose: > > testSomething > > Â Â Â NonExistenteClass > > > Whem I accept the method, a popup brings saying it doesn't exist...etc. Then, I can define as global. > > If I then evaluate:Â Â Smalltalk globals at: #NonExistenteClass > > the key exist and it has nil as value. Perfect. > > So..if I understand well, all these globals variables AND classes are stored in this globals, which is the only instance of SystemDictionary (for the moment). > > Now my question is, where are nil, true, false, etc stored? Magic in the compiler. They are also referenced in the special objects array. > I know there are only one instance ofÂ UndefinedObject, False, True, etc have only one instance...but WHERE are they stored? who keep them?Â They don't seem to be in SystemDictionary. Why no? Efficiency. There are special bytecodes to push them. AFAIK Gemstone is the only Smalltalk that has them in the "SystemDictionary". Lukas > > I did a "chase pointers" to nil for example, and it says > "CLASS: SmalltalkImage class > subclasses: UndefinedObject" > > I still don't understand :( > > Thanks for any hints > > Mariano > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 5, 2010

[Pharo-project] [update 1.2] #12083

by Marcus Denker

12083 ----- Issue 2749: NewTextMorph does not react to enter and escape keystrokes (part 2) Issue 2750: Loading an image segment can introduce a class named AnObsoleteFake37SomeName -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 5, 2010

[Pharo-project] Basic question about globals variables

by Mariano Martinez Peck

Hi. I know this is a newbie question, but there is something I don't understand about globals. I am writing a piece of code, and I refer to "a class" that does exist. Suppose: testSomething NonExistenteClass Whem I accept the method, a popup brings saying it doesn't exist...etc. Then, I can define as global. If I then evaluate: Smalltalk globals at: #NonExistenteClass the key exist and it has nil as value. Perfect. So..if I understand well, all these globals variables AND classes are stored in this globals, which is the only instance of SystemDictionary (for the moment). Now my question is, where are nil, true, false, etc stored? I know there are only one instance of UndefinedObject, False, True, etc have only one instance...but WHERE are they stored? who keep them? They don't seem to be in SystemDictionary. Why no? I did a "chase pointers" to nil for example, and it says "CLASS: SmalltalkImage class subclasses: UndefinedObject" I still don't understand :( Thanks for any hints Mariano

Aug. 5, 2010

Re: [Pharo-project] How do you extract a superclass if you can't select multiple classes?

by Max Leske

Good point. I've been struggling with multiple selection too e.g. when setting the refactoring scope. There's an entry called "selection..." but since I've never been able to select more than one item from a list, selecting "selection..." has the same effect as âcategory" (when in a category list of course). Max On 05.08.2010, at 14:52, Tim Mackinnon wrote: > Its a real pain that you can't multiple select things in the pharo UI... > > As I try and do things in Pharo and compare the operations to what I can easily do in Eclipse or Intelli-J - I've hit a new one - how do I extract a common superclass from 2 classes that are similar? > > I can refactor create superclass - but that just does it for one class, and then I can't easily make my second class a subclass as Pharo complains about duplicate instance variables. > > It seems like the capability is locked in there - but I keep struggling to work it out (refactoring in Pharo seems more complicated than it should be somehow - and I'm really looking forward to sitting down with someone someday and working out some keystrokes to use - extract method, extract temporary, inline temporary should just be keystrokes). > > Tim > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2010

[Pharo-project] How do you extract a superclass if you can't select multiple classes?

by Tim Mackinnon

Its a real pain that you can't multiple select things in the pharo UI... As I try and do things in Pharo and compare the operations to what I can easily do in Eclipse or Intelli-J - I've hit a new one - how do I extract a common superclass from 2 classes that are similar? I can refactor create superclass - but that just does it for one class, and then I can't easily make my second class a subclass as Pharo complains about duplicate instance variables. It seems like the capability is locked in there - but I keep struggling to work it out (refactoring in Pharo seems more complicated than it should be somehow - and I'm really looking forward to sitting down with someone someday and working out some keystrokes to use - extract method, extract temporary, inline temporary should just be keystrokes). Tim

Aug. 5, 2010

Re: [Pharo-project] [ANN 1.2] pre-built core#12082

by StÃ©phane Ducasse

Thanks marcus. I was busy integrating and this is good to snapshot. Stef On Aug 5, 2010, at 9:19 AM, Marcus Denker wrote: > > https://gforge.inria.fr/frs/download.php/27329/PharoCore-1.2-12082.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2010