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

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

2009/10/27 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/27 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/10/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> so what is the fix? >>> I would really like to get announcement instead of event >>> systemNotification but I'm sure that this >>> can be a bit tricky. >>> >> >> Yes, tricky :) >> Here what i have in mind: >> >> Any change to system should be captured _before_ it applied. >> This allows us to introduce a policy which can validate the change and decide >> whether it allowed to be made or not. >> >> I made the SystemChangeEvent class, which having following state: >> Â - changeKind - a symbol, which identifies the change > > Hi Igor, > IMHO, nowadays, the trend would be to create subclasses rather than > internal symbols... > Shouldn't there be a symmetry with the hierarchy of changes in > DeltaStream (for example) ? > Well, my own 'trend' is to use GLOBALS as little as possible. So instead of spawning a whole tree of different event types, and then spit them around in different places, i prefer to use messages instead. I am using a single #newSystemEvent: message to create an instance of system event. So, there will be only a few places, where #SystemChangeEvent global be referenced, and therefore you can refactor the whole thing by changing few places. I don't plan to put into the SystemChangeEvent any kind of clever code. It just a state holder, notthing more. And handlers usually do a simple dispatch to handle the event. Moreover, i won't be using numerous #isXXXXX stinky tests, which is just a code bloat and don't really helpful unless you writing plainly wrong code ( remember? "don't ask - tell" ) :) For instance, i tried to track all listeners of particular SystemNotification event, and had hard times to find them out, because its dispatching scheme generates the selector consisting from 3 parts: itemKind, changeKind, 'Event:' (see implementation of #eventSelector) but when i staring at code which creates a notification, i don't see these selectors, and to figure out, that is the actual method is used to handle given notification i need to go exploring the internals of dozens of AbstractEvent subclasses. In contrast, if i would want to find out all handlers of particular SystemChangeEvent , i would need only to see implementors of changeKind selector (such as #changeSelectorCategory) , which is right before my eyes, in the code which emits the system change event. But i want to hear your counterarguments, why bunch of subclasses is more appropriate. Symmetry with DeltaStreams: no symmetry. The difference is that deltas capturing 'before' and 'after' state. While for SystemChangeEvent, there is no 'after' happened yet. It should carry the only state which is enough to analyze & perform the change. And its not necessary that this state will consist of simple objects (strings, symbols etc), simply for speed & efficiency purposes - i could pass the CompiledMethod instance instead of the source of method, behavior object, instead of a class name and 'isMeta' boolean, and so on. Moreover, it is not necessary that change will be applied at all. The users of SystemChangeEvent operating directly with system data model, therefore you don't need to translate everything to simplest forms, as deltastreams doing, because these events living & dying inside the system and have little use for outside. Of course, the arbiter object, which i mentioned before could easily capture all 'before' and 'after' state, and then broadcast this to all subscribers. And of course its free to translate the event into more edigible form. > Nicolas > >> Â - parameters - a dictionary , which holding different parameters, >> important for change >> Â - subject - the object which is going to be changed (or taking a main >> role in change) >> Â - action - a block closure which , if evaluated, will apply the >> change to system >> >> For example, here the method which creates & populates the system change event: >> >> classify: element under: heading suppressIfDefault: aBoolean >> >> Â Â Â Â (self subject newSystemEvent: #changeSelectorCategory) >> Â Â Â Â Â Â Â Â subject: element; >> Â Â Â Â Â Â Â Â param: #behavior->self subject; >> Â Â Â Â Â Â Â Â param: #category->heading asSymbol; >> Â Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; >> Â Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: >> aBoolean ]; >> Â Â Â Â Â Â Â Â signal. >> --------- >> >> The event handling procedure is following: >> >> - first of all, an event passed to a system arbiter object >> - a system arbiter checking with the policy >> - if everything ok, change is applied by evaluating action. >> - and finally, change is announced to any interesting parties >> >> I want to make each package to hold own policy (a set of flags >> identified by name, to ease fileout). >> Then, any event could be validated by policy by issuing: >> Â package policy validate: change >> >> For example, lets see , what validations we could introduce for method >> recategorization event. >> >> Â - lets take most interesting case, when we want to recategorize the >> method in ClassA, which belongs to PackageA, >> Â and putting it into extension category, like *PackageB >> >> Â - check, if we allow any changes to ClassA (policy of PackageA) >> Â - check if PackageA allows method extensions (policy of PackageA) >> Â - check if PackageB allows extending the classes of another packages >> (policy of PackageB) >> Â - check if extension overrides existing method >> Â - and of course, we should check that given extension does not >> creates a circular dependency between the packages. >> >> There, of course, some problems which arising. >> - changes nesting. >> Â Some changes is complex ones, and even a simple method >> recategorization could lead to another event - creating a new >> Â category in class. Â Optimally, it would be cool to have only most >> basic events, which can't be nested. And any action which may lead to >> multiple changes, should be split on a number of basic ones. >> A SystemChangeNotifier solving this by allowing doing things silently: >> Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. >> so, any changes within the block , if any, won't be announced. >> >> - atomicity support. To support the bulk model updating, i can imagine >> the framework, which capturing any changes without applying them, by >> building/collecting all changes in parallel, and then applying them by >> a single mass-become. This is what SystemEditor does. >> >> - metaprogramming. There should be a means to leave a room for >> metaprogramming. We wouldn't want to signal a system change for >> anonymous classes, and many other things, which can be tricky here. >> >> P.S. as you can see , the plans is quite bold, and will require >> numerous refactorings :) So, the more people is interested in that, >> the better. >> >>> Stef >>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 27, 2009

