On Mon, Oct 3, 2016 at 6:47 PM, CodeDmitry <dimamakh...@gmail.com> wrote:

> LOL (in GrowlMorph):
> is: rect saneWithRespectTo: morphs
>
>         ^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph
> bounds
> intersects: rect]]) not
>
> for some reason I find this method name quite amusing :3
>

There are interesting things in there indeed. "Intention revealing" enough?

>
>
> Let me guess;
>
> 1. "World defer: aBlock." defers the event to be called as soon as
> possible(not necessarily now).
>

Actually this works for any Morph in 5.0

Morph>>#defer: aValuable
"aValuable will be executed in the next UI rendering cycle"
self owner
ifNotNil: [ self owner defer: aValuable]
ifNil: [ UIManager default defer: aValuable ]

UIManager (MorphicUIManager) will do this at one point (track implementers
'til class side in WorldState)

defer: aValuable
"aValuable will be executed in the next UI rendering cycle"
self addDeferredUIMessage: aValuable.

This will stick it in a queue:

deferredUIMessages

^DeferredUIMessages ifNil: [DeferredUIMessages := WaitfreeQueue  new].

and then, there is interesting black magic going on

runStepMethodsIn: aWorld
"Perform periodic activity inbetween event cycles"
| queue nextInQueue|
"If available dispatch some deferred UI Message"
queue := self class deferredUIMessages.

[(nextInQueue := queue nextOrNil) isNil]            "<<----------------
here all is happening -------"
whileFalse: [ nextInQueue value].

self runLocalStepMethodsIn: aWorld.                 "<<------------ step
methods -----------------"

"The multi-threaded global Transcript needs to be updated periodically and
synchronously with the UI."
Transcript stepGlobal.
 "<<------------ and *this* is some black magic for Transcript ----"


Fun thing:

stepGlobal
" The superclass method Model>>step indicates a convention that might be
used to interoperate
synchronously with the UI-thread.  However when multiple Transcript windows
are open, their
PluggableTextMorphs share a single instance, from the global Transcript.
To avoid potential trouble,
this method should not be named #step.
As well, we need this method to execute even when no Transcript windows are
open, so the stream
continues to be reset periodically, otherwise it would grow indefinitely.
So this method is invoked
from WorldState>>runStepMethodsIn:.
"

"Next three lines required temporarily to initialize instance variables
added to existing instance"
deferredClear ifNil: [ deferredClear := false ].
deferredEndEntry ifNil: [ deferredEndEntry := false ].
stepContents ifNil: [ stepContents := '' ].
deferredClear ifTrue:
[ deferredClear := false.
stepContents := ''.
self changed: #clearText.
].
deferredEndEntry ifTrue:
[ deferredEndEntry := false.
self critical:
[ stepContents := stream contents.
stream resetContents.
].
self changed: #appendEntry.
].

Just in case one was wondering how Transcript clear actually works, check
this:

clear
" Clear all characters by resetting the stream and voiding any previously
flagged deferredEndEntry.
Redisplays the view by signalling for #step to send #changed: .
"
self
critical: [
deferredClear := true.             "<------- magic! -------"
deferredEndEntry := false.     "<------- more magic!--------"
stream reset ]


Good luck to infer that from scratch.





> 2. "[Block] fork" is called immediatly, but on a new thread.
>

Yeah, use forkNamed: aString if you actually want to track the thing easily
in the Process Browser.



> 3. "<number> <time unit> wait"  blocks the current thread for specific time
> before continuing.
>

Right.

>
> Now rearrange it into:
>
> [
>     10 seconds wait.
>     World defer: [
>         Transcript show: 'Hello, World!'.
>     ].
> ] fork.
>
> Into
>
> do: aBlock after: nanoTime
>     [
>         10 seconds wait.         "<------- you need to say something like
> nanoTime asNanoSeconds wait. But careful as Delay works up to milliseconds
> I think, so 5 asNanoseconds asSeconds will just be zero"
>         World defer: aBlock.  "<-- OK, World is a WorldMorph, wich extends
> PasteUpMorph, the old World class in Pharo 3.x"
>     ] fork.
>
> I guess that all of this shows that there is some flexibility in Pharo
async.

Check the Generator class for some brain twisting with fork.

Run

Generator examplePrimes.

for a start.

Phil

>
>
> --
> View this message in context: http://forum.world.st/Intro-
> to-Microsoft-COM-for-Smalltalkers-tp4917738p4917913.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Reply via email to