my thoughts on a clean build

Dan Ingalls DanI at wdi.disney.com
Mon Jan 25 16:18:42 UTC 1999


merlyn at stonehenge.com (Randal L. Schwartz) wrote...
>So, if a person from another planet was given just a working VM and
>the Squeak.sources file, how much would they be missing?  Is there
>anyway to ask the image? :)

I don't think they would be missing very much (I'm assuming we have permormed a condenseSources operation so that the sources file includes ALL the current sources).

Given that, there are really only a few structures of significance

	The Smalltalk dictionary

	The Pool dictionaries

	The Class dictionaries

	The Current (top-level) project

The Smalltalk dictionary is almost entirely filled with global refs to classes.  Everything else in it can be enumerated by the do-it in SystemDictionary's class comment (there is one! ;-).  Most of these (Transcript ImageImports ScheduledControllers Display Sensor SourceFiles SystemOrganization Processor) are simple to create.  Similarly, the top-level project is simple to create (there is code in Project to do this).

The only remaining Pool dictionaries (BalloonEngineConstants and TextConstants) have code to initialize them, and nearly every ClassDictionary has code to initialize it in its initialize method or some submethod.  I'm sure we would find one or two cases, though, for which this turns out not to work quite right, though.

So I don't see any problem in doing this, and I think it would be an enlightening project.  One piece of bootstrapping would be required, but I recently added code that makes it very simple.  The system will need a TextStyle in TextConstants, that has one or more StrikeFonts in it.  These must be read in from some file and assembled into at TextStyle.  If you look at the code in FontSet as of the 2.3 release, though, you will see that this is not much more than a one-liner.

If one were serious about this approach, one would want to make two changes during the boot-up process: namely output to the Transcript and calls to the debugger should be fielded by some primitive mechanism until the Squeak structures are operational, just so you can tell if something breaks during boot-up.  The recent change that causes SqueakDebug.log to get written to the disk is probably adequate for most needs.

There is, of course, more to booting the sources that this, because you need to bootstrap the compiler so that you can read the class defs into the Smalltalk Dictionary.

I have never considered this approach (building from the sources) to be very important, and I have always found it easier to use the system itself, rather than some bootstrapping scheme, to clean things up.  I am curious why anyone would want to do this.  The only answer I can see is that there is some mystery about what exactly is in the image (other than what is manifest from the sources) and how one can find it all.  If this is the case, perhaps we need a Squeak Archaeology Toolkit on a web page somewhere, that makes known all the wonderful things that one can do in Squeak to track down any and all extraneous objects in an image.  If there is general interest, I would be happy to take a first crack at this.

	- Dan





More information about the Squeak-dev mailing list