[squeak-dev] Maintaining Etoys in Squeak

Milan Zimmermann milan.zimmermann at sympatico.ca
Sat Jul 11 19:20:06 UTC 2009


Hi Colin,

For a few days, I was thinking about switching the "desirability order" you 
suggested (that removing Etoys  from Squeak would better then leave things as 
they are). While my preference remains to keep Etoys in Squeak, perhaps taking 
the step of removing Etoys  would be a "big kick". motivation for someone (or 
a team rather) to provide a reloadable Etoys package. But in any case, I 
continue to think that Bert is right, and for this purpose Etoys and Morphic 
need to be considered one package, otherwise we will not get there.

I started to think that the "fork of interest" for Etoys users have shifted to 
the Squeakland version (http://squeakland.org/download/) by now, but checking 
the ESUG 2009 Award Nominations

http://www.esug.org/Conferences/2009/Innovation+Technology+Awards/Nominations

I created a somewhat arbitrary statistics, I am likely a bit off but :

Business Apps: 4
Other Apps: 2 
Web Frameworks: 3
Other Frameworks:  5
Persistence: 2
Using Etoys in Squeak: 4

I do not think those projects use the Squeakland version. So also from that 
perspective just unloading Etoys (+Morphic) without providing reload would not 
be fair to these users. (But again my analysis above is not precise at all)

A few more notes inline


On July 9, 2009, Colin Putney wrote:
> Hi Milan,
>
> Thanks for taking the time to reply. Those do seem to be the available
> options, but I think I'd order them with #1 and #2 reversed. I think
> what we have now is the least desirable state of affairs. Further
> comment inline:
>
> On 5-Jul-09, at 11:53 PM, Milan Zimmermann wrote:
> > Colin,
> >
> > Thanks for taking a fresh look at this. My Etoys/Squeak
> > synchronization
> > approaches are, from the "least desirable" to the "most desirable":
> >
> > #1. Remove Etoys from Squeak, as some suggested:
> > 	- Cons and Questions: Where is the boundary between Morphic and
> > Etoys? Does
> > it mean Morphic removal as well? What does it mean for Squeak in
> > education?
> > 	- Pros: None for me. I voted for board individuals who I assumed
> > would not
> > support this.
>
> I think this implies that the Squeakland distribution remains separate
> from Squeak, and gradually diverges, as Squeak becomes less and less
> Etoys-compatible. It also means, I think, removing Etoys but not
> Morphic. The boundary can be somewhat arbitrary, and the freedom to
> break Etoys compatibility makes it easier to clean up Morphic over time.
>

I think that is true. If the intent was "we do not care about Etoys, just 
Morphic", a arbitrary line could be drawn, leaving "Morphic of sorts" in 
squeak, but removing any useful Etoys stuff. The reason I do not like this 
option at all is that it would probably make close to impossible" to provide a 
"loadable Etoys" package.  There would be no practical hope to synchronize 
Squeakland with Squeak in the future.

> > #2. Do nothing
>
> Does this really mean nothing at all, or are you imagining that Squeak
> gets updated to the latest Etoys, even though we can't draw a line
> around it and manage it with Monticello? If you mean nothing at all,
> I'd say this is the least desirable scenario. If nobody is using the
> Etoys code in Squeak, it should be removed. On the other hand, if we
> can get Squeakland using a vanilla Squeak 3.11 (or whatever the
> release is called) it would be worth living with the kernel bloat for
> a while longer.

Well, in brief, I did mean "nothing at all now" - with some hope doing 
"something" in the future. But I realize this is not sustainable for long. We 
need small kernels a loadable packages with defined dependencies.... At the 
same time there are still teams using Etoys in Squeak (e.g. above link to 
submissions to ESUG).

>
> > #3. Achieve ability to Manage Etoys+Morphic as single Monticello
> > project.
> > Unload existing Morphic+Etoys version from Squeak, and replace it
> > with the one
> > in Etoys 4.0 image
> > 	- Cons: Boundary between Morphic and Etoys remains undefined. Would
> > be nice,
> > but it may be impossible given the time we have.
> > 	- Pros: Refresh of Etoys (and some Morphic elements) from the work
> > made for
> > OLPC in the last 2 years. This was a significant investment!
>
> It seems like this could be done in the reverse as well - update
> Morphic/Etoys from the Etoys 4.0 image, then draw the line around it
> and make it a Monticello package.

My thinking on the approach would be:
	A) Make Morphic+Etoys a loadable Monticello package in the Squeakland 
