astares at gmx.de
Fri Feb 4 12:55:11 UTC 2005
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.
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
More information about the Squeak-dev