> More generally, some of the losing changes/sources problem could
> probably be helped by the suggestions bandied aruond a while ago
> about putting the sources 'in the vm' in some sense (ie mac resource,
> windows resource, Acorn app.dir., unix links etc) and perhaps, by
> making releases that have condensed sources and null change logs (so
> it gets created on first startup rather than being looked for).

I was going for the minimum cognitive overhead.
People are used to the idea of an "application & document" on their
host OS.

	VM = application
	image = document

Simplicity itself. Why hide the sources in the VM? Make them
accessible and understandable from within Squeak.  What could
be eaiser to understand than having CompiledMethods having an instVar
named 'source' that points to a string?  What could be easier to extend
than having a source pointer that points to an object?

One could always have a method that externalizes the sources, so
people who understand the sources/changes mechanism could easily generate
them.

I'm always seeing people new to Smalltalk doing things like starting
an image from a directory other than the current working directory,
and then saving image to a new name.  It doesn't work right in squeak.
The changes gets copied to the original image directory, but the new image
gets saved in the current working directory.
(VW can't even find the changes file BEFORE saving).


-- Mike Klein