On Tue, Jul 14, 2009 at 11:34 PM, Asaf Paris Mandoki <asa...@gmail.com>wrote:
> > > On Tue, Jul 14, 2009 at 6:27 PM, Gary C Martin <g...@garycmartin.com>wrote: > >> On 13 Jul 2009, at 05:46, Asaf Paris Mandoki wrote: >> >> On 13 Jul 2009, at 03:11, Gary C Martin wrote: >>> >>> Think we need to make a call on the stability of the new Physics Journal >>>> state format first, or at least make sure everyone knows the storage format >>>> may (or may not) be stable long term (hate to see a bunch of folks >>>> generating/posting examples for lesson plans only to have them all fail to >>>> resume in a few versions from now). >>>> >>> >>> Are we talking about doing something like this? >>> >>> http://wiki.laptop.org/go/Physics_File_Format >>> (See also the discussion) >>> >>> I think the format described there is much too elaborate for our needs >>> although the right thing to do is implement it at the elements level and >>> that may require to do more than what we really need for this activity. >>> >>> JSON sounds like a good option for the format. I'll look into the api we >>> have available. >>> >> >> Cool, the simpler the better, my main concern would be that we should at >> least have control over the stored format should upstream change (unless >> upstream are willing to offer some guarantee of backwards compatibility in >> box2d if things do need to change). > > > By looking at the elements api I see that there isn't that much more to to > if I do it at the elements layer so I'll start doing it there. I'll reopen > http://dev.sugarlabs.org/ticket/1034 and post my ideas for the > implementation there so we can comment on them. > I would do my best to ensure backward compatibility, but I can't 100% guarantee it. Erin Catto just recently made a lot of completely unexpected changes <http://www.box2d.org/forum/viewtopic.php?f=2&t=3201> on the SVN which break compatibility (and currently offer almost no benefit to the Physics project). It'll be a good deal of time before he's done with those changes, and even more before I get around to modifying the Python-side of things. The main benefit of just using the built-in pickling is (obviously?) its simplicity. It will serialize all of your bound userData and the whole world, no problem. I didn't experience any issues with it in 2.0.2b1. You can test out the functionality in the pybox2d testbed by using F5/F7 and see what you think. The relevant code is in pygame_main.py's pickle_load/pickle_save methods. If you just want to save individual objects here and there, perhaps you would be better off just using an XML-like format like the one listed on that page -- which is incidentally based off of some thing I threw together in a few hours early last year. As the first case of someone actually wanting to use the pickling I spent a good deal of time on, I'm happy. Whether or not its the best fit for your application is yours to decide in the end though. > > > >> We should also start considering adding some sort of Save/Load state so >>> it's easier to test tweaks to a contraption. >>> >> >> You mean undo/redo? Save/Load is not a Sugar thing. Hmmm. Undo/redo would >> need to snap shot the state of the entire simulation on every user change... >> Could be a tough one. Of course with Journal state working, the Keep button >> is all about keeping a version of the current state (allowing you to 'stop' >> and resume an earlier 'version') :-) >> > > The problem I see with the Keep button is that you have to close the > activity and open it again to restore the state. I'm not talking about > saving to a file it's more like picking a state and then returning to it. > Something like an undo/redo but the snap shots are selected by the user. > Pickling would take care of save states, and with its serializability, they could just be thrown in a list or dictionary and saved along with the rest of it. Of course, so could an XML-format. :) Best, Ken
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel