<br><br><div class="gmail_quote">On Tue, Jul 14, 2009 at 11:34 PM, Asaf Paris Mandoki <span dir="ltr"><<a href="mailto:asafpm@gmail.com">asafpm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote">On Tue, Jul 14, 2009 at 6:27 PM, Gary C Martin <span dir="ltr"><<a href="mailto:gary@garycmartin.com" target="_blank">gary@garycmartin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 13 Jul 2009, at 05:46, Asaf Paris Mandoki wrote:<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
On 13 Jul 2009, at 03:11, Gary C Martin wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>
</blockquote>
<br></div>
Are we talking about doing something like this?<br>
<br>
<a href="http://wiki.laptop.org/go/Physics_File_Format" target="_blank">http://wiki.laptop.org/go/Physics_File_Format</a><br>
(See also the discussion)<br>
<br>
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.<br>
<br>
JSON sounds like a good option for the format. I'll look into the api we have available.<br>
</blockquote>
<br></div>
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).</blockquote>
<div><br>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 <a href="http://dev.sugarlabs.org/ticket/1034" target="_blank">http://dev.sugarlabs.org/ticket/1034</a> and post my ideas for the implementation there so we can comment on them.<br>
</div></div></blockquote><div><br><br>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 <a href="http://www.box2d.org/forum/viewtopic.php?f=2&t=3201">unexpected changes</a> 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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We should also start considering adding some sort of Save/Load state so it's easier to test tweaks to a contraption.<br>
</blockquote>
<br></div>
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') :-)<div>
</div></blockquote><div><br>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.<br>
</div></div></blockquote></div><br>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. :)<br>
<br>Best,<br><br>Ken<br>