- Pharo-dev - lists.pharo.org

Re: [Pharo-project] A point a.k.a excuse to you

by CÃ©drick BÃ©ler

2009/3/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Fun enough I got the same feeling. Do you remember this etoy 3.8 > release that should have been done fast and > last more than a couple of month and after no communication with 3.9 > at all. Or the fork of Croquet. > So Marcus do not worry I can tell you that we are not paranoid and I > will not let anybody damage us. > And now we are even considered as the bad guy not wanted to merge.... > I believe that people gets afraid by Pharo or have time to show us > that we are wrong (of course some may want to > really collaborate). let's say (hope) this is a question of favorable conjecture (which you hadn't back when you took 3.9)... I think Matthiew and Keith... and some others, really pushed the idea to live with forks (instead of building another image)... After a year or two, people start to go in their way... + people have maybe more time to collaborate. IMO, the arrival of Igor and Eliot is also a big win... I think 2008 was a good smalltalk year... Pharo is a good choice though because you offer something to developer that was simply absent before and moreover, "people" were really reluctant to go in that direction for squeak hence all your problems... So still, even if there's a resurgence of squeak development collaboration, Pharo has its place for the everyday developer (even people like me who like to do simple stuffs ... but in smalltalk). I see Pharo as the Smalltalk oriented to developers, where you experience good development practices (and invent new one) whereas squeak is more global, touch at everything, experiment in all directions... Pharo decision process will be anyway quicker than squeak (even with Andreas proposal)... You can't imagine how much a little change like the menu shrinking is important to me (and looked impossible to ask for in squeak...). Maybe you won't totally reinvent Smalltalk but you already provide a solid smalltalk basis for everyday work (nb: I'm interested in first class slots ;) ). Anyway I find the present synergy around smalltalk/squeak/pharo/gs... really cool. Even if I understand your frustration, it might be important to try to stay in sync as much as possible. Keep the really good work :) My 2 cents, > > For now I will not discuss that point anymore on this list because we > do not make any progress and > we do not have to justify ourselves. > >>>> The croquet people namely (andreas) are on my case, and he clearly >>> gets >>> this concept since he based his "running for the board" email on it. >>> >>> The cobalt people = matthew and others, they "get it", and are using >>> some of the tools, and proposing common libraries. >>> >>> Bertf has expressed an interest in etoys moving up to 3.10+ if the >>> transition can be eased. > > I'm curious to see what they would gain. > And as if merging two streams would be that easy. > >>> >> >> So interestingly, all these peope never had *any* interest in >> cooperating on anything. >> >> Etoys ignored 3.9 *completely*. (and all my activity to merge etoys >> back before that was always done not with that much enthusiasm from >> their side. I Â got some bit of help from Bert and Michael, but the >> activity always came from Â my side). >> >> Andreas disapeared for years (just to pee on us for a good laugh >> on Â and off). >> >> So I really wonder why they all changed their mind suddenly. >> Seriously. >> >> Â Â Â Marcus > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

March 4, 2009

[Pharo-project] about parsing the complete image

by StÃ©phane Ducasse

Hi guys I discussed with gwenael about the parsing of the complete image to remove _ and strange character. Apparently there is an issue related to numbers. He will certainly post more information but we will have to think about that. Stef

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

Thanks this is strange that exactly the same week where we talk about that and where we discuss about announcements, such topics got interesting from some other people. We are probably not that wrong. ;) Thanks cedric keep us informed. Stef On Mar 4, 2009, at 11:26 AM, CÃ©drick BÃ©ler wrote: > As some of us are unregistered, I thought it could be of interest ;) > > > ---------- Forwarded message ---------- > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: 2009/3/4 > Subject: [squeak-dev] [ANN] Preference pragmas > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > Folks - > > I wanted to make the property whether to show individual processes in > MessageTally a preference and couldn't recall any of the three > gazillion methods to create one ;-) So I decided enough is enough and > added the ability to register a preference via Pragma. In other words, > you specify two class side accessors (using MessageTally as example): > > showProcesses > "Indicates whether to show each process separately or > cumulatively." > <preference: 'Show Processes in MessageTally' > category: 'debug' > balloonHelp: 'If enabled, each profiled process is > shown individually in MessageTally' > type: #Boolean> > ^ShowProcesses > > showProcesses: aBool > "Indicates whether to show each process separately or > cumulatively." > ShowProcesses := aBool. > > and then register the preference in the class initialization method > via: > > initialize > "MessageTally initialize" > "By default, show each process separately" > ShowProcesses := true. > "Register preferences" > Preferences addPreferencesFor: self. > > The nice thing about this scheme is that the preference is local to > the code where it's used and that there are no more generated > accessors which mess up Monticello packages etc. What could probably > be improved is the self-registration; I left it that way for now since > I don't know how expensive it would be to scan all classes for new > preferences when one opens a preference browser. There is also an > example class PreferenceExample that illustrates the different types > of preferences (textual, numeric, color, boolean) you can use. > > To install, just execute the following from Squeak 3.10.2: > > Installer mantis fixBug: 7306. > > Enjoy! > - Andreas > > > > > -- > CÃ©drick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by StÃ©phane Ducasse

Fun enough I got the same feeling. Do you remember this etoy 3.8 release that should have been done fast and last more than a couple of month and after no communication with 3.9 at all. Or the fork of Croquet. So Marcus do not worry I can tell you that we are not paranoid and I will not let anybody damage us. And now we are even considered as the bad guy not wanted to merge.... I believe that people gets afraid by Pharo or have time to show us that we are wrong (of course some may want to really collaborate). For now I will not discuss that point anymore on this list because we do not make any progress and we do not have to justify ourselves. >>> The croquet people namely (andreas) are on my case, and he clearly >> gets >> this concept since he based his "running for the board" email on it. >> >> The cobalt people = matthew and others, they "get it", and are using >> some of the tools, and proposing common libraries. >> >> Bertf has expressed an interest in etoys moving up to 3.10+ if the >> transition can be eased. I'm curious to see what they would gain. And as if merging two streams would be that easy. >> > > So interestingly, all these peope never had *any* interest in > cooperating on anything. > > Etoys ignored 3.9 *completely*. (and all my activity to merge etoys > back before that was always done not with that much enthusiasm from > their side. I got some bit of help from Bert and Michael, but the > activity always came from my side). > > Andreas disapeared for years (just to pee on us for a good laugh > on and off). > > So I really wonder why they all changed their mind suddenly. > Seriously. > > Marcus

March 4, 2009

Re: [Pharo-project] Preference refactoring again

by StÃ©phane Ducasse

>> I was just suggesting it; it seems that once you implement > enough to have generic boolean, string, or enumerable > preferences, you basically have a watered-down magritte anyway. > And who's to say we won't want a generic timezone, email > address, or url preference in the future? Magritte can do those > without having to rewrite string parsing/verification into every > class. indeed. But I do not see how the magritte description** pattern would work for preferences.

March 4, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

TX tx tx! Stef >>>> Hi Stef, > > I gave a look at Micheal fix, and have integrated it into > KomHttpServer-gc.45.mcz available in the main KomHttpServer > repository ( http://www.squeaksource.com/KomHttpServer/ ). Still > need to be tested though. > > Giovanni >

March 4, 2009

Re: [Pharo-project] Fwd: On the OTDebugger...

by Damien Cassou

Ok On Wed, Mar 4, 2009 at 10:34 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Ok for me. > > Cheers, > Alexandre > > > On 4 Mar 2009, at 10:30, StÃ©phane Ducasse wrote: > >> So we should proceed that way: >> Â Â Â - Put a big warning + the expression to switch debugger in the pharo- >> dev >> Â Â Â - then we follow what dale is saying >> Â Â Â Â Â Â Â - I will produce a list of important features we need to have >> Â Â Â Â Â Â Â Â Â Â Â -- copy stack >> Â Â Â Â Â Â Â Â Â Â Â -- chase pointer >> Â Â Â Â Â Â Â Â Â Â Â ... in OT >> >> Is is ok for your community? >> >> Stef >> >> >> Begin forwarded message: >> >>> From: Dale Henrichs <dale.henrichs(a)gemstone.com> >>> Date: March 3, 2009 6:57:36 PM CEST >>> To: stephane.ducasse(a)inria.fr >>> Subject: On the OTDebugger... >>> Reply-To: dale.henrichs(a)gemstone.com >>> >>> Steph, >>> >>> This note isn't about your 'disable OB-debugger for now message', >>> but it is a response, of sorts to the ensuing discussion. >>> >>> If you want a '120% debugger' then folks working on Pharo need to >>> use the debugger and eat their own dogfood. It's the only way to >>> ensure that a tool like the debugger gets enough coverage to ensure >>> that it is stable. With that said, I wouldn't want to commit to >>> using a tool that was broken or that I couldn't depend upon. >>> >>> With that in mind, I am willing to commit to the following things: >>> >>> 1. fix any bugs or implement any features that are deemed as show >>> stoppers with the current OTDebugger - i.e., the things that are >>> preventing folks from getting work done today. >>> >>> 2. I also promise a quick response to any show stopper bugs that >>> folks come across while doing development with the OTDebugger (or >>> any other of the OB-Tools). >>> >>> I came to maintain the OB-Tools through the 'back door'. I use a >>> branch the OB-Tools in GLASS and have decided to maintain the OB- >>> Tools for the Squeak/Pharo community as a way to contribute back to >>> the community. What that means specifically is that next to Lukas, I >>> probably know more about the OB-Tools than anyone else, however, I >>> don't have a laundry list of features that need to be added to the >>> debugger. >>> >>> I could go through the Squeak debugger and duplicate all of the >>> 'missing features', but my personal sense is that some of those >>> features aren't useful - I know that I have not even read all of the >>> menu items in the old Squeak debugger, let alone tried to figure out >>> what they do... >>> >>> Getting a list of important/missing features from a small group is >>> important to me (at least at the start). I don't have a personal >>> sense of "what's missing" from the current OTDebugger, since I have >>> not used the old Squeak debugger extensively. So getting feedback >>> from "old hands" is important, but I also know that I won't be able >>> to respond correctly to a general query for "what's missing from the >>> debugger?" >>> >>> For direction towards the "120% debugger", I think it makes sense >>> that you and rest of the Pharo leadership team make a list of >>> "debugger franchise features" - i.e., a list of features that are a >>> must have for the Pharo debugger and the other OB-Tools as well >>> (BTW, if that list is to "duplicate all of the 'missing features'" >>> then that's fine and I'm willing to do it). >>> >>> The debugger along with browsers are the face of the development >>> environment and I don't want to bloat the debugger without at least >>> a second opinion and I trust the opinions of you and the rest of the >>> Pharo leadership team. >>> >>> Thanks, >>> >>> Dale >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

March 4, 2009

[Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by CÃ©drick BÃ©ler

As some of us are unregistered, I thought it could be of interest ;) ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example): showProcesses Â Â Â Â "Indicates whether to show each process separately or cumulatively." Â Â Â Â <preference: 'Show Processes in MessageTally' Â Â Â Â Â Â Â Â category: 'debug' Â Â Â Â Â Â Â Â balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally' Â Â Â Â Â Â Â Â type: #Boolean> Â Â Â Â ^ShowProcesses showProcesses: aBool Â Â Â Â "Indicates whether to show each process separately or cumulatively." Â Â Â Â ShowProcesses := aBool. and then register the preference in the class initialization method via: initialize Â Â Â Â "MessageTally initialize" Â Â Â Â "By default, show each process separately" Â Â Â Â ShowProcesses := true. Â Â Â Â "Register preferences" Â Â Â Â Preferences addPreferencesFor: self. The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use. To install, just execute the following from Squeak 3.10.2: Â Installer mantis fixBug: 7306. Enjoy! Â - Andreas -- CÃ©drick

