Kevin Fisher wrote:

This is a very subjective question...to anyone that's using Squeak on your handheld of choice, I ask: How responsive does Morphic feel?

Since you're running on a machine about half as fast as my Acorn (until we find solutions to the ARMlinux build problems - I managed to do some more investigation over the weekend and it seems to be mis-optimisation in some places) it will certainly feel very sluggish most of the time. You'll also notice that the 3D stuff tends to be dismally slow since it uses a lot of FP stuff and there is no hardware support.

tim

From: "Eric Arseneau" eat@huv.com

[squeak being very active, polling etc.]

As an example, the Palm platform pushes this idea to an extreme in

order to

increase the lifetime of batteries significantly. When the system is polling the pen location on the touch sensitive screen, the engineers realized that the speed of people moving the stylus and the

resolution of

the touch screen did not require the polling loop to be running all the time. So, the poll loop actually puts the CPU and other

components asleep

for a small unit of time and then wakes up to see if any change

gas occured.

This seems like a very small thing, but they found that this gave

percentage

point improvements on battery consumption. I believe the Squeak

mentality

needs to start to change to go in this direction in order to be more effective on battery driven platforms.

Well, my take on this is that mainline Squeak should become completely passive. There should be an entry point that has an event (or message) as an argument, processes that and then returns control to the host.

If time-based behaviour is desired, these should be scheduled externally, so that events come into the system at regular intervals.

If there is no host system, an adapter can easily be placed on top of the basic passive system to 'activate' it and take the role of the event-supplier (either VM-based or image-based).

Why such a radical change?

Mainly for architectural reasons. First, adding 'activity' to a passive system is easy, just place an event-loop on top of it. On the other hand, adding passive event-reception to a fundamentally active system is much more difficult, because you have conflicting assumptions about ownership of the thread of control. These can only be resolved by leaving each of the parties with its own thread-of-control, meaning multi-threading and the resulting synchronization, or by bizarre and fragile code-intertwining.

Morphic already has much of the basis for this, but because it is implemented on an active substrate, the architectural assumption of active-ness pervades the code, at least that's what it seems like to me. Making the substrate inherently passive would flush out these architectural assumptions, which are often implicit and can go unnoticed for quite some time.

Marcel