jb at speed.net
Thu Apr 9 23:57:13 UTC 1998
Andreas Raab wrote:
> Why don't we just take
> out stuff that is not needed to actually run squeak in some sort of
> plugins?! The only thing which would be needed is a well-defined
> to access, register and unregister from the VM. Than we could put a
> lot of stuff in separate classes (such as BitBlt) and keep the actual
> interpreter small.
> Even more, we could build customized VMs for certain application
> which might not include networking, sound, or even file support (if
> running a bare chip system). Also, adding new stuff would be probably
> easier - you would not have to modify the Interpreter but could just
> create a new plugin which can be translated into C code.
I like this approach. If we could seperate most of the machine specific
I/O out of the Interpreter and place the support into "plug-ins", this
could satisfy most of the concerns that have been voiced on the list
lately. Shrinking Squeak for hand held devices seems diametrically
opposed to multi-megabyte devolopment environments. A configurable VM
would seem to solve this problem nicely.
A facility for message passing from the VM should also be formalized.
Here is an example: I am currently working on native widgets for the
Mac. The Mac VM event dispatching loop is sprinkled throughout the VM.
When a window update event is received, the VM passes the event to C
support code. What I would like to do is pass a message from the VM to
an window object in Squeak saying "this window needs updating".
Of course, a pluggable event handler in the VM would mean that a person
on a big machine could write their event handler in Smalltalk, while a
person writing for a hand held device could keep all of their event
support code in C.
This of course brings up another question -- how do we handle image
startup / configuration ?
More information about the Squeak-dev