Hi,

Image stripping is the most boring and stupid task ever invented
for Smalltalk. Nobody builds a house by taking a rock, a knife and 
starts carving. We should build it step by step and stone by stone. 

Even when the removal task is automated (ST/MT has a good image stripper) 
there are cases you have to take care. If you use #perform: somewhere
in your code you have to reference the symbol of the method you
are calling - otherwise it's not in the runtime image. If method's 
have the same signature they are all in the runtime, even if just 
one is needed since the type info is dynamic. (That doesnt mean 
that we should switch to static typed languages).

The current problem we have is the (currently) unmaintainable huge 
squeak image and the lack of time we are able to spend to repair and
maintain it. There is lot's of stuff in it - MVC, morphic, old code 
from disney, etoys, code from research projects, ... and different
people have different ideas what to do with it.

I agree with Cees that it is wise to have a small core kernel
which should be maintainable by the harvesters. I would vote for
including namespaces and a packaging system into it's metamodel and
try to keep it as small and simple as possible. Starting from this
we could load packages like a command line squeak, traits, croquet,
etoys, morphic, ... and create distributions. 
We should at least have keep one "full image" distribution assembling 
all the interesting projects to keep the dynabook nature and 
multimedia part of squeak.

So what we need is an image builder (maybe from the "spoon" project)
and build a small maintainable core image with support for SqueakMap.

Just my 2 cents.

Bye
Torsten








-- 
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail