[Squeak-e] adding eventual sending to Croquet's ScriptProcess and
ScriptScheduler
Robert Withers
rwithers12 at attbi.com
Sat Feb 15 21:41:14 CET 2003
On Saturday, February 15, 2003, at 10:41 AM, Andreas Raab wrote:
> Rob,
>
>> What do you think would be the best way to activate the resolver?
>
> Remember the resolver in the process' properties (cheap way to
> experiment
> with it - later we may want this to be an iVar) and then use
> #stopScriptProcess: to notify the resolver (if there is one). Seems
> like the
> simplest solution to me. One more thing to keep in mind though:
> #stopScriptProcess: is also invoked from #terminate and you'll
> probably need
> something else to notify the resolver that this promise was broken.
Andreas, I have integrated eventual sending into the Scripting
framework. It looks like there may be a reference issue with
#waitUntil:, since I have to inspect the scriptProcess or the results
are intermittent.
The easy way was an EventualScriptMessageSend, which holds the
resolver. The #valueWithArguments:event: method computes the result
and resolves the promise ( or smashes it).
If you load SqueakElib ( http://swiki.squeakfoundation.org/squeak-e/3 )
into a *throw away* Croquet image (I modify the Interpreter), then
load this changeset: (
http://swiki.squeakfoundation.org/squeak-e/uploads/3/croquet-squeake-
bridge.cs ).
You can look at the comment of CroquetContext for examples.
But...there is an issue:
The problem i am having is that I can't seem to get #waitUntil: to
work. I need that so that a send of #immediateRef, to a promise, will
result in that script blocking, until the underlying computations have
completed and resolved the promise. This computes intermittent
results. I believe that the ScriptProcess is going away. So, to
test I tried building a test out of this:
[Transcript cr;
show: 'platformName: ';
show: ((Smalltalk startScript: #platformName) waitUntil: #done;
result) ] newScript resume.
Otherwise it is working well, and I now have a "working" (minus the
issue above) CroquetPromiseContext>>#immediateRef. :-))))
I am really impressed with the work you have here, Andreas. It's
really powerful.
cheers!
rob
Here is the performance dump of a regular smalltalk expression and an
eventual smalltalk expression that is fairly intensive, but it only
evaluates 4 eventual message sends. The cost of an eventual send is
between 20 and 80 ms. I need to figure out a way to make these
measurements more accurate.
The performance ratio is: 1.032
Output from straight smalltalk
Morphs with more than 50 instances
Thumbnail => 118
PolygonMorph => 139
BorderedStringMorph => 62
AlignmentMorph => 253
ThreePhaseButtonMorph => 61
SameGameTile => 201
Morph => 267
TransformMorph => 58
StringMorph => 1379
TileMorph => 58
ImageMorph => 193
ScrollBar => 58
SketchMorph => 157
RectangleMorph => 611
IconicButton => 143
SimpleButtonMorph => 101
WordGameLetterMorph => 320
start time: 23985907
stop time: 23996228
running time: 10321 ms
Output from the eventualCroquetRef
Morphs with more than 50 instances
Thumbnail => 118
PolygonMorph => 139
BorderedStringMorph => 62
AlignmentMorph => 252
ThreePhaseButtonMorph => 61
SameGameTile => 201
Morph => 267
TransformMorph => 55
StringMorph => 1361
TileMorph => 58
ImageMorph => 187
ScrollBar => 55
SketchMorph => 153
RectangleMorph => 588
IconicButton => 139
SimpleButtonMorph => 101
WordGameLetterMorph => 320
start time: 24012995
stop time: 24022998
running time: 10003 ms
More information about the Squeak-e
mailing list