[Edu-sig] FYI: PataPata postmortem link

[Paul D. Fernhout]

Ian-

Yep, that sounds about right to me -- I like how you phrase "That will 
help you see why the program acts like it does, but not how it got to be 
how it is.". And that is why modifying complex systems like event driven 
GUIs of significant size is non-trivial, and involves using some analogue 
of all the Smalltalk-inspired tools of Inspector, Browser, Debugger, and 
Workspace, no matter how much we how some great tool could make it easier, 
or how approachable we try to make the experience for beginners. There is 
a lot going on under the hood of a modern application (or in its support 
libraries at least) and making it easier to understand in detail might 
require an entire paradigm shift (perhaps functional programming or even 
logical AI programming?).

--Paul Fernhout

Ian Bicking wrote:
> 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.
> 
>