Hi!

Cees de Groot <cg at cdegroot.com> wrote:
> On Fri, 4 Feb 2005 11:12:26 +0200, <goran.krampe at bluefish.se> wrote:
> > What you describe is already being done in the Spoon project mainly
> > worked on by Craig Latta:
>
> I know.

I know you know, and you know I know you know :), but perhaps Jan didn't
know.

> > This work is planned to eventually become the base for Squeak 4 or 5.
> 
> I know that to. The whole uncertainty of planning, of where it's going,  
> etcetera, makes Spoon - while an extremely interesting piece of work - a  
> more longer-term goal. When it's there, it's nice to start with; as long  
> as it ain't there we should not let everyone wait. One doesn't preclude  
> the other, IMO.

I agree of course. And I also have fears of Spoon not "getting there".

> > Eh, well IMHO the problem with uninstalling packages is not exactly what
> > you describe.
> 
> Yup. But I think you agree that it's hard. IMO harder than taking an  
> arbitrary package, attempting to load it on a too small image, and fixing  
> dependencies, whatever.

Yeah.

> > 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.
> 
> If that is necessary just for making sure that the package can be  
> unloaded, I think it's throwing out the baby with the bathwater.

I didn't mean that. I just tried to explain that to be 100% *sure* about
it - we need to take code side effects into account. But if we just move
to Monticello and look through the class initializers - we should be
pretty fine. A malicious package would still be able to screw you over,
just so everybody understands that.

> > 2. If arbitrary code still should be allowed to run - we need
> > transactional object memory and/or some kind of sandboxes. Hehe, yeah,
> > right.
>
> Yup. Very long term goal :)

Right. :)
 
> > 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.
> >
> That's a bit the problem that I'm having with all this. "Soon" we'll have  
> Spoon. "Soon" we'll have Tweak. Etcetera. We're waiting for stuff that  
> might or might not happen, while it's about time to do something (I really  
> think that Squeak deteriorated during the 3 series)

I agree. And I am just trying to describe various paths forward. I also
wouldn't want us to just wait for Tweak and Soon - two projects that are
"high risk" in various respects. Spoon is IMHO high risk because there
are so few committed to it.

And Tweak is high risk because the project seems so.... well. Andreas
surely will get annoyed with me for saying so - but it feels pretty
closed. Yes, I know - we now have the code - but in what direction is it
going? Perhaps I am just being... whatever. :)

So sure, picking a small image (One of the older ones? A severely shrunk
new one? Whichever) and then starting to build a load-chain on top of it
is a great way to go. Especially since if we automate the load chain we
can later switch the start image to another one - if we decide it was a
bad one to start with. The "bootstrap chain" will still be usable.

So I assume first task with a small kernel is to get Monticello into it
and working. Then SqueakMap. Hmmm, feel a bit tempted to try this
myself...

> > 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.
> >
> That bit has to be done anyway, so I'll be glad to help.

Cool. Then we are 2. :) More people joining up? This is all in the
"let's do it, damnit" spirit - I got so tired of all the
yaddayadda-threads the last month. Though I will respond to those too
soon.

regards, Göran