Ian Bicking wrote: >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. > > Sure is difficult for us tech mortals to understand where these issues intersect with the intent of OLPC.
As a point of real-world reference, I have communicated a bit with my son - working now in the South Pacific equivalent of the bush, for the U.S. Peace Corps - about OLPC, i.e. the availablility of inexpensive laptops that can used in an environment without ready access to electicity. He tells me books are difficult to access, and that he could see it as a great advantage to be able to retrieve and distribute books and other text information electronically. Sounds logical, and the kind of thing I would expect OLPC to be focusing upon. What are we talking about here? I know, why be nasty..... but I smell a generally decent idea being hijacked by the absolutely unproven - as in the only proof that does exist is in the negataive - radical electronic constructivists. And I suspect the influence of my usual suspects (suspect) is at the root. Too bad, really. I have "oops" consistently here lately, and am certainly as oops prone as anyone else, at least. If I am oopings here again, i apologize in advance. But I also get it right often enough, going by smell. Art >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. > > > > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
