[squeak-dev] Squeak vision

> On 03.07.2009, at 01:44, Colin Putney wrote:
>
>> On 2-Jul-09, at 2:49 PM, Ramon Leon wrote:
>>
>>> Exactly the point, Etoys already forked.  Stop holding onto an old  
>>> rotting version in Squeak that isn't used, take it out, it doesn't  
>>> belong there. People who want eToys have their fork where it is  
>>> maintained.
>>
>> I think this is one of the key issues in the wider Squeak community  
>> right now, made all the more difficult because the Etoys team has  
>> been completely silent on the issue.
>
> Err, counting the number of mails I sent on the subject just in the  
> last few days can hardly be called "completely silent," can it?

> On 2-Jul-09, at 2:49 PM, Ramon Leon wrote:
> > Exactly the point, Etoys already forked.  Stop holding onto an old
> > rotting version in Squeak that isn't used, take it out, it doesn't
> > belong there. People who want eToys have their fork where it is
> > maintained.
>
> I think this is one of the key issues in the wider Squeak community
> right now, made all the more difficult because the Etoys team has been
> completely silent on the issue. It's clear that Etoys can be excised
> from Squeak - it's been done a few times already. It's much more
> difficult to separate out a working Etoys package that can be loaded
> into a base image, particularly since the people that would be best
> able to do that are busy with other things. But even if we put in the
> effort and managed to create a loadable Etoys package, it's not clear
> that it would ever get used.
>
> So how about it, Etoys developers? Are you at all interested in
> synchronizing with Squeak at some point in the future? If so, how do
> you imagine it could be accomplished? Is there value in the Etoys code
> that's part of Squeak 3.10? Would you be interested in having a
> cleanly defined Etoys package?
>
> I'm not asking for promises, here, just opinions.

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

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

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

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

>> The first step in this direction could be a fast bytecode package
>> loader, without the need to compile Smalltalk code.
>
>
> Indeed. Perhaps you remember the discussions we had about ImageSegments
> that loaded classes complete with CompiledMethods? Which is way way
> faster than compiling code, and could not only be used to load squeak
> apps on top of a fixed image like for Dr Geo on Etoys, but could also
> lead to blazingly fast updates, or to very efficient field patches of
> deployed software. Maybe bringing this idea up in a separate thread here
> on squeak-dev would get some developer intrigued - I for one do find
> this a fascinating project.

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

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

> On 7/9/09 9:38 AM, "Colin Putney" <[hidden email]> 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 .....

> Bert Freudenberg a écrit :
>
> >> The first step in this direction could be a fast bytecode package
> >> loader, without the need to compile Smalltalk code.
> >
> >
> > Indeed. Perhaps you remember the discussions we had about ImageSegments
> > that loaded classes complete with CompiledMethods? Which is way way
> > faster than compiling code, and could not only be used to load squeak
> > apps on top of a fixed image like for Dr Geo on Etoys, but could also
> > lead to blazingly fast updates, or to very efficient field patches of
> > deployed software. Maybe bringing this idea up in a separate thread here
> > on squeak-dev would get some developer intrigued - I for one do find
> > this a fascinating project.
>
> I have the felling (unobjective) such feature could make life easier to
> third party Etoys developer and eventually attract more of them to Etoys.
>
> Hilaire
>

> At Mon, 13 Jul 2009 13:14:43 HST,
> [hidden email] wrote:
> >
> > > Bert Freudenberg a $BqD(Brit :
> > >
> > > >> The first step in this direction could be a fast bytecode package
> > > >> loader, without the need to compile Smalltalk code.
> > > >
> > > >
> > > > Indeed. Perhaps you remember the discussions we had about

> > > > on squeak-dev would get some developer intrigued - I for one do find
> > > > this a fascinating project.
> > >
> > > I have the felling (unobjective) such feature could make life easier to
> > > third party Etoys developer and eventually attract more of them to Etoys.
> > >
> > > Hilaire
> > >
> >
> > Closed-sourse EToys would violate the concept of the user having access to
> > everything in the system, a cornerstone of Alan Kay's vision.
>
>   Well, it would violate the concept if it is closed source.
>
> > "User" does not refer strictly to the person using the computer at
> > that moment. A teacher setting up and running an EToy session
> > qualifies as the "user," and as such should have access to complete
> > source and the right to modify it as they see fit.
>
>   They do.
>
> > Educational software as product should not be treated as a for-profit
> > market. All educational software and content should be open-source. The
> > bulk of this work should be pro bono. What renumeration there is should
> > come from grants. The educational system should benefit from free learning
> > materials in the same manner we have benefited from Squeak.
>
>   I'd think that not all educational software and content should be
> open-source.  But Etoys is.  So, what is your point?

>
> Bert Freudenberg a écrit :
>
> >> The first step in this direction could be a fast bytecode package
> >> loader, without the need to compile Smalltalk code.
> >
> > Indeed. Perhaps you remember the discussions we had about ImageSegments
> > that loaded classes complete with CompiledMethods? Which is way way
> > faster than compiling code, and could not only be used to load squeak
> > apps on top of a fixed image like for Dr Geo on Etoys, but could also
> > lead to blazingly fast updates, or to very efficient field patches of
> > deployed software. Maybe bringing this idea up in a separate thread here
> > on squeak-dev would get some developer intrigued - I for one do find
> > this a fascinating project.
>
> I have the felling (unobjective) such feature could make life easier to
> third party Etoys developer and eventually attract more of them to Etoys.

>
> > Bert Freudenberg a 馗rit :
> >
> > >> The first step in this direction could be a fast bytecode package
> > >> loader, without the need to compile Smalltalk code.
> > >
> > >
> > > Indeed. Perhaps you remember the discussions we had about ImageSegments
> > > that loaded classes complete with CompiledMethods? Which is way way
> > > faster than compiling code, and could not only be used to load squeak
> > > apps on top of a fixed image like for Dr Geo on Etoys, but could also
> > > lead to blazingly fast updates, or to very efficient field patches of
> > > deployed software. Maybe bringing this idea up in a separate thread here
> > > on squeak-dev would get some developer intrigued - I for one do find
> > > this a fascinating project.
> >
> > I have the felling (unobjective) such feature could make life easier to
> > third party Etoys developer and eventually attract more of them to Etoys.
> >
> > Hilaire
> >
>
> Closed-sourse EToys would violate the concept of the user having access to
> everything in the system, a cornerstone of Alan Kay's vision.