Friday, 20 April 2007

0317 GMT

  1. Is Spoon a fork of Squeak, or a future version of it?

          For now, it's a fork; perhaps at some point in the future Spoon could be used as the basis for Squeak. I think it would make sense to plan for Spoon as the basis for Squeak 4.

          I think Spoon would make a good basis for Squeak (or any Smalltalk system), because it's small and extensible, without compromising on reflection, simulation, or portability. It enables a system which is quick and easy to install. This is very attractive to me; installation difficulty has been a classic turn-off for Squeak newcomers, in my observation.

          I also think the way in which Spoon affords extensibility (its module system) would be a big improvement over traditional Smalltalk system organization, and the traditional file-based means of distributing Smalltalk changes. It's much easier to compose a system with such modules, and easier to pull things out (e.g., for deployment in a different snapshot). During distribution, the providing and receiving systems can have a two-way conversation about just what the receiving system needs (and what the providing system has). I have found this to be much more accurate than using files, which represent generic one-way messages from the provider to the receiver. Using live modules often results in a drastic decrease in network traffic, too.

          A Squeak system based on Spoon would need to be a new major version, because Spoon introduces object memory changes which are incompatible with previous virtual machines (e.g., marked method dictionaries), and virtual machine changes which are incompatible with previous object memory snapshots (e.g., method and method dictionary activation marking). We're in the Squeak 3 series now, and there are already several compatibility-breaking changes waiting from the community (e.g., Tim Rowledge's new compiled method format). Let's discuss this!

  2. Would I have to use Spoon's module system to use Spoon?

          No. It will be a part of the kernel Spoon snapshot, so that Spoon can bootstrap itself, but you'll be able to unload it just like anything else. Nothing will keep people from implementing alternative system organizations, change management systems, etc.

  3. What's the smallest snapshot so far? How much bigger would a useful one be?

          The smallest snapshot I've made so far is 1,337 bytes long, on 19 January 2006. You can get the bits and a visualization of its objects (also see my notes about the visualization tools). It adds 3 and 4, then quits. I created it with a new version of the system tracer that I wrote. This tracer is implemented as a feature of the virtual machine simulator. It keeps track of all the objects that are touched during a particular duration of operation, then uses that information to guide a final garbage collection and snapshot.

          The smallest memory I've got that actually does useful things (supports remote browsing, synchronization, etc.) is 162 KB. I think there's some middle ground between that and the smallest possible memory; I'm currently looking for it. :) My current guess is that the eventual snapshot and virtual machine will each be around 64 KB, and the total memory footprint during execution (virtual machine with object memory) will be 128KB. If anything changes, I'll certainly mention it. :)

  4. What is Spoon missing to be useful for scripting?

          This depends on the kind of scripting you mean. For web-based scripting (AKA "server-side" or "client-side" scripting), the fundamental execution functionality is here now. There are certainly improvements to be made, however. For one, the system has not reached its smallest possible size; download time could be improved. For another, there are many common modules left to be tested, such as XML parsing support. Each person will have their own definition of "usable". I look forward to hearing them, and to planning future releases accordingly.

          As for shell-based scripting (à là perl or ruby), I'm working on that, but have nothing releasable yet. In August 2003 I started work on "squish" (a Squeak shell). It's an enhanced version of tcsh that can do all the normal shell things, as well as communicate with a Spoon snapshot in new and bizarre ways. :) The scripts that squish runs are called "squipts". The production system will probably be called "squipt". I've registered squipt.org and squipt.com in anticipation of this.

  5. Are you going to keep calling it "Spoon"?

          Probably. :)   Consider the catchphrase possibilities...

    • There is no Spoon.

    • Spoon is a fork (or Spoon is not a fork, depending on how things go).

    • Spoon will cause quite a stir.

    • SPOOON! The object system of JUSTICE!

          Updating could be called spoon-feeding. "Spoon" spelled backwards is no-ops. And there are already spoons everywhere, providing constant reminders. :)