- Pharo-dev - lists.pharo.org

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

by Nicolas Cellier

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 >

April 20, 2009

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

by StÃ©phane Ducasse

Nicolas for the integration of the second patch. Is the Delay startTimerEventLoop mandatory? Stef >>>> >>>> >>>> >>>>> 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 >

April 20, 2009

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

by StÃ©phane Ducasse

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 >

April 20, 2009

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

by Nicolas Cellier

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 >

April 20, 2009

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

by StÃ©phane Ducasse

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 >

April 20, 2009

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

by Nicolas Cellier

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 >

April 20, 2009

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

by StÃ©phane Ducasse

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

April 20, 2009

[Pharo-project] [ANN] 10287 Delay cleanup

by StÃ©phane Ducasse

>> To install DelayCleanup.1.cs it is necessary to write a ScriptLoader >> script like: >> script363 >> Delay startTimerEventLoop. >> (self buildConfigurationMapFor: >> #('Kernel-nice.renggli.300.mcz')) load >

April 20, 2009

Re: [Pharo-project] Lots of characters lost while typing in Unix

by Michael Roberts

sorry to be pedantic but Michael's right. even if the second client of the class is a test where you make an instance on the fly, assert a few things and clean it up. You then have at least 2 instances. the singleton and short-lived adhoc ones. systems with dependencies on global state or behaviour are very hard to test. cheers, Mike On Mon, Apr 20, 2009 at 6:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/4/20 Michael Rueger <m.rueger(a)acm.org>: >> Igor Stasenko wrote: >>> Another thing, that i think it would be better is to not have an >>> instance side methods. >>> Since we never need a multiple instances of InputEventFetcher in >>> system, then instead of singleton scheme, it would be better to move >>> all methods and ivars to class side - simply because a class is >>> already singleton. >>> This will help to avoid discrepancies, like we just met. >> >> -10000 >> >> Using singleton instances is a proven design pattern. >> And, you never know if you won't need more than one input fetcher ;-) >> > Clearly, this is not the case, because your code hosted on a single VM > ;) and its the only source of events for fetcher. > >> Michael >> >> _______________________________________________ >> 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 >

April 20, 2009

Re: [Pharo-project] Lots of characters lost while typing in Unix

by Igor Stasenko

2009/4/20 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> Another thing, that i think it would be better is to not have an >> instance side methods. >> Since we never need a multiple instances of InputEventFetcher in >> system, then instead of singleton scheme, it would be better to move >> all methods and ivars to class side - simply because a class is >> already singleton. >> This will help to avoid discrepancies, like we just met. > > -10000 > > Using singleton instances is a proven design pattern. > And, you never know if you won't need more than one input fetcher ;-) > Clearly, this is not the case, because your code hosted on a single VM ;) and its the only source of events for fetcher. > Michael > > _______________________________________________ > 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.

April 20, 2009