Meeting Report for 8/18/2010

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

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

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

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

> On Tue, Aug 24, 2010 at 5:40 AM, Andreas Raab<[hidden email]>  wrote:
>> 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?
>
> Because the smallest kernel.image contains only the platform specific
> code for linux, the scripts should be executed there.
>
> The process starts with with the updated morphicCore image. It loads
> basic packages like network support and monticello from the
> SqueakSource and saves the source code to a file.
>
> Then it shrinks yourself down to the kernel.image, it saves this image
> and then it starts to load saved basic packages again. When the image
> has Monticello, it loads all packages again from the repository (but
> only to have all code in the image covered with packages, no changes
> are made).
>
> With the Monticello support it creates the next images up to image
> with EToys support. The bootstrapping process then can start again
> from the morphicCore image.

> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]> wrote:
>> Andreas Raab wrote:
>>>
>>> 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
> full-timers now. And original goals of Squeak are very different from
> duplicating of effort already done somewhere else. Squeak has to face
> to competition of Pharo and EToys. Squeakers can "fight" them or use
> them. Please do not let personal disagreements blind you...

> El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió:
>
>> 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.
>
>
> IMHO Squeak's
> Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is
> (far) behind Pharo's.
>
>>> full-timers now. And original goals of Squeak are very different from
>>
>> Hiring more people doesn't mean it will be better.
>
> This sound like only a few genius are capable of touching those parts,
> very humble indeed.
>
> Now, shoot all you have! :)
>

>
> On 8/24/2010 4:55 PM, Miguel Enrique Cobá Martínez wrote:
> > El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió:
> >
> >> 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.
> >
> >
> > IMHO Squeak's
> > Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is
> > (far) behind Pharo's.
> >
> >>> full-timers now. And original goals of Squeak are very different from
> >>
> >> Hiring more people doesn't mean it will be better.
> >
> > This sound like only a few genius are capable of touching those parts,
> > very humble indeed.
> >
> > Now, shoot all you have! :)
> >
>
>

> This is your private club it appears, by invite only. Good luck Pavel!
>
>>
>> On 8/24/2010 4:55 PM, Miguel Enrique Cobá Martínez wrote:
>>> El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió:
>>>
>>>> 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.
>>>
>>>
>>> IMHO Squeak's
>>> Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is
>>> (far) behind Pharo's.
>>>
>>>>> full-timers now. And original goals of Squeak are very different from
>>>>
>>>> Hiring more people doesn't mean it will be better.
>>>
>>> This sound like only a few genius are capable of touching those parts,
>>> very humble indeed.
>>>
>>> Now, shoot all you have! :)
>>>
>>
>>
>

> On 8/24/2010 8:23 PM, Miguel Enrique Cobá Martínez wrote:
> > El mar, 24-08-2010 a las 17:19 -0700, Andreas Raab escribió:
> >> Don't feed this troll.
> >>
> >>     - A.
> >
> > Come on Andreas, what is this attitude of letting your friends to say
> > what they want but jumping to put a troll label to any other that think
> > different, Isn't mature.
>
> I think it's perfectly mature to call a troll a troll while letting
> people who are presenting criticism in good faith (such as Pavel) say
> what they want to say. That is exactly the difference between the two.

>
> Cheers,
>    - Andreas
>
> > This is your private club it appears, by invite only. Good luck Pavel!
> >
> >>
> >> On 8/24/2010 4:55 PM, Miguel Enrique Cobá Martínez wrote:
> >>> El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió:
> >>>
> >>>> 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.
> >>>
> >>>
> >>> IMHO Squeak's
> >>> Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is
> >>> (far) behind Pharo's.
> >>>
> >>>>> full-timers now. And original goals of Squeak are very different from
> >>>>
> >>>> Hiring more people doesn't mean it will be better.
> >>>
> >>> This sound like only a few genius are capable of touching those parts,
> >>> very humble indeed.
> >>>
> >>> Now, shoot all you have! :)
> >>>
> >>
> >>
> >
>
>