(license clean) image. That way, we, people interested in Etoys, proove it is 
possible, and "do it" in our image
	B) Remove Morphic+Etoys from Squeak (e.g. 3.11?) image.
	C) Make the Squeakland Morphic+Etoys Monticello package loadable in Squeak 
(3.11)
	D) Release Squeak 3.12 with loadable Morphic+Etoys
	E) At this point Squeakland and Squeak would be in sync.
I think this is what you ment (maybe I misunderstood?).

How much work it is, would there be a reasonably strong consensus .. I do not 
know

>
> > #4. Define Boundariies between Morphic and Etoys. Achieve ability to
> > Manage
> > Morphic as one Monticello project and Etoys as a separate Monticello
> > project.
> > Unload existing Morphic+Etoys version from Squeak, and replace at
> > least  Etoys
> > from the Etoys 4.0 image
> > 	- Cons: None for me. Except we may not have enough time to achieve
> > this...
> > 	- Pros: Refresh of Etoys (and some Morphic elements) from the work
> > made for
> > OLPC in the last 2 years. This was a significant investment! Ability
> > to manage
> > Morphic and Etoys separately would unlock much potential (e.g.
> > replace Morphic
> > with Morphic2 and keep Etoys functional on top of Morphic2)
>
> Sure. This is definitely the ideal.
>
> It occurs to me that your numbering could represent steps in a
> progression rather than a prioritizing mutually-exclusive
> possibilities. 

I agree - these should be made into evolutionary steps. If the evolution ends 
at #3, I would be happy enough ( :) )

> #1 has already been done, a few different ways.

Yes .. I assume with an accidentally defined boundary between Morphic and 
Etoys. But I may be wrong

> Understanding what gets removed when we create an image without Etoys
> is a good first step. Even more important are the changes that have to
> be made to the base image to keep it running correctly in the absence
> of Etoys.
>
> #2 might be seen as porting the latest Etoys to a different base image
> - one with no Etoys present.
>
> #3 and #4 are going to be difficult  no matter what, but they might be
> a bit easier if #1 and #2 have already been accomplished.

I agree, but at the same time if we "remove Etoys from Squeak first", it will 
be around some arbitrarily / randomly defined boundary and I am afraid there 
may be no way to proceed to loadability in #3 and #4. At the same time, Squeak 
modularization "should" happen at some point. Perhaps at some point the board 
will a make a statement like "if within this year, non-core packages are not 
reloadable, and someone provides a good kernel image, what is known as Squeak 
will be this new kernel image. Whoever wishes to make their packages loadable, 
go ahead"...

>
> I don't have loads of spare time either, nor even the expertise in
> this area of the image. But I, too, would be willing to help. I think
> that achieving #4 is probably the most valuable thing we could put our
> collective effort into, now that the legal and social issues are
> largely fixed. Once our technical issues - of which Etoys is by far
> the largest - are sorted out, we'll be in a very good position to
> progress and grow as a community.

Well, I would not pick Etoys as "the largest technical issue" , but perhaps I 
would agree that "Etoys and Morphic" are the "most argued about issues" :) - 
with an additinal note those who argue often do not have a good idea about a 
well-definable boundary between them (that includes me!).

Thanks, Milan
>
> Colin





More information about the Squeak-dev mailing list