On Wed, Aug 25, 2010 at 12:21 PM, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
> On 8/25/10, Pavel Krivanek <squeak1 at continentalbrno.cz> wrote:
>> 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.
>
> Could you please elaborate on this? Some kind of metrics? (I.e. take
> all classes and method names in Squeak with the last change date and
> the same thing in Pharo and give some indication what has changed? -
> Of course this will be very rough as it does not really show what has
> been changed. Touching a method to replace the underscore assignment
> by := will show up), maybe you have better idea of metrics.

Ok, I'll try to do something.

>>>> full-timers now. And original goals of Squeak are very different from
>>>
>>> Hiring more people doesn't mean it will be better.
> Yes
>
>
>>>> 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?
>>
>
> EToys is not a competition to Squeak. Bert Freudenberg says that they
> want to move over the Squeakland image to Squeak 4.1 trunk. I assume
> that he would appreciate your help, Pavel in this. In particular as
> you say such an effort would only take about 2 weeks. I consider this
> to be an amazing statement and we are interested in learning from you
> how such a thing can be done.

Well, if EToys really want to be based on Squeak then it changes everything.

>> 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 but not for others that's the point. We still have a common
> base and on top of that different distributions.
>
> For them the concept
>> of general purpose Smalltalk (of the Sqeuak's way) is antiquated.
>
> OK, for them but please note that it is not for other kinds of people.

That is not about the beauty of the idea. EToys need a lot of deep
refactorings and the existence of EToys fork would disvalue it because
people who really use EToys are somewhere else.

>> 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.
>
> This is interesting. Could you please elaborate why you think it is
> not a vital concept?

See above. If EToys will join forces with Squeak than we are in the
different situation.

-- Pavel

>  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).
>
> As far as I understand the situation EToys is supported by the
> Squeakland people and they are happy to put it onto Squeak 4.1. But
> this question is better answered by Bert Freudenberg.
>
>
>> 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.
>
> Still the original thing - personal digital media plus re-emphasized -
> to be a common basis for forks. More details on request. Maybe we
> should open another thread where we re-hearse the goals for Squeak 4.2
> (or re-activate an older one).
>
>
>> Cheers,
>> -- Pavel
>
> Again - thank you Pavel for rejoining and contributing in various ways.
>
> --Hannes
>
>
>>> Levente
>>>
>>>> them. Please do not let personal disagreements blind you...
>>>>
>>>> Cheers
>>>> -- Pavel
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>