March 4, 2009

Re: [Pharo-project] New Compiler

by StÃ©phane Ducasse

I would love to have one compilerContext object so that we do not have to pass all these parameters plague It would be nice to have compile: 'text' context: (aCompilerContext) aCompilerContext in: aClass ; silently: true ; inCategory: 'zork' But this is something we should do after :) On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote: > Hi Jorge, > > great to hear. I have two things that I wish you add to your list: > > 1. My first wish also affects the old compiler, but that should be > easy to fix in Pharo. Currently there are dozens of selectors in > Behavior that hardcode the currently used compiler #parseClass, > #compilerClass, #evaluatorClass, #decompilerClass, > #subclassDefinerClass, ... I would prefer to have exactly one entry > point, for example under the name #compiler. This object could act > like a compiler MOP on the receiving class and set through a > preference for all classes of the system that do not override this > method themselves. This would make it much cleaner to have different > compilers in the image, swap them on the fly, get rid of various hacks > and overrides and even allow to unload the old compiler. > > 2. My second wish is only about the new compiler. One thing stroke me > when working on transactional memory and domain specific languages, is > that the new compiler isn't as extensible as it advertises. The > problem is there is no central place where the different phases > (parsing, annotation, bytecode generation) of the compilation is > triggered. Currently this happens at various places throughout the > system. This has not only the problem that extending the compiler is > difficult without patching it, but also makes it nearly impossible to > get certain information at a particular place of the process. For > example, during parsing it is not know in what class the method is > supposed to be compiled, or during bytecode generation I don't know > the source code anymore, etc. I suggest to introduce a compilation > context, that is accessible anywhere and that can pass necessary > information through the compilation phases. Furthermore I suggest to > implement the delegation to the different parts of the compiler in a > deticated object that can be subclassed and used for example if > somebody wants to cleanly replace, customize or extend certain parts > of the compiler. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] New Compiler

by Lukas Renggli

Hi Jorge, great to hear. I have two things that I wish you add to your list: 1. My first wish also affects the old compiler, but that should be easy to fix in Pharo. Currently there are dozens of selectors in Behavior that hardcode the currently used compiler #parseClass, #compilerClass, #evaluatorClass, #decompilerClass, #subclassDefinerClass, ... I would prefer to have exactly one entry point, for example under the name #compiler. This object could act like a compiler MOP on the receiving class and set through a preference for all classes of the system that do not override this method themselves. This would make it much cleaner to have different compilers in the image, swap them on the fly, get rid of various hacks and overrides and even allow to unload the old compiler. 2. My second wish is only about the new compiler. One thing stroke me when working on transactional memory and domain specific languages, is that the new compiler isn't as extensible as it advertises. The problem is there is no central place where the different phases (parsing, annotation, bytecode generation) of the compilation is triggered. Currently this happens at various places throughout the system. This has not only the problem that extending the compiler is difficult without patching it, but also makes it nearly impossible to get certain information at a particular place of the process. For example, during parsing it is not know in what class the method is supposed to be compiled, or during bytecode generation I don't know the source code anymore, etc. I suggest to introduce a compilation context, that is accessible anywhere and that can pass necessary information through the compilation phases. Furthermore I suggest to implement the delegation to the different parts of the compiler in a deticated object that can be subclassed and used for example if somebody wants to cleanly replace, customize or extend certain parts of the compiler. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2009