Stripping out unused sources from Squeak [was: RE: [ANN] SqueakOS ]
cgreuter at calum.csclub.uwaterloo.ca
Mon Oct 18 22:30:36 UTC 1999
On Mon, Oct 18, 1999 at 04:59:03PM -0400, Norton, Chris wrote:
> Hi Folks.
> While reading Tim's thoughts on creating a very tiny VM, I was reminded of
> another line of thought I have had several times over my ST career. In my
> quest to reduce the installation requirements for customer copies of
> Smalltalk programs I have written, I have often wished I had a source
> stripper tool that could read my application code and could suggest what
> other "base" code could be stripped out of my image. I've dreamt of a tool
> that would, given a set of application specific classes, create a proposed
> list of other classes that can be discarded from your image. You would then
> have the option of approving or disproving the removal of all specific
> classes, which the tool could automatically discard. The tool would have be
> powerful enough to ensure you didn't remove any required classes after
> you've overridden its default choices for removal. The tool would also have
> to be smart enough to keep classes around for any global instances/class
> variables that are defined in your image.
> Thus, if you create a simple program that has no UI, the whole UI system,
> MVC, morphic, balloon 3d, etc., would be discarded and you are left with a
> tiny, powerful program that rivals your typical C program in size and power
> (except for the fact that it would be platform independent -- Yay!). This
> would be great for all end-user applications.
> Has anyone done (or thought about) anything like this?
Well, my thoughts tend to be toward something like:
Smalltalk stripToSend: #begin to: AppMainClass
preservingGlobals: #(Foo, Bar)
preservingMessages: #(baz, bobo).
That is, hand it an object and method (or a block?) and it removes
everything not needed to send the message to the object, then saves
the image, then sends the message. The image is a stripped executable
that starts up right away.
Basically, it would trace the first object (AppMainClass), then trace
everything it references, then trace everything they reference and so
on until all references are resolved at which point it throws away
everything else. Then, it would go through all methods with the first
message name (begin) searching for new message names and then trace
through those looking for new names and so on until there's a complete
set of sent messages, after which all unset messages are eliminated.
After this, of course, there may be newly-unreferenced classes about
again so it starts again. It itterates through this until there are
no more changes.
In addition, allow extra messages and globals to be explictly listed
as being kept so that things like:
xxx perform: ('as', className) asSymbol.
can be worked around.
More information about the Squeak-dev