[Pharo-project] SeasideTesting

by Norbert Hartl

Hi, is there a SeasideTesting that is working in pharo? Norbert

Oct. 27, 2009

Re: [Pharo-project] Preferences refactoring pushed

by Alain Plantec

Igor Stasenko wrote: > the 'message pane missin' spam in transcript is really annoying :) > Issue 1378 <http://code.google.com/p/pharo/issues/detail?id=1378>: annoying MC Transcript log "Warning: pane summary not found" Fixed Cheers Alain

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Tudor Girba

The GForge maintenance was announced in a forward by Stef on Oct 23 :). Doru On 27 Oct 2009, at 10:07, Michael Roberts wrote: > Probably. Where are they announced? Can they be posted here? > > Cheers mike > > On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> > wrote: >> Wasn't this problem due to the announced maintenance of GForge for >> Monday 26th October 2009, from 18:30 to 22:00? >> >> Doru >> >> On 27 Oct 2009, at 08:57, Michael Roberts wrote: >> >>> yes it's working now. thanks >>> Mike >>> >>> On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> apparently the forge was down yesterday evening. >>>> Not sure that this is available now. >>>> >>>> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >>>> >>>>> i'm getting timeouts from the update server. can someone confirm? >>>>> >>>>> thanks, >>>>> Mike >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> -- >> www.tudorgirba.com >> >> "Problem solving should be concentrated on describing >> the problem in a way that is relevant for the solution." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "We are all great at making mistakes."

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Michael Roberts

Probably. Where are they announced? Can they be posted here? Cheers mike On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Wasn't this problem due to the announced maintenance of GForge for > Monday 26th October 2009, from 18:30 to 22:00? > > Doru > > On 27 Oct 2009, at 08:57, Michael Roberts wrote: > >> yes it's working now. thanks >> Mike >> >> On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> apparently the forge was down yesterday evening. >>> Not sure that this is available now. >>> >>> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >>> >>>> i'm getting timeouts from the update server. can someone confirm? >>>> >>>> thanks, >>>> Mike >>>> >>>> _______________________________________________ >>>> 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 > > -- > www.tudorgirba.com > > "Problem solving should be concentrated on describing > the problem in a way that is relevant for the solution." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2009

[Pharo-project] update server down?

by Torsten Bergmann

>Wasn't this problem due to the announced maintenance of GForge for >Monday 26th October 2009, from 18:30 to 22:00? or related to a squeaksource server reset: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140479.… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Tudor Girba

