- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

On May 3, 2009, at 2:37 AM, Igor Stasenko wrote: > 2009/5/3 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> Beware: there are two issues here, not one. >> >> (a) the faulty remoteString code is ill behaved. Fine that can be >> fixed or as Igor suggested refactored to oblivion. >> > IMO this should be done sooner or later. Its a pain to see it. > Oh well, too bad, this is not the only thing which requires > attention :) > >> (b) The deeper issue is that we affected how finalization works so >> that this ill behavior now causes application failure. >> If in the past it worked, now it doesn't I don't see anyone really >> having a good answer other than perhaps my guess, >> and how do we get back to the point were ill behaviour by *my* code >> won't cause Socket Failures. >> > I used finalization in my code multiple times. It didn't caused many > problems, if you know how to do it right (by taking an implementation > into account). > >> No doubt people have ugly code that is *silently* busted like >> RemoteString, but they don't know it. >> And as you saw actually finding the culprit is difficult. >> >> Lastly some people DO use finalization to do resource cleanup on >> purpose, not as a safety fallback, so they will >> be impacted I think by the new Pharo behaviour. >> > It looks like i missed this part. Where i can read details about what > is altered in finalization, which could break things? In this thread or the one related john mentioned it. > > >> Wasn't finalization tagged as bloated and need fixing? Igor I'm sure >> suggested a few things before the flurry of >> code for optimizing semaphores and process switching? >> > Yes, i proposed a little change to VM (just a couple lines of code in > single method + registering additional special object) > which would allow us more direct finalization. > It not makes weak refs to be a full pledged ephemerons, but much > easier to adopt in VM. And besides you wont find any finalization code > in squeak which relies on ephemeron's special behavior -- reference > 'value' slot weakly, only when reference in 'key' slot is dies. > > http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.… > > >> On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: >> > > > > -- > 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 >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Nicolas Cellier

2009/5/3 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Beware: there are two issues here, not one. > > (a) the faulty remoteString code is ill behaved. Fine that can be > fixed or as Igor suggested refactored to oblivion. > > (b) The deeper issue is that we affected how finalization works so > that this ill behavior now causes application failure. > If in the past it worked, now it doesn't I don't see anyone really > having a good answer other than perhaps my guess, > and how do we get back to the point were ill behaviour by *my* code > won't cause Socket Failures. > > No doubt people have ugly code that is *silently* busted like > RemoteString, but they don't know it. > And as you saw actually finding the culprit is difficult. > > Lastly some people DO use finalization to do resource cleanup on > purpose, not as a safety fallback, so they will > be impacted I think by the new Pharo behaviour. > > Wasn't finalization tagged as bloated and need fixing? Igor I'm sure > suggested a few things before the flurry of > code for optimizing semaphores and process switching? > Yes! RemoteString patch is what I would call "un pansement sur une jambe de bois" unless it has more of "un arbre qui cache la forÃªt".. We need to write a SUnit TestCase stressing the finalization mechanism and identify what's going on. Debugging such low level high priority multi-process may imply instrumenting the VM though... Nicolas > On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > >> Yes but why don't we close them with an ensure or something like that. >> I mean is the logic of the connection making it that we cannot use >> ensure or this is just a legacy? >> >> On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: >> >>> Well somewhere someone needs to close the socket before it is >>> *forgotten* >>> >>> On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: >>> >>>> I would like to know why does the system rely on finalisation to >>>> release socket >>>> Apparently david mentioned that this is the source of huge problems. >>>> So what would be the alternative? >>>> >>>> Stef >>> > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

On May 3, 2009, at 1:46 AM, John M McIntosh wrote: > Beware: there are two issues here, not one. > > (a) the faulty remoteString code is ill behaved. Fine that can be > fixed or as Igor suggested refactored to oblivion. > > (b) The deeper issue is that we affected how finalization works so > that this ill behavior now causes application failure. > If in the past it worked, now it doesn't I don't see anyone really > having a good answer other than perhaps my guess, > and how do we get back to the point were ill behaviour by *my* code > won't cause Socket Failures. Yes this was also implied in my remark. > No doubt people have ugly code that is *silently* busted like > RemoteString, but they don't know it. > And as you saw actually finding the culprit is difficult. > > Lastly some people DO use finalization to do resource cleanup on > purpose, not as a safety fallback, so they will > be impacted I think by the new Pharo behaviour. I agree! > > > Wasn't finalization tagged as bloated and need fixing? Igor I'm sure > suggested a few things before the flurry of > code for optimizing semaphores and process switching? > > On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > >> Yes but why don't we close them with an ensure or something like >> that. >> I mean is the logic of the connection making it that we cannot use >> ensure or this is just a legacy? >> >> On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: >> >>> Well somewhere someone needs to close the socket before it is >>> *forgotten* >>> >>> On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: >>> >>>> I would like to know why does the system rely on finalisation to >>>> release socket >>>> Apparently david mentioned that this is the source of huge >>>> problems. >>>> So what would be the alternative? >>>> >>>> Stef >>> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

