Hi Torsen,

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

I want to add some comments on this approach of building an image from a
seed.
I have had some interesting experiences building an image "inside" another
image (gestation).
The most important effect of building an image inside another image, is that
the development objects(tools) of the host image can be used to browse and
asist the build process (senders&implementors and contour/references
marking).
Building an image in that way let us change customize an test any part of
the growing image while building.
The built (newborn) image can be saved in image format with a method similar
to image tracers, cutting the link to host image.
I have used this kind of approcahes in private projects (and personal
essays) and has been proved that this method is efficient and confortable in
practice. It also shown me the real difficulty in building images with
stripping vs. building by growing in real practice. The main problem with
stripping is that we must specify what is NOT needed for an
application(/image)... so we must define the system according to the
portions of the system we do not know about (our expreience IN the system
does not help). Building an image from bigBang (from very first objects) let
us define the sistem by composition and oue experience with the system can
be used to know what is requiered.

>Starting from this
> we could load packages like a command line squeak, traits, croquet,
> etoys, morphic, ... and create distributions.

I must say that when we built an image with a low number of objects (e.g.
100kb image), it was interesting to us to built a concrete VM with ONLY the
requiered functionality (with the primitives used in the image). A tool for
building the VM while building the image will be an interesting tool to have
when small images can be built.

If we want to built an image in a declarative way by dynamic composition, we
must support dynamic loading of primitives and provably declarative
specifications for building the VM during booting stage.

cheers,
Ale.



----- Original Message ----- 
From: "Torsten Bergmann" <astares at gmx.de>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, February 04, 2005 1:55 PM
Subject: Shrinking sucks!


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