- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] 10289

by StÃ©phane Ducasse

SharedQueue fix InputEventSensor>>flushNonKbd Closure>>asText fixing missing literalsDo: please check Stef

April 21, 2009

Re: [Pharo-project] Nile and pharo?

by StÃ©phane Ducasse

what! ;) here it is cold and raining.... only 300km away on the east. Stef On Apr 21, 2009, at 12:06 PM, Damien Cassou wrote: > On Tue, Apr 21, 2009 at 11:07 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> ok great news! >> I will add that to the list of items to integrate... argh - busy >> holidays luckily this is cold and raining (yes the south of france is >> not >> anymore what it was used to be)> > > Weather is quite nice in Arcachon :-). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2009

Re: [Pharo-project] Nile and pharo?

by Damien Cassou

On Tue, Apr 21, 2009 at 11:07 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ok great news! > I will add that to the list of items to integrate... argh - busy > holidays luckily this is cold and raining (yes the south of france is > not > anymore what it was used to be)> Weather is quite nice in Arcachon :-). -- Damien Cassou http://damiencassou.seasidehosting.st

April 21, 2009

[Pharo-project] Next items planned and resting

by StÃ©phane Ducasse

Hi guys I want to do something else than integrating fixes. So I will harvest traits, removal of powermanagement, Streams and flush the inbox. After I will rest and write stuff I have too. Stef

April 21, 2009

Re: [Pharo-project] Another issue with new events

by Michael Rueger

Igor Stasenko wrote: > I unsure if it because of my intrusions.. but it happens second time > when i hit 'save the image'. I can't reproduce that, especially with a fully updated 288 image. > The Delay instance of EventPollingFetcher are created just once, and > then reused in event loop. > At the time when image saved, its already scheduled in Delay, but then > new eventpolling fetcher get installed in new process, and same delay > got rescheduled , which leads to this error. In the latest fixes the delay is unscheduled, so this shouldn't happen anymore. Michael

April 21, 2009

Re: [Pharo-project] Closure simulation errors

by Nicolas Cellier

Since I'm not sure it's the same issue, you have two... http://code.google.com/p/pharo/issues/detail?id=761 http://code.google.com/p/pharo/issues/detail?id=762 2009/4/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > can you add an issue on the bugtracker? > > On Apr 21, 2009, at 1:09 AM, Nicolas Cellier wrote: > >> You certainly noticed a lot of Closure related tests fail. >> A few because of unavailable BlockContext API in BlockClosure... (most >> are fixed yet) >> But mainly because of tests messing with: >> >> MethodContext>>#runSimulated:contextAtEachStep: >> >> I think something is broken there... One missing or not up to date >> change from Eliot probably. >> >> Also there is a problem in the debugger: when halted in a Closure, >> executing restart then proceed won't restart correclty: >> Example: >> 1) Execute this : >> Â (ScriptLoader new buildConfigurationMapFor: #('foobar.blast')) load >> 2) Open the debugger (click debug) >> 3) select top but one context >> Â Â [] in ScriptLoader>>buildConfigurationMapFor: >> 4) click restart, then proceed >> >> You get Character doesNotUnderstand: #encodeForHttp >> a real mess, as if evaluating the code in wrong context... >> >> _______________________________________________ >> 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 >

April 21, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by StÃ©phane Ducasse

