March 2009 - Pharo-dev - lists.pharo.org

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

by CÃ©drick BÃ©ler

2009/3/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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. no problems, I can do that ;) you see that's exactly why I find Pharo forks as the right decision... First, it frees you (and this is huge)... Second people indirectly accepts/pick ideas/participate to what's discussed... :) So now, in a certain way, we have "le beurre et l'argent du beurre" ;) Cheers > > 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 >> > > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

tx perl hacker :) Stef ] On Mar 4, 2009, at 2:56 PM, CÃ©drick BÃ©ler wrote: > 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 > > _______________________________________________ > 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 Schwab,Wilhelm K

Stef, I agree that it is time to politely and unapologetically stick to the job of making Pharo a lean fast open Smalltalk with a robust IDE. I too think that Pharo is very upsetting to some people - it is turning into a success. You are wise to give others credit for wanting to collaborate, but finishing the cleaning seems the best approach. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, March 04, 2009 8:26 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you 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 _______________________________________________ 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 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