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
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@gmx.de To: squeak-dev@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
On Fri, 4 Feb 2005 13:55:11 +0100 (MET), Torsten Bergmann astares@gmx.de wrote:
I agree with Cees that it is wise to have a small core kernel which should be maintainable by the harvesters.
The core of the issue, of course, is that mostly everyone agrees that this is wise. The disagreement (and therefore inertia) is about how to get there.
I propose to "burn the diskpacks". Strip one image, publish it, start maintaining it, and if someone wants Morphic back in, fine, let him/her work on it.
squeak-dev@lists.squeakfoundation.org