As of this post, the latest svn revision, r148, has pickling support which is working great on the testbed. I'm rather excited about it, as it's somewhat of a powerful and unique feature.
For those who can compile the library, check out the testbed. It works like your regular quicksave (F5)/quickload (F7) system. There's an additional test, test_pickle.py, that shows how easy it is to load a pickled world. As far as the code itself goes, there's still some commenting to be done, but it should be readable.
Tuesday, January 20, 2009
Monday, January 12, 2009
SWIG and Pickle
I have yet to see any site that explains how to pickle swig objects well enough. SWIG objects exist both on the Python and C++ side.
Without calling the __init__ function on the Python class instance of a SWIG object, it doesn't exist as far as SWIG is concerned. So you'll get a TypeError on the 'self' parameter of your functions.
If we were using old-style classes, __getinitargs__ would work well enough. Since we aren't, as far as I can tell, it's necessary for us to call the initializer ourselves.
EDIT 2009/1/14:
If you use properties for all those C++ getters/setters (as you should be doing), you can then iterate over all of the properties for a much cleaner solution. It takes even more tweaking to get pickling to work with outputs from factory products (e.g., trying to pickle a b2Body instead of a b2BodyDef). Expect something like this to show up soon in pybox2d. :)
Without calling the __init__ function on the Python class instance of a SWIG object, it doesn't exist as far as SWIG is concerned. So you'll get a TypeError on the 'self' parameter of your functions.
If we were using old-style classes, __getinitargs__ would work well enough. Since we aren't, as far as I can tell, it's necessary for us to call the initializer ourselves.
def generic_setstate(self, dict):If you have the dict __pickle_vars__ set up such as:
self.__init__()
for key, value in dict.iteritems():
setattr(self, key, value)
def generic_getstate(self):
return dict((var, getattr(self, var)) for var in
__pickle_vars__[self.__class__.__name__])
__pickle_vars__ = { 'myclass' : ['x', 'y'], 'myclass2' : ['zz'], ... }You can then set:
myclass.__getstate__=generic_getstate
myclass.__setstate__=generic_setstate
EDIT 2009/1/14:
If you use properties for all those C++ getters/setters (as you should be doing), you can then iterate over all of the properties for a much cleaner solution. It takes even more tweaking to get pickling to work with outputs from factory products (e.g., trying to pickle a b2Body instead of a b2BodyDef). Expect something like this to show up soon in pybox2d. :)
Friday, January 9, 2009
pybox2d svn r136
Added something I've wanted to for a long time.
Anywhere there's a b2Vec2, you should now be able to pass in a [length-2] list, tuple, or None -- (0,0). As I learn more about SWIG every time I try to throw some more functionality into Box2D.i, I'm more and more impressed with how much can be done with it.
Changes can be seen in test_ApplyForce.py and test_Web.py. I'll eventually update the rest of the testbed examples.
Oh yeah, also fixed a longtime standing bug with unset userData causing seg faults.
Any other things you can think of that would be convenient? I'll probably allow matrices in list format.
If you notice any side-effects, please let me know as always.
Anywhere there's a b2Vec2, you should now be able to pass in a [length-2] list, tuple, or None -- (0,0). As I learn more about SWIG every time I try to throw some more functionality into Box2D.i, I'm more and more impressed with how much can be done with it.
Changes can be seen in test_ApplyForce.py and test_Web.py. I'll eventually update the rest of the testbed examples.
Oh yeah, also fixed a longtime standing bug with unset userData causing seg faults.
Any other things you can think of that would be convenient? I'll probably allow matrices in list format.
If you notice any side-effects, please let me know as always.
Friday, January 2, 2009
distutils, oh how I hate you...
It took me forever and a day to get the original setup.py working for pybox2d, and then some people came along and told me how it was unnecessarily complex. And that it didn't work in the standard way and was somewhat confusing. Great.
With a push from the user snickell, I worked on restructuring the code-base to get it to conform to standard distribution methods.
I've decided that I will no longer install the testbeds and things to c:\Python2x\Box2D for Windows users and will simply just offer them in a separate archive as I see some other libraries do.
*EDIT*
My problem has been resolved and everything is apparently working now. I'm ready for another release -- but with nothing really new on the Box2D end, I guess there's nothing to do but wait.
A few questions for you faithful few who reload this page every once in a while:
Windows users: Do you prefer MSI's or executables for your libraries?
Linux users: Any interest in an RPM distribution?
Any other comments/etc. about the releases are always welcome.
With a push from the user snickell, I worked on restructuring the code-base to get it to conform to standard distribution methods.
I've decided that I will no longer install the testbeds and things to c:\Python2x\Box2D for Windows users and will simply just offer them in a separate archive as I see some other libraries do.
*EDIT*
My problem has been resolved and everything is apparently working now. I'm ready for another release -- but with nothing really new on the Box2D end, I guess there's nothing to do but wait.
A few questions for you faithful few who reload this page every once in a while:
Windows users: Do you prefer MSI's or executables for your libraries?
Linux users: Any interest in an RPM distribution?
Any other comments/etc. about the releases are always welcome.
Subscribe to:
Posts (Atom)