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

Pavel Krivanek squeak1 at continentalbrno.cz
Wed Aug 25 08:34:00 UTC 2010


2010/8/25 Levente Uzonyi <leves at elte.hu>:
> 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.

Pharoers are preparing Opal and Ocean so at least it is not right that
they don't have enough courage and skills to touch this parts. As
someone who tried to be in touch with Pharo development from the
perspective of my previous modularization effort I had to say that the
amount of important changes in Pharo is really huge.

>> 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?

>From Back to the future: "In December of 1995, the authors found
themselves wanting a development environment in which to build
educational software that could be used—and even programmed—by
non-technical people, and by children. We wanted our software to be
effective in mass-access media such as PDAs and the Internet, where
download times and power considerations make compactness essential,
and where hardware is diverse, and operating systems may change or be
completely absent. Therefore our ideal system would be a small,
portable kernel of simple and uniform design that could be adapted
rapidly to new delivery vehicles."

Smalltalk was only an instrument.

>> 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?

Of course not. But for people who want to use EToys, the EToys image
is more natural choice. That was the main reason why Pharoers stopped
to support it because it was only a dead weight. For them the concept
of general purpose Smalltalk (of the Sqeuak's way) is antiquated.

The KernelImage project tried to show that it is possible to have a
modular Smalltalk with EToys support. But I did it only because it was
possible not because I really trusted it is a vital concept. I
supposed that the fact that we will have EToys in a separate package
will probably show that nobody cares about its support (however I
didn't wanted that).

Please, can you tell me for what target group of users the Squeak is
and how it differs from Pharo and EToys? Because I'm confused in that.

Cheers,
-- Pavel

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



More information about the Squeak-dev mailing list