[Squeak-e] adding eventual sending to Croquet's ScriptProcess and ScriptScheduler

[Robert Withers]

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