[Etoys] Questions questions

[Bert Freudenberg]

On Nov 11, 2007, at 11:21 , Luke Gorrie wrote:

> Howdy!
>
> I have some questions and suggestions following up this blog post:
> http://nepal.ole.org/home/?q=node/86
>
> 1. How can we load applications like Monticello, Whisker, Refactoring
> Browser, etc into the XO image?
> From #squeak I have a working method to import Monticello but it's not
> pretty (it involves the debugger's 'Return from frame:' feature for
> example)

I don't quite understand. Use whatever methods you would normally  
use? The problem is making this permanent in the image, and writing  
the changes file (both are read-only in /usr/share/etoys). We do not  
support saving the image to the Journal - yet. Even if we did, how  
would we associate a project with an image? The only way I can think   
of is to save the new image in a new .xo bundle. Not sure if/when  
Sugar/Rainbow will allow one activity to create a new activity,  
authoring support does not appear to be a top-priority at OLPC for now.

A work-around would be saving the image to the SUGAR_ACTIVITY_ROOT/ 
data directory, and if we find it, use it instead of the system- 
provided one. The problem with that is that it would get used for all  
Etoys work from then on, and it's too easy to save a broken image,  
which would break Etoys completely. I do not have a good idea for  
that - the Sugar UI should probably provide a way to "reset" an  
activity by wiping out its data/ directory, but this is not  
implemented yet (nor even in a feature request ticket - those get  
punted from milestone to milestone anyway).

> 2. What repository should we use for our project files?
> We're developing a set of activities as project files, much like
> Demon's Castle and Etoys Challenge. We're trying to choose between a
> shared folder, git/svn/etc repository, attachments on Wiki pages, a
> SuperSwiki, etc. How's it done for the projects that ship with the XO?

We use a subversion repository - it works better for binary files  
than git.

Actually we use a WebDAV folder, too, but that's only for convenience  
for those who find SVN too hard to use. Projects are then moved to  
SVN for release.

SuperSwikis are generally aimed at user-provided content.

To make a project available, you can simply put a link to it on a web  
page. Clicking the link then downloads the project to the Journal  
from where it can be launched.

You might also want to read about "Content Bundles":

http://wiki.laptop.org/go/Creating_a_content_bundle

> 3. To begin with we're using a custom Squeak image to run our
> activities in. This is mostly a simple way to make our Smalltalk
> codebase available to all projects. Should we be thinking about a
> better way to do this?

Definitely. I'd very much like the default image to be reused by all  
Squeak-based activities. How to make application loading be efficient  
while sharing the read-only image is ... interesting.

> Finally I've found a performance-degradation problem with
> Morph>>duplicate that I haven't figured out how to reproduce from a
> fresh image. In one of my images Morph>>duplicate is spending lots of
> time (600ms on a fast machine) searching for a unique name in the
> series Sketch1/Sketch2/etc. It seems to be rejecting thousands of
> names that have actually fallen out of use (their morphs have been
> garbage collected). In this image I've found the following dubious
> change helpful in PasteUpMorph>>uniqueNameForReferenceFor:
>
> old: ((self referencePool includesKey: nameSym) not and:
> new: (((self referencePool at: nameSym ifAbsent: nil) isNil) and:
>
> because many names are present as keys in the referencePool with value
> nil. I'm not sure if this is the right thing or how I ended up with so
> many names in use.

You should open a Trac ticket about that.

- Bert -