"Norton, Chris" <chrisn at Kronos.com> wrote...
>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?

This is why I'm so eager for someone to finish a type inference system for squeak (a couple of people have started).  A good type inference system can do a great job of this.

HOWEVER, one can do a great deal without it, and there is a fair amount of code right inside of Squeak that addresses this task already.  Check out the category 'shrinking' in SystemDictionary, and most particularly the method removeAllUnSentMessages, and the way it is used in majorShrink.

This is how I produced the last mini image (2.2) that had a full development environment in a 580K image, and it was also used to produce the earlier headless image that was 250K.

It's not automatic, but it's pretty usable once you get into it.  Note that it leaves in several other useful routines such as printSpaceAnalysis, which will tell you how many instances there are of every class and how much space they consume in the image.  The zero instance counts are a useful guide to what other classes can be deleted.  Another good guide is obsoleteClasses which will list classes you have deleted but that are still referenced.  Usually these are because of code that doesn't get used, but sometimes they are held onto by orphaned instances.  Those in turn can be found by inspecting the obsolete classes and using the inspector to find all objects that point to the obsolete class (and so on up the chain until you find something that makes sense).

Just wanted to let folks know that there are lots of tools that can help with this already.

	- Dan