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

Levente Uzonyi leves at elte.hu
Tue Aug 24 23:09:06 UTC 2010


On Tue, 24 Aug 2010, Pavel Krivanek wrote:

> 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

Sorry, but I totally don't get what you're talking about. IMHO Pharo's 
Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think 
Pharo lacks developers who have enough knowledge to touch those parts of 
the system and are willing to spend their time on it. But I may be wrong, 
so please let me know how is PharoKernel/Core better than Squeak.

> full-timers now. And original goals of Squeak are very different from

Hiring more people doesn't mean it will be better.

> duplicating of effort already done somewhere else. Squeak has to face

What are the original goals of Squeak besides being a general purpose free 
Smalltalk?

> to competition of Pharo and EToys. Squeakers can "fight" them or use

How is EToys competition to Squeak? Is EToys a free general purpose 
Smalltalk?


Levente

> them. Please do not let personal disagreements blind you...
>
> Cheers
> -- Pavel
>
>


More information about the Squeak-dev mailing list