January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Schwab,Wilhelm K

One should always be *able* to unsubscribe, but it should not be required. Squeak's weak collections do not measure up to the competition. Please take a look at my 1/2/2010 post "RE: [Pharo-project] Can't debug in 1.1". I doubt SharedLookupTable could be called efficient, but it solved some problems I was having due to the current implementation. I welcome concrete examples of how horrible it is, and offer it up as a starting point or simple inspiration for something more useful. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Thursday, January 07, 2010 6:57 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus On 07.01.2010 14:50, Schwab,Wilhelm K wrote: > Gary, > > If announcements are at all what I am expecting (perhaps a non-trivial assumption??), then I doubt it will be a problem. One would observe the world/window-manager for open events, and then express interest in events from individual windows. That might turn out to be easier on consumers than getting everything from one source. Cleanup should be trivial if the announcement framework uses weak references. > > Bill > The Pharo implementation does not include weak announcement subscriptions, you have to manually unsubscribe if you need to. This can be solved in VisualWorks without keeping a list of whom you are subscribed to, by using the fact that the block in subscribe:do: can take 2 args instead of one, in which case the second argument is the announcer. If this were the case in the Pharo/Squeak implementation, the Global WindowOpened/Local InterestingWindowEvents could be written: (receiveAnnouncements to true in initialize, false in release) SystemWindow openAnnouncer subscribe: WindowOpened do: [:ann : | ann window satisfiesMyCriteria ifTrue: [ ann window subscribe: InterestingWindowEvent do: [:ann :announcer | receiveAnnouncements ifTrue: [self handleInterestingEvent: ann] ifFalse: [announcer unsubscribe: self]] Not very pretty, but still better than the alternative if you know the dynamic announcer is likely to outlive the consumer. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

Re: [Pharo-project] Finalization quirk

by John M McIntosh

> initializeMemorySettingsProfileSeaSide is in the pharo image also initializeMemorySettingsProfileQF which I have no idea about... On 2010-01-07, at 2:12 AM, Adrian Lienhard wrote: > > On Jan 6, 2010, at 22:09 , John M McIntosh wrote: > >> Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. >> This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC. >> >> SystemDictionary>>setGCParameters >> >> Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. >> Smalltalk setGCBiasToGrow: 1. >> >> Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. >> (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost >> of deferring some finalized objects.... >> >> Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, >> those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide >> someone picked more rational numbers but I think it's time that we clean those up this whole area. > > Where can I find #initializeMemorySettingsProfileSeaSide? Could you propose new parameters for these settings? It's time to adjust them for the new decade ;) > > Cheers, > Adrian > > > [...] -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 8, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Mariano Martinez Peck

This is getting cool: Interdim build server, Hudson integration, Metacello, Loader, new Sunit extension and refactorm etc ......excellent !!! On Fri, Jan 8, 2010 at 12:51 AM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > haha, I see that Esteban has gone much farther towards creating a set of > tools that go way beyond the simple loading of a configuration ... > > Dale > > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: > > | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: > | > | | A minor comment: > | | > | | > Gofer new > | | > squeaksource: 'MetacelloRepository'; > | | > package: 'ConfigurationOfPharo'; > | | > load. > | | > > | | > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0- > | | > rc2.10505') load. > | | > | | > | | I find this incantation quite ugly. > | > | Alexandre, > | > | How about something like the following expressions: > | > | Gofer loadConfiguration: 'Pharo' version: '1.0-rc2.10505'. > | Gofer loadConfiguration: 'NewInspector'. > | Gofer loadConfiguration: 'Magritte' load: #( 'Magritte-Model' > | 'Magritte-Tests' ). > | Gofer loadConfiguration: 'OmniBrowser' version: '1.0' load: 'Core'. > | > | I whipped together some extension methods for Gofer that adds support > | for the above to Gofer: > | > | Gofer new > | gemsource: 'metacello'; > | package: 'Metacello-Gofer-Extensions'; > | load. > | > | If there is no leading ConfigurationOf in the configuration name, > | 'ConfigurationOf' is tacked on. If no version is specified (or is nil) > | the latest version of the configuration is loaded. If no explicit load > | list is supplied (or is nil), then the default load list is loaded. In > | all cases it is expected that the configuration will be found in the > | MetacelloRepository on SqueakSource... > | > | Dale > | > | _______________________________________________ > | 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 >

Jan. 7, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Henrik Sperre Johansen

