At 15:59 -0400 on 1999-10-18, you wrote:
0D

>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.

SmallTalkAgents had something like this. Basically you'd point it to 
your project (a project is basically a named change-set if I remember 
correctly) and it would use that as the roots for it's garbage 
collector. Then it would run a multiple pass forced garbage 
collection until pass N+1 resulted in the same image as pass N. It 
wasn't perfect, but it stripped a very large image (2.5 meg?) down to 
about 700 Kb for me. The place where it started to lose is in the 
arena of polymorphism. If you project called method xyz, then ALL 
methods xyz were kept. Dan touched on this with his email about the 
type inference engine.

             Ryan Davis         -=-    Zen Spider Software
-=- mailto:ryand at ZenSpider.com -=- http://www.ZenSpider.com/ -=-
I know that you believe you understand what you think I said but,
I'm not sure you realize that what you heard is not what I meant.