[Etoys] Questions questions
bert at freudenbergs.de
Sun Nov 11 06:51:01 EST 2007
On Nov 11, 2007, at 11:21 , Luke Gorrie wrote:
> I have some questions and suggestions following up this blog post:
> 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
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
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":
> 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 -
More information about the Etoys