On 07.01.2010 14:50, Schwab,Wilhelm K wrote: > Gary, > > If announcements are at all what I am expecting (perhaps a non-trivial assumption??), then I doubt it will be a problem. One would observe the world/window-manager for open events, and then express interest in events from individual windows. That might turn out to be easier on consumers than getting everything from one source. Cleanup should be trivial if the announcement framework uses weak references. > > Bill > The Pharo implementation does not include weak announcement subscriptions, you have to manually unsubscribe if you need to. This can be solved in VisualWorks without keeping a list of whom you are subscribed to, by using the fact that the block in subscribe:do: can take 2 args instead of one, in which case the second argument is the announcer. If this were the case in the Pharo/Squeak implementation, the Global WindowOpened/Local InterestingWindowEvents could be written: (receiveAnnouncements to true in initialize, false in release) SystemWindow openAnnouncer subscribe: WindowOpened do: [:ann : | ann window satisfiesMyCriteria ifTrue: [ ann window subscribe: InterestingWindowEvent do: [:ann :announcer | receiveAnnouncements ifTrue: [self handleInterestingEvent: ann] ifFalse: [announcer unsubscribe: self]] Not very pretty, but still better than the alternative if you know the dynamic announcer is likely to outlive the consumer. Cheers, Henry

Jan. 7, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Dale Henrichs

haha, I see that Esteban has gone much farther towards creating a set of tools that go way beyond the simple loading of a configuration ... Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | | | A minor comment: | | | | > Gofer new | | > squeaksource: 'MetacelloRepository'; | | > package: 'ConfigurationOfPharo'; | | > load. | | > | | > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0- | | > rc2.10505') load. | | | | | | I find this incantation quite ugly. | | Alexandre, | | How about something like the following expressions: | | Gofer loadConfiguration: 'Pharo' version: '1.0-rc2.10505'. | Gofer loadConfiguration: 'NewInspector'. | Gofer loadConfiguration: 'Magritte' load: #( 'Magritte-Model' | 'Magritte-Tests' ). | Gofer loadConfiguration: 'OmniBrowser' version: '1.0' load: 'Core'. | | I whipped together some extension methods for Gofer that adds support | for the above to Gofer: | | Gofer new | gemsource: 'metacello'; | package: 'Metacello-Gofer-Extensions'; | load. | | If there is no leading ConfigurationOf in the configuration name, | 'ConfigurationOf' is tacked on. If no version is specified (or is nil) | the latest version of the configuration is loaded. If no explicit load | list is supplied (or is nil), then the default load list is loaded. In | all cases it is expected that the configuration will be found in the | MetacelloRepository on SqueakSource... | | Dale | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Dale Henrichs

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | A minor comment: | | > Gofer new | > squeaksource: 'MetacelloRepository'; | > package: 'ConfigurationOfPharo'; | > load. | > | > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0- | > rc2.10505') load. | | | I find this incantation quite ugly. Alexandre, How about something like the following expressions: Gofer loadConfiguration: 'Pharo' version: '1.0-rc2.10505'. Gofer loadConfiguration: 'NewInspector'. Gofer loadConfiguration: 'Magritte' load: #( 'Magritte-Model' 'Magritte-Tests' ). Gofer loadConfiguration: 'OmniBrowser' version: '1.0' load: 'Core'. I whipped together some extension methods for Gofer that adds support for the above to Gofer: Gofer new gemsource: 'metacello'; package: 'Metacello-Gofer-Extensions'; load. If there is no leading ConfigurationOf in the configuration name, 'ConfigurationOf' is tacked on. If no version is specified (or is nil) the latest version of the configuration is loaded. If no explicit load list is supplied (or is nil), then the default load list is loaded. In all cases it is expected that the configuration will be found in the MetacelloRepository on SqueakSource... Dale

Jan. 7, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Esteban Lorenzano

>> > Yes, I agree. But don't worry. Esteban Lorenzano is working exatly in that. > You will be able to do: > > Loader load: 'Pharo' version: '1.0' and wala!! > > (Esteban, correct me if I am wrong). > > However, this is yet in development and we are not even sure if this > architecture will be the choosen one. We are just trying to see what we can > doo. yep, that's true. Currently I'm alpha-testing it and writing some tests and documentation, but now you can do things like: Loader new list. "Lists all available projects, scanning all repositories" Loader new search: 'Blah'. "Looks for project Blah scanning all repositories. 'Blah' can be a segment, not just a full name" Loader new load: 'Blah'. "Load latest usable version of ConfigurationOfBlah." Loader new load: 'Blah' version: '1.0'. "Load '1.0' version of ConfigurationOfBlah." Loader new managed. "Answers a list of current managed projects." Loader new update. "Updates configurations for all managed projects." Loader new update: 'Blah'. "Updates ConfigurationOfBlah." Loader new upgrade. "Upgrades all managed project to a newest version (if present)". Loader new upgrade: 'Blah'. "Upgrades project 'Blah' to a newest version (if present)". You can specify permanent repositories by executing: Loader repository: 'http://myownrepo/project'. Loader repository: 'http://myownrepo/project' username: 'myself' password: 'secret'. (this acts as adding universes to apt-get of debian) And you can use "temporal" repositories: Loader new repository: 'http://myownrepo/project'; load: 'Blah'. This repostories are dropped after use it, but any managed project keeps it for future managing. I hope this will solve all the loading issues. In the future, you could do just: Loader new load: 'Pharo'. and get a full PharoDev image :) Cheers, Esteban

Jan. 7, 2010

Re: [Pharo-project] [update] #10505

by Mariano Martinez Peck

Yes, sorry. I am VERY stupid...I put bloq mayus without wanting hahaha and I didn't realize. It works well now :) On Thu, Jan 7, 2010 at 9:17 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Did you restart? It works for me on OS X (and other OS should not be > affected anyway). > > Adrian > > On Jan 6, 2010, at 23:31 , Mariano Martinez Peck wrote: > > > On Wed, Jan 6, 2010 at 11:29 PM, Mariano Martinez Peck < > > marianopeck(a)gmail.com> wrote: > > > >> > >> > >> On Wed, Jan 6, 2010 at 10:21 PM, Adrian Lienhard <adi(a)netstyle.ch> > >> wrote: > >> > >>> This update "fixes" the double paste bug by unloading the system > >>> host > >>> menu support. Please note, that the image needs to be restarted to > >>> take effect. > >>> > >>> 10505 > >>> ----- > >>> Issue 1323: Input problems (resolved for 1.0 by unloading > >>> System Host > >>> Menus) > >>> > >> > >> > >> Sorry for my ignorance, but is it common I cannot copy and past > >> using cmd > >> + c and cmd +d ?? I have to use ctrl instead of cmd. Is this > >> expected? > >> > >> > > > > The weird thing is that the other shortcuts like cmd + p cmd + > > i ...they > > are working. > > > > > >> Issue 1604: The disabled buttons look ugly with the new strike > >> fonts > >>> (thanks, Gary) > >>> Issue 1415: New version VBRegex (fix splitjoin) > >>> > >>> ___________________ > >>> http://www.adrian-lienhard.ch/ > >>> > >>> _______________________________________________ > >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010

Re: [Pharo-project] Pharo testers.... WE NEED YOU!!!

by Mariano Martinez Peck

Ok...I will put a prefix in the subject called "[BetaTesting]". If you use a descent email client you will b able to create a filter with that. So, if I send an email to Pharo mailing list and that label, is enough ? On Thu, Jan 7, 2010 at 10:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > +1 > On Jan 7, 2010, at 10:14 PM, Michael Roberts wrote: > > > one of the goals is for Pharo communication to be open so I would say > > -1 on a private list. +1 on some tag convention > > > > Mike > > > > 2010/1/7 Benoit St-Jean <bstjean(a)yahoo.com>: > >> A mailing for me please... Besides, that way we wouldn't have to deal > with > >> the "everybody jumps in the conversation" if the list is private to > testers > >> only... > >> > >> ----------------- > >> Benoit St-Jean > >> Yahoo! Messenger: bstjean > >> Blog: lamneth.wordpress.com > >> A standpoint is an intellectual horizon of radius zero. > >> (Albert Einstein) > >> > >> ________________________________ > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Sent: Thu, January 7, 2010 4:02:30 PM > >> Subject: Re: [Pharo-project] Pharo testers.... WE NEED YOU!!! > >> > >> Do you think we need a mailing list ? Or just copying each person is > enough > >> ? > >> > >> I am active in mailing list, but maybe some of you don't. Please let me > know > >> what do you prefer as I -almost- have done my first dev image based in > 10505 > >> and metacello configurations :) > >> > >> Cheers > >> > >> > >> On Sat, Jan 2, 2010 at 2:39 PM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >>> > >>> Cool....we are already 13 beta testers :) More than enought :) > >>> > >>> I updated http://code.google.com/p/pharo/w/list > >>> > >>> And we almost cover all the conbinations of OS, Browser and type of > image > >>> :) > >>> > >>> Cheers > >>> > >>> Mariano > >>> > >>> On Sat, Jan 2, 2010 at 2:30 PM, Mariano Martinez Peck > >>> <marianopeck(a)gmail.com> wrote: > >>>> > >>>> > >>>> On Sat, Jan 2, 2010 at 1:50 AM, HernÃ¡n Morales Durand > >>>> <hernan.morales(a)gmail.com> wrote: > >>>>> > >>>>> Hi Mariano, > >>>>> I don't use dev or web images. I've found the PharoCore more stable, > >>>>> for example now I'm fixing a dependency browser bug in the dev image > >>>>> #10502 (trying a dev after a long time), and clicking with the right > >>>>> button gives me : > >>>>> > >>>>> MessageNotUnderstood: OBTextSelection>>isMethodNode > >>>>> > >>>> > >>>> Yes, this is issue: > http://code.google.com/p/pharo/issues/detail?id=1182 > >>>> > >>>>> > >>>>> but isn't just that bug, I've never worked 30 minutes with the > dev/web > >>>>> images without interaction bugs. I wonder what happens with Smalltalk > >>>>> and Pharo newcomers when these bugs appears, but there's no survey > >>>>> system for Pharo users so no one can't figure out anyway. Well, > >>>>> fortunately there are no too many public word of mouth recommendation > >>>>> systems yet :) > >>>> > >>>> > >>>> HernÃ¡n: I agreee 100%. All of what you describe is what I said in the > >>>> email with subject "We need to do something, seriously, ..." > >>>> > >>>> And that's exactly what I proposed to do this stuff about the beta > >>>> testers. > >>>> > >>>> Cheers > >>>> > >>>> Mariano > >>>> > >>>>> > >>>>> Cheers, > >>>>> > >>>>> HernÃ¡n > >>>>> > >>>>> 2010/1/1 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>>>>> Sorry, I realize something. Maybe it would be cool also if you tell > us > >>>>>> if > >>>>>> you use web or dev. I happens also several times that the seaside > >>>>>> installation, or pier or whatever are not working very well. So...it > >>>>>> would > >>>>>> be cool to have both testers :) > >>>>>> > >>>>>> If you have access to the wiki, just add your self on it. If you > don't > >>>>>> have > >>>>>> access ask to Adrian and he will give you. Finally you can put it > here > >>>>>> and > >>>>>> then I put it in the wiki. > >>>>>> > >>>>>> Cheers! > >>>>>> > >>>>>> Mariano > >>>>>> > >>>>>> On Fri, Jan 1, 2010 at 10:56 PM, Mariano Martinez Peck > >>>>>> <marianopeck(a)gmail.com> wrote: > >>>>>>> > >>>>>>> Ok.....I collect all the information here: > >>>>>>> > >>>>>>> http://code.google.com/p/pharo/wiki/ListOfBetaTesters > >>>>>>> > >>>>>>> Feel free to add something else. > >>>>>>> > >>>>>>> The only thing we need now is Damien's answer...maybe he is in > >>>>>>> holidays, I > >>>>>>> don't know. > >>>>>>> > >>>>>>> The last thing I would like to propose is that when we have a new > >>>>>>> image to > >>>>>>> test, not only we send the email to the mailing list but also cc to > >>>>>>> each of > >>>>>>> us. There is a lot of traffic (fortunately!!) in Pharo mailing list > >>>>>>> and not > >>>>>>> all the people here keeps truck for it every day. So, I think > having > >>>>>>> them in > >>>>>>> cc is a good idea. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> M > >>>>>>> > >>>>>>> On Fri, Jan 1, 2010 at 12:41 AM, Miguel CobÃ¡ < > miguel.coba(a)gmail.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>>> So...here is the list, if you offer yourself, it would be cool to > >>>>>>>>> know: > >>>>>>>>> OS, > >>>>>>>>> VM version, Dev or Web, browser you usually work, 32 o 64 bits, > >>>>>>>>> I will then collect this and I will put it in the wiki. > >>>>>>>>> > >>>>>>>>> - Mariano Martinez Peck. Mac OS, Squeak 4.2.2beta1U.app, Dev, > >>>>>>>>> OB, 32 > >>>>>>>>> bits > >>>>>>>>> - Stan Shepherd > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> WHO ELSE IS IN THE LIST ?? > >>>>>>>> > >>>>>>>> Me too. > >>>>>>>> > >>>>>>>> - Miguel CobÃ¡, Debian GNU/Linux Squeeze (testing), Pharo0.1 of 16 > >>>>>>>> May > >>>>>>>> 2008 [latest update: #10074], Web, OB, 32 bits > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> cheers and happy new year!! > >>>>>>>>> > >>>>>>>> > >>>>>>>> Feliz aÃ±o tambiÃ©n Mariano. > >>>>>>>> > >>>>>>>> Miguel CobÃ¡ > >>>>>>>> http://miguel.leugim.com.mx > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> ________________________________ > >> Reclaim your name @ymail.com or @rocketmail.com. Get your new email > address > >> now! > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010

Re: [Pharo-project] Interim build server update

by Mariano Martinez Peck

On Thu, Jan 7, 2010 at 11:36 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > a simple test report for PharoCore 1.1 is now automatically published at > > http://pharo.gforge.inria.fr/experimental/ > > what do you think? > That's really cool!!! I cannot image what good this will be together with Hudson!!! I am agree with the OS. Some tests use to be ok for one platform but not in another one (I don't remember right now). Even more, I would print the VM also. Maybe you can put all that information that it is put at the beginning of the PharoDebug.log. I remember there was a way to get that information....but I don't remember how hahaha. EXCELLENT! Cheers Mariano > > I would propose to remove the google wiki test entries (for 1.1) and > point them here. > > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2010