Yassine Khlifi
Bull, Architect of an Open World TM Centre De Services Paris e-mail: yassine.khlifi@bull.net tel : 01-69-93-92-92 (223-9292) site : http://www.bull.com
|---------+---------------------------------------------> | | squeak-dev-request@lists.squeakfou| | | ndation.org | | | Envoyé par : | | | squeak-dev-bounces@lists.squeakfou| | | ndation.org | | | | | | | | | 25/03/2009 12:58 | | | Veuillez répondre à squeak-dev | | | | |---------+--------------------------------------------->
-------------------------------------------------------------------------------------------------------------------------------|
| | | Pour : squeak-dev@lists.squeakfoundation.org | | cc : | | Objet : Squeak-dev Digest, Vol 75, Issue 43 |
-------------------------------------------------------------------------------------------------------------------------------|
Send Squeak-dev mailing list submissions to squeak-dev@lists.squeakfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev or, via email, send a message with subject or body 'help' to squeak-dev-request@lists.squeakfoundation.org
You can reach the person managing the list at squeak-dev-owner@lists.squeakfoundation.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Squeak-dev digest..."
Today's Topics:
1. WorldState deferredUIMessages queue (Chris Muller) 2. Re: WorldState deferredUIMessages queue (Andreas Raab) 3. Re: WorldState deferredUIMessages queue (Andreas Raab) 4. Re: [bug] xor: is this an old bug or what? (Eliot Miranda) 5. Re: Re: WorldState deferredUIMessages queue (Bert Freudenberg) 6. Re: Re: How to get a list of all plugins in VM (Andreas Raab) (Igor Stasenko) 7. Re: WorldState deferredUIMessages queue (Andreas Raab) 8. Re: Re: WorldState deferredUIMessages queue (Igor Stasenko) 9. Re: Re: OSProcess capabilities on Windows (UZONYI Levente) 10. Agenda for Board meeting March 26th 2009 (Andreas Raab) 11. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 12. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Andreas Raab) 13. Re: [bug] xor: is this an old bug or what? (Klaus D. Witzel) 14. How to tell if you have a boolean when you care to know (Jerome Peace) 15. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 16. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Andreas Raab) 17. Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Aran Lunzer) 18. Re: Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on Windows] (Simon Kirk) 19. Re: Newbie Questions (Keith Hodges) 20. Monticello compatibility (was Re: Newbie Questions) (Bert Freudenberg)
----------------------------------------------------------------------
Message: 1 Date: Tue, 24 Mar 2009 16:17:37 -0500 From: Chris Muller ma.chris.m@gmail.com Subject: [squeak-dev] WorldState deferredUIMessages queue To: squeak dev squeak-dev@lists.squeakfoundation.org Message-ID: 1ac5f6d0903241417h59b47a76o3142401a0a852f35@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1
(3.9 Morphic). With Maui I occassionally get World lockups due to the UI process waiting for the #next of the deferredUIMessages, which is empty.
Specifically, the freeze, when it occurs, is always in WorldState>>#runStepMethodsIn:. There's a while loop to process messages in the queue:
"Dispatch deferred messages while maintaing rudimentary UI responsiveness." [i < numItems and: [(Time millisecondsSince: stamp) < limit]] whileTrue: [queue next value. i := i + 1].
and its hung waiting for "queue next". But it seems like this shouldn't be possible because, at the top of the method, "numItems" is set to the size of the queue.
numItems := queue size.
and so the only explanation is, somehow in processing one of the messages, it causes another one to be removed from the queue. This appears to be possible if the first message calls a #doOneCycle, leading it back through this same method..
I do have 4 or 5 #doOneCycles sprinkled around, in order to force correct layout or screen redraws. I'm pretty sure these are causing the deadlock but.. when I tried taking some of them out I get the layout/redraw problem..
Any advice is greatly appreciated.
- Chris
------------------------------
Message: 2 Date: Tue, 24 Mar 2009 14:37:26 -0700 From: Andreas Raab andreas.raab@gmx.de Subject: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 49C95296.1030208@gmx.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chris Muller wrote:
(3.9 Morphic). With Maui I occassionally get World lockups due to the UI process waiting for the #next of the deferredUIMessages, which is empty.
Specifically, the freeze, when it occurs, is always in WorldState>>#runStepMethodsIn:. There's a while loop to process messages in the queue:
"Dispatch deferred messages while maintaing rudimentary UI
responsiveness."
[i < numItems and: [(Time millisecondsSince: stamp) < limit]] whileTrue: [queue next value. i := i + 1].
This is plain wrong. I don't know what the rationale of the change was but you'll have much better success if you change this to e.g.,
queue := self class deferredUIMessages. [(msg := queue nextOrNil) == nil] whileFalse: [ msg value. ].
The reason why the original version is wrong is that there is absolutely no assurance that some Morph won't call World doOneCycle which would re-enter the above loop, pull out all of the events and leave the original caller hanging; just as you report.
Cheers, - Andreas
------------------------------
Message: 3 Date: Tue, 24 Mar 2009 14:43:24 -0700 From: Andreas Raab andreas.raab@gmx.de Subject: [squeak-dev] Re: WorldState deferredUIMessages queue To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 49C953FC.70405@gmx.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chris Muller wrote:
Any advice is greatly appreciated.
Actually, here is a fun test to exercise the problem:
testDoOneCycleWorksWithDeferredQueue "Ensure that nested doOneCycles don't break deferred UI messages" | finished | [ WorldState addDeferredUIMessage:[World doOneCycleNow]. WorldState addDeferredUIMessage:["whatever"]. World doOneCycleNow. finished := true. ] valueWithin: 1 second onTimeout:[finished := false]. self assert: finished
Cheers, - Andreas
------------------------------
Message: 4 Date: Tue, 24 Mar 2009 15:01:45 -0700 From: Eliot Miranda eliot.miranda@gmail.com Subject: Re: [squeak-dev] [bug] xor: is this an old bug or what? To: "Randal L. Schwartz" merlyn@stonehenge.com Cc: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Message-ID: 3ac5ce8a0903241501k73fafc2ei142aa2000d4d436a@mail.gmail.com Content-Type: text/plain; charset="iso-8859-1"
On Tue, Mar 24, 2009 at 1:36 PM, Randal L. Schwartz merlyn@stonehenge.comwrote:
"Eliot" == Eliot Miranda eliot.miranda@gmail.com writes:
Eliot> I think just
True> xor: aBoolean Eliot> ^aBoolean not
False> xor: aBoolean Eliot> ^aBoolean
Eliot> and then leave subsequent usage to catch possible type errors;
e.g.
(false Eliot> xor: #blah) ifTrue: ... will raise a mustBeBoolean error.
What I don't like about this is that the right operand doesn't get a
chance
to "boolify" itself, or define its own xor logic. The double-dispatch versions were a lot better at that.
If you want to do that you could implement it as
False> xor: aBoolean ^aBoolean not not
but I'd argue that isn't necessary. The old code didn't type check and we've lived with it for a loooong time.
But in any case, the not is a form of double-dispatch. It just points out that one can use not instead of xorTrue and is more comprehensible because "not" is familiar.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
squeak-dev@lists.squeakfoundation.org