I'm pushing the delayPArttwo now and after I will do that SharedQueue>>#findFirst: On Apr 21, 2009, at 11:32 AM, Nicolas Cellier wrote: > Yes, SharedQueue>>#findFirst: MUST be corrected ASAP > > 2009/4/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> So nicolas should I harvest the find related bug fixes? >> >> >> On Apr 20, 2009, at 10:34 PM, Nicolas Cellier wrote: >> >>> Wait, I think the problem is not at all caused by Concurrency >>> fixes... >>> >>> I strongly suspect introduction of SharedQueue>>#findFirst: >>> >>> The test hang randomly in: >>> >>> InputEventSensor>>peekKeyboardEvent >>> "Allows for use of old Sensor protocol to get at the keyboard, >>> as when running kbdTest or the InterpreterSimulator in >>> Morphic" >>> >>> ^eventQueue findFirst: [:buf | self isKbdEvent: buf] >>> >>> Old code was: >>> >>> peekKeyboardEvent >>> "Return the next keyboard char event from the receiver or >>> nil if none >>> available" >>> ^eventQueue nextOrNilSuchThat: >>> [:buf | >>> buf first = >>> EventTypeKeyboard and: [(buf fourth) = EventKeyChar]] >>> >>> But I noticed SharedQueue>>findFirst: and >>> SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... >>> findFirst: FAILS TO INCREMENT readPos... >>> >>> >>> Nicolas >>> >>> >>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I know that john has a vm with traces but I do not know how to do >>>> what >>>> you need. >>>> Do you think that it can help if I integrate the next batch? >>>> Nicolas I can also remove from the stream the item so that you can >>>> take time to look at it. >>>> you just need to load the version 836 of the scriptLoader (from the >>>> pharo repository). >>>> and manually launch the loading of the last update. >>>> >>>> ScriptLoader new update10287 >>>> >>>> Stef >>>> >>>> On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote: >>>> >>>>> Do you know how to dump Smalltalk process stacks from within the >>>>> VM >>>>> debugger (I mean gdb) ? >>>>> >>>>> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>> But the tests just blocked after 2256 run, 2162 passes, etc... >>>>>> and no response to ALT+. :( >>>>>> >>>>>> I will have a quick look... >>>>>> >>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> Ok now I understand why I only got 14 and not 16 tests green. >>>>>>> >>>>>>> >>>>>>> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >>>>>>> >>>>>>>> Yes, it seems OK >>>>>>>> The tests are running on my linux versions now... not yet >>>>>>>> frozen >>>>>>>> The two additionnal DelayTest from Andreas which were in >>>>>>>> KernelTests-nice.95.mcz are not yet loaded but will be with >>>>>>>> KernelTests-nice.96.mcz >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>>> it is not a problem. >>>>>>>>> I just want to make sure. Some changes are easy to undo some >>>>>>>>> not. >>>>>>>>> So I will integrate the second batch. >>>>>>>>> Did you have a look at the integration I just did. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>>>>>>> >>>>>>>>>> Yes, >>>>>>>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for >>>>>>>>>> Delay >>>>>>>>>> because Andreas changes solved the problem. >>>>>>>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>>>>>>> System-Support-nice.11.mcz fix a problem of sending >>>>>>>>>> deprecated >>>>>>>>>> Process>>#offList (it should have gone with earlier change) >>>>>>>>>> >>>>>>>>>> I wanted to decompose integration of Andreas changes >>>>>>>>>> carefully >>>>>>>>>> to be >>>>>>>>>> sure it can be redone... >>>>>>>>>> But now, I realize that I published too many messages, that's >>>>>>>>>> confusing >>>>>>>>>> >>>>>>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>>>>> >>>>>>>>>>> nicolas >>>>>>>>>>> >>>>>>>>>>> I integrated in 10287 >>>>>>>>>>> >>>>>>>>>>>>> script363 >>>>>>>>>>>>> Delay startTimerEventLoop. >>>>>>>>>>>>> (self buildConfigurationMapFor: >>>>>>>>>>>>> #('Kernel-nice.renggli.300.mcz')) load >>>>>>>>>>> >>>>>>>>>>> So I imagine that the following one is another fix that I >>>>>>>>>>> should >>>>>>>>>>> integrate. >>>>>>>>>>> Is is correct >>>>>>>>>>> >>>>>>>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>>>>>>> concurrency fixes? 3.10 >>>>>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>>>>>>> >>>>>>>>>>>> I published the changes in PharoInbox >>>>>>>>>>>> I checked that entire changes related to mantis 7321 list >>>>>>>>>>>> can >>>>>>>>>>>> be >>>>>>>>>>>> loaded with following instructions: >>>>>>>>>>>> >>>>>>>>>>>> Delay startTimerEventLoop. >>>>>>>>>>>> (ScriptLoader new buildConfigurationMapFor: >>>>>>>>>>>> #('Kernel-nice.renggli.301.mcz' >>>>>>>>>>>> 'KernelTests-nice.96.mcz' >>>>>>>>>>>> 'System-Support-nice.11.mcz')) load. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are listed in the >>>>>>>>>>>> owner >>>>>>>>>>>> or CC fields of this issue, or because you starred this >>>>>>>>>>>> issue. >>>>>>>>>>>> You may adjust your issue notification preferences at: >>>>>>>>>>>> http://code.google.com/hosting/settings >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >

April 21, 2009

Re: [Pharo-project] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

Yes, SharedQueue>>#findFirst: MUST be corrected ASAP 2009/4/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > So nicolas should I harvest the find related bug fixes? > > > On Apr 20, 2009, at 10:34 PM, Nicolas Cellier wrote: > >> Wait, I think the problem is not at all caused by Concurrency fixes... >> >> I strongly suspect introduction of SharedQueue>>#findFirst: >> >> The test hang randomly in: >> >> InputEventSensor>>peekKeyboardEvent >> Â Â Â "Allows for use of old Sensor protocol to get at the keyboard, >> Â Â Â as when running kbdTest or the InterpreterSimulator in Morphic" >> >> Â Â Â ^eventQueue findFirst: [:buf | self isKbdEvent: buf] >> >> Old code was: >> >> peekKeyboardEvent >> Â Â Â "Return the next keyboard char event from the receiver or nil if none >> available" >> Â Â Â ^eventQueue nextOrNilSuchThat: >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [:buf | >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â buf first = EventTypeKeyboard and: [(buf fourth) = EventKeyChar]] >> >> But I noticed SharedQueue>>findFirst: and >> SharedQueue>>nextOrNilSuchThat: are not EXACTLY the same... >> findFirst: FAILS TO INCREMENT readPos... >> >> >> Nicolas >> >> >> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I know that john has a vm with traces but I do not know how to do >>> what >>> you need. >>> Do you think that it can help if I integrate the next batch? >>> Nicolas I can also remove from the stream the item so that you can >>> take time to look at it. >>> you just need to load the version 836 of the scriptLoader (from the >>> pharo repository). >>> and manually launch the loading of the last update. >>> >>> ScriptLoader new update10287 >>> >>> Stef >>> >>> On Apr 20, 2009, at 10:15 PM, Nicolas Cellier wrote: >>> >>>> Do you know how to dump Smalltalk process stacks from within the VM >>>> debugger (I mean gdb) ? >>>> >>>> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> But the tests just blocked after 2256 run, 2162 passes, etc... >>>>> and no response to ALT+. :( >>>>> >>>>> I will have a quick look... >>>>> >>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> Ok now I understand why I only got 14 and not 16 tests green. >>>>>> >>>>>> >>>>>> On Apr 20, 2009, at 9:54 PM, Nicolas Cellier wrote: >>>>>> >>>>>>> Yes, it seems OK >>>>>>> The tests are running on my linux versions now... not yet frozen >>>>>>> The two additionnal DelayTest from Andreas which were in >>>>>>> KernelTests-nice.95.mcz are not yet loaded but will be with >>>>>>> KernelTests-nice.96.mcz >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>> it is not a problem. >>>>>>>> I just want to make sure. Some changes are easy to undo some >>>>>>>> not. >>>>>>>> So I will integrate the second batch. >>>>>>>> Did you have a look at the integration I just did. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> On Apr 20, 2009, at 9:42 PM, Nicolas Cellier wrote: >>>>>>>> >>>>>>>>> Yes, >>>>>>>>> Kernel-nice.renggli.301.mcz simply remove the upper limit for >>>>>>>>> Delay >>>>>>>>> because Andreas changes solved the problem. >>>>>>>>> KernelTests-nice.96.mcz change the Delay upper bound test >>>>>>>>> System-Support-nice.11.mcz fix a problem of sending deprecated >>>>>>>>> Process>>#offList (it should have gone with earlier change) >>>>>>>>> >>>>>>>>> I wanted to decompose integration of Andreas changes carefully >>>>>>>>> to be >>>>>>>>> sure it can be redone... >>>>>>>>> But now, I realize that I published too many messages, that's >>>>>>>>> confusing >>>>>>>>> >>>>>>>>> 2009/4/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>>>> >>>>>>>>>> nicolas >>>>>>>>>> >>>>>>>>>> I integrated in 10287 >>>>>>>>>> >>>>>>>>>>>> script363 >>>>>>>>>>>> Â Delay startTimerEventLoop. >>>>>>>>>>>> Â (self buildConfigurationMapFor: >>>>>>>>>>>> Â #('Kernel-nice.renggli.300.mcz')) load >>>>>>>>>> >>>>>>>>>> So I imagine that the following one is another fix that I >>>>>>>>>> should >>>>>>>>>> integrate. >>>>>>>>>> Is is correct >>>>>>>>>> >>>>>>>>>>> Comment #1 on issue 688 by nicolas.cellier.aka.nice: Kernel >>>>>>>>>>> concurrency fixes? 3.10 >>>>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>>>>>>>>> >>>>>>>>>>> I published the changes in PharoInbox >>>>>>>>>>> I checked that entire changes related to mantis 7321 list can >>>>>>>>>>> be >>>>>>>>>>> loaded with following instructions: >>>>>>>>>>> >>>>>>>>>>> Â Delay startTimerEventLoop. >>>>>>>>>>> Â (ScriptLoader new buildConfigurationMapFor: >>>>>>>>>>> Â Â Â Â Â #('Kernel-nice.renggli.301.mcz' >>>>>>>>>>> Â Â Â Â Â 'KernelTests-nice.96.mcz' >>>>>>>>>>> Â Â Â Â Â 'System-Support-nice.11.mcz')) load. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are listed in the owner >>>>>>>>>>> or CC fields of this issue, or because you starred this >>>>>>>>>>> issue. >>>>>>>>>>> You may adjust your issue notification preferences at: >>>>>>>>>>> http://code.google.com/hosting/settings >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >

April 21, 2009

Re: [Pharo-project] Hernan stack top fix and some literalDo: fix still missing

by StÃ©phane Ducasse

this is strange since I merge and do not load. So I will redo that (reargh). Stef On Apr 21, 2009, at 1:34 AM, Nicolas Cellier wrote: > Pharo/Kernel-stephane_ducasse.renggli.293 has been lost > (overwritten by Kernel-stephane_ducasse.renggli.294 which has > Kernel-michael_rueger.renggli.292 as ancestor). > > Thus Pharo image 10287 miss Hernan stack top fix and a literals do: > fix > > This can be repaired by merge tool though... > While at it, why cannot we apply a chirurgical merge ? > I mean select or reject item by item > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2009

Re: [Pharo-project] Closure simulation errors

by StÃ©phane Ducasse

can you add an issue on the bugtracker? On Apr 21, 2009, at 1:09 AM, Nicolas Cellier wrote: > You certainly noticed a lot of Closure related tests fail. > A few because of unavailable BlockContext API in BlockClosure... (most > are fixed yet) > But mainly because of tests messing with: > > MethodContext>>#runSimulated:contextAtEachStep: > > I think something is broken there... One missing or not up to date > change from Eliot probably. > > Also there is a problem in the debugger: when halted in a Closure, > executing restart then proceed won't restart correclty: > Example: > 1) Execute this : > (ScriptLoader new buildConfigurationMapFor: #('foobar.blast')) load > 2) Open the debugger (click debug) > 3) select top but one context > [] in ScriptLoader>>buildConfigurationMapFor: > 4) click restart, then proceed > > You get Character doesNotUnderstand: #encodeForHttp > a real mess, as if evaluating the code in wrong context... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 21, 2009