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

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

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

by Igor Stasenko

2009/4/20 Igor Stasenko <siguctua(a)gmail.com>: > 2009/4/20 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >> > Thinking a bit more about it.. > > It could stay separated (instance/class side). But there are two > things is missing IMO: > - reinstalling a new event fetcher should preserve the list of handlers and then a old event fetcher can simply #become: to a new one. sorry for flooding :) > - an access to collection of eventHandlers should be guarded by > semaphore, because there could be a concurrency issues when one > process handling an event, while another one trying to install new > event handler to same collection. > > maybe more appropriate would be to remove startup/shutdown methods > from event fetcher, and merge things in InputEventSensor, to make sure > everything is ok , and sensor always speaking with currently installed > event fetcher. > >> >> 2009/4/20 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>> >>>> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >>>>> >>>>> ... unless... >>>>> I tried this in windows: >>>>> (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' >>>>> [latest update: #7179]') >>>>> >>>>> InputEventFetcher deinstall; install. >>>>> InputEventFetcher default. -> an InputEventFetcher >>>>> >>>>> It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the >>>>> inputSemaphore? >>>>> >>>> Err, I did not installEventSensorFramework >>>> >>>> InputEventFetcher deinstall. >>>> InputEventSensor installEventSensorFramework. >>>> >>>> ... and the image become unresponsive >>>> >>> i had some problems with reinstalling event fetcher too. >>> Let's wait for Mike, to show us the proper doits for reinstalling >>> event fetching process. >>> >>>> _______________________________________________ >>>> 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. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 20, 2009

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

by Michael Rueger

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 ;-) Michael

April 20, 2009

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

by Igor Stasenko

2009/4/20 Igor Stasenko <siguctua(a)gmail.com>: > 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. > Thinking a bit more about it.. It could stay separated (instance/class side). But there are two things is missing IMO: - reinstalling a new event fetcher should preserve the list of handlers - an access to collection of eventHandlers should be guarded by semaphore, because there could be a concurrency issues when one process handling an event, while another one trying to install new event handler to same collection. maybe more appropriate would be to remove startup/shutdown methods from event fetcher, and merge things in InputEventSensor, to make sure everything is ok , and sensor always speaking with currently installed event fetcher. > > 2009/4/20 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> >>> 2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >>>> >>>> ... unless... >>>> I tried this in windows: >>>> (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' >>>> [latest update: #7179]') >>>> >>>> InputEventFetcher deinstall; install. >>>> InputEventFetcher default. -> an InputEventFetcher >>>> >>>> It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the >>>> inputSemaphore? >>>> >>> Err, I did not installEventSensorFramework >>> >>> InputEventFetcher deinstall. >>> InputEventSensor installEventSensorFramework. >>> >>> ... and the image become unresponsive >>> >> i had some problems with reinstalling event fetcher too. >> Let's wait for Mike, to show us the proper doits for reinstalling >> event fetching process. >> >>> _______________________________________________ >>> 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. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 20, 2009

Re: [Pharo-project] Kernel Branch Name (was: Delays Semaphores and Processes)

by StÃ©phane Ducasse

Yes I should pay attention but the system does not prompt me to give name when I merge and release. Stef On Apr 20, 2009, at 6:44 PM, Lukas Renggli wrote: >> does it make sense if I load kernel-nice.renggli.300 > > I am enjoying to see these nice.renggli branch names everywhere, but > maybe sometime this tag should be removed ;-) > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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