September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Configuration loading 1.4 vs 2.0

by Camillo Bruni

After Igor's remark about the loading speed of configs in 2.0 I ran twice the same configuration in 1.4 and 2.0 and things load incredibly slow under 2.0 Subjectively it seems that 2.0 spends ages loading Metacello / Gofer stuff. I'll dive a bit into it to see if somethings stands out... The two images with the Profiler opened: http://dl.dropbox.com/u/18184943/LoadConfig1.4.zip http://dl.dropbox.com/u/18184943/LoadConfig2.0.zip

Sept. 9, 2012

Re: [Pharo-project] NewClassOrganizer

by Camillo Bruni

On 2012-09-09, at 12:31, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Hi all, > > I'm looking at the NewClassOrganizer package. Is that part of the system reimplementation effort ? > > In it, I'm worried by ClassOrganization>>addCategory: aProtocolName before: aUselessArgument. > > I want to be able to fix the ordering of protocols when I develop (it's more to my taste, as an old-timer, to have usually initialization / instance creation on top of the protocol list, and private at the bottom... Alphabetical ordering of protocols is far less satisfying, and an implementation which force an internal reordering contrary to my whishes would be problematic). Ordering of protocols should happen in the Browser not in the model. Protocols are simple dictionary entries, the old implementation simply did not want to use dicts for performance / space reasons. I doubt that we will add explicit ordering to protocols...

Sept. 9, 2012

[Pharo-project] NewClassOrganizer

by GOUBIER Thierry

Hi all, I'm looking at the NewClassOrganizer package. Is that part of the system reimplementation effort ? In it, I'm worried by ClassOrganization>>addCategory: aProtocolName before: aUselessArgument. I want to be able to fix the ordering of protocols when I develop (it's more to my taste, as an old-timer, to have usually initialization / instance creation on top of the protocol list, and private at the bottom... Alphabetical ordering of protocols is far less satisfying, and an implementation which force an internal reordering contrary to my whishes would be problematic). Thierry

Sept. 9, 2012

[Pharo-project] RE : RPackage question

by GOUBIER Thierry

No, that's because RPackage does a search for a non existing At2-test MCWorkingCopy, and Monticello auto-creates a capitalized version of at2-test truncated to at2. (Proof: removing the capitalization and truncation in Monticello result in only one RPackage created, At2-test) And then, depending on the capitalisation of at2-test, Nautilus bugs because he's looking for, say at2-test, where MC has created At2-test and Nautilus search among RPackages is case sensitive :( (RPackageOrganizer faulty API) (this one I haven't tried to correct. I've stopped using Nautilus instead :)) Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Tudor Girba [tudor(a)tudorgirba.com] Date d'envoi : dimanche 9 septembre 2012 03:09 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage question > That happens because RPackage mirrors categories for now. When you create At2-Test, it creates both an At2 and an At2-Test category. Hence, you will get two RPackages. Cheers, Doru On Thu, Sep 6, 2012 at 2:42 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 06/09/2012 14:32, Tudor Girba a Ã©crit : > >> This is just the way symbols print like when they have non alpha numeric >> characters :) > > > And of course $- is not an alpha numeric character... :) > > Ok, > > helps the understanding. > > 6647 is apparently solved by unregistering MCPackageManager from > SystemAnnouncer. > > But still : > > Why, if you add a method in an extension protocol (such as #'*At2-Test') > with indirect creation of a package, > > RPackageOrganizer ends up with: > RPackage(#'*At2-Test') > And > RPackage(#At2) > Because > MCWorkingCopy has created the #At2 MCPackage ? > > Thierry > > >> Doru >> >> >> On 6 Sep 2012, at 14:10, Goubier Thierry wrote: >> >>> I'm trying to see what's happening with bug 6647, since it's pretty >>> dangerous for development on Pharo 2.0 at the moment, and annoying as well. >>> >>> So I'm looking at RPackageOrganizer packages key and is there a reason >>> for some keys to have quotes and others not ? >>> >>> for example : >>> #Nautilus >>> and >>> #'Ring-Core-Kernel' >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> -- >> www.tudorgirba.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> >> >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 9, 2012

Re: [Pharo-project] RPackage question

by Tudor Girba

That happens because RPackage mirrors categories for now. When you create At2-Test, it creates both an At2 and an At2-Test category. Hence, you will get two RPackages. Cheers, Doru On Thu, Sep 6, 2012 at 2:42 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 06/09/2012 14:32, Tudor Girba a Ã©crit : > >> This is just the way symbols print like when they have non alpha numeric >> characters :) > > > And of course $- is not an alpha numeric character... :) > > Ok, > > helps the understanding. > > 6647 is apparently solved by unregistering MCPackageManager from > SystemAnnouncer. > > But still : > > Why, if you add a method in an extension protocol (such as #'*At2-Test') > with indirect creation of a package, > > RPackageOrganizer ends up with: > RPackage(#'*At2-Test') > And > RPackage(#At2) > Because > MCWorkingCopy has created the #At2 MCPackage ? > > Thierry > > >> Doru >> >> >> On 6 Sep 2012, at 14:10, Goubier Thierry wrote: >> >>> I'm trying to see what's happening with bug 6647, since it's pretty >>> dangerous for development on Pharo 2.0 at the moment, and annoying as well. >>> >>> So I'm looking at RPackageOrganizer packages key and is there a reason >>> for some keys to have quotes and others not ? >>> >>> for example : >>> #Nautilus >>> and >>> #'Ring-Core-Kernel' >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> -- >> www.tudorgirba.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> >> >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 9, 2012

Re: [Pharo-project] git support

by Max Leske

For all those interested: I changed the repository for FileSystem-Git. Installation instructions can be found on github: https://github.com/dalehenrich/FSGit. Please note that a lot of things might be broken on load because FileSystem itself is still under development. Cheers, Max On 07.09.2012, at 18:15, Max Leske <maxleske(a)gmail.com> wrote: > Be sure to use the version from the experimental branch (FSGit-Experimental) and to use the gemstone repo (the github repo is up to date but you wouldn't be able to load the traits) > > Max > > > On 07.09.2012, at 16:15, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Excellent...I'll take it for a spin soonly and let you know how it goes! >> >> Dale >> >> ----- Original Message ----- >> | From: "Max Leske" <maxleske(a)gmail.com> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Friday, September 7, 2012 6:54:20 AM >> | Subject: Re: [Pharo-project] git support >> | >> | Runs on 1.4 and 2.0 as long as you manually backport the newest >> | filesystem packages (I've got both images on my machine and it works >> | fine). >> | >> | >> | On 07.09.2012, at 15:32, Camillo Bruni <camillobruni(a)gmail.com> >> | wrote: >> | >> | > On 2012-09-07, at 15:29, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> | >> Does FsGit run in Pharo1.4 or is ti Pharo2.0 only ... if it ran in >> | >> Pharo1.4 I would start using it in my daily work:) >> | > >> | > so that's a motivation to get it up and running in 1.4 :P >> | > With FileSystem being backported I don't see any immediate problems >> | > ahead... >> | > >> | >> ----- Original Message ----- >> | >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | >> | To: Pharo-project(a)lists.gforge.inria.fr >> | >> | Sent: Friday, September 7, 2012 6:22:44 AM >> | >> | Subject: Re: [Pharo-project] git support >> | >> | >> | >> | >> | >> | On 2012-09-07, at 15:13, Dale Henrichs <dhenrich(a)vmware.com> >> | >> | wrote: >> | >> | > Cami, >> | >> | > >> | >> | > What kind of work needs to be done for the Cypress-compatible >> | >> | > format? I've done a couple of different implementations >> | >> | > already:) >> | >> | > So I can definitely do one more ... If you give me the name of >> | >> | > the >> | >> | > class that is the entry point for read/write then I can take >> | >> | > it >> | >> | > from there ... >> | >> | >> | >> | Since you ported it to the new FileSystem I don't have to change >> | >> | much >> | >> | :) >> | >> | The git stuff works on top of the new FileSystem, thus >> | >> | completely >> | >> | transparent to >> | >> | whatever FileOperations you used. >> | >> | >> | >> | - load filetree >> | >> | - use filetree instead of my own git exporter >> | >> | - use filetree for recreating mc snapshots >> | >> | >> | >> | I will try to hook that up this weekend, then I need busy >> | >> | testers :P >> | >> | >> | >> | >> | >> | > Metacello integration is also among the "missing" from the >> | >> | > perspective that I want some real users using the Metacello >> | >> | > Preview[1] and giving me feedback[2] before I make a general >> | >> | > release. >> | >> | >> | >> | I guess we could push some work to Versionner? That would then >> | >> | have >> | >> | to interact >> | >> | with the low-level git filesystem to set the tags / commits >> | >> | >> | >> | > Also keep in mind that we will need to be inventing the >> | >> | > Smalltalk >> | >> | > workflow for git... >> | >> | >> | >> | yes :) I hope to get closer to that once I have a running >> | >> | implementation in pharo.. >> | >> | >> | >> | > Dale >> | >> | > >> | >> | > [1] >> | >> | > https://github.com/dalehenrich/metacello-work/blob/master/README.md >> | >> | > [2] https://groups.google.com/group/metacello/ >> | >> | > >> | >> | > ----- Original Message ----- >> | >> | > | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | >> | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" >> | >> | > | <pharo-project(a)lists.gforge.inria.fr> >> | >> | > | Sent: Friday, September 7, 2012 4:15:46 AM >> | >> | > | Subject: [Pharo-project] git support >> | >> | > | >> | >> | > | who will help? >> | >> | > | >> | >> | > | max and I, stimulated by ESUG, worked on the latest version >> | >> | > | of >> | >> | > | FS-Git >> | >> | > | to make it stable again. >> | >> | > | we are very close to have a complete set of git tools >> | >> | > | written in >> | >> | > | pharo ready! >> | >> | > | >> | >> | > | missing >> | >> | > | ======= >> | >> | > | - a better mc integration >> | >> | > | - a cypress compatible fileout format >> | >> | > | - complete interaction with the git protocol >> | >> | > | - a direct way to commit stuff >> | >> | > | >> | >> | > | as always my time is somewhat limited as well and we're the >> | >> | > | only >> | >> | > | two >> | >> | > | developers working on it... >> | >> | > | >> | >> | > | The current work is available here: >> | >> | > | http://ss3.gemstone.com/ss/FSGit-Experimental.html >> | >> | > | https://github.com/dalehenrich/FSGit >> | >> | > | >> | >> | > | best >> | >> | > | cami >> | >> | > | >> | >> | > >> | >> | >> | >> | >> | >> | >> | >> >> | > >> | > >> | >> | >> | >>

Sept. 8, 2012

[Pharo-project] [ANN] Dr. Geo 12.10 for GNU-Linux/Windows/MACOSX

by Hilaire Fernandes

Hello, After the Android version, here are the workstations release 12.10 of DrGeo. http://drgeo.eu Thanks Hilaire

Sept. 8, 2012

[Pharo-project] RE : RE : RE : RE : RPackage, Monticello and the removal of PackageInfo

by GOUBIER Thierry

________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : samedi 8 septembre 2012 08:53 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RE : RPackage, Monticello and the removal of PackageInfo > No they are layered. > > Monticello > RPackage > > and not the inverse. They should be, you mean. In practice, they are not layered like that. > We would not need tags with this scenario. > In scenario 2 RPackage are first class categories handling class extension. Ok. I would like more to call them RGroup, then :-) > I do not think so. > This is just that we decided to be backward compatible. > Personnally I would have just throw away categories. We do not need them. > But we are like poor people wanted to be rich, we do not have the money but we want more stuff. :-) I want that too. >> There is also a body of adding additional hierarchy levels in MCPackages by carefully naming packages with well chosen prefixes and - (System-whatever for example), which points out to the fact packages developpers need at least one more level of hierarchy. > This is why in the first design we added tags. But tags would have worked inside todays MCPackage, not when multiple MCPackages are grouped together via a common prefix. And even then, it's too much. To make the base system understandable, I added two additional levels on top of the MCPackage. > I think that we should let esteban experiment and we will discuss again to see. > Frankly I do not like the pattern-matching semantics and I understand that we do not want an explosion of packages > so let us give a bit more time and see. But could it be possible then to make the current one as stable as possible, to see if it can be made viable (and help correct bugs in both?). Moving a RPackage-based tool from RPackage+tags to RPackageSet + RPackage should not be too hard, once settled on a design choice (and trying to keep more or less the same API). Thierry

