Meeting Report for 8/18/2010

> Hi Folks,
>
> These are the notes for the last Board Meeting, posted at the Squeak Board
> blog at
> http://squeakboard.wordpress.com/2010/08/20/meeting-report-for-8182010/ .
>
> Almost full house today. Only Chris was missing because he is on vacation. We
> had a good meeting and discussed many issues.
>
> Money transfers to SFC. Andreas has been extremely busy at work, but will be
> able to pick it up again now.
>
> Squeak 4.2 release: Date and Scope. Setting up the infrastructure for
> Community Supported Packages and start picking them. We currently don?t have
> an active Release Team. If somebody steps up to work on this, we can start

> planning. Please volunteer!
>
> Documentation. The community has previously shown interest in having a
> Documentation Team, so Jecel will post to squeak-dev to check up on the
> current volunteers and seek out new ones.
>
> Randal suggested doing a wide survey on usage of Squeak and Squeak
> derivatives to help in planning and decision making. This would include
> Pharo, Etoys, Cobalt, Scratch, Cuis and others. We?d need input from groups
> and organizations that are not members of the squeak-dev list. Therefore we
> need to approach members of those groups and organizations for coordination.
> We?ll also need cooperation from everybody to get all users of Squeak and
> derivatives to be aware of this effort, and to consider answering the survey.
> Randal will start contacting some of these groups for coordinating.
>
> Bert will attend to Esug 2010 partly on behalf of the Squeak Board as a
> Squeak PR activity. We decided to financially support his trip.
>
> Andreas and Juan would like to find a way to leverage the work done to reduce
> Cuis for Squeak. Ideally, Squeak would become a smaller kernel, about the
> size of Cuis, and everything else would be in optional packages that would be
> unloadable. Comments, suggestions, volunteers, are all welcome!

> Hi Folks,
>
> These are the notes for the last Board Meeting, posted at the Squeak Board blog at http://squeakboard.wordpress.com/2010/08/20/meeting-report-for-8182010/ .
>
> Almost full house today. Only Chris was missing because he is on vacation. We had a good meeting and discussed many issues.
>
> Money transfers to SFC. Andreas has been extremely busy at work, but will be able to pick it up again now.
>
> Squeak 4.2 release: Date and Scope. Setting up the infrastructure for Community Supported Packages and start picking them. We currently don’t have an active Release Team. If somebody steps up to work on this, we can start planning. Please volunteer!
>
> Documentation. The community has previously shown interest in having a Documentation Team, so Jecel will post to squeak-dev to check up on the current volunteers and seek out new ones.
>
> Randal suggested doing a wide survey on usage of Squeak and Squeak derivatives to help in planning and decision making. This would include Pharo, Etoys, Cobalt, Scratch, Cuis and others. We’d need input from groups and organizations that are not members of the squeak-dev list. Therefore we need to approach members of those groups and organizations for coordination. We’ll also need cooperation from everybody to get all users of Squeak and derivatives to be aware of this effort, and to consider answering the survey. Randal will start contacting some of these groups for coordinating.
>
> Bert will attend to Esug 2010 partly on behalf of the Squeak Board as a Squeak PR activity. We decided to financially support his trip.
>
> Andreas and Juan would like to find a way to leverage the work done to reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel, about the size of Cuis, and everything else would be in optional packages that would be unloadable. Comments, suggestions, volunteers, are all welcome!
> Cheers,
> Juan Vuletich (for the SOB)
>

>
> On 8/20/10 9:04 AM, "Juan Vuletich" <[hidden email]> wrote:
>
>  
>> Andreas and Juan would like to find a way to leverage the work done to
>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel,
>> about the size of Cui
>>    
>
> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>
> Why smart people like both you desire do all again ?
>
> Edgar
>  

> So, you think that this Pharo Kernel would be better than Cuis as the
> Squeak kernel? Why? Is anybody with a deep knowledge of Pharo Kernel
> willing to help base Squeak on it?
>
> Are you asking why I do Cuis? Isn't
> http://www.jvuletich.org/Cuis/Index.html clear enough?
>
> Please, do answer these questions.
>
> Cheers,
> Juan Vuletich

