Meeting Report for 8/18/2010

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Meeting Report for 8/18/2010

Juan Vuletich-4
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)

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Edgar De Cleene



On 8/20/10 9:04 AM, "Juan Vuletich" <[hidden email]> wrote:

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

If still i can help with †his...

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Edgar De Cleene
In reply to this post by Juan Vuletich-4



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



Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Levente Uzonyi-2
In reply to this post by Juan Vuletich-4
On Fri, 20 Aug 2010, Juan Vuletich wrote:

> 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

Release Team? Like what 3.11, 3.10, 3.9, etc had?

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

Sounds good. I think we could start with finding package dependencies
(AFAIK we know the dependencies at the class level, but not at method
level) and splitting the Tests package.


Levente

> Cheers,
> Juan Vuletich (for the SOB)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Casey Ransberger-2
In reply to this post by Juan Vuletich-4
My time is currently somewhat limited, as I'm in the process of ramping up at a new job, but as long as that's okay with the other team members, I would love to volunteer for the release team.

On Aug 20, 2010, at 5:04 AM, Juan Vuletich <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Juan Vuletich-4
In reply to this post by Edgar De Cleene
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.
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Andreas.Raab
In reply to this post by Edgar De Cleene
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?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Hannes Hirzel
In reply to this post by Juan Vuletich-4
On 8/20/10, Juan Vuletich <[hidden email]> wrote:
....
>
> Squeak 4.2 release: ....
...
>
> 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!

Excellent. Thank you Juan and Andreas for your willingness to attempt
this. I assume it will not be easy (Markus Denker brought up the topic
about 'Stable Squeak' 10 years ago on the Pharo list). Anyhow the list
of packages which unload by now in Squeak is considerable. So if we
can continue this way for 4.2 then this is fine even if the goal is
not reached fully.

A buzz word which has been lingering around for quite some time is
'habitability',
that means if it is comfortable "living" in the coding environment.

i.e. see for example
http://www.slideshare.net/michele.lanza/of-code-and-change-beautiful-software-presentation.
The presentation as such stands out of the normal IT presentations.

It is about the city metaphor for software.
BTW did somebody create a picture of Squeak 4.1 trunk city?

So to summarize my comment: A goal for Squeak 4.2 should be to
continue to make it more "habitable". If you have access paths and
know your way around it is much more comfortable - this of course
links the issue to having 'guide posts'.

Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Edgar De Cleene
In reply to this post by Juan Vuletich-4



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





Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

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

On 8/21/10, Edgar J. De Cleene <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Edgar De Cleene



On 8/21/10 8:44 AM, "Hannes Hirzel" <[hidden email]> wrote:

> 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


I badly want a smaller and modular images.
Working on this for a long time.
You said start from top , unload all we know how to load again.
Same as Ralph and me long time ago.
Andreas polish all and we have a SqueakCore now.
This image is not updated. Why ?

I continue my wild SqueakLight3, this image could be updated and follow the
trunk, packages unloaded don't load again .

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Juan Vuletich-4
In reply to this post by Edgar De Cleene
Edgar J. De Cleene wrote:
>
> On 8/20/10 7:50 PM, "Juan Vuletich" <[hidden email]> wrote:
>
>  

Just for the record. This started with you saying:
"You have a kernel and this is the Pharo Kernel, mostly Pavel work.
Why smart people like both you desire do all again ? "

 

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

Well, at least you did answer one of my questions. Maybe Pharo Kernel is
simpler. I don't know. But even if simplicity is of key importance to
me, I want a balance between simplicity and some other properties. For
instance, Dan's mini.image or Squeak 1.2 are much simpler than Cuis. But
I prefer Cuis anyway.

> No
>
> What community needs is HOW TO go from it to complex images in a documented
> way.
>
>
> Edgar
>  

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Pavel Krivanek
In reply to this post by Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Consensus Call (was Re: [squeak-dev] Re: Meeting Report for 8/18/2010)

Edgar De Cleene



On 8/22/10 5:05 AM, "Pavel Krivanek" <[hidden email]> 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


Thanks Pavel, now I ask...

We could have a Skype conference ?

We means Andreas, Juan , you and all who want help to have a SqueaKernel or
a SwissKnife like image , minimal in classes but from all could grow to say
Etoys or Cobalt or Seaside complex images ?

I volunteer for hard work to any 3 Master agree, but like to hear you on
live.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Andreas.Raab
In reply to this post by Pavel Krivanek
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Levente Uzonyi-2
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
>>>
>>>
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Andreas.Raab
In reply to this post by Pavel Krivanek
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

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Pavel Krivanek
In reply to this post by Levente Uzonyi-2
2010/8/23 Levente Uzonyi <[hidden email]>:

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

Sorry, I didn't want to be ugly. Maybe not, I only wanted to tell that
from my point of view the speed of Pharo development seems to be more
progressive.

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

Reply | Threaded
Open this post in threaded view
|

Re: Meeting Report for 8/18/2010

Pavel Krivanek
In reply to this post by Andreas.Raab
On Tue, Aug 24, 2010 at 5:40 AM, Andreas Raab <[hidden email]> 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?

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.

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

It is very sad that the Smalltalk community is splitted only because
of political reasons and the amount of technical ones will only grow.
Especially when goals of all fractions seems to be so close...

Of course if you will want to use my work for Squeak modularization, I
will help you.

Cheers,
-- Pavel
>
> Cheers,
>  - Andreas
>
>

123