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

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Nick Papoylias

Ok, first of all thank you all ! It' s definetely a nice welcome for me, from the list. Let me point out one things or two though: It whould be nice to have PEPs (Pharo Enhancement Proposals), for these major issues. See PEP for Python: http://www.python.org/dev/peps/ . Smalltalk is so powerfull that Namespaces can be done in a (large) number of ways. For example should the namespaces have an hierarchy ? Should the Inheritance hierarcy of classes be able to 'break' the boundaries of namespaces ? Should namespaces be first-class ? (ok, yes..), and the list goes on. For example there currently exist a setter in the class side for 'migratting' in a new environment, that just alters the class knowledge about the new namespace and does not erase it's record from the old namespace. Is this intented ? What is the underlying design ? Should we add an environment: setter in the subclass message, so that we integrate namespaces with the current Browser ? Should Behavior always return Smalltalk globals, or there should be a setter to be able to migrate a whole hierarchy of classes elsewhere ? Ok.. hope next time I will posting code instead of questions. Thank you very much, Nick On Mon, Oct 11, 2010 at 3:59 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I'm glad to see that it works like class names (at least effectively) as > messages to environments than a clone of Java syntax that I saw elsewhere. > On the completely pragmatic level, it will make more obvious the fact that > our browser selection panes are not individually sizable. I find them > narrow at times now, and adding another column will squeeze even more. > Maybe I find them narrow specifically because I use long class names that > would not be necessary if we had namespaces :) > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Simon Denier [ > Simon.Denier(a)inria.fr] > Sent: Monday, October 11, 2010 9:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Hallo Pharoers.. namespaces in the system > level ? > > On 11 oct. 2010, at 15:17, Igor Stasenko wrote: > > Also, i remember someone presented the namespaces implementation > during last ESUG conference. Its fresh, and probably will run on pharo. > But i don't remember who did this. > > > > Here you go, it's a GSOC project, video included: > > Begin forwarded message: > > From: James Foster <Smalltalk(a)JGFoster.net<mailto:Smalltalk@JGFoster.net>> > Date: 24 septembre 2010 00:09:39 HAEC > To: Pharo-project(a)lists.gforge.inria.fr<mailto: > Pharo-project(a)lists.gforge.inria.fr>, ESUG Mailing list < > esug-list(a)lists.esug.org<mailto:esug-list@lists.esug.org>> > Subject: [Pharo-project] GSoC Project for Namespaces > Reply-To: Pharo-project(a)lists.gforge.inria.fr<mailto: > Pharo-project(a)lists.gforge.inria.fr> > > GermÃ¡n Leiva was accepted in Google Summer of Code 2010 and developed a > Namespaces implementation for Pharo Smalltalk. A video at > http://www.youtube.com/watch?v=n4I7fSVNX2A is based on his presentation at > ESUG in Barcelona last week. You can get the code at > http://www.squeaksource.com/Environments.html. > > James Foster > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto: > Pharo-project(a)lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

[Pharo-project] [update 1.2] #12190

by StÃ©phane Ducasse

12190 ----- - Issue 3065: HardCoded SystemOrganization references. Stef

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

