Whither Squeak?

Pavel Krivanek squeak1 at continentalbrno.cz
Sun May 21 13:46:41 UTC 2006

> I wonder why Pavel don't say he could build a basic console with no MVC and
> no Morphic.
I was on an official trip
> I prefer use his old 3.7 kernel and not his new 3.9 , but is my taste.
> Others could start from his newer.

There's no conceptual difference between kernel image for Squeak 3.7 and 
Squeak 3.9, but Squeak 3.9 includes m17n and some other code that makes 
this image much bigger. Kernel image form Squeak 3.7 is perfect starting 
point for some kind of applications like PocketPC games. Shrinking 
operations in kernel image for Squeak 3.9 are less destructive and this 
image is definitely better in many ways.

> Or take Boris procedure for a MVC image if they like MVC.
> The hard thing (to me) is how you grow again.
> How you go from Spoon (the favorite choice of many) or from Boris MVC or
> from Pavel kernel to what we wish ?
> How many people realize what current MC1 fails load (in small images what
> could understand Monticello and friends) because class initialization is not
> fileOut in right order ? (as in Network)
 From my point of view, the best next progress can be:
1a - take the kernel image for Squeak 3.9 and merge all relevant fixes 
since 6719
1b - create simple mirrors browser for more comfortable work
1c - create some fixes like WideString problems with condesing of 
changes etc.
2a - clean the kernel
2b - merge SUnit and relevant test
2c - create new important tests
3 - test the kernel image
4 - load everything back to create basic image. Don't create packages, 
just simply load new classes and methods and initialize it in the right 

(Task with the same number can be done in parallel)

Then we will have nice UI independent kernel image and perfect 
referential material for next packaging effort.

Then we can do the same process with next packages like network support, 
compression etc. Separate, load everything back.  It will be the set of 
small steps but with every one we will get the next clean package with 
the defined relation to the kernel and prerequisites.

Just an idea. I think that it's doable. If we reached the state when we 
have consistent UI-less kernel image, why don't continue? The packaging 
"from top" and standard Squeak development and fixing can still continue 
because with every step we will have full image. So, what about to 
establisth a team for that?

If we will have kernel image, the set of "primitive" packages like 
network, compression, UI independent MC and one big package "the rest of 
Squeak", we can mark it as Squeak 3.10 and then begin with version 4.0 - 
adopt many Spoon ideas, change VM and image format etc.

-- Pavel

More information about the Squeak-dev mailing list