- Pharo-dev - lists.pharo.org

[Pharo-project] RE : RE : RE : NewClassOrganizer

by Philippe Back

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...

Sept. 9, 2012

[Pharo-project] RE : RE : NewClassOrganizer

by GOUBIER Thierry

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...

Sept. 9, 2012

Re: [Pharo-project] RE : NewClassOrganizer

by Camillo Bruni

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...

Sept. 9, 2012

[Pharo-project] RE : NewClassOrganizer

by GOUBIER 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 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. > 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. Thanks for the warning. Thierry

Sept. 9, 2012

[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