On Oct 11, 2010, at 3:55 PM, Levente Uzonyi wrote: > On Mon, 11 Oct 2010, StÃ©phane Ducasse wrote: > >>>> That "hack" is really cool IMO. The code is easily understood by anyone: >>> >>> #(4 1 3 5 2) sort: #<=. >> >> yes in Moose people are using that a lot for scripting. Now the problem is that as soon >> as you need more you have to get a block. > > Why is that a problem? You can use the symbol for simple cases and write blocks for the complicated ones. Indeed this is why we added Symbol>>value, even if I was against because been burned by Object>>value in some VW projects :) Now I do not see the point for ifNotNil: and for ifTrue:ifFalse:

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Levente, Ok, but just because the system saves us at the last instant does not mean that we should be going out of our way to multiply free external resources. Files are well known to the vm; other things (GSL vectors/matrices comes to mind) will not enjoy such protections. This strikes me as a feature that got added when errors arose from attempts to add redundant executors, ultimately due to lack of thread safety. Many things that are being fixed at great cost got started (it sure seems) because someone added a feature or placed something in or too near to Object only to avoid errors vs. finding and fixing the real problem. Maybe you have made a strong argument for multiple executors; if so, I've missed it. Right now, it looks like a design flaw instead of a feature. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, October 11, 2010 10:24 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Levente, > > A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessarily follow (we probably should not), though with careful design, an interrupted chain of events might survive to be handled on a subsequent attempt. > > I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. Smalltalk is not C. Try this: | file | file := StandardFileStream fileNamed: 'foo.txt'. file close. file primClose: (file instVarNamed: #fileID). "Those pesky plugins save us all the time. ;)" Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, October 11, 2010 9:51 AM > To: Pharo Development > Cc: The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> Hello, >> >> here a situation, with which we can deal in more safer manner: >> >> Suppose you have a weak registry, populated by different objects and >> their executors. >> >> Now, when some of them died, a weak registry performs finalization. >> >> The potential danger is , that if there's an error triggered by some >> executor(s), >> then rest of executors will have no chance to run and will be >> forgotten, causing memory leakage. >> >> What you think, should we handle this more graciously? >> >> (Consider a following meta-code) >> >> WeakRegistry>>finalizeValues >> | executors | >> executors := self gatherExecutorsToRun. >> >> executors do: [:ex | >> [ ex finalize ] fork. >> ]. > > The "gatherExecutorsToRun" part was implemented in the previous version > of WeakRegistry (history is not available from the image...). #finalize > wasn't sent from the protected block. The current version lacks it, so it > will deadlock if a finalizer will try to access the same WeakRegistry. > Other kind of deadlocks are also possible. For example when a finalizer > can access a semaphore which is also used by another process that > uses the same semaphore and also uses the WeakRegistry, but locks them in > a different order (JNIPort). > This only happens if the VM doesn't support the new finalization scheme > which is the case for most current VMs. > > There is another issue with removal, and this affects the new finalization > scheme too, because the finalizer of valuesDictionary is #finalizeValues. > This means that finalization can happen in a process other than the > finalization process. This can lead to random errors. > > So I think parts of the old WeakRegistry implementation should be > restored, like: > - WeakRegistry should collect executors > - executors should be evaluated outside the protected block > >> >> in this way, if any executor's #finalize causing error, it won't >> interfere with other executors, and they will accomplish their task >> normally. >> Of course, i'm not saying that we should use #fork for this, because >> it is costly. Similar could be done w/o forking. >> I just wanted to show a simplest code with which we could achieve a >> more gracious error handling. > > Wouldn't it be better to use an exception handler? > > > Levente > >> >> P.S. of course, in a first place it would be good to make sure that we >> writing executors, which can't cause an error during finalization. >> But bad things happen, and we should make sure that rest of system >> won't be put on its knees because of some stupid bug in a single >> #finalize. >> >> -- >> 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

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> Hello, >> >> here a situation, with which we can deal in more safer manner: >> >> Suppose you have a weak registry, populated by different objects and >> their executors. >> >> Now, when some of them died, a weak registry performs finalization. >> >> The potential danger is , that if there's an error triggered by some >> executor(s), >> then rest of executors will have no chance to run and will be >> forgotten, causing memory leakage. >> >> What you think, should we handle this more graciously? >> >> (Consider a following meta-code) >> >> WeakRegistry>>finalizeValues >> | executors | >> Â executors := self gatherExecutorsToRun. >> >> Â executors do: [:ex | >> Â Â [ ex finalize ] fork. >> Â ]. > > The "gatherExecutorsToRun" part was implemented in the previous version of > WeakRegistry (history is not available from the image...). #finalize wasn't > sent from the protected block. The current version lacks it, so it will > deadlock if a finalizer will try to access the same WeakRegistry. Other kind > of deadlocks are also possible. For example when a finalizer can access a > semaphore which is also used by another process that uses the same semaphore > and also uses the WeakRegistry, but locks them in a different order > (JNIPort). > This only happens if the VM doesn't support the new finalization scheme > which is the case for most current VMs. > > There is another issue with removal, and this affects the new finalization > scheme too, because the finalizer of valuesDictionary is #finalizeValues. > This means that finalization can happen in a process other than the > finalization process. This can lead to random errors. > err no. valuesDictionary are held privately by weak registry. and any access to it possible only through instance of weak registry, which always using protect: []. > So I think parts of the old WeakRegistry implementation should be restored, > like: > - WeakRegistry should collect executors > - executors should be evaluated outside the protected block > agreed on this one. But weak registry lost this feature before my intervention: This is a code from Squeak 4.1. image: finalizeValues "Some of our elements may have gone away. Look for those and activate the associated executors." self protected: [ valueDictionary finalizeValues ] ul 2/22/2010 14:23 Â· finalization Â· 2 implementors Â· in no change set Â· So, i thought, it not a big sacrifice, besides it runs faster. And to my thinking, the code which needs to manipulate weak registry during finalization smells badly. >> >> in this way, if any executor's #finalize causing error, it won't >> interfere with other executors, and they will accomplish their task >> normally. >> Of course, i'm not saying that we should use #fork for this, because >> it is costly. Similar could be done w/o forking. >> I just wanted to show a simplest code with which we could achieve a >> more gracious error handling. > > Wouldn't it be better to use an exception handler? > Well, its a bit complicated, since what i want is to: - report an error - but continue run #finalize for rest executors or: - report an error (stop finalization process), then - continue running for next executor , if user press 'abandon' - or continue with running fixed code If i'm not mistaken, currently, if you put halt inside a finalization process (like in some #finalize method) and then abandon it, you won't have finalization process in system anymore, because it will be terminated. > > Levente > >> >> P.S. of course, in a first place it would be good to make sure that we >> writing executors, which can't cause an error during finalization. >> But bad things happen, and we should make sure that rest of system >> won't be put on its knees because of some stupid bug in a single >> #finalize. >> >> -- >> 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 >> > > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Schwab,Wilhelm K

