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

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

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

by StÃ©phane Ducasse

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 >

April 21, 2009

Re: [Pharo-project] Nile and pharo?

by StÃ©phane Ducasse

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)> Stef On Apr 20, 2009, at 11:41 PM, Alexandre Bergel wrote: >> Thanks markus. It is probably related to the point alex raised. > > My fix solve the problem. Loading my fix _before_ loading nile, make > all the test green > >> Since now traits do not share their methods it may happen that a >> conflict >> arise when it should not. >> Could you do me a favor and load the fixes proposed by alex that he >> published in the Traits >> project on squeaksource. And redo your experiment this way we may >> learn something. > > After my fix, all the test are green. This is enough to convince me to > push the fix in PharoInbox. > > Note that if you load the fix _after_ having loaded Nile, the test > will remain red. Conflicting methods are set when loading Traits. > > ISSUE #725 has been updated. > > Cheers, > Alexandre > > > >> >> On Apr 18, 2009, at 9:43 PM, Markus Fritsche wrote: >> >>> Markus Fritsche <fritsche.markus(a)gmx.net> wrote: >>> >>>> I installed Nile from the Universe. I wonder if it's a) my image or >>>> if b) >>>> Nile/ c) Pharo Traits is broken? For instance, >>>> NSCollectionStreamTest gives >>>> me an error: >>> >>>> 'A class or trait does not properly resolve a conflict between >>>> multiple >>>> traits it uses.' >>> >>> I downloaded the advertised pharo-dev image, installed universe, >>> nile, >>> started the test... same error (so, at least once, a) is not the >>> culprit >>> :-P) >>> >>> >>> _______________________________________________ >>> 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 >

April 21, 2009

Re: [Pharo-project] IMPORTANT BUGFIX IN SharedQueue>>#findFirst:

by StÃ©phane Ducasse

Ok I will do that now. Stef On Apr 20, 2009, at 11:40 PM, Nicolas Cellier wrote: > And that help me running all tests without freezing the image... > > 3015 run, 2922 passes, 2 expected failures, 15 failures, 76 errors, 0 > unexpected passes > > Well, still some bugs and regressions to fix, but that's on a better > way > > 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Please load ASAP Collections-Sequenceable-nice.15 IMPORTANT BUG FIX >> IN >> SharedQueue>>findFirst: >> Otherwise you risk an infinite loop in high priority process... >> This happens randomly while running all tests >> >> Another change related to new InputEventSensor can also go in image >> immediatly: >> Kernel-nice.renggli.302 fixes missing >> InputEventSensor>>#flushNonKbdEvents >> >> Cheers >> > > _______________________________________________ > 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] Some bugs with the last version of pharo (10281) and pharo-dev (10284)

by John M McIntosh

This is because the pharo system now is much more utf-8 filename aware. Unfortunately the the 4.0.1b1U VM is still setup for macintosh (macroman) file name translation which causes Pharo to die, when a directory search encounters oh I'd don't know "folder Ã§Ã 2" perhaps? The fix is to change your 4.0.1x squeak vm or pharo one-click app setting on the macintosh to have the VM give back UTF-8 characters. To do this control click to show contents and open the *.app then dig inside the Contents folder and alter the Info.plist change the SqueakEncodingType to UTF-8 At this late hour I'm not sure how to distribute such a change since if you run the VM in UTF-8 mode then it mess up any non-ascii 128-255) characters in the Squeak 3.8/3.9/3.10/3.11 File Browser. Then again perhaps we say oh if you use a pending? 4.1.0 VM you MUST ensure your image is UTF8 aware? BTW the macintosh carbon VM is very UTF8 aware since we did no-end of testing on file names in Sophie. However we preserved all file name paths as URI references, versus unix path names, and flip the URI into the proper path with encoding by asking it for it's file path name when it was needed as a file link. On 21-Apr-09, at 12:48 AM, Laval Jannik wrote: > Ok, I have found the problem: > > When I run the image for the first time, a folder "package-cache" is > created. > When the image is in a folder on my desktop ("/Users/jannik/Desktop/ > Pharo"), it does not works. > If I put this folder in "/Applications/Pharo", it works. > > Maybe, the bug come from the VM. > > Jannik -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 21, 2009