[etoys-dev] together again

[Jecel Assumpcao Jr]

Andreas Raab wrote on Mon, 05 Oct 2009 20:58:53 -0700
> Jecel Assumpcao Jr wrote:
> > Indeed. I think it is good to have these discussions now. I will start
> > by confessing that I have not looked at the Etoys code to see what the
> > problem is, so am only repeating what other people have said.
> 
> Actually, this is *precisely* why I'm saying it's premature to talk 
> about these issues. Neither you, nor Göran, nor Serge, nor I have really 
> any clue about what it entails. Consequently we are only discussing our 
> own prejudices about Etoys.

True, but those who know more are also here on this list. I am hoping my
ignorant rants will provoke them to add a fact or two to the discussion
:-)

> If we want to move this forward we need insights from the Etoys 
> developers. We need someone who can take a high-level census of Etoys 
> and tell us which areas are mostly unchanged, which areas have undergone 
> significant changes, which areas need to be closely investigated.

That is the information we need for the merge of Etoys 4.0 and Squeak
Trunk, which was the original subject of this thread. My last comment
was about making Etoys be a reloadable package since Göran is interested
in that. In theory these are two completely separate problems, but I
expect that most changes that would help with one would also help with
the other.

>  From a practical perspective, one way to move forward would be 
> something along the following lines:
> 
> * Get MC loaded into the Etoys image (by hook or by crook)

http://tracker.squeakland.org/browse/SQ-106
> http://wiki.laptop.org/go/Etoys_Tips_and_Tricks#Installing_Monticello_on_your_Etoys_image

Currently this is scheduled for the June 2010 version of Etoys.

> * Create the package structure we find in the trunk

This means just moving classes and methods from one category to another,
right?

> * Adopt the latest trunk versions as ancestors (to fake heritage)

Interesting - I didn't know this was an option.

> * FixUnderscores where necessary
> * Compute the number of changes between the Etoys image and trunk
> 
> Once finished, I think we will find that packages generally fall into 
> one of the following categories:
> 
> * New: Packages that are in one but not the other
> * Easy: Less than 100 changes between versions
> * Hard: Less than 1000 changes between versions
> * Ouch: More than 1000 changes between versions
> 
> Based on this we should be able to get a feel for what we're talking 
> about on the highest level. I'm in particular interested in packages 
> that are in one but not the other since they are most likely the ones 
> that create the most unforeseen dependencies (take traits for example or 
> pango rendering).

As a very crude approximation, I compared the categories in
SystemOrganization for a Squeak 3.10.2-7179 image and for the
Etoys-To-Go-4.0.2258-beta image. The first one has 159 categories not
present in the second, while the Etoys one had 120 categories that are
missing from the 3.10 image. They have 108 categories in common.

It would be more interesting to look at packages instead, but the Etoys
image lists only two: FlexibleVocabularies and Connectors.

-- Jecel