[Edu-sig] FYI: PataPata postmortem link
ianb at colorstudy.com
Tue Nov 28 17:17:41 CET 2006
Paul D. Fernhout wrote:
> Thanks for the comment.
> I think the issue you raise is a really difficult one to resolve. If I
> understand the general issue correctly, when you are looking at a GUI
> interface with underlying processes, and a person wants to "see the code",
> the question is what to show them, and also whether to show it to them in
> such a way as they can modify either what they see right then, or what
> they might see if the restarted the program.
> One thing I had sometimes dreamed about is mapping every pixel on the
> screen with a programming or debugging equivalent of a "Z-Buffer". But in
> this, call it perhaps an "S-Buffer", instead of storing Z-depth from a
> pixel on a polygon, you could associate a stack trace with every pixel
> from the process that last wrote to that pixel (you might even store the
> stacks of everyone who wrote to that pixel).
Of course that takes a lot of space, and OLPC is a considerable step
backwards in terms of resources. With 128Mb of RAM (and not really any
feasible swap) we have to be very conservative. This also can't have
any overhead if a child isn't using it.
My initial thought was more like a "view source" that showed the "main"
file -- which might be automatically detectable, or maybe we'd just have
the activity declare what its main file is. Then you could essentially
enter a stepped mode, where the next event would be captured and you'd
see execution at that point. OTOH, a "mouse-in" event is often pretty
boring, so there might be different kinds of events you can catch.
Also, we can just look at events until we see one that actually points
to Python code (with the assumption that all C code is totally opaque --
which in practice it is).
That will help you see why the program acts like it does, but not how it
got to be how it is. Simple/safe restarting might make that even more
complicated -- if we try to get activities to safely shut down and
restart without losing state or information, then a lot of state is
going to essentially appear from nowhere (like from a pickle). And that
state might be "corrupt" in some fashion, if you are preserving buggy
state, or you are preserving state with no longer matches the code (if
you are restarting to see edits). Ugh; I hate persistence.
OK, so now I realize we need to think about simple ad hoc persistence.
And that persistence has to be transparent, otherwise it's not possible
to debug or handle upgrades. Well, there should always be an option to
ditch anything that has persisted and start from scratch.
Sigh... this opens up enough issues that I have to think about it some
more. Serialization is going to be a big deal. Oh, but in conclusion
-- restarting with saved sessions makes it even harder to figure out why
the state (and UI) gets set up the way it does, and it wasn't easy to
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Edu-sig