Skip to main content

About Scripts

We were looking into another Croquet performance problem the other day so we fired up a message tally (world menu - debug - start MessageTally). Curiously enough, 70 percent was taken by ScriptScheduler>>runActiveScripts! Unfortunately, the tally did not further differentiate this item.

But what are scripts, anyway? Everyone knows that Smalltalk is all about objects and messages, so what the heck are scripts?

Well, Croquet and Tweak are not just using Smalltalk as you know it (and the underlying Squeak still is pretty much vanilla Smalltalk-80), but instead improve on it by implementing a new enriched object system. There still are objects (the entities of the system) and messages (their means of communication). But where in Smalltalk methods are invoked synchronously by a message send, we now have asynchronous method invocations as well, which are called "scripts".

Synchronous in this context means that the sender sends a message, which invokes a method in the receiver that is immediately processed. Only after finishing the method the control returns to the sender. In contrast, an asynchronous send only schedules a method invocation for later processing, control is immediately returned to the sender. Here is an example (#perform: is synchronous, #startScript: asynchronous):
Transcript perform: #show: withArguments: #('1').
Transcript startScript: #show: withArguments: #('2').
Transcript perform: #show: withArguments: #('3').
If you execute this snippet from inside Tweak, it prints "132". Outside of it just "13" is printed because the second invocation is only started but never executed. There is no ScriptScheduler running to manage the execution of scripts. Inside Tweak there is one, and Croquet does it in a similar fashion.

Historically the term script in Squeak comes from the Etoys environment, where kids make objects and specify their behavior using scripts. One can have multiple objects and multiple scripts for each. All these scripts are running in parallel, at least from the user's point of view. Surprisingly enough kids don't have any problem with that, whereas concurrency normally is a hard problem even for seasoned programmers.

One reason why the parallel execution of interacting scripts is no problem in practice is the underlying scheduling policy: Scripts are never interrupted by other scripts. Other scripts are only executed when your script finished, or when it gives up control explicitly by waiting for an event. You can write your script almost as if it was the only process on the machine. Here's an example script:
| p |
p := CRectanglePlayer open.
1 to: 500 do: [:i |
    p x: i.
    self waitTick].
Looks just like how we did animations back when, right? Move a bit, wait for vsync, repeat. But the best part is this: While the loop is executing, you can perfectly well use anything else in the world! It's running "in parallel" to everything else on screen.

Another advantage is that you can easily have thread-local storage that way. Say, on mouse click you want to change an object's color to red, and on mouse up set it back to what the color was before. In most GUI frameworks you would have to implement both a mouse down and mouse up handler, and use an instance variable to store the previous color on mouse down. Not so in Tweak. The mouse down handler would look like this:
| oldColor |
oldColor := self color.
self color: Color red.
self waitUntil: #mouseUp.
self color: oldColor.
Much cleaner, in my book. Anyway, to get back to the original problem: So scripts are run as separate processes, but MessageTally's spyOn: method normally only takes samples in the process it was run in, which is the main UI process. Fortunately, there is a new method spyOnScript: which does the Right Thing. When starting the message tally from the Tweak project builder's debug menu, this new method is used, and indeed, we got a much more meaningful tally, and could spot the performance hog immediately.

Comments

Anonymous said…
I'm still trying to determine if scripts can be used for objects in 3D Croquet. In an earlier blog entry, you talk about a Tweak-based Croquet, but it looks to me like the TweakTeapot is just embedding the morph in a Tweak project. Maybe that's all that is required? Tweak looks appealing to me, but I'm really interested in 3D-ness right now. Soooo, can Tweak scripts be used in 3D Croquet???
Dave_faught@yahoo.com
Vanessa said…
Yes, you can, and it is already used in Croquet code. The TeapotMorph provides its own ScriptScheduler (see its initialize method).

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is Croquet.io, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: can be hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully controls the inputs to these identi

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Emulating Smalltalk-76

If you got as excited as me about Dan Ingalls' live Smalltalk-76 demo on an actual 1970's Xerox Alto, you may have wanted to try it yourself.  For one, you could try my Smalltalk-78 VM. Smalltalk-78 is a leaner version of Smalltalk-76 but very much identical in syntax semantics.  It is also possible to run the full Smalltalk-76 environment, and here is how: First, you need an emulator for the Alto computer. Ken Shiriff posted a nice piece on how to run ContrAlto on Windows . It is written in C# and I got it to work on my Mac using Mono. So here's a step-by-step: Install Mono from  http://www.mono-project.com/download/ Download ContrAlto-mono.zip from https://github.com/livingcomputermuseum/ContrAlto/releases Download this Smalltalk-76 disk image: http://www.bitsavers.org/bits/Xerox/Alto/disk_images/chm/xmsmall.zip Unzip both  ContrAlto-mono.zip  and  xmsmall.zip  in the same folder. In a terminal, change to the ContrAlto directory and run mono Contralto.exe .