[Sugar-devel] Physics activity (Was: Release v3 tonight?)

[Ken Lauer]

On Tue, Jul 14, 2009 at 11:34 PM, Asaf Paris Mandoki <asafpm at gmail.com>wrote:

>
>
> On Tue, Jul 14, 2009 at 6:27 PM, Gary C Martin <gary at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090715/e005d76e/attachment.htm