Hi all!

=?UTF-8?Q?Jan_B=2E_Krej=C4=8D=C3=AD?= <janbkrejci at gmail.com> wrote:
> > I've been busy shrinking a 3.6(wx) image today. What a mess.
> 
> probably many of us have faced the same. Few weeks ago I have
> discussed another possible approach with Pavel Krivanek.
> 
> In my opinion we should focus not on cutting parts of today's huge and
> messy image, but on building a compact, well shaped image from zero
> up.

What you describe is already being done in the Spoon project mainly
worked on by Craig Latta:
	http://www.netjam.org/spoon/

This work is planned to eventually become the base for Squeak 4 or 5.
Craig has high hopes for getting to a really interesting point during
2005. If you can and want to help Spoon - do so. :)

[SNIP]
> Another issue concerning image cleanup is (and it was also discussed
> here many times already) to find a way how to unload any package
> completely. Even linux distributions do NOT clean up correctly in all

Frankly - I don't think this part is at all the real problem. The
problem is untangling.
But IMHO we should care that much about untangling for starters - the
goals of TFNR (a dormant project) was to make sure we *assign
maintainers* to *clearly defined parts* of the image in order to come
around the harvesting bottleneck and to improve the sense of ownership
and responsibility etc. I still very much think this is *THE* way to go,
but in parallell with other routes - see below.

And also, since we now have PackageRegistry I really think we should get
going with this.

> cases. I know it can be almost impossible to remove methods added with
> the package to classes outside it (like adding IsWhatever to Object).
> Many people seems to think that until we don't solve this, we'll never
> have 100% pure system. Undefining messages is not a problem until two
> packages will modify the same concurrently.

Eh, well IMHO the problem with uninstalling packages is not exactly what
you describe.
If all packages were forced to be constrained to be Monticello packages
(without dirty code running in class initializers) - then we would more
or less already have that. But they aren't.

Changesets and .st files and .sar files all have the possibility of
*executing arbitrary code* on install. And in fact - Monticello packages
have that option too - using class side initialize methods.

And that code can do stuff. And there is of course currently no
theoretical way of restoring those actions. Two choices:

1. Don't allow code to run on package installation. Class initilization
still needs to be done, so either that code HAVE TO be nice or we will
have to come up with another way to do class initialization - or sandbox
it somehow. Realistically we would have to simply make sure that code is
"nice" and gradually move that code over to other more "declarative"
mechanisms.

2. If arbitrary code still should be allowed to run - we need
transactional object memory and/or some kind of sandboxes. Hehe, yeah,
right.

So given that 2 is simply too much work to just "do" over the weekend,
number 1 is still the way to go. And given that we can't remove class
initialization - we will have to make sure that the code running there
behaves correctly. And then we would have to convert all packages over
to the .mcz format (or .sars with only .mczs and no postscripts). Which
of course wouldn't be a bad thing. :)

> But when we would have separate small packages, reconstructing the
> image without one package is trivial (we just start again with empty
> one and load all the other packages in), so we do not need to be able
> to remove package cleanly, therefore the time wasted creating unload
> scripts can be wasted with something more funny.

Well, as I described above - it isn't that simple. You would still need
to *produce* all those packages. Just try ripping out something from
Morphic and you will soon understand what we mean. It is hard work. On
the other hand, given that Tweak soon is operational (?) perhaps we
stand a better chance.

Now - in short, my choice of attack would be something like this (in not
exactly this order, and many things can be done in parallell):

1. TFNR. Yes. Let's finally partition the image and put people in charge
of each part. Yes, the parts will still be totally intertangled - but
each line of code will have a maintainer. And each logical "tool" or
"mechanism" will have a caring Squeaker. We should do this NOW.

2. Get all the VM people to help Craig with Spoon. Get the VM changes he
has made into the regular official VM ASAP.

3. Create a category on SM called "unloadable package" (or something)
and gradually start to migrate packages over to Monticello with *nice*
class initializers. Again, unloadability is not key to all this, but we
can still do it. Having stuff in Monticello format is on the other hand
pretty important - especially for having correct upgrades (the other
formats can't do that).

4. Start moving tools over to Tweak, so that we can get rid of Morphic.
And move to newer tools where appropriate - like Omnibrowser instead of
the old browser etc. In essence we need Omnibrowser, a workspace,
exporer/inspectors and a debugger. At least. :)

5. Get Monticello/SqueakMap and other low basics to load on top of
Spoon. Then Tweak. Then OmniBrowser and the tools. :) Or whatever. We
need to get a *head* on Spoon with a minimal tool env. Noone will choose
to "live" there until it has that at a *minimum*. So until we get there
the manpower working on Spoon will be low.

6. Get the next release of SM out with full dependencies.


Well, something like that. Ok, do we have someone willing to be General
on this? I can and should grab number 1 and get that done. And damnit, I
will. But I need help with the rest.

regards, Göran