Thread: [cgkit-user] ArgumentError: Python argument types in ... did not match C++ signature
Brought to you by:
mbaas
From: Chris B. <chr...@gm...> - 2005-05-29 22:48:35
|
Hi, I'm using cgkit- 2.0.0-alpha3. After a while of running my code I get: Trying to make a quat: q =3D quat(radians, v) File "/usr/lib/python2.3/site-packages/cgkit/cgtypes.py", line 292, in __init__ self.fromAngleAxis(angle,axis) ArgumentError: Python argument types in quat.fromAngleAxis(quat, float, vec3) did not match C++ signature: fromAngleAxis(support3d::quat<double> {lvalue}, double, support3d::vec3<double>) Is it possible that it doesn't match because float!=3Ddouble? (I assume there should be automatic type conversion between float and double, so this shouldn't be the case). If I insert a print statement before the error line I get: print 'v2=3D'+str(v) ArgumentError: Python argument types in vec3.__str__(vec3) did not match C++ signature: __str__(support3d::vec3<double> {lvalue}) This is in a loop that does a lot of things, so it normally works. Which makes me suspect some kind of memory corruption.. but my code is 100% python. I run valgrind and (ignoring errors from libpython) just before the error I get: =3D=3D25452=3D=3D Use of uninitialised value of size 8 =3D=3D25452=3D=3D at 0x199C0D30: _ZN5boost6python6detail12caller_arityILj2EE4implIPFP7_objectRN9support3d4ma= t3IdEERKdENS0_21default_call_policiesENS_3mpl7vector3IS6_SA_SC_EEEclES6_S6_ (in /usr/lib/python2.3/site-packages/cgkit/_core.so) =3D=3D25452=3D=3D by 0x1998ACF0: _ZN5boost6detail8function21function_obj_invoker2INS_3_bi6bind_tIbNS_6python= 6detail19translate_exceptionIN9support3d11EIndexErrorEPFvRKS9_EEENS3_5list3= INS_3argILi1EEENSG_ILi2EEENS3_5valueISD_EEEEEEbRKNS6_17exception_handlerERK= NS_9function0IvSaINS_13function_baseEEEEE6invokeENS1_11any_pointerESP_SV_ (in /usr/lib/python2.3/site-packages/cgkit/_core.so) .......... =3D=3D25452=3D=3D Invalid read of size 4 =3D=3D25452=3D=3D at 0x1A1FA30A: dJointDestroy (in /usr/lib/python2.3/site-packages/ode.so) =3D=3D25452=3D=3D Address 0x1A8C8E38 is 3296 bytes inside a block of size = 16384 free'd =3D=3D25452=3D=3D at 0x1910F959: free (vg_replace_malloc.c:152) =3D=3D25452=3D=3D by 0x1A25F767: dFree (in /usr/lib/python2.3/site-packa= ges/ode.so) =3D=3D25452=3D=3D by 0x19151687: (within /usr/lib/libpython2.3.so.1.0) ........ which look like the only things that could be relevant.=20 And a bit of googling later I find:=20 (from http://regina.sourceforge.net/docs/python-caveats.html#python-ownersh= ip) Due to a constraint of boost.python, whenever ownership of an object is transferred away from the Python console, the old reference to that object becomes no longer valid. In the above example, further attempts to use the object p will result in an ugly Python error. Depending on your system configuration, this might be either a TypeError or a Boost.Python.ArgumentError. Which also sounds relevant!=20 Can someone with more clue than myself about how the boost wrappers work please please let me know whats going on. Am I supposed to explicity use doubles? Are there some weird object ownership rules I have to follow for using these classes and copying them/having references from other objects? Thanks, Chris |
From: Chris B. <chr...@gm...> - 2005-05-30 01:15:06
|
Replying to myself.., It looks as though I was doing something bad. You can't deepcopy or pickle python boost objects (in this case vec3), or else when you try to actually use it you get that error. Apparently theres a noncopyable attribute you can use in boost which would have thrown an error earlier. |
From: Matthias B. <ba...@ir...> - 2005-05-30 09:27:27
|
Chris Bainbridge wrote: > It looks as though I was doing something bad. You can't deepcopy or > pickle python boost objects (in this case vec3), or else when you try > to actually use it you get that error. Apparently theres a noncopyable > attribute you can use in boost which would have thrown an error > earlier. Good catch! Indeed, the cgtypes in cgkit2 didn't support the pickling protocol and when you actually tried to pickle a vec3 a (more or less) appropriate exception was thrown. I was not aware that using the copy module led to such a weird behavior. Well, instead of throwing an exception during an attempt to copy a vec3 I took the other route and added support for the pickling protocol. :) I've just checked in the changes. So in the next release you actually can pickle or copy the types in the cgtypes module. By the way, another way of copying a vec3 would have been to pass it into a another vec3 constructor: v = vec3(1,2,3) w = vec3(v) # now w is a copy of v (but of course, this doesn't always replace the copy functionality) The float vs double issue should never be a problem on the Python side. In Python, there is only one "float" type (which is actually a double) whereas in C++ you have both, a float and a double. By default, I'm using doubles for most of the stuff on the C++ side which can lead to somewhat confusing error messages. But as long as you're in Python you can regard the Python floats as being the same than the C++ doubles (and floats). - Matthias - |