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

[Pharo-project] Making Pharo 2.0 usable
by Alexandre Bergel Sept. 11, 2012

Sept. 11, 2012

Hi! I will be happy to see Pharo 2.0 usable. A lot of things happens and I cannot benefit from them. At the next ESUG I will invite the one who make Pharo 2.0 usable to a restaurant / plenty of beers. Go go go! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

[Pharo-project] RE : Re: RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

Cami, A general ordering of standard (so to speak) protocols would be nice indeed. But what about pretty local protocols? Like things in PetitParser for example. Alphabetical would be a nuisance. Philippe Back Camillo Bruni <camillobruni(a)gmail.com> a Ã©crit : On 2012-09-09, at 13:39, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > You are a very directive kind of person, when it comes to thoses things... > If a user want it classified his way, who am I to change his ordering ? You got me wrong there, I am talking about a user defined / preference dict. It's like choosing your preferred font. Of course this solution is very simplistic only holding up to a single global order. The other solution might be to simply replace the Dictionary in the new class organizer by something like an OrderedKeyDictionary plus a Nautilus plugin, DONE If you want my very personal opinion, I think it's not really helpful to have anything but alphabetic sorting. I use the new shortcuts in 2.0 to simply jump to the category I want, that saves me some couple of 100ms visual perception time on each selection. > No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. I don't see any problem there. > By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? in regard to what? I would say if you do a DeltaSlowness / AddedFeaturesIn2.0 you end up with something close to 0...

3 2

[Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

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

2 1

Re: [Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

On 2012-09-09, at 14:24, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I guess you tried both with an empty package-cache, right? yes, not much of a diff...

2 8

Re: [Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

On 2012-09-09, at 14:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I think it has to do with the change in #readableFileNames Indeed it metacello does this big mistake of gathering all the local gofer-references first. But that would mean on an empty package-cache it should load the same way, but even then it's still considerably slower in 2.0 There's also an additional overhead by the announcement system for recategorizing methods..

1 0

[Pharo-project] RE : RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

300Megs with Eclipse. With the base install you mean. We do hit triple that over here... SOA/JEE and some CLM plugins involved. Ah RAM is cheap. The problem is that all programs think they need it all these days. Philippe Back GOUBIER Thierry <thierry.goubier(a)cea.fr> a Ã©crit : WzYou are a very directive kind of person, when it comes to thoses things... If a user want it classified his way, who am I to change his ordering ? No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] Date d'envoi : dimanche 9 septembre 2012 13:25 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : NewClassOrganizer On 2012-09-09, at 13:18, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] > Date d'envoi : dimanche 9 septembre 2012 12:48 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] NewClassOrganizer > >> Ordering of protocols should happen in the Browser not in the model. > > Hum, it looks like to save a few lines there, it's gonna cost a few thousands lines and caching complexity in the Browser. I doubt that you'll need any caching there, for any given protocol finding the proper methods should be O(1), so the only thing that's left is ordering the protocol. - define a global ordered collection of predefined categories which will be sorted first - sort the rest alphabetically... so that's an O(n) lookup overhead for the all the entries. given that there is hardly any class defining 100 protocols you can redo that calculation as often as you want... >> 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... > > Then the new implementation looks worse than the previous one, from a GUI point of view in addition to the performance / space ones. not at all... the old categories are a big mess without any documentation => nobody will every maintain that and as mentioned above, the only trade-off is space, which honestly you cannot complain about unless we hit something like a 300MB boundary like Eclipse...

3 2

[Pharo-project] NewClassOrganizer
by GOUBIER Thierry Sept. 9, 2012

Sept. 9, 2012

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

2 5

[Pharo-project] RE : RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

I happen to like to be able to have the protocols the way Thierry describes. Protocols are a distinctive feature of Smalltalk. Why allow ourselves anything else than stellar support for them? Private goes to the bottom, accessors to the top. And the rest the way we want it. Anyway, we'll soon have the TG_patch... Philippe Back GOUBIER Thierry <thierry.goubier(a)cea.fr> a Ã©crit : You are a very directive kind of person, when it comes to thoses things... If a user want it classified his way, who am I to change his ordering ? No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] Date d'envoi : dimanche 9 septembre 2012 13:25 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : NewClassOrganizer On 2012-09-09, at 13:18, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] > Date d'envoi : dimanche 9 septembre 2012 12:48 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] NewClassOrganizer > >> Ordering of protocols should happen in the Browser not in the model. > > Hum, it looks like to save a few lines there, it's gonna cost a few thousands lines and caching complexity in the Browser. I doubt that you'll need any caching there, for any given protocol finding the proper methods should be O(1), so the only thing that's left is ordering the protocol. - define a global ordered collection of predefined categories which will be sorted first - sort the rest alphabetically... so that's an O(n) lookup overhead for the all the entries. given that there is hardly any class defining 100 protocols you can redo that calculation as often as you want... >> 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... > > Then the new implementation looks worse than the previous one, from a GUI point of view in addition to the performance / space ones. not at all... the old categories are a big mess without any documentation => nobody will every maintain that and as mentioned above, the only trade-off is space, which honestly you cannot complain about unless we hit something like a 300MB boundary like Eclipse...

1 0

[Pharo-project] RPackage question
by Goubier Thierry Sept. 9, 2012

Sept. 9, 2012

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

3 4

[Pharo-project] git support
by Camillo Bruni Sept. 8, 2012

Sept. 8, 2012

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

6 15