Tim Rowledge wrote:
> 
> On Mon 18 Jan, Dwight Hughes wrote:
> > Alright now, let's not get into a "tastes great"/"less filling" debate.
> > :-) I find it quite interesting to consider what one might potentially
> > do with the combination of an ImageCreator (which would be part of the
> > Squeak image, not an external static program) _and_ the SystemTracer.

> Err, I'm confused; not that this is such an unusual occurence you
> understand :-)
> One way to  read your sentence above is that you think the SystemTracer is
> an external program - but I'm convinced you don't actually mean that since
> you have demonstrated on plenty of occasions that you know what you're
> talking about. 

Thanks, and no, I don't mean that the SystemTracer is an external
program. What I was emphasizing is that the ImageCreator should _not_ be
an external program (at least not in the "creator" Squeak image). I
think some might visualize an ImageCreator as a specialized external
"static" program for reading in a large pile of Smalltalk source and
automagically turning it into an image with a particular format (much
like some Lisp systems do to bootstrap their images) -- but this is
*not* what I'm thinking about. I'm talking about leveraging off of the
capabilities already present in the Squeak image and adding to it this
new capability. [When I made my comments in the Squeak FAQ page on
creating a Squeak image from scratch, the basic constraint was how to
create a Squeak image from only source when you had *no image* of any
sort to begin with.]

An ImageCreator should fundamentally be able to an image from scratch
(duh - but this does not imply that it would bootstrap its own running
image into existence), and this by itself has a number of nice
properties -- being able to create known "clean" images directly from
the source, being able to create the absolute minimal image for
delivery, treating Smalltalk in a more declarative manner with
separation of development image from application image, direct simple
source management and versioning control, separation of the definition
of the image's functionality (the complete declarative source) from the
format of the image itself, .... There are other ways to approach each
of these tasks, but I think having the ability to directly create images
from source is the simplest, most direct, and most generally useful
approach. John Sarkela's comments on the difference "between the
specification of a thing and the thing itself" and the importance of
this are central to the advantages of this approach. [Note that Squeak
is presently NOT entirely defined by its source -- information is
present in its image that was interactively defined at some point. So
getting a clear, precise picture of what the Squeak system really is and
how it all works is made more difficult than necessary.]

>               So I'm puzzled as to what you see an ImageCreator doing that
> the cloner doesn't already do? I've used it on many occasions to create new
> images with different content, format, layout, and whatever else I have had
> to alter. What is missing? Is it just too-early mental binding of
> SystemTracer to some idea of 'merely' recreating the extant image?

I don't see the issue as "either the SystemTracer OR an ImageCreator"
but as "both the SystemTracer AND an ImageCreator". The critical thing
is that an ImageCreator would enable a new style of operation for Squeak
-- analogous to the difference between trying to port an application to
Squeak by repeatedly attempting to file it all in and trying to debug
the conflicts and failures within your now modified image OR instead
using the FileContentsBrowser to directly examine the code and
manipulate it into a safer, more predictable form using a stable, known
image before filing it in to test. I see an ImageCreator as able to
directly handle large scale restructuring, refactoring, and rewriting of
the system -- no matter how critical the parts of the system -- and be
able to do so all at once in a largely order independent fashion (just
define all the classes up front and go on down the road). Since the
image being built is not the running image much is simplified. You would
not have to "sneak up on it", or carefully juggle things just so like
you had to do in creating your new CompiledMethod format image (though
you may not consider the manipulations as any big deal, since you are
very fluent in SystemTracer -- but even so, when all you have is a
hammer...). Can the SystemTracer produce an image that is non-isomorphic
with the spawning image? Say an image where the class structure desired
is entirely and fundamentally restructured from the spawning image?

-- Dwight