On May 3, 2009, at 1:09 AM, Igor Stasenko wrote: > Oh, remoteString!!! I LOVE IT :))) > > Stephane, remember this mail ? no :) but I agree we will have to address that in the future. But this will be a bit more complex > > I didn't sent it to list. Sending now, just as a reminder. > > 9 December 2008 05:20 > subject One big mess :) > > Here is an IRC log me chatting with Keith. > > I just hope that Pharo guys will address this issue somewhere in > future. > > [03:36] <sig__> btw, i just found your #7239 > [03:36] <sig__> i'm also took a look at this code time ago > [03:36] <sig__> and i would recommend following: > [03:37] <sig__> - completely remove using RemoteString from practice. > [03:37] <sig__> - make sure that access to source streams is > synchronized > [03:37] <sig__> (no concurrency issues) > [03:37] *** optikalmouse (n=user@bas1- > toronto10-1279398477.dsl.bell.ca) joined > [03:38] <keithy> its a big job I started looking at it last wek > [03:38] <sig__> RemoteString is very , very , very brittle thing yes a terrible one :) > > [03:38] <keithy> do add you comment > [03:39] <sig__> i wouldn't pass anything except actual source code > outside source handling/management code > [03:39] <keithy> definitely > [03:39] <keithy> hmm > [03:39] *** wgsilkie (n=aidan(a)203.109.162.247) joined > [03:39] <keithy> or a proxy? > [03:39] <sig__> remote string is a proxy! > [03:40] <keithy> so... "I am a method" could I have my source please > [03:40] <sig__> but you can easily damage source files with it > [03:40] <sig__> or make it read complete mess instead of code > [03:42] <sig__> because , from what i have seen, it assumes that there > is nobody else accessing the source stream ATM, except single instance > of RemoteString > [03:46] <sig__> as well, as i don't like when different code in > different classes able to manipulate with the source streams directly > [03:46] <keithy> its ludicrous > [03:46] <sig__> by passing array with two elements around > [03:49] <sig__> check the references to SourceFiles :) > [03:50] <sig__> 55 references in my image! > [03:51] <sig__> a single, big, open wide security HOLE! :) > [03:52] <keithy> and lots of horrible code > [03:52] <sig__> yeah I totally agree. > > [03:52] *** wgsilkie quit (Remote closed the connection) > [03:53] <sig__> (SourceFiles at: 2) > [03:53] <sig__> very illustrative bit of code :) > [03:54] *** bmp > (n=benjamin(a)207-237-69-172.c3-0.avec-ubr3.nyr-avec.ny.static.cable.rcn.com > ) > joined > [03:55] <sig__> things like that makes me smile, when Edgar says "my > image smaller , and therefore more modular" > [03:55] <sig__> for GOD SAKE!! > [03:59] <keithy> hmm, if you gzip the image does it get more modular? > [04:00] <sig__> it is clear, that source management subsystem deserves > a separate, well defined protocol. Without any exposure where it > reads/takes source from, or where storing to > [04:03] <sig__> and i can't call it a bug, it doesn't fits into any > imaginable bugs category, simply because its not a bug, but design > flaw > [04:04] <sig__> and i think it would require few weeks to make it > fixed > [04:04] <keithy> an implementation flaw, no design obvious > [04:04] *** lamneth2 (n=IceChat7(a)bas1-longueuil15-1176159811.dsl.bell.ca > ) joined > [04:05] <sig__> well, an implementation should always follow a design > [04:05] <sig__> actually a bug, to my sense, is an implementation flaw > [04:06] <sig__> when it doesn't follows design > [04:06] <sig__> but design flaw is when everything works (no bugs), > but it works in an awfull way :) > > > > 2009/5/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Apparnetly after 10296 I can load moose without problem. >> So the fixes of nicolas closing remoteString solved the problem. >> Now this is only partially solved since I would really like to >> understand >> why it broke in the first place since we did not touch this code. >> >> Stef >> >> _______________________________________________ >> 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 >

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Igor Stasenko