The UI changes are indeed a separate problem; if anything, this will make them more likely to happen as more people will run into the need for more space in the class and method columns at the expense of the others. Agreed that it looks like a smooth way to add the functionality. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 10:15 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ? On 11 October 2010 16:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I'm glad to see that it works like class names (at least effectively) as messages to environments than a clone of Java syntax that I saw elsewhere. On the completely pragmatic level, it will make more obvious the fact that our browser selection panes are not individually sizable. I find them narrow at times now, and adding another column will squeeze even more. Maybe I find them narrow specifically because I use long class names that would not be necessary if we had namespaces :) > > Yep. Fixing UI could be seen as a separate problem. But since traditionally, smalltalk seen as a language AND environment, so in order to use it, we should do the both, otherwise nobody will use it. P.S. i like the design of Environments. Its not intrusive (no syntax changes), and coexists peacefully with existing code. -- 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Levente Uzonyi

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Levente, > > A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessarily follow (we probably should not), though with careful design, an interrupted chain of events might survive to be handled on a subsequent attempt. > > I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. Smalltalk is not C. Try this: | file | file := StandardFileStream fileNamed: 'foo.txt'. file close. file primClose: (file instVarNamed: #fileID). "Those pesky plugins save us all the time. ;)" Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, October 11, 2010 9:51 AM > To: Pharo Development > Cc: The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> Hello, >> >> here a situation, with which we can deal in more safer manner: >> >> Suppose you have a weak registry, populated by different objects and >> their executors. >> >> Now, when some of them died, a weak registry performs finalization. >> >> The potential danger is , that if there's an error triggered by some >> executor(s), >> then rest of executors will have no chance to run and will be >> forgotten, causing memory leakage. >> >> What you think, should we handle this more graciously? >> >> (Consider a following meta-code) >> >> WeakRegistry>>finalizeValues >> | executors | >> executors := self gatherExecutorsToRun. >> >> executors do: [:ex | >> [ ex finalize ] fork. >> ]. > > The "gatherExecutorsToRun" part was implemented in the previous version > of WeakRegistry (history is not available from the image...). #finalize > wasn't sent from the protected block. The current version lacks it, so it > will deadlock if a finalizer will try to access the same WeakRegistry. > Other kind of deadlocks are also possible. For example when a finalizer > can access a semaphore which is also used by another process that > uses the same semaphore and also uses the WeakRegistry, but locks them in > a different order (JNIPort). > This only happens if the VM doesn't support the new finalization scheme > which is the case for most current VMs. > > There is another issue with removal, and this affects the new finalization > scheme too, because the finalizer of valuesDictionary is #finalizeValues. > This means that finalization can happen in a process other than the > finalization process. This can lead to random errors. > > So I think parts of the old WeakRegistry implementation should be > restored, like: > - WeakRegistry should collect executors > - executors should be evaluated outside the protected block > >> >> in this way, if any executor's #finalize causing error, it won't >> interfere with other executors, and they will accomplish their task >> normally. >> Of course, i'm not saying that we should use #fork for this, because >> it is costly. Similar could be done w/o forking. >> I just wanted to show a simplest code with which we could achieve a >> more gracious error handling. > > Wouldn't it be better to use an exception handler? > > > Levente > >> >> P.S. of course, in a first place it would be good to make sure that we >> writing executors, which can't cause an error during finalization. >> But bad things happen, and we should make sure that rest of system >> won't be put on its knees because of some stupid bug in a single >> #finalize. >> >> -- >> 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 >

Oct. 11, 2010

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by Johannes Rasche

Thanks Alain, Stef and Mariano for fast answer. I assume that will help. Possibly I can contribute to improve documentation by carefull reading, trying and so on Johannes Am 11.10.2010 um 14:51 schrieb Mariano Martinez Peck: > > > 2010/10/11 Johannes Rasche <johannesrasche(a)mac.com> > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) > > > http://book.pharo-project.org/book/Localisation/ > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! > > Thanks in advance > > > > > Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > > mail: johannesrasche(a)me.com > skype: johannesrasche > www: http://myNeat.de > fon: +49-30-7469 4425 (skypeIn) > fax: +49-30-315 66 821 > > > > > > > > > > > _______________________________________________ > 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. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Igor Stasenko