Sept. 8, 2012

[Pharo-project] RE : RE : RE : RPackage, Monticello and the removal of PackageInfo

by GOUBIER Thierry

StÃ©phane, I'll describe what I'll have done for AltBrowser processing the relevant announcement, according to what I know of the way MC maps packages and names : System announce class category change for classA, from catB to catC. In AltBrowser / class side - Find RPackage owning catB (matching Rpackage name + tag). - Find ClassA inside RPackage/catB representation - Remove my Alt object representing ClassA from class global structure. -- Announce to all AltBrowser instances to remove their Wrapper on Alt object for ClassA - Find RPackage owning catC - Find tag catC / create if needed - Create an Alt object representing ClassA inside RPackage (and catC if package has more than one tag). -- Announce to all AltBrowser instances to add the new object if appropriate This is the core of the code I have in the browser for each announcement, more or less. I was hoping RPackage would do the right thing, which is : As long as the system still has system categories, do any operation involving system categories according to the expected semantics (and MC is, for me, the judge of what those expected semantics may be). It would be nicer to be able to scrap directly the categories; for that, I would : build a new set of tools (RPackage-based system browser) disregarding categories. Disconnect that from MC except for an initial loading (not even querying MC for the related package, hey Nautilus!). Try to work in the system by removing everything that uses categories (return to basic, new, RPackage-based browsers). Have a reverse unload to MC (propagate all changes registered in RPackage back in MC when asked for it by the developper). Have only RPackageOrganizer or MC tracking changes, but not both. Reconnect both when all is stable. If you want, I can make an AltBrowser which would be a pure RPackage / tags only System Browser, no categories. Maybe RPackage is integrating too much too early in the system. Oh, as an aside since we're tracking unwanted instances, I wonder if there isn't a leak somewhere in dependencies / announcements (which would explain the more than one RPackageOrganizer instance bug cropping up). I'm leaking, and some instances of my browser don't garbage collect. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : samedi 8 septembre 2012 08:58 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo Thierry one of the problem we encountered is the following one with version 1 you have your package and tags MyPackage extensions methods... tagA classA classB tagB classC Now what do we do if the user change the category of the class. So we started to think that we should change class definition template so that we get category:'' -> package:'' tag: '' but this was implying to check in a lot of places. After we will see may be we will do it. The idea of esteban was to see if we can first get rid of PackageInfo, then in the future version of categories. Stef

Sept. 8, 2012

Re: [Pharo-project] RE : RE : RPackage, Monticello and the removal of PackageInfo

by StÃ©phane Ducasse

Thierry one of the problem we encountered is the following one with version 1 you have your package and tags MyPackage extensions methods... tagA classA classB tagB classC Now what do we do if the user change the category of the class. So we started to think that we should change class definition template so that we get category:'' -> package:'' tag: '' but this was implying to check in a lot of places. After we will see may be we will do it. The idea of esteban was to see if we can first get rid of PackageInfo, then in the future version of categories. Stef

Sept. 8, 2012