In message <8525690E.0067B178.00 at intlnamsmtp20.us.pw.com> you wrote:


> Thanks for your reply. However, I believe that my point #2 and #3 still refer to
> different aspects of tailoring the Squeak environment.
Believe me John, I understand the problems all too well having suffered
the need for many years!


> The requirement here is to strip out all classes
> and methods that are not specifically called by the program (same functionality
> as C++ compilers). This process includes stripping out the all of the
> development tools. The stripping process may remove only parts of modular
> plugins or categories as well as entire subsystems. The goal is to create a
> "runtime" image for the user.
Although stripping can be done quite thoroughly if you use a whittling
down process (like we used to use in VW when I was still at PPS; you
remove unused stuff, loop back and remove stuff left orphan by that
removal, repeat until bored) and care, it's a hard path. Since we don't
(thank goodness) have types, you don't get to check them. Lex shewed a
pretty impressive inferencer at last years OOPSLA that would help a
great deal in trying to do a whittle, but you'll still be left with
uncertainties.

Building up from a base and modules _could_ (if done sufficuently
well) mean not having to worry about this. To produce your deployment
'image' you simply leave out all the stuff you think is not needed. The
smaller and more focussed each module is, the more certain you will be
about whether you need it or not.

Another intriuging possibility that would be great in some cases and
useless in others would be to have an on-demand repository of all the
class & method (come to that, any object might be useful) so that a
running image could load just what it needed, when needed. We have
finally got a basic run at this into the VM codebase. Demand loading
would probably be great for net connected machines and suchlike, but I
can also see possibilities for small machines where we would have the
repository in ROM and thereby keep the RAM demand down to what is really
needed.

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Why Dogs Hate WIn95:-17)  Too difficult to "mark" every website they visit.