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

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

by Igor Stasenko

On a second thought, i think the toublemaker is not my code :) It seems that reinstalling event loop works incorrectly, because it should make sure that previous event loop process is terminated. And hence any delays which was scheduled in it will be unscheduled by #ifCurtailed: block Delay>>wait "Schedule this Delay, then wait on its semaphore. The current process will be suspended for the amount of time specified when this Delay was created." self schedule. [delaySemaphore wait] ifCurtailed:[self unschedule]. The solution, is to promote fetcherProcess ivar to class var, to make sure that there is only one event loop process existing in system (but we could have multiple instance of InputEventFetcher singletons ;) 2009/4/21 Igor Stasenko <siguctua(a)gmail.com>: > I unsure if it because of my intrusions.. but it happens second time > when i hit 'save the image'. > > I can't give a textual trace, because at the moment when error > appears, image is no longer able to receive the events. > > Image are saved OK, but then it going through warm startup and throws > this error. > Now i know what is wrong, and the troublemaker is my code. :) > > 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. > > Btw, i just found that saved image, has same problems - it throws the > same error just a bit later after startup :) > > One solution is to create a new delay each time we need to wait: > (Delay forMilliseconds: EventPollDelay) wait. > > another, is to make sure that given delay is not scheduled, by sending > Â #unschedule to it at the time when it reinitializing event fetcher. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 21, 2009

[Pharo-project] Another issue with new events

by Igor Stasenko

I unsure if it because of my intrusions.. but it happens second time when i hit 'save the image'. I can't give a textual trace, because at the moment when error appears, image is no longer able to receive the events. Image are saved OK, but then it going through warm startup and throws this error. Now i know what is wrong, and the troublemaker is my code. :) 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. Btw, i just found that saved image, has same problems - it throws the same error just a bit later after startup :) One solution is to create a new delay each time we need to wait: (Delay forMilliseconds: EventPollDelay) wait. another, is to make sure that given delay is not scheduled, by sending #unschedule to it at the time when it reinitializing event fetcher. -- Best regards, Igor Stasenko AKA sig.

April 21, 2009

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

by Nicolas Cellier

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

April 20, 2009

[Pharo-project] Closure simulation errors

by Nicolas Cellier

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...

April 20, 2009

Re: [Pharo-project] Nile and pharo?

by Alexandre Bergel

> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 20, 2009

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

by Nicolas Cellier

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 >

April 20, 2009

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

by Nicolas Cellier

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

April 20, 2009

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

by Igor Stasenko

2009/4/20 Michael Roberts <mike(a)mjr104.co.uk>: > 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. > Thanks, for argument! I'm also trying to be pedantic when proposing this. :) My point was, that its obviously an overkill to have a singleton<class> linked with singleton<instance> without strong evidences where multiple instances could be useful. > 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 >> > > _______________________________________________ > 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] Issue 688 in pharo: Kernel concurrency fixes? 3.10

by Nicolas Cellier

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 >

April 20, 2009

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

by Michael Roberts

just to say that the tests freeze around 10284cl. I was going to mention it but it already came up! Do we run all the tests before pushing out updates? 10281cl ran through ok. thanks, Mike

April 20, 2009