The Form of the Squeak Release [LESS LONGISH]

Edward P Luwish eluwish at uswest.com
Thu Jul 15 16:43:54 UTC 1999


Dan Ingalls wrote:

> Folks -
>
> [This is really a footnote to my last message about the 2.5 release]
>

>
> It is even possible to derive a Mini image from the Jumbo, but this is not so simple.  In fact it is fairly complicated and for this reason, each time I have produced a mini image (about once a year), I have posted it on the server for those who are interested.
>

If the complicated process can be automated (made easier by standardizing the functionality of a mini image), then it can be made into a class.  The result is that only the Jumbo release would be required.  I assume this is a lot of work, but it could form the basis of a more general customization architecture that could meet some of  the concerns about modules and plugins.  I think that
the best way to modularize the VM is to (temporarily) remove categories of methods from the interpreter classes BEFORE translating it to C code, rather than adding them afterwards to a fixed kernel interpreter.  This may require some rethinking of parts of the interpreter, but ultimately permits greater control, puts the module sources into the Smalltalk source rather than C addons, and
eliminates compatibility headaches between different versions of loadables.

You are correct that almost everyone has at least ONE Squeak development system (or access to one) that can be used to generate customized images and VMs to run on other targets.  Squeak Central should not perform (test, support) any customizations, but should provide the enabling technologies (which it already does).

As far as the incorporation of everyone's favorite new features, I recommend following the model that has been used successfully for years in the Tcl community.  There has always been a parallel development of "TclX", a collection of everyone's favorite features using an informal release process.  It's similar to the work that stp does.  Most of the work done by the TclX developers has
been to ensure compatibility to the latest Tcl release, which IS formal and centralized.  The most compelling new features of TclX have always migrated into the mainline of Tcl, maybe not very quickly, but who cares? - there is always a way of obtaining the features.  My proposal is to keep Squeak the way it is currently released, and to add a user-supported catchall goodies changeset
that serves as a pool of potential new features for Squeak Central to draw on for inspiration (if not actual code).  This goodies changeset can also be a place for Squeak Central developers to try out partially-baked ideas in a less formal environment.  I am not sure how all this will be administered - just proposing the concept to the community, so please don't flame me on "who's going
to run this" until we have rejected the idea on less pragmatic grounds :-)

Ed





More information about the Squeak-dev mailing list