[squeak-dev] Re: Meeting Report for 8/18/2010

Pavel Krivanek squeak1 at continentalbrno.cz
Tue Aug 24 08:38:45 UTC 2010


On Tue, Aug 24, 2010 at 5:40 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 8/23/2010 4:28 AM, Pavel Krivanek wrote:
>>
>> Hi Andreas,
>>
>> the latest KernelImage based on Squeak 3.10 is here:
>> http://comtalk.cz/public/pub/KernelImage/current/
>> I continuously compared the image to Squeak and commented the changes.
>> For more information see http://www.squeaksource.com/KernelImage.html.
>
> Thanks Pavel, that's *hugely* helpful. I'm seriously wondering how I could
> have missed that - the only explanation I have is that this must have
> happened when I didn't pay any attention to Squeak :-)
>
> One thing that I'm not sure about is how to interpret the scripts at the
> above URL - are they used to create the package structure in the KernelImage
> repository or are they for something different?

Because the smallest kernel.image contains only the platform specific
code for linux, the scripts should be executed there.

The process starts with with the updated morphicCore image. It loads
basic packages like network support and monticello from the
SqueakSource and saves the source code to a file.

Then it shrinks yourself down to the kernel.image, it saves this image
and then it starts to load saved basic packages again. When the image
has Monticello, it loads all packages again from the repository (but
only to have all code in the image covered with packages, no changes
are made).

With the Monticello support it creates the next images up to image
with EToys support. The bootstrapping process then can start again
from the morphicCore image.

> In any case, I think that's very good starting point. I'm curious, Juan, how
> does that stack up to Cuis? Is that similar to the structure you've ended up
> with or very different?
>
>> There are several possible approaches:
>> - take the original KernelImage and adopt it for the latest Squeak. It
>> should be quite easy.
>> - do the similar remodularization and patches as the Pharo did. The
>> package structure of Pharo and Squeak then will be very similar.
>> - Pharo did a lot of important work on the cleanup of the system, it
>> has wider and motivated community of developers and its goals are
>> subset of goals of Squeak. What about to use whole Pharo as the basic
>> system for Squeak and let Pharo people to finish its modularization
>> and focus on tasks important for Squeak? Give me week or two and I
>> will show you that it's possible to load EToys and other Squeak
>> specific stuff to Pharo...
>
> I'm sure it's possible given enough effort. But it won't matter. The issue
> isn't technical, the rift between Squeak and Pharo is something that is the
> result of both personal as well philosophical differences. Contrary to which
> Cuis is much closer to Squeak; not only is Juan a Squeak board member, but
> the idea of having a system that a single person can understand is dear to
> all of us, I think :-)

It is very sad that the Smalltalk community is splitted only because
of political reasons and the amount of technical ones will only grow.
Especially when goals of all fractions seems to be so close...

Of course if you will want to use my work for Squeak modularization, I
will help you.

Cheers,
-- Pavel
>
> Cheers,
>  - Andreas
>
>



More information about the Squeak-dev mailing list