2009/5/3 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Beware: there are two issues here, not one. > > (a) the faulty remoteString code is ill behaved. Fine that can be > fixed or as Igor suggested refactored to oblivion. > IMO this should be done sooner or later. Its a pain to see it. Oh well, too bad, this is not the only thing which requires attention :) > (b) The deeper issue is that we affected how finalization works so > that this ill behavior now causes application failure. > If in the past it worked, now it doesn't I don't see anyone really > having a good answer other than perhaps my guess, > and how do we get back to the point were ill behaviour by *my* code > won't cause Socket Failures. > I used finalization in my code multiple times. It didn't caused many problems, if you know how to do it right (by taking an implementation into account). > No doubt people have ugly code that is *silently* busted like > RemoteString, but they don't know it. > And as you saw actually finding the culprit is difficult. > > Lastly some people DO use finalization to do resource cleanup on > purpose, not as a safety fallback, so they will > be impacted I think by the new Pharo behaviour. > It looks like i missed this part. Where i can read details about what is altered in finalization, which could break things? > Wasn't finalization tagged as bloated and need fixing? Igor I'm sure > suggested a few things before the flurry of > code for optimizing semaphores and process switching? > Yes, i proposed a little change to VM (just a couple lines of code in single method + registering additional special object) which would allow us more direct finalization. It not makes weak refs to be a full pledged ephemerons, but much easier to adopt in VM. And besides you wont find any finalization code in squeak which relies on ephemeron's special behavior -- reference 'value' slot weakly, only when reference in 'key' slot is dies. http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.… > On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > -- Best regards, Igor Stasenko AKA sig.

May 3, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by John M McIntosh

Beware: there are two issues here, not one. (a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion. (b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures. No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult. Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour. Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching? On 2-May-09, at 1:52 PM, StÃ©phane Ducasse wrote: > Yes but why don't we close them with an ensure or something like that. > I mean is the logic of the connection making it that we cannot use > ensure or this is just a legacy? > > On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: > >> Well somewhere someone needs to close the socket before it is >> *forgotten* >> >> On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: >> >>> I would like to know why does the system rely on finalisation to >>> release socket >>> Apparently david mentioned that this is the source of huge problems. >>> So what would be the alternative? >>> >>> Stef >> -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

May 2, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Igor Stasenko

Oh, remoteString!!! I LOVE IT :))) Stephane, remember this mail ? I didn't sent it to list. Sending now, just as a reminder. 9 December 2008 05:20 subject One big mess :) Here is an IRC log me chatting with Keith. I just hope that Pharo guys will address this issue somewhere in future. [03:36] <sig__> btw, i just found your #7239 [03:36] <sig__> i'm also took a look at this code time ago [03:36] <sig__> and i would recommend following: [03:37] <sig__> - completely remove using RemoteString from practice. [03:37] <sig__> - make sure that access to source streams is synchronized [03:37] <sig__> (no concurrency issues) [03:37] *** optikalmouse (n=user(a)bas1-toronto10-1279398477.dsl.bell.ca) joined [03:38] <keithy> its a big job I started looking at it last wek [03:38] <sig__> RemoteString is very , very , very brittle thing [03:38] <keithy> do add you comment [03:39] <sig__> i wouldn't pass anything except actual source code outside source handling/management code [03:39] <keithy> definitely [03:39] <keithy> hmm [03:39] *** wgsilkie (n=aidan(a)203.109.162.247) joined [03:39] <keithy> or a proxy? [03:39] <sig__> remote string is a proxy! [03:40] <keithy> so... "I am a method" could I have my source please [03:40] <sig__> but you can easily damage source files with it [03:40] <sig__> or make it read complete mess instead of code [03:42] <sig__> because , from what i have seen, it assumes that there is nobody else accessing the source stream ATM, except single instance of RemoteString [03:46] <sig__> as well, as i don't like when different code in different classes able to manipulate with the source streams directly [03:46] <keithy> its ludicrous [03:46] <sig__> by passing array with two elements around [03:49] <sig__> check the references to SourceFiles :) [03:50] <sig__> 55 references in my image! [03:51] <sig__> a single, big, open wide security HOLE! :) [03:52] <keithy> and lots of horrible code [03:52] <sig__> yeah [03:52] *** wgsilkie quit (Remote closed the connection) [03:53] <sig__> (SourceFiles at: 2) [03:53] <sig__> very illustrative bit of code :) [03:54] *** bmp (n=benjamin(a)207-237-69-172.c3-0.avec-ubr3.nyr-avec.ny.static.cable.rcn.com) joined [03:55] <sig__> things like that makes me smile, when Edgar says "my image smaller , and therefore more modular" [03:55] <sig__> for GOD SAKE!! [03:59] <keithy> hmm, if you gzip the image does it get more modular? [04:00] <sig__> it is clear, that source management subsystem deserves a separate, well defined protocol. Without any exposure where it reads/takes source from, or where storing to [04:03] <sig__> and i can't call it a bug, it doesn't fits into any imaginable bugs category, simply because its not a bug, but design flaw [04:04] <sig__> and i think it would require few weeks to make it fixed [04:04] <keithy> an implementation flaw, no design obvious [04:04] *** lamneth2 (n=IceChat7(a)bas1-longueuil15-1176159811.dsl.bell.ca) joined [04:05] <sig__> well, an implementation should always follow a design [04:05] <sig__> actually a bug, to my sense, is an implementation flaw [04:06] <sig__> when it doesn't follows design [04:06] <sig__> but design flaw is when everything works (no bugs), but it works in an awfull way :) 2009/5/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Apparnetly after 10296 I can load moose without problem. > So the fixes of nicolas closing remoteString solved the problem. > Now this is only partially solved since I would really like to > understand > why it broke in the first place since we did not touch this code. > > Stef > > _______________________________________________ > 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.

