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)
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?
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?
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.
-Luke
P.S. TimeProfileBrowser is a dreamboat!
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
- 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).
- 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
- 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 -
Hi, Luke,
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.
I don't know why you have thousands of them there, but please update your image at least to 1755, and go to the problematic project, and evaluate:
ActiveWorld cleanUpReferences
this would remove the references to objects that are already garbage collected.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org