> Hi
>
> I would like to comment on the trigger word "competition" which Pavel
> has brought up in connection with Squeak / Etoys / Pharo and Cuis.
> Andreas is advocating a discussion which actually promotes the work
> and I support this.
>
> 1) There is competition - sure - but as a whole it is just a sign of a
> healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis
> around. I have written this earlier this year when we were asked to
> fill in a questionnaire. In fact as a user of a Squeak based Smalltalk
> "distribution" or "fork" I am happy that there are alternatives. The
> use of these alternatives may vary though.
>
> 2) It is probably more precise to speak of coopetition.
> 'http://en.wikipedia.org/wiki/Coopetition
> <citation>Coopetition or Co-opetition (sometimes spelled
> "coopertition"  or "co-opertition") is a neologism  coined to describe
> cooperative competition. Coopetition occurs when companies work
> together for parts of their business where they do not believe they
> have competitive advantage and where they believe they can share
> common costs.</citation>
>
> Or maybe we should speak of a 'distributed' development approach or
> just having different distributions which share ideas / concepts/
> strategies / code snippets and packages. This is reuse on all levels
> (analysis, design, implementation, package, methods). A recent example
> is the WebClient and the release announcment of Pharo 1.1 for example
> states (http://www.pharo-project.org/pharo-download/release-1-1).
>
> <citation>StandardFilestream now performs read-buffering, dramatically
> speading up some operations like "Object compileAll" (2x improvement)
> as well as various other operations (scanning change lists etc). This
> change was taken from Squeak."</citation>
>
> and further down
> <citation>
> A new general cleanup protocol has been added. The cleanUp protocol
> takes an optional argument to indicate whether we're doing an
> aggressive cleanup (which involves deleting projects, change sets, and
> possibly other destructive actions) or a more gentle cleanup that's
> only supposed to clean out transient caches. This change was taken
> from Squeak.
> </citation>
>
> 3) Squeak, Etoys, Pharo, Scratch and Cuis have different "missions" so
> to say. Or we could say "different customer groups".
>
> As a reminder for the goals of Squeak I would like to mention the
> article "Personal Dynamic Media" written in 1977 which is to be found
> on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is
> amazing what was there at that time.
>
> The problem in the past was that Squeak development did not scale in
> terms of developers working together and going for forks was the only
> reasonable thing to do at that time. But this does not mean that new
> approaches are not feasible. Scratch so to say was 'silent' fork. And
> at the same time a very successful one. It did not create much noise
> on this list. Maybe we should call it an application. In the area of
> Squeak these borders are blurred (intentionally) and this might be
> part of the causes for these kinds of discussions.
>
> 4) Going for a minimal kernel with loadable packages maintained by
> various people is actually meant to stimulate "competition". People
> will be encouraged to take the minimal kernel and load all kinds of
> things on it and distribute the result and create communities around
> it.
>
> 5) For this to work the kernel has to be minimal in a sense that it
> can be managed by a small team. This is the aspect Cuis strongly
> promotes and we want to adapt for Squeak. Actually this is not new at
> all.  It has been a long standing goal. But for many reasons about
> which  we have pondered many times it had not been achieved so far.
> Juan has given the real-life proof that it is possible to maintain his
> own fork as a single person while at the same time adapting important
> changes from elsewhere. In addition he has contributed back to the
> main-line Squeak development. From this point of view we should really
> de-emphasise the negative aspects of competition.
>
> 6) This time we have Andreas, Pavel and Juan for the core, Eliot on
> the VM side and Bert for the Etoys link working together. Others are
> working on various aspects improving the system. I think this is an
> opportunity and there is a real chance of success.
>
> 7) As an illustration I did a sketch. (see attached PNG file). I think
> the overlap of the distributions is considerable. As a follow up it
> would be nice to have some simple statistics like no. of classes per
> distribution. Number of classes with identical names across
> distributions. As the picture is very rough somebody might post a more
> accurate one.
>
> Cheers
>
> Hannes
>
>
> P.S.
>
> Please note that in the meeting report this thread is about Randal
> says that he wants to contact the other Squeak based projects to talk
> about a minimal core.
>
>
>
>

