On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <juan at jvuletich.org> wrote:
> Andreas Raab 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?
>>
>> 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?
>
> I have only looked at Pavel's work very briefly, so my comments might be
> wrong. The main focus of KernelImage is about modularization, while the main
> focus of Cuis is cleaning.
>
> This means that Cuis doesn't provide a set of packages to build a "bigger
> image", and therefore doesn't have a clear structure of how those packages
> might be like. On the other hand, it means that KernelImage doesn't provide
> simple, efficient, clean code. I mean, with KernelImage you have either just
> a headless system, or a a bigger image, with more stuff loaded, but without
> significant improvements in code quality.
>
> It seems that there is a lot to learn from KernelImage about the
> modularization of the image. If you want to start with a headless image, may
> be you can even start building on top of it.

With shrinking and cleaning of the system it was always easy to reach
the state where you create a new fork. I wanted to beware it so I
spent lot of time on maintaining of the binding to the original system
(for example see KernelImageOverride on mantis). It was more important
than the next polishing. Unfortunately I cannot say I was really
successful ;-)

> Cuis is useful if you want to start with a complete, working ST-80 like
> system, including a GUI, dev tools, etc.
>
> As a side note, headless KernelImage is about 2Mb. Cuis (reducing fonts to a
> usable minimum) is about 2.9Mb. This might suggest that Cuis has bigger
> "bang for the buck", and this could mean simpler, better code. This would be
> consistent with the huge amount of hours I've spent cleaning Cuis. Somebody
> could try to do a fair comparison between them, though. When I realized that
> KernelImage is headless, and therefore, not a easy to browse and study, I
> just didn't spend any more time on it.
>
>>> 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 :-)
>>
>> Cheers,
>>  - Andreas
>
> I fully agree, but I see a clear technical issue. Current Pharo has too much
> 'optional stuff' to be considered the basic system. If the Pharo
> modularization efforts lead to a much smaller kernel (perhaps the size of
> Cuis or KernelImage), then that could be the basic system.
>
> So it seems that Squeak and Pharo might be walking a similar path to system
> modularization. So, personal and social issues aside, what would be nice is
> some form of cooperation between those efforts.
>

I still think that Squeakers should entertaint the possibility to
adopt PharoCore (or PharoKernel?) some way as the base. The reasons
are clearly practical - and not only for Smalltalk programmers. Squeak
hardly can keep pace with Pharo. Moreover Pharo starts to have several
full-timers now. And original goals of Squeak are very different from
duplicating of effort already done somewhere else. Squeak has to face
to competition of Pharo and EToys. Squeakers can "fight" them or use
them. Please do not let personal disagreements blind you...

Cheers
-- Pavel