Hi again,
From time to time (well, during school holidays), I experience a strong desire to hack some Smalltalk. Since I'm trying to make more use of EToys, the EToys dev image is where I start.
However, it still seems harder than expected to get SqueakMap and Monticello loaded, so I can then get Shout and eCompletion from SqueakMap. (I think I mentioned this difficulty during a previous school holiday ...!)
Currently, the best way I know is to use LevelPlayingField (which gives me a working SqueakMap and Monticello), then I have to manually revert methods in SARInstaller to invoke ChangeSorter>>removeChangeSet rather than ChangeSet>>removeChangeSet (which doesn't exist) following a suggestion from Subbu on squeak-dev (thanks!).
If I try to use SqueakMap without LevelPlayingField, it gets confused trying to upgrade from version 2.0 to version 2.2, and I don't know how to fix that.
Am I unusual in wanting to do this? Is there a better thing to do?
cheers, Simon
At Wed, 30 Sep 2009 16:00:17 +1300, Simon Guest wrote:
Currently, the best way I know is to use LevelPlayingField (which gives me a working SqueakMap and Monticello), then I have to manually revert methods in SARInstaller to invoke ChangeSorter>>removeChangeSet rather than ChangeSet>>removeChangeSet (which doesn't exist) following a suggestion from Subbu on squeak-dev (thanks!).
If I try to use SqueakMap without LevelPlayingField, it gets confused trying to upgrade from version 2.0 to version 2.2, and I don't know how to fix that.
Am I unusual in wanting to do this? Is there a better thing to do?
It is true that most of the developers are happily hacking without Shout and eCompletion and stuff. One of the considerations is the deployment; we've been making the deployment image without shrinking the dev image (very little), and extra things for developers need means bigger deployment images, and some extra care will be needed for the Etoys-user-oriented text objects, etc.
I forgot when was the last time I tried to use Monticello in the etoys dev image (I seem to remember fixing removeChangeSet or such method in my image when I did it), but didn't carry it much further. And often all I need is just to load a .mcz file and it works. If there is a minimal change we can make in the image side, we should do that.
-- Yoshiki
Simon Guest wrote:
Am I unusual in wanting to do this? Is there a better thing to do?
No you're not. I'd like to do the same. Unfortunately the Etoys image is so far behind at this point that it has become a serious hindrance for me. No Monticello, Shout, ToolBuilder, Closures etc. You name it. OTOH, Etoys has all the media activities that are broken in Squeak.
Here is a VHLQ (very high-level question): How do people feel about bringing Squeak.org and Etoys together again? Since the Etoys-haters left, there is both room as well as a need for a driving application. A merger with Etoys would give Squeak back its primary purpose for existence, would allow the Etoys community to benefit from improvements made at Squeak.org and allow of us to focus our efforts in trying to provide a unified artifact for personal dynamic media. We have an open development process that I think could work for such a project so that at the end of the day the Squeakland release may come with a special "skin" for the UI but where the basic system is a Squeak.org image right out of the box.
I'm not sure if we have the resources to do this quickly but I'd like at least to raise the question to see how people feel about it. Is this even option?
Cheers, - Andreas
On 30.09.2009, at 09:09, Andreas Raab wrote:
Simon Guest wrote:
Am I unusual in wanting to do this? Is there a better thing to do?
No you're not. I'd like to do the same. Unfortunately the Etoys image is so far behind at this point that it has become a serious hindrance for me. No Monticello, Shout, ToolBuilder, Closures etc. You name it. OTOH, Etoys has all the media activities that are broken in Squeak.
Here is a VHLQ (very high-level question): How do people feel about bringing Squeak.org and Etoys together again? Since the Etoys-haters left, there is both room as well as a need for a driving application. A merger with Etoys would give Squeak back its primary purpose for existence, would allow the Etoys community to benefit from improvements made at Squeak.org and allow of us to focus our efforts in trying to provide a unified artifact for personal dynamic media. We have an open development process that I think could work for such a project so that at the end of the day the Squeakland release may come with a special "skin" for the UI but where the basic system is a Squeak.org image right out of the box.
I'm not sure if we have the resources to do this quickly but I'd like at least to raise the question to see how people feel about it. Is this even option?
IMHO (and as I said previously) it is the *only* option for sustained development of Etoys.
So, in a word, yes. Not trivial by any measure but necessary in one way or the other.
There was even a coarse plan for how to do it, but I'm not sure if we ever wrote it up. Something along the lines of document the current UI / behavior (what we consider officially supported in Etoys), and when the "new thing" meets the spec, switch over.
Good news is that work on the documentation part is already starting (see below).
- Bert -
Begin forwarded message:
From: Bert Freudenberg bert@freudenbergs.de Date: 3. September 2009 13:38:12 MESZ To: etoys dev etoys-dev@squeakland.org, "squeakland.org mailing list" squeakland@squeakland.org Subject: [etoys-dev] Re: Etoys documentation TOC
On 03.09.2009, at 13:23, Timothy Falconer wrote:
On Sep 3, 2009, at 7:01 AM, Rita Freudenberg wrote:
Hi all,
as you all know we don't really have an Etoys documentation. So let's start writing it. As I wrote earlier I propose to use FLOSS Manuals. It is used by the olpc and sugar community for writing manuals and books. To get started we should have a TOC outline. Here are my suggestions:
- Introduction (short description what etoys is about)
- Getting started (technical description on how to install and
start etoys on different operating systems) 3. User Interface (painting tools, halo, viewer ...) 4. Tiles (describing every available tile) 5. Objects (everything from the supplies bin and object catalogue, flaps)
What am I missing? Of course we can have subchapters and also later add main chapters if we find out we need it. Here is the manual for TurtleArt so you can get the idea what our documentation could look like: http://en.flossmanuals.net/turtleart
What do you think? If we come up with a TOC outline I can send it to Anne Gentle from FLOSS manuals to set it up and we can start writing:)
It's a good list. So this would be more of a reference manual than a getting started guide? (with tutorials)
IMHO that would be much harder to write than a reference manual. It's still desperately needed of course but we should start simple.
The reference manual also serves another purpose: it defines the boundary of what we consider officially supported, and what not. As you know there is much more in Etoys than is easily accessible on the surface. If it's documented, we try hard support it. If not, you may still use it but can't rely on to work in future versions.
- Bert -
Andreas Raab wrote:
Simon Guest wrote:
Am I unusual in wanting to do this? Is there a better thing to do?
No you're not. I'd like to do the same. Unfortunately the Etoys image is so far behind at this point that it has become a serious hindrance for me. No Monticello, Shout, ToolBuilder, Closures etc. You name it. OTOH, Etoys has all the media activities that are broken in Squeak.
Here is a VHLQ (very high-level question): How do people feel about bringing Squeak.org and Etoys together again?
YES!! This is the way to go for the future of Etoys and Squeak! As an educator, I would *love* to be able to go on from Etoys down to Squeak in teaching, and we do have many children in the world who are now learning Etoys in school. It would be so sad to loose all of them who have deeper interest in programming to other programming languages only because there is no easy way to dive into Squeak. As a board member of Squeakland Foundation I know about the amount of work we have to accomplish in order to maintain and improve Etoys further, so we *need* Squeak developers, and if what they are doing for Squeak could be used by us for Etoys and vice versa, that would help the whole community. And, by the way, in Brazil we discovered, that most of the people call it "Squeak Etoys" or even Squeak (when they talk about Etoys), so that's another reason to give them Etoys, too, when they download Squeak somewhere :)
Greetings, Rita
Since the Etoys-haters left, there is both room as well as a need for a driving application. A merger with Etoys would give Squeak back its primary purpose for existence, would allow the Etoys community to benefit from improvements made at Squeak.org and allow of us to focus our efforts in trying to provide a unified artifact for personal dynamic media. We have an open development process that I think could work for such a project so that at the end of the day the Squeakland release may come with a special "skin" for the UI but where the basic system is a Squeak.org image right out of the box.
I'm not sure if we have the resources to do this quickly but I'd like at least to raise the question to see how people feel about it. Is this even option?
Cheers,
- Andreas
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Wednesday 30 Sep 2009 6:33:46 pm Rita Freudenberg wrote:
YES!! This is the way to go for the future of Etoys and Squeak! As an educator, I would love to be able to go on from Etoys down to Squeak in teaching, and we do have many children in the world who are now learning Etoys in school.
+1. I am a community member helping students in about 120 village schools (near Bangalore, India) use Etoys on a regular basis in 5th..7th grade. Though the interface is in English and the students and teachers are barely literate in this language, there is a ground swell of support for such intuitive software amongst students and teachers for appropriation in classrooms. It is so nice to be able to drill down from "ideas" to the "metal" with Etoys and Squeak.
Etoys may be getting long in the tooth for researchers and Squeak may be evolving rapidly as a commercial deployment engine. But let us not lose sight of the value of the combination as a learning lab in schools across the world.
Subbu
Andreas Raab asked:
I'm not sure if we have the resources to do this quickly but I'd like at least to raise the question to see how people feel about it. Is this even option?
While I can't contribute any resources at the moment, this is a very high priority for me. I tried to start a discussion about a merged Etoys and Squeak shortly before the Squeak board election.
Not all Etoys haters have gone away, but I see no reason why they can't put up with an official Squeak containing Etoys plus a script to remove them. The ideal would be a tiny kernel into which things could be loaded but that is not going to happen right now so this option will have to do.
If I remember correctly, Squeak had split into several forks at the time of 3.7: official, Squeakland, SmallLand, Japanese and Croquet. Thanks to the hard work of several people, the first four were merged into the official 3.8 and with more work by other people Croquet was brought into sync with this.
My small experience with looking at the licensing changes in Pharo makes me think that a current Squeak trunk / Etoys merge might actually be a bit harder to do than Squeak 3.8 (a point Keith always insists on), but this could be just my lack of familiarity with Monticello.
It would be great if the gap between programming in Etoys and in Smalltalk-80 could become smaller and smaller in the future and it would be a pity to add having to switch between images to that gap.
-- Jecel
etoys-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Jecel Assumpcao Jr -
K. K. Subramaniam -
Rita Freudenberg -
Simon Guest -
Yoshiki Ohshima