> Hi Hannes -
>
> I think that's a very insightful analysis. I hadn't heard the term
> coopetition before and I've not seen the concept applied to open source
> projects. A very interesting set of thoughts.
>
> Would you mind if I quote this memo in full on my blog to preserve it?
>
> Cheers,
>    - Andreas
>
> On 8/24/2010 9:50 PM, Hannes Hirzel wrote:
>> Hi
>>
>> I would like to comment on the trigger word "competition" which Pavel
>> has brought up in connection with Squeak / Etoys / Pharo and Cuis.
>> Andreas is advocating a discussion which actually promotes the work
>> and I support this.
>>
>> 1) There is competition - sure - but as a whole it is just a sign of a
>> healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis
>> around. I have written this earlier this year when we were asked to
>> fill in a questionnaire. In fact as a user of a Squeak based Smalltalk
>> "distribution" or "fork" I am happy that there are alternatives. The
>> use of these alternatives may vary though.
>>
>> 2) It is probably more precise to speak of coopetition.
>> 'http://en.wikipedia.org/wiki/Coopetition
>> <citation>Coopetition or Co-opetition (sometimes spelled
>> "coopertition"  or "co-opertition") is a neologism  coined to describe
>> cooperative competition. Coopetition occurs when companies work
>> together for parts of their business where they do not believe they
>> have competitive advantage and where they believe they can share
>> common costs.</citation>
>>
>> Or maybe we should speak of a 'distributed' development approach or
>> just having different distributions which share ideas / concepts/
>> strategies / code snippets and packages. This is reuse on all levels
>> (analysis, design, implementation, package, methods). A recent example
>> is the WebClient and the release announcment of Pharo 1.1 for example
>> states (http://www.pharo-project.org/pharo-download/release-1-1).
>>
>> <citation>StandardFilestream now performs read-buffering, dramatically
>> speading up some operations like "Object compileAll" (2x improvement)
>> as well as various other operations (scanning change lists etc). This
>> change was taken from Squeak."</citation>
>>
>> and further down
>> <citation>
>> A new general cleanup protocol has been added. The cleanUp protocol
>> takes an optional argument to indicate whether we're doing an
>> aggressive cleanup (which involves deleting projects, change sets, and
>> possibly other destructive actions) or a more gentle cleanup that's
>> only supposed to clean out transient caches. This change was taken
>> from Squeak.
>> </citation>
>>
>> 3) Squeak, Etoys, Pharo, Scratch and Cuis have different "missions" so
>> to say. Or we could say "different customer groups".
>>
>> As a reminder for the goals of Squeak I would like to mention the
>> article "Personal Dynamic Media" written in 1977 which is to be found
>> on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is
>> amazing what was there at that time.
>>
>> The problem in the past was that Squeak development did not scale in
>> terms of developers working together and going for forks was the only
>> reasonable thing to do at that time. But this does not mean that new
>> approaches are not feasible. Scratch so to say was 'silent' fork. And
>> at the same time a very successful one. It did not create much noise
>> on this list. Maybe we should call it an application. In the area of
>> Squeak these borders are blurred (intentionally) and this might be
>> part of the causes for these kinds of discussions.
>>
>> 4) Going for a minimal kernel with loadable packages maintained by
>> various people is actually meant to stimulate "competition". People
>> will be encouraged to take the minimal kernel and load all kinds of
>> things on it and distribute the result and create communities around
>> it.
>>
>> 5) For this to work the kernel has to be minimal in a sense that it
>> can be managed by a small team. This is the aspect Cuis strongly
>> promotes and we want to adapt for Squeak. Actually this is not new at
>> all.  It has been a long standing goal. But for many reasons about
>> which  we have pondered many times it had not been achieved so far.
>> Juan has given the real-life proof that it is possible to maintain his
>> own fork as a single person while at the same time adapting important
>> changes from elsewhere. In addition he has contributed back to the
>> main-line Squeak development. From this point of view we should really
>> de-emphasise the negative aspects of competition.
>>
>> 6) This time we have Andreas, Pavel and Juan for the core, Eliot on
>> the VM side and Bert for the Etoys link working together. Others are
>> working on various aspects improving the system. I think this is an
>> opportunity and there is a real chance of success.
>>
>> 7) As an illustration I did a sketch. (see attached PNG file). I think
>> the overlap of the distributions is considerable. As a follow up it
>> would be nice to have some simple statistics like no. of classes per
>> distribution. Number of classes with identical names across
>> distributions. As the picture is very rough somebody might post a more
>> accurate one.
>>
>> Cheers
>>
>> Hannes
>>
>>
>> P.S.
>>
>> Please note that in the meeting report this thread is about Randal
>> says that he wants to contact the other Squeak based projects to talk
>> about a minimal core.
>>
>>
>>
>>
>
>
>

> Is SqueakLight or FunSqueak of Edgard maintained? Probably yes, though
> on a more occasional basis. Edgar tries to preserve the original
> Squeak flavor.
>
> Cheers
>
> --Hannes
>
> On 8/25/10, Andreas Raab<[hidden email]>  wrote:
>> Hi Hannes -
>>
>> I think that's a very insightful analysis. I hadn't heard the term
>> coopetition before and I've not seen the concept applied to open source
>> projects. A very interesting set of thoughts.
>>
>> Would you mind if I quote this memo in full on my blog to preserve it?
>>
>> Cheers,
>>     - Andreas
>>
>> On 8/24/2010 9:50 PM, Hannes Hirzel wrote:
>>> Hi
>>>
>>> I would like to comment on the trigger word "competition" which Pavel
>>> has brought up in connection with Squeak / Etoys / Pharo and Cuis.
>>> Andreas is advocating a discussion which actually promotes the work
>>> and I support this.
>>>
>>> 1) There is competition - sure - but as a whole it is just a sign of a
>>> healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis
>>> around. I have written this earlier this year when we were asked to
>>> fill in a questionnaire. In fact as a user of a Squeak based Smalltalk
>>> "distribution" or "fork" I am happy that there are alternatives. The
>>> use of these alternatives may vary though.
>>>
>>> 2) It is probably more precise to speak of coopetition.
>>> 'http://en.wikipedia.org/wiki/Coopetition
>>> <citation>Coopetition or Co-opetition (sometimes spelled
>>> "coopertition"  or "co-opertition") is a neologism  coined to describe
>>> cooperative competition. Coopetition occurs when companies work
>>> together for parts of their business where they do not believe they
>>> have competitive advantage and where they believe they can share
>>> common costs.</citation>
>>>
>>> Or maybe we should speak of a 'distributed' development approach or
>>> just having different distributions which share ideas / concepts/
>>> strategies / code snippets and packages. This is reuse on all levels
>>> (analysis, design, implementation, package, methods). A recent example
>>> is the WebClient and the release announcment of Pharo 1.1 for example
>>> states (http://www.pharo-project.org/pharo-download/release-1-1).
>>>
>>> <citation>StandardFilestream now performs read-buffering, dramatically
>>> speading up some operations like "Object compileAll" (2x improvement)
>>> as well as various other operations (scanning change lists etc). This
>>> change was taken from Squeak."</citation>
>>>
>>> and further down
>>> <citation>
>>> A new general cleanup protocol has been added. The cleanUp protocol
>>> takes an optional argument to indicate whether we're doing an
>>> aggressive cleanup (which involves deleting projects, change sets, and
>>> possibly other destructive actions) or a more gentle cleanup that's
>>> only supposed to clean out transient caches. This change was taken
>>> from Squeak.
>>> </citation>
>>>
>>> 3) Squeak, Etoys, Pharo, Scratch and Cuis have different "missions" so
>>> to say. Or we could say "different customer groups".
>>>
>>> As a reminder for the goals of Squeak I would like to mention the
>>> article "Personal Dynamic Media" written in 1977 which is to be found
>>> on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is
>>> amazing what was there at that time.
>>>
>>> The problem in the past was that Squeak development did not scale in
>>> terms of developers working together and going for forks was the only
>>> reasonable thing to do at that time. But this does not mean that new
>>> approaches are not feasible. Scratch so to say was 'silent' fork. And
>>> at the same time a very successful one. It did not create much noise
>>> on this list. Maybe we should call it an application. In the area of
>>> Squeak these borders are blurred (intentionally) and this might be
>>> part of the causes for these kinds of discussions.
>>>
>>> 4) Going for a minimal kernel with loadable packages maintained by
>>> various people is actually meant to stimulate "competition". People
>>> will be encouraged to take the minimal kernel and load all kinds of
>>> things on it and distribute the result and create communities around
>>> it.
>>>
>>> 5) For this to work the kernel has to be minimal in a sense that it
>>> can be managed by a small team. This is the aspect Cuis strongly
>>> promotes and we want to adapt for Squeak. Actually this is not new at
>>> all.  It has been a long standing goal. But for many reasons about
>>> which  we have pondered many times it had not been achieved so far.
>>> Juan has given the real-life proof that it is possible to maintain his
>>> own fork as a single person while at the same time adapting important
>>> changes from elsewhere. In addition he has contributed back to the
>>> main-line Squeak development. From this point of view we should really
>>> de-emphasise the negative aspects of competition.
>>>
>>> 6) This time we have Andreas, Pavel and Juan for the core, Eliot on
>>> the VM side and Bert for the Etoys link working together. Others are
>>> working on various aspects improving the system. I think this is an
>>> opportunity and there is a real chance of success.
>>>
>>> 7) As an illustration I did a sketch. (see attached PNG file). I think
>>> the overlap of the distributions is considerable. As a follow up it
>>> would be nice to have some simple statistics like no. of classes per
>>> distribution. Number of classes with identical names across
>>> distributions. As the picture is very rough somebody might post a more
>>> accurate one.
>>>
>>> Cheers
>>>
>>> Hannes
>>>
>>>
>>> P.S.
>>>
>>> Please note that in the meeting report this thread is about Randal
>>> says that he wants to contact the other Squeak based projects to talk
>>> about a minimal core.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

> El mar, 24-08-2010 a las 20:47 -0700, Andreas Raab escribió:
>> On 8/24/2010 8:23 PM, Miguel Enrique Cobá Martínez wrote:
>>> El mar, 24-08-2010 a las 17:19 -0700, Andreas Raab escribió:
>>>> Don't feed this troll.
>>>>
>>>>      - A.
>>>
>>> Come on Andreas, what is this attitude of letting your friends to say
>>> what they want but jumping to put a troll label to any other that think
>>> different, Isn't mature.
>>
>> I think it's perfectly mature to call a troll a troll while letting
>> people who are presenting criticism in good faith (such as Pavel) say
>> what they want to say. That is exactly the difference between the two.
>
> Well, I suppose that Levente's comment about the capabilities of the
> pharo developers is in good faith too and that is the reason that it is
> permitted in this list.
>
>>
>> Also, if this were your first troll, I'd give you a bit more leeway. But
>> it's not, you have a history of making inflammatory comments on this
>> list and I don't want others to fall for your trap.
>
> Considering your own history of burning very capable developers in the
> past and that you were a key player in the events that lead to the Pharo
> fork from Squeak, I suppose that I must feel very honored to be called a
> troll by you.
>
>>
>> In short, if you're commenting with the purpose of improving Squeak,
>> you're welcome. If indeed that was your intention, then I'm looking
>> forward to your elaboration and contributions on how to improve Squeak.
>> However, if you're commenting with the only purpose of proving the
>> superiority of Pharo, you're not. You can post those comments on the
>> Pharo list where I'm sure they will be welcome.
>
> No, I'm not saying that Pharo is better that Squeak, in fact my response
> to Levente's comment was, just as his, preceded by IMHO. That is, no
> very humble from him nor from me.
>
> Now, he in fact suggested that the developers on Pharo were lesser
> capable (and maybe we are, but that don't stops us from improving Pharo
> a little each day) and that even by hiring full time developers, Pharo
> couldn't match the level of expertise that the squeak developers have.
> That is really not humble at all.
>
> Finally I was responding to a comment by Levente that seem to me very
> offensive to the Pharo developers. Had he say that in any other list I
> will have respond all the same, isn't a Squeak list trolling as you put
> it. So think what you want.
>
>>
>> Cheers,
>>     - Andreas
>>
>>> This is your private club it appears, by invite only. Good luck Pavel!
>>>
>>>>
>>>> On 8/24/2010 4:55 PM, Miguel Enrique Cobá Martínez wrote:
>>>>> El mié, 25-08-2010 a las 01:09 +0200, Levente Uzonyi escribió:
>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> IMHO Squeak's
>>>>> Business penetration/Comercial apps/Look&Feel/Website/Logo/new blood/ is
>>>>> (far) behind Pharo's.
>>>>>
>>>>>>> full-timers now. And original goals of Squeak are very different from
>>>>>>
>>>>>> Hiring more people doesn't mean it will be better.
>>>>>
>>>>> This sound like only a few genius are capable of touching those parts,
>>>>> very humble indeed.
>>>>>
>>>>> Now, shoot all you have! :)
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

> On Tue, 24 Aug 2010, Pavel Krivanek wrote:
>
>> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]> 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.

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

> 2010/8/25 Levente Uzonyi <[hidden email]>:
>> On Tue, 24 Aug 2010, Pavel Krivanek wrote:
>>
>>> On Tue, Aug 24, 2010 at 1:53 PM, Juan Vuletich <[hidden email]>
>>> 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.

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

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