Wasn't this problem due to the announced maintenance of GForge for Monday 26th October 2009, from 18:30 to 22:00? Doru On 27 Oct 2009, at 08:57, Michael Roberts wrote: > yes it's working now. thanks > Mike > > On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> apparently the forge was down yesterday evening. >> Not sure that this is available now. >> >> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >> >>> i'm getting timeouts from the update server. can someone confirm? >>> >>> thanks, >>> Mike >>> >>> _______________________________________________ >>> 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 -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

Oct. 27, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Nicolas Cellier

2009/10/27 Igor Stasenko <siguctua(a)gmail.com>: > 2009/10/26 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> so what is the fix? >> I would really like to get announcement instead of event >> systemNotification but I'm sure that this >> can be a bit tricky. >> > > Yes, tricky :) > Here what i have in mind: > > Any change to system should be captured _before_ it applied. > This allows us to introduce a policy which can validate the change and decide > whether it allowed to be made or not. > > I made the SystemChangeEvent class, which having following state: > Â - changeKind - a symbol, which identifies the change Hi Igor, IMHO, nowadays, the trend would be to create subclasses rather than internal symbols... Shouldn't there be a symmetry with the hierarchy of changes in DeltaStream (for example) ? Nicolas > Â - parameters - a dictionary , which holding different parameters, > important for change > Â - subject - the object which is going to be changed (or taking a main > role in change) > Â - action - a block closure which , if evaluated, will apply the > change to system > > For example, here the method which creates & populates the system change event: > > classify: element under: heading suppressIfDefault: aBoolean > > Â Â Â Â (self subject newSystemEvent: #changeSelectorCategory) > Â Â Â Â Â Â Â Â subject: element; > Â Â Â Â Â Â Â Â param: #behavior->self subject; > Â Â Â Â Â Â Â Â param: #category->heading asSymbol; > Â Â Â Â Â Â Â Â param: #suppressIfDefault->aBoolean; > Â Â Â Â Â Â Â Â action: [ super classify: element under: heading suppressIfDefault: > aBoolean ]; > Â Â Â Â Â Â Â Â signal. > --------- > > The event handling procedure is following: > > - first of all, an event passed to a system arbiter object > - a system arbiter checking with the policy > - if everything ok, change is applied by evaluating action. > - and finally, change is announced to any interesting parties > > I want to make each package to hold own policy (a set of flags > identified by name, to ease fileout). > Then, any event could be validated by policy by issuing: > Â package policy validate: change > > For example, lets see , what validations we could introduce for method > recategorization event. > > Â - lets take most interesting case, when we want to recategorize the > method in ClassA, which belongs to PackageA, > Â and putting it into extension category, like *PackageB > > Â - check, if we allow any changes to ClassA (policy of PackageA) > Â - check if PackageA allows method extensions (policy of PackageA) > Â - check if PackageB allows extending the classes of another packages > (policy of PackageB) > Â - check if extension overrides existing method > Â - and of course, we should check that given extension does not > creates a circular dependency between the packages. > > There, of course, some problems which arising. > - changes nesting. > Â Some changes is complex ones, and even a simple method > recategorization could lead to another event - creating a new > Â category in class. Â Optimally, it would be cool to have only most > basic events, which can't be nested. And any action which may lead to > multiple changes, should be split on a number of basic ones. > A SystemChangeNotifier solving this by allowing doing things silently: > Â SystemChangeNotifier uniqueInstance doSilently: [ ... ]. > so, any changes within the block , if any, won't be announced. > > - atomicity support. To support the bulk model updating, i can imagine > the framework, which capturing any changes without applying them, by > building/collecting all changes in parallel, and then applying them by > a single mass-become. This is what SystemEditor does. > > - metaprogramming. There should be a means to leave a room for > metaprogramming. We wouldn't want to signal a system change for > anonymous classes, and many other things, which can be tricky here. > > P.S. as you can see , the plans is quite bold, and will require > numerous refactorings :) So, the more people is interested in that, > the better. > >> Stef >> > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Michael Roberts

yes it's working now. thanks Mike On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > apparently the forge was down yesterday evening. > Not sure that this is available now. > > On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: > >> i'm getting timeouts from the update server. can someone confirm? >> >> thanks, >> Mike >> >> _______________________________________________ >> 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 >

Oct. 27, 2009

Re: [Pharo-project] Thread-safe collections

by StÃ©phane Ducasse

On Oct 25, 2009, at 10:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It sounds like I am indeed missing something in saving slices. I > saw mention of it, but thought I read that it was not the preferred > method and didn't dig further. Are you saying that I can make one > big slice with all of my stuff and suddenly all becomes easy?? if you have a package and some dependents when you will save a comments will be propagated to all the dependents no need to repeat that. > On the load side, I was having problems over name mis-matches that > would not exist given a good packaging system. I could probably get > around them now by reifying the names in my load script. I suggest that you start also to look at metacello because dale is managing glass with it and doru moose/mondrian.... in the future we want to manage the release with it. Stef > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Sunday, October 25, 2009 2:59 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > > On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> With no disrespect to Sig's opinions, I'm glad to hear that. I very >> quickly cobbled together a class called SharedLookupTable, and have >> no >> problems making it (suitably debugged) available. >> >> Now it's time for me to kick your ass a little, to coin a phrase :) > > no problem > >> Monticello is pretty good at what it does, but I sense the things it >> does not do interfering with good decision making. The class ended >> up >> in my Dolphin compatibility package, in part because it belongs >> there, >> though it really should be separate so I can easily release it and >> people would be able to get it w/o having to accept other ideas they >> might not want. But it went in the compatiblity package so I would >> not have to mess around with another package. Saving them is a pain; >> loading them into a new image is a pain. > > why? > >> Saving: the interface works well once understood, and the features it >> offers should never go away. However, either by script or by >> multiple >> selection, it would be nice to provide a comment to be applied to >> everything to be saved "now" vs. having to be prompted for it, then >> have the list scroll, then have to click away another window. Do >> that >> 30 times and it starts to get old. > > this is strange because I thought that we fixed that pop up plague > when saving slices Then you get all the comments you already typed > in one of the button of the poped up window. Did you see it? > > >> Loading: I spent a chunk of yesterday trying to build an RC1 image. >> Doing so revealed that my script-loader for script-loader does not >> validate package names. I had one build attempt come to a halt over >> case-sensitivity; I do not mind that. What I mind is that the >> particular case mix in question was more or less forced on me by a >> typo of mine. If MC were better about offering choices when they >> apply, I might not have typed it that way. >> >> I realize that Gofer is coming, and it might fix a lot of this. > > yes > and also metacello which is coming along well > >> The ideas above are probably not new, but I list them just in case. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Friday, October 23, 2009 2:46 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Thread-safe collections >> >> I would really like to see some packages getting implementing around >> the idea of a couple of robust and well tested thread safe >> collections. >> >> Stef >> >> On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: >> >>> Sig, >>> >>> One can always construct examples in which protecting the entire >>> loop >>> is the better option. That's not the scenario of interest. >>> Just as shared queues are useful, shared sets and dictionaries have >>> value for sporadic access scenarios. Doing it your way, everyone >>> writes their own incompletely protected (read buggy/dangerous) ad- >>> hoc implementations of these common collections. >>> >>> I favor having solid implementations that are complete and as >>> correct >>> as we can get them, leaving people to optimize as you suggest when >>> it >>> makes sense to do so. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >>> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >>> Sent: Thursday, October 22, 2009 5:23 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Thread-safe collections >>> >>> 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>>> Hello all, >>>> >>>> I just looked around for thread-safe collections, and found nothing >>>> that looks like a shared dictionary. The squeak-dev archives >>>> contain the obligatory newbie posts (wanting all collections to be >>>> thread >>>> safe) and the expected replies, some of which are overly dismissive >>>> of the idea. Something that protects things like >>>> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >>>> existing implementation? >>>> >>> >>> Imo, there's only one shared collection which is useful - shared >>> queue. :) If you need more kinds of thread-safe collections, it >>> probably indicating that the concurrent code (or model) which you >>> designed is in pretty bad shape. >>> >>> Just compare two following snippets: >>> >>> 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. >>> >>> and: >>> >>> semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: >>> something] ]. >>> >>> What you think, which one is better? >>> >>> >>>> Bill >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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

Oct. 27, 2009