On July 10, 2009, Edgar J. De Cleene wrote:
> On 7/9/09 9:38 AM, "Colin Putney" <cputney at wiresong.ca> 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.
> >
> >> #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.
> >
> >> #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.
> >
> >> #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. #1 has already been done, a few different ways.
> > 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 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.
> >
> > Colin
>
> Milan and Colin:
> I do the rip of Etoys (my way) some time ago.
> Also have some success in reloading again an have old Etoys .pr working.
> I exchange some email  with Yoshiki and following his advice...
> This days I looking how to made a Monticello version from Etoys 4.0 and the
> load this into my SqueakLightII, which is a 3.10 shrinked version full
> compatible
> So if we could work together could be very nice .....

HI Edgar,

could you provide a link to a "do it" or the mechanism you used to unload / 
partly reload Etoys in the past?

Thanks, Milan

> Y puede ser un equipo bilingue, dos de tres entendemos español.
>
> Edgar