Menu
▾
▴
pyode-user
|
From: brett h. <bha...@ya...> - 2004-03-25 05:15:31
|
Hello All, What is the status of the ODE c++ wrappers? Tim, Baas, and I are making the python wrappers in boost, but the bad state of the c++ wrappers has put a hold on things. It seems little has changed since this thread: http://q12.org/pipermail/ode/2002-April/005120.html Does anyone have more updated c++ wrappers they can share? If not then we will need to rewrite most of it. If we do this, i'd like to propose it as a replacement to the current c++ wrappers, and have it integrated as a standard part of ode. What are the thoughts of the ODE crew about this? -brett __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html |
|
From: Martin C. M. <ma...@me...> - 2004-03-25 11:48:46
|
Hi, > What is the status of the ODE c++ wrappers? They're done, I use them all the time. > but the bad state of the c++ wrappers They're in a perfect state for me. Can you be more specific? > It seems little has changed since this thread: > http://q12.org/pipermail/ode/2002-April/005120.html The problem in that email was that the wrappers didn't use inheritance. Now they do. Again, can you point to a specific problem with the wrappers as you see them? > Does anyone have more updated c++ wrappers they can share? Yes, they come with the ODE distro. > I'd like to propose it as a replacement to the current c++ wrappers, What, exactly, would you change? I consider the current ones very well thought out. Both Russ and I went over them. I can't speak for Russ, but I'm very happy with them. Can you forward my comments to the ODE mailing list? I'm no longer subscribed. Thanks, Martin |
|
From: brett h. <bha...@ya...> - 2004-03-25 18:23:52
|
Hi Martin, The current c++ wrappers function as a thin layer ontop of the C API, which i think works well for c++ programmers. But, for the purposes of making the python wrappers, they need to be thicker, and more object oriented. The big change i guess would be enclosing the dReals inside a new vector or matrix object. There is also a few other smaller things that need to be changed, dxSpace is causing a problem in wrapping the collide methods. If dxSpace is being used by a class, then dxSpace must also be exposed to boost, however dxSpace is not defined in the public ode headers, so i must include it from collision_kernel.h, but it seems that the public header odecpp_collision.h and collision_kernel.h do not 'get along', they do not like being included in the same file becuase there are some things that get re-declared. There are some other little things like this that need to be changed so boost will be happy. -brett --- "Martin C. Martin" <ma...@me...> wrote: > Hi, > > > What is the status of the ODE c++ wrappers? > > They're done, I use them all the time. > > > but the bad state of the c++ wrappers > > They're in a perfect state for me. Can you be more specific? > > > It seems little has changed since this thread: > > http://q12.org/pipermail/ode/2002-April/005120.html > > The problem in that email was that the wrappers didn't use inheritance. > Now they do. Again, can you point to a specific problem with the > wrappers as you see them? > > > Does anyone have more updated c++ wrappers they can share? > > Yes, they come with the ODE distro. > > > I'd like to propose it as a replacement to the current c++ wrappers, > > What, exactly, would you change? I consider the current ones very well > thought out. Both Russ and I went over them. I can't speak for Russ, > but I'm very happy with them. > > Can you forward my comments to the ODE mailing list? I'm no longer > subscribed. > > Thanks, > Martin > > __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html |
|
From: Martin C. M. <ma...@me...> - 2004-03-25 18:49:52
|
Alright, I resubscribed. > The current c++ wrappers function as a thin layer ontop of the C API, > which i think works well for c++ programmers. "Thin layer" just means that Russ did a good job with his object oriented design, so that IDs that ODE returns corresponded to objects, and function calls to methods. That made the wrapper trivial to implement, although it required a surprizing amount of tweaking to get it where I wanted. I suggest you do the same with Python. > But, for the purposes of making the python wrappers, they need to be thicker, > and more object oriented. Hmm, why is this? Just because "thin is trivial, so thicker is better"? > The big change i guess would be enclosing the dReals inside a new > vector or matrix object. I've never integrated C code into python, but can't it access a contiguous set of floats as a vector or an array? Doesn't it already have types that do that? > If dxSpace is being used by a > class, then dxSpace must also be exposed to boost, I don't see why. Can't Python manipulate dxSpace through an ID, the way it presumably does with everything else? You could store the handle in the "user data" field. - Martin ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# |
|
From: brett h. <bha...@ya...> - 2004-03-25 23:36:38
|
That is one of the big problems, that boost can not use the dReal types directly. Below is the response i got from the boost.python mailing list. """Is dReal a typedef for double or float? If so: Python float are immutable. You cannot return pointers to immutable types. Somehow you have to change your interface, e.g. through the use of "thin wrappers." Please explain in more detail what exactly you want to do; hopefully this will lead us to the best solution.""" - Ralf Unfortunately, i don't know why boost now requires the internal 'dx' types to also be wrapped. I hope that i am able to change how the c++ wrappers are working so that it will not be needed to expose those internal types to python. It may also be possible to do this the other way round, by changing the boost wrappers rather than the c++ wrappers, but how to do that is beyond my boost skillz. -brett --- "Martin C. Martin" <ma...@me...> wrote: > Alright, I resubscribed. > > > The current c++ wrappers function as a thin layer ontop of the C API, > > which i think works well for c++ programmers. > > "Thin layer" just means that Russ did a good job with his object > oriented design, so that IDs that ODE returns corresponded to objects, > and function calls to methods. That made the wrapper trivial to > implement, although it required a surprizing amount of tweaking to get > it where I wanted. I suggest you do the same with Python. > > > But, for the purposes of making the python wrappers, they need to be > thicker, > > and more object oriented. > > Hmm, why is this? Just because "thin is trivial, so thicker is better"? > > > The big change i guess would be enclosing the dReals inside a new > > vector or matrix object. > > I've never integrated C code into python, but can't it access a > contiguous set of floats as a vector or an array? Doesn't it already > have types that do that? > > > If dxSpace is being used by a > > class, then dxSpace must also be exposed to boost, > > I don't see why. Can't Python manipulate dxSpace through an ID, the way > it presumably does with everything else? You could store the handle in > the "user data" field. > > - Martin > > __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html |
|
From: Ed J. <ed....@or...> - 2004-03-26 00:34:28
|
For what it's worth, I'd like to see an updated C++ interface to ODE too. And I'm all for thin wrappers, the thinner the better. Just off the top of my head, some of the things I think could be improved are; - It would be better to have a consistent dVector equivalent class to pass to things like "void setGravity (dReal x, dReal y, dReal z)" and to be returned from things like "const dReal * getPosition() const" rather than passing three separate dReals and receiving a pointer to an internal structure. - Likewise for dMass, dQuaternion, dMatrix3, etc - The copy constructors and assignment operators should be implemented - Trimesh stuff needs including (and the Plane2D joint, if that's going to be promoted to core) - I'm not sure I like exposing the setData / getData, isn't that very C-stylee, can't you get the same effect (in a more OO way) by subclassing? - If we could wrap the collision callback up in an interface like "dCollisionListener" or something that'd be cool. - Stick everything in a namespace, "ode" for example. Yes it's possible for everyone to write their own C++ wrappers (I've done it myself, a couple of times), or modify the existing one but as you say "it required a surprizing amount of tweaking to get it where I wanted" and surely it'd be better to have a single consistent wrapper rather any everybody writing their own? Obviously all this is IMHO! Cheers, Ed. P.S. I've had some issues with VC 2003 .NET and the dx structures, meaning you have to forward declare them (just as empty structs) in one of your project source files. Something to do with managed and unmanged code, or something else that I don't understand, maybe a "proper" C++ interface would fix this compatibility issue. Or maybe it's just me being stupid? Martin C. Martin wrote: > Alright, I resubscribed. > >> The current c++ wrappers function as a thin layer ontop of the C API, > > > which i think works well for c++ programmers. > > "Thin layer" just means that Russ did a good job with his object > oriented design, so that IDs that ODE returns corresponded to objects, > and function calls to methods. That made the wrapper trivial to > implement, although it required a surprizing amount of tweaking to get > it where I wanted. I suggest you do the same with Python. > > > But, for the purposes of making the python wrappers, they need to be > thicker, > >> and more object oriented. > > > Hmm, why is this? Just because "thin is trivial, so thicker is better"? > >> The big change i guess would be enclosing the dReals inside a new >> vector or matrix object. > > > I've never integrated C code into python, but can't it access a > contiguous set of floats as a vector or an array? Doesn't it already > have types that do that? > >> If dxSpace is being used by a >> class, then dxSpace must also be exposed to boost, > > > I don't see why. Can't Python manipulate dxSpace through an ID, the > way it presumably does with everything else? You could store the > handle in the "user data" field. > > - Martin > > > > ################################################################# > ################################################################# > ################################################################# > ##### > ##### > ##### > ################################################################# > ################################################################# > ################################################################# > _______________________________________________ > ODE mailing list > OD...@q1... > http://q12.org/mailman/listinfo/ode |
|
From: birbilis <birbilis@.SYNTAX-ERROR> - 2004-03-25 18:03:06
|
did you see the .net ODE version at the CVS? I think it has C++ wrapper classes (or was it C# ones?). In any case, their design might prove useful (or the contact with their author) -- George Birbilis (bir...@ka...) http://www.kagi.com/birbilis Αρχικό μήνυμα από brett hartshorn <bha...@ya...>: > Hello All, > > What is the status of the ODE c++ wrappers? Tim, Baas, and I are making the > python wrappers in > boost, but the bad state of the c++ wrappers has put a hold on things. It > seems little has > changed since this thread: > http://q12.org/pipermail/ode/2002-April/005120.html > > Does anyone have more updated c++ wrappers they can share? If not then we > will need to rewrite > most of it. If we do this, i'd like to propose it as a replacement to the > current c++ wrappers, > and have it integrated as a standard part of ode. What are the thoughts of > the ODE crew about > this? > > -brett > > __________________________________ > Do you Yahoo!? > Yahoo! Finance Tax Center - File online. File on time. > http://taxes.yahoo.com/filing.html > _______________________________________________ > ODE mailing list > OD...@q1... > http://q12.org/mailman/listinfo/ode > ------------------------------------------------- This mail sent through Greek School Network: http://www.sch.gr/ Το μήνυμα εστάλη μέσω του Πανελλήνιου Σχολικού Δικτύου: http://www.sch.gr/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X