Thanks Ben.
I can tell you that we want to remove all such activeHand. :)
One day it will come.
Stef
Le 3/10/16 à 12:25, Ben Coman a écrit :
On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <b...@openinworld.com> wrote:
On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakh...@gmail.com> wrote:
a JavaScript timeout is a function that takes a block and a period of time,
and after this period of time, puts the block at the end of the event
queue, to be executed as soon as the runtime is done performing the tasks in
front of it.
I am not sure if Pharo has an event queue, so it's a bit harder to do
it(since without one you can't ensure only one thing happens at a time, and
strange things can happen).
That said, in simplest terms, imagine writing a clock app for Pharo, which
updates time every second, in JS this would be done by setting an interval
that ticks every 1000ms, and each time places the callback function(block)
at the end of the event queue.
Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ
Pharo has a single threaded VM, but multiple green threads can run concurrently.
The closest to the event loop you are thinking of most likely the
Morphic UI Process
which you can see using World > Tools > Process Browser. When you execute code
from Playground it runs in that Process (note what Smalltalk
historically (circa 1970s?) has
called a Process is today more commonly know as a Green Thread)
If you select Morphic UI Process you will see its call stack on the
right, where an interesting method is WorldState>>doOneCycleFor:
You can gain some insight by turning on auto-update in the Process
Browser, then open a Browser on WorldState>>doOneCycleFor:
and put "self haltOnce" at the top, then enable it via...
Pharo 5: World > System > Enable halt/inspect once.
Pharo 6: World > Debugging > Enable all break/inspect once.
You will see in the Process Browser that a new Morphic UI Process is
spawned, and the original Morphic UI Process call stack now has
#debugProcess at the top
and a debug window appears that you can step through. Note, since two
UI loops are executing here, the image may lock up, but usually its
fine so hey! live on the edge!
I meant to ask the list about a bug I hit doing this....
Putting a "self haltOnce" here...
WorldState>>doOneCycleNowFor: aWorld
DisplayScreen checkForNewScreenSize.
self haltOnce.
"process user input events"
LastCycleTime := Time millisecondClockValue.
self handsDo: [:h |
self activeHand: h.
h processEvents.
self activeHand: nil.
].
self activeHand: self hands first.
aWorld runStepMethods. "there are currently some variations here"
self displayWorldSafely: aWorld.
When stepping over "self activeHand: nil."
another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil
in GLMPagerPanePreviewMorph(Morph)>>delete
self activeHand
releaseKeyboardFocus: self;
releaseMouseFocus: self.
This can obviously be fixed by wrapping "self activeHand" with an #ifNil:
but alternatively I wonder if the "self activeHand: nil" is really needed?
It seems redundant since activeHand is set at the top of the loop and
immediately after exiting the loop.
Eliminating it would reduce the propagation of #ifNil: anti-pattern.
https://pharo.fogbugz.com/default.asp?19169
cheers -ben
In #runStepMethodsIn: you'll see "queue := self class
deferredUIMessages" for which you enqueue items like this...
http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slowly-td3228060.html
After processing the deferred UI messages, each Morph's #step method
is processed by #runLocalStepMethodsIn:
refer... http://wiki.squeak.org/squeak/2096
The display is then rendered by #displayWorldSafely: calling...
--> #displayWorld
--> #displayWorld:submorphs:
which then is a lot to trace through, but depending on the graphics
back end eventually ends up calling...
Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn:
or...
AthensCanvas>>fullDrawMorph: which ultimately invokes one of many
#drawOnAthensCanvas:
So, for a regular timed UI animation, you would define your custom
morph's #step and #stepTime methods,
and for lower level stuff you would fork like Dennis suggests.
cheers -ben