On 11 October 2010 16:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I'm glad to see that it works like class names (at least effectively) as messages to environments than a clone of Java syntax that I saw elsewhere. Â On the completely pragmatic level, it will make more obvious the fact that our browser selection panes are not individually sizable. Â I find them narrow at times now, and adding another column will squeeze even more. Â Maybe I find them narrow specifically because I use long class names that would not be necessary if we had namespaces :) > > Yep. Fixing UI could be seen as a separate problem. But since traditionally, smalltalk seen as a language AND environment, so in order to use it, we should do the both, otherwise nobody will use it. P.S. i like the design of Environments. Its not intrusive (no syntax changes), and coexists peacefully with existing code. -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Levente, A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessarily follow (we probably should not), though with careful design, an interrupted chain of events might survive to be handled on a subsequent attempt. I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, October 11, 2010 9:51 AM To: Pharo Development Cc: The general-purpose Squeak developers list Subject: Re: [Pharo-project] Another finalization concern: error handling On Mon, 11 Oct 2010, Igor Stasenko wrote: > Hello, > > here a situation, with which we can deal in more safer manner: > > Suppose you have a weak registry, populated by different objects and > their executors. > > Now, when some of them died, a weak registry performs finalization. > > The potential danger is , that if there's an error triggered by some > executor(s), > then rest of executors will have no chance to run and will be > forgotten, causing memory leakage. > > What you think, should we handle this more graciously? > > (Consider a following meta-code) > > WeakRegistry>>finalizeValues > | executors | > executors := self gatherExecutorsToRun. > > executors do: [:ex | > [ ex finalize ] fork. > ]. The "gatherExecutorsToRun" part was implemented in the previous version of WeakRegistry (history is not available from the image...). #finalize wasn't sent from the protected block. The current version lacks it, so it will deadlock if a finalizer will try to access the same WeakRegistry. Other kind of deadlocks are also possible. For example when a finalizer can access a semaphore which is also used by another process that uses the same semaphore and also uses the WeakRegistry, but locks them in a different order (JNIPort). This only happens if the VM doesn't support the new finalization scheme which is the case for most current VMs. There is another issue with removal, and this affects the new finalization scheme too, because the finalizer of valuesDictionary is #finalizeValues. This means that finalization can happen in a process other than the finalization process. This can lead to random errors. So I think parts of the old WeakRegistry implementation should be restored, like: - WeakRegistry should collect executors - executors should be evaluated outside the protected block > > in this way, if any executor's #finalize causing error, it won't > interfere with other executors, and they will accomplish their task > normally. > Of course, i'm not saying that we should use #fork for this, because > it is costly. Similar could be done w/o forking. > I just wanted to show a simplest code with which we could achieve a > more gracious error handling. Wouldn't it be better to use an exception handler? Levente > > P.S. of course, in a first place it would be good to make sure that we > writing executors, which can't cause an error during finalization. > But bad things happen, and we should make sure that rest of system > won't be put on its knees because of some stupid bug in a single > #finalize. > > -- > 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

Oct. 11, 2010