On 8/25/10, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
> 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)

And here
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149923.html
    Monticello-based updates for Etoys

Bert Freudenberg gives the information where the EToys development is
heading for and gives the relevant links for the sources.

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