May 2, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

Apparnetly after 10296 I can load moose without problem. So the fixes of nicolas closing remoteString solved the problem. Now this is only partially solved since I would really like to understand why it broke in the first place since we did not touch this code. Stef

May 2, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

Yes but why don't we close them with an ensure or something like that. I mean is the logic of the connection making it that we cannot use ensure or this is just a legacy? On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: > Well somewhere someone needs to close the socket before it is > *forgotten* > > On 30-Apr-09, at 5:29 AM, StÃ©phane Ducasse wrote: > >> I would like to know why does the system rely on finalisation to >> release socket >> Apparently david mentioned that this is the source of huge problems. >> So what would be the alternative? >> >> Stef > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 2, 2009

Re: [Pharo-project] [ANN] 10294, 10295, 10296

by StÃ©phane Ducasse

The problem was not upgrating betwen 293 and 296 (this was the only case that was working in fact) the problem was upgrading from pre 293 (for example 281) and 296. > I updated a 293 to get a 296. It seems to work. "ScriptLoader > loadOBAlpha" works well. Strange but good so may be the fixes on remoteString of nicolas fixed a bit the problem. I will try to reload moose in 296 to see if I succeed. Stef > > > > Alexandre > > > On 2 May 2009, at 17:23, StÃ©phane Ducasse wrote: > >> or I can publish a 10296 made from 10293 >> may be saving the image is an important step. >> >> Stef >> >> On May 2, 2009, at 4:43 PM, StÃ©phane Ducasse wrote: >> >>> Yes I can reproduce it and it makes the image totally unusable on >>> mac >>> So I will cancel all the releases above 10294, 10295, 10296 (cool I >>> was stupid to push not working code) and remove 10294. >>> >>> I will try to see if this is really 10294 which fucked up from >>> 10281. >>> >>> Stef (bored). >>> >>> >>> >>> >>> >>>> Thanks igor >>>> take the published 10281-core and do update. >>>> I'm redoing it now to verify it I can reproduce it. >>>> >>>> Stef >>>> >>>> >>>> On May 2, 2009, at 4:16 PM, Igor Stasenko wrote: >>>> >>>>> 2009/5/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> this is quite strange. >>>>>> I wanted to offer a new image so I took 10281 and did an update >>>>>> but at the end I got problem with sensor and hand.... >>>>>> >>>>> >>>>> Stef, can you give me a list of doits to repeat teh problems? >>>>> I'll try to debug & fix. >>>>> >>>>>> Stef >>>>>> >>>>>> On May 2, 2009, at 3:56 PM, StÃ©phane Ducasse wrote: >>>>>> >>>>>>> Hi >>>>>>> here are some updates: >>>>>>> >>>>>>> 10294 >>>>>>> - not working sensor fixes :( but like that they are in >>>>>>> >>>>>>> 10295 >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=789 >>>>>>> (PseudoContext >>>>>>> initialize) >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=788 (compact >>>>>>> classes >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=783 Issue >>>>>>> 783: >>>>>>> Better ContextPart>>errorReportOn: >>>>>>> >>>>>>> 10296 >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=790: >>>>>>> bookmorph >>>>>>> cleaning >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=756 font >>>>>>> rendering >>>>>>> speed up >>>>>>> - http://code.google.com/p/pharo/issues/detail?id=786 >>>>>>> (remoteString >>>>>>> closing) >>>>>>> >>>>>>> stef >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

May 2, 2009