[Etoys] [sugar] Multiple documents
bert at freudenbergs.de
Wed Aug 1 11:02:16 EDT 2007
Well, we (the etoys minions) try to accommodate whatever the platform
Our original thinking was to have just one Etoys process that serves
multiple instances. There were issues on the Sugar side, like that
Sugar insists on having a separate X window for each activity instance.
So for the time being we implemented a one-process-per-instance
policy, first using a wrapper reusing the Python activity code, and
currently using sugar-native-factory.c which forks off new Squeak/
So two instances do not share their memory at the moment which is
inefficient. It could be more efficient if the "static" parts of the
object memory could be shared, this is not supported yet - even if
forking with copy-on write semantics the first full garbage
collection would touch all pages (*).
OTOH, having separate processes simplifies activity handling quite a
bit. For example, if two instances of Etoys would be shared on the
mesh, they would have to be handled simultaneously, which would be
hard if these were inside one Squeak process as only one Etoys
project can be active at a time.
A "project" is the Etoys equivalent of an activity instance
(predating Sugar but has pretty much the same keep/resume idea). A
different issue is that we currently create multiple journal entries
per instance, one per project. Only one project is ever active, but
in one "session" multiple projects can be created.
So in short - we do have something that works now, we still would
like to become more efficient, supporting multiple-instances-per-
process might help with that, it gives more options to activity
- Bert -
(*) We have a incremental mark-and-sweep GC, the mark bits are in
each object header scattered trough memory, so they are written in
each mark pass. And when compacting, objects move, and object
references change, so a lot of memory is touched by that, too
(although compacting happens less often than the incremental mark-and-
sweep). The object memory and garbage collector was not designed for
On Jul 12, 2007, at 13:47 , Noah Kantrowitz wrote:
> We (the security minions) had been working under the assumption that
> etoys would be operating in single-instance mode because of memory
> Bert Freudenberg wrote:
>> Well, we can create several projects and switch between them, like
>> for making a presentation. Until now this has been done inside Etoys.
>> But my question was about what the desired Sugar model is, and we'll
>> try to fit in.
>> See my mail to the olpc etoys list:
>> - Bert -
>> On Jul 12, 2007, at 16:03 , Tomeu Vizoso wrote:
>>> Bert, how can a single eToys activity instance create several
>>> objects in
>>> the journal? Wouldn't be everything inside a single eToys project?
>>> On Thu, 2007-07-12 at 09:25 -0400, Erik Blankinship wrote:
>>>> This is a good question; access to individual photographs &
>>>> videos in
>>>> the journal have this problem.
>>>> On 7/12/07, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> If I understand the Sugar philosophy correctly, we won't
>>>> multiple documents per activity. If we want to have
>>>> documents opened at the same time, these would be multiple
>>>> of the same activity.
>>>> Is this the case?
>>>> And if so, what would one activity instance have to do to
>>>> create a
>>>> new instance?
>>>> - Bert -
More information about the etoys-dev