[Edu-sig] FYI: PataPata postmortem link

[Ian Bicking]

Paul D. Fernhout wrote:
> Ian-
> 
> 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 
begin with.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org