On 8/25/10, Pavel Krivanek <squeak1 at continentalbrno.cz> wrote:
> 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.

Yes, we are talking about basing a product on Squeak 4.1 trunk which
runs on 1 to 2 million computers by now.

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

Yes, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-August/152521.html
(Bert Freudenberg says that he want to do the same thing as Andreas.
Andreas moved the Cobalt code over so that it is based on Squeak 4.1
trunk)


> -- Pavel

I'm glad about this conclusion.

--Hannes


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