>
>
>
> On 8/20/10 7:50 PM, "Juan Vuletich" <[hidden email]> wrote:
>
>> So, you think that this Pharo Kernel would be better than Cuis as the
>> Squeak kernel? Why? Is anybody with a deep knowledge of Pharo Kernel
>> willing to help base Squeak on it?
>>
>> Are you asking why I do Cuis? Isn't
>> http://www.jvuletich.org/Cuis/Index.html clear enough?
>>
>> Please, do answer these questions.
>>
>> Cheers,
>> Juan Vuletich
>
> First, don't take personal.
>
> Cuis is a very valuable fork, but until now I don't see how you go from Cuis
> to  any trunk complex image.
>
> Maybe is again my lack of skill...
>
> This also is true for the Pharo kernel.
>
> But in my (maybe wrong) view, the kernel is simpler.
> No
>
> What community needs is HOW TO go from it to complex images in a documented
> way.
>
>
> Edgar
>
>
>
>
>
>

> In the sense of step towards a smaller image.
>
> On the 20th May Igor Stasenko started a thread
> <citation>
>         Towards clean unloading Morphic (an idea)
>
> i just thought, that in order to get down to a minimal kernel image,
> it would be nice to move all Morphic globals into a shared pool.
>
> Things like, World, ActiveWorld
> could be placed into a MorphicPool class.
> </citation>
> ...
>
> Eliot Miranda considered the idea to be good.
>
>
> In addition I think it would be good to split the Morphic package.
>
> It is quite big and it is often changed. The version number is
> currently over 400. This is high compared to over packages.
>
>
> But I assume Andreas and Juan have some more precise ideas how they
> want to proceed.
>
> --Hannes

>> So, you think that this Pharo Kernel would be better than Cuis as the
>> Squeak kernel? Why? Is anybody with a deep knowledge of Pharo Kernel
>> willing to help base Squeak on it?
>>
>> Are you asking why I do Cuis? Isn't
>> http://www.jvuletich.org/Cuis/Index.html clear enough?
>>
>> Please, do answer these questions.
>>
>> Cheers,
>> Juan Vuletich
>>    
>
> First, don't take personal.
>
> Cuis is a very valuable fork, but until now I don't see how you go from Cuis
> to  any trunk complex image.
>
> Maybe is again my lack of skill...
>
> This also is true for the Pharo kernel.
>
> But in my (maybe wrong) view, the kernel is simpler.
>  

> On 8/20/2010 7:30 AM, Edgar J. De Cleene wrote:
>>
>> On 8/20/10 9:04 AM, "Juan Vuletich"<[hidden email]>  wrote:
>>>
>>> Andreas and Juan would like to find a way to leverage the work done to
>>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel,
>>> about the size of Cui
>>
>> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>
> I'm not sure what exactly you're talking about, can you elaborate? Is there
> an image to look at and learn from? So far, I found Cuis to be the best
> alternative.
>
>> Why smart people like both you desire do all again ?
>
> Mostly because doing something like that requires help from the people who
> have done it before. I haven't seen a post from Pavel in two years; to me
> that is a clear expression of disinterest. Contrary to which Juan isn't only
> present, but he's also ran and be elected to the Squeak board and has
> repeatedly expressed his willingness to help. All other things being equal,
> that seems like a vast advantage, wouldn't you agree?
>

> On Sat, Aug 21, 2010 at 5:34 AM, Andreas Raab <[hidden email]> wrote:
>> On 8/20/2010 7:30 AM, Edgar J. De Cleene wrote:
>>>
>>> On 8/20/10 9:04 AM, "Juan Vuletich"<[hidden email]>  wrote:
>>>>
>>>> Andreas and Juan would like to find a way to leverage the work done to
>>>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel,
>>>> about the size of Cui
>>>
>>> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>>
>> I'm not sure what exactly you're talking about, can you elaborate? Is there
>> an image to look at and learn from? So far, I found Cuis to be the best
>> alternative.
>>
>>> Why smart people like both you desire do all again ?
>>
>> Mostly because doing something like that requires help from the people who
>> have done it before. I haven't seen a post from Pavel in two years; to me
>> that is a clear expression of disinterest. Contrary to which Juan isn't only
>> present, but he's also ran and be elected to the Squeak board and has
>> repeatedly expressed his willingness to help. All other things being equal,
>> that seems like a vast advantage, wouldn't you agree?
>>
>
> Hi Andreas,
>
> I'm ready to help you.
>
> -- Pavel

> On Sat, Aug 21, 2010 at 5:34 AM, Andreas Raab<[hidden email]>  wrote:
>> On 8/20/2010 7:30 AM, Edgar J. De Cleene wrote:
>>>
>>> On 8/20/10 9:04 AM, "Juan Vuletich"<[hidden email]>    wrote:
>>>>
>>>> Andreas and Juan would like to find a way to leverage the work done to
>>>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel,
>>>> about the size of Cui
>>>
>>> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>>
>> I'm not sure what exactly you're talking about, can you elaborate? Is there
>> an image to look at and learn from? So far, I found Cuis to be the best
>> alternative.
>>
>>> Why smart people like both you desire do all again ?
>>
>> Mostly because doing something like that requires help from the people who
>> have done it before. I haven't seen a post from Pavel in two years; to me
>> that is a clear expression of disinterest. Contrary to which Juan isn't only
>> present, but he's also ran and be elected to the Squeak board and has
>> repeatedly expressed his willingness to help. All other things being equal,
>> that seems like a vast advantage, wouldn't you agree?
>>
>
> Hi Andreas,
>
> I'm ready to help you.
>
> -- Pavel
>
>

> Hi Pavel,
>
> Thanks for your offer! I've been talking to Juan about an approach that
> might give us at least a feel about the size of the effort we're talking
> about, namely to use the Cuis image and cluster all classes and methods into
> three categories:
> * Unchanged. Those classes and methods exist both in current Squeak trunk
> and Cuis.
> * Squeak-Only. Those classes and methods do only exist in Squeak.
> * Modified. Those classes and methods are different between Cuis and Squeak.
> The idea here is to get a feel for the size of the effort before it gets
> into the details (i.e., it would help us to understand whether the modified
> portions are 1% or 10% of the total size). Do you think the approach would
> be equally applicable to your Kernel images?
>
> Speaking of which, I'm not entirely sure what the scope or direction for
> these images is. Can you say a little bit about whether there's some
> underlying theme to this work (i.e., do you have actual use cases for these
> kernel images) or is it mostly just an attempt to make things smaller?
>
> Lastly, where can I find one of those kernel images these days? I'm
> interested in seeing how different or similar the structure is, in
> particular compared to Cuis.
>
> Cheers,
>  - Andreas
>
>
> On 8/22/2010 1:05 AM, Pavel Krivanek wrote:
>>
>> On Sat, Aug 21, 2010 at 5:34 AM, Andreas Raab<[hidden email]>  wrote:
>>>
>>> On 8/20/2010 7:30 AM, Edgar J. De Cleene wrote:
>>>>
>>>> On 8/20/10 9:04 AM, "Juan Vuletich"<[hidden email]>    wrote:
>>>>>
>>>>> Andreas and Juan would like to find a way to leverage the work done to
>>>>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller kernel,
>>>>> about the size of Cui
>>>>
>>>> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>>>
>>> I'm not sure what exactly you're talking about, can you elaborate? Is
>>> there
>>> an image to look at and learn from? So far, I found Cuis to be the best
>>> alternative.
>>>
>>>> Why smart people like both you desire do all again ?
>>>
>>> Mostly because doing something like that requires help from the people
>>> who
>>> have done it before. I haven't seen a post from Pavel in two years; to me
>>> that is a clear expression of disinterest. Contrary to which Juan isn't
>>> only
>>> present, but he's also ran and be elected to the Squeak board and has
>>> repeatedly expressed his willingness to help. All other things being
>>> equal,
>>> that seems like a vast advantage, wouldn't you agree?
>>>
>>
>> Hi Andreas,
>>
>> I'm ready to help you.
>>
>> -- Pavel
>>
>>
>
>
>

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

> On Mon, 23 Aug 2010, 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.
>>
>> The approach to PharoKernel is a little bit different. There is not a
>> current image that can be downloaded. Pharo is almost prepared for
>> this remodularization, it only needs to finish integration of this
>> issue:
>> http://code.google.com/p/pharo/issues/detail?id=2635
>> For the description of its scope of the Kernel, the following issue is
>> important:
>> http://code.google.com/p/pharo/issues/detail?id=2105
>>
>> The goal of the KernelImage/PharoKernel is to have a modular system
>> with well defined packages a dependencies, not only the smallest
>> system. That was the reason why I always tried to keep the binding to
>> mainstream Squeak content.
>>
>> 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
>
> Oh, really?

>> 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...
>
> Do you mean that the current Squeak trunk should be thrown away and Squeak
> should be based on Pharo?
> Levente
>
>
>>
>> To Edgar: sorry, I do not have Skype.
>>
>> Cheers,
>> -- Pavel
>>
>>
>> On Sun, Aug 22, 2010 at 9:53 PM, Andreas Raab <[hidden email]> wrote:
>>>
>>> Hi Pavel,
>>>
>>> Thanks for your offer! I've been talking to Juan about an approach that
>>> might give us at least a feel about the size of the effort we're talking
>>> about, namely to use the Cuis image and cluster all classes and methods
>>> into
>>> three categories:
>>> * Unchanged. Those classes and methods exist both in current Squeak trunk
>>> and Cuis.
>>> * Squeak-Only. Those classes and methods do only exist in Squeak.
>>> * Modified. Those classes and methods are different between Cuis and
>>> Squeak.
>>> The idea here is to get a feel for the size of the effort before it gets
>>> into the details (i.e., it would help us to understand whether the
>>> modified
>>> portions are 1% or 10% of the total size). Do you think the approach
>>> would
>>> be equally applicable to your Kernel images?
>>>
>>> Speaking of which, I'm not entirely sure what the scope or direction for
>>> these images is. Can you say a little bit about whether there's some
>>> underlying theme to this work (i.e., do you have actual use cases for
>>> these
>>> kernel images) or is it mostly just an attempt to make things smaller?
>>>
>>> Lastly, where can I find one of those kernel images these days? I'm
>>> interested in seeing how different or similar the structure is, in
>>> particular compared to Cuis.
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>> On 8/22/2010 1:05 AM, Pavel Krivanek wrote:
>>>>
>>>> On Sat, Aug 21, 2010 at 5:34 AM, Andreas Raab<[hidden email]>
>>>>  wrote:
>>>>>
>>>>> On 8/20/2010 7:30 AM, Edgar J. De Cleene wrote:
>>>>>>
>>>>>> On 8/20/10 9:04 AM, "Juan Vuletich"<[hidden email]>    wrote:
>>>>>>>
>>>>>>> Andreas and Juan would like to find a way to leverage the work done
>>>>>>> to
>>>>>>> reduce Cuis for Squeak. Ideally, Squeak would become a smaller
>>>>>>> kernel,
>>>>>>> about the size of Cui
>>>>>>
>>>>>> You have a kernel and this is the Pharo Kernel, mostly Pavel work.
>>>>>
>>>>> I'm not sure what exactly you're talking about, can you elaborate? Is
>>>>> there
>>>>> an image to look at and learn from? So far, I found Cuis to be the best
>>>>> alternative.
>>>>>
>>>>>> Why smart people like both you desire do all again ?
>>>>>
>>>>> Mostly because doing something like that requires help from the people
>>>>> who
>>>>> have done it before. I haven't seen a post from Pavel in two years; to
>>>>> me
>>>>> that is a clear expression of disinterest. Contrary to which Juan isn't
>>>>> only
>>>>> present, but he's also ran and be elected to the Squeak board and has
>>>>> repeatedly expressed his willingness to help. All other things being
>>>>> equal,
>>>>> that seems like a vast advantage, wouldn't you agree?
>>>>>
>>>>
>>>> Hi Andreas,
>>>>
>>>> I'm ready to help you.
>>>>
>>>> -- Pavel
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>

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