pyode-user — PyODE User Discussions

[Pyode-user] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Pyode-user] Re: [ODE] Re: ODE c++ API

[Ed J. <ed....@or...>]

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

[Pyode-user] Re: ODE c++ API

[brett h. <bha...@ya...>]

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

[Pyode-user] Re: ODE c++ API

[Martin C. M. <ma...@me...>]

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



#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################

[Pyode-user] Re: ODE c++ API

[brett h. <bha...@ya...>]

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

[Pyode-user] Re: [ODE] ODE c++ API

[birbilis <birbilis@.SYNTAX-ERROR>]

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/

[Pyode-user] Re: ODE c++ API

[Martin C. M. <ma...@me...>]

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

Re: [Pyode-user] Re: Boost-PyODE

[brett h. <bha...@ya...>]

Hi Matthias,

distutils sounds cool, please send me something when you have it working.  If you can at the same
time, make distutils to statically link to liboost_python.dll/so and install it, that would be
great.

some notes about the file structure:

pyode_devel/
           include/
           PyODE/
           site-packages/

pyode_devel/site-packages is temporary, when distutils is working and installing the binaries we
wont need it.  For now you will find a PyODE.so file in there, which is a binary linux users can
use.

pyode_devel/PyODE contains all the cpp source files.  Most of the work is going on in here.

pyode_devel/include contains the header files local to our project, and may also contain
overloaded boost headers.  However, at the moment is it pretty dirty in that folder.  All ODE
stuff we are including should be located externally, as you had it setup in your own project. 
But, ODE contains some 'private' headers which are not part of the standard install.  I have
copied these private headers to our local include folder because they are required when using the
external ODE c++ headers when combined with Boost.  This of course is a bad thing, and things
could get easily out of sync with peoples local ODE install.  I will ask the ODE guys if they can
help us with this problem.

I'm not sure how the collision handling will be done either.  Can you give me a quick idea of how
ODE normally does that?  The collide() member function is having some problems.  It is part of the
dSpace class, but boost fails to build when trying to wrap that function.  Here is the error:
PyODE/odecpp_collision.cpp:72:   instantiated from here
/usr/include/boost/type_traits/add_cv.hpp:34: error: `const volatile'
   qualifiers cannot be applied to `void ()(void*, dxGeom*, dxGeom*)'


i think we are going to have to take a step back, and rewrite the c++ wrappers.  I don't think
this will be too much work, at least it will be less work than trying to make lots of 'thin
wrappers' around the c++ wrappers.  Plus we have a good starting point already, there's the
existing c++ wrappers, and the work that Tim already has done.

-brett

--- Matthias Baas <ba...@ir...> wrote:
> brett hartshorn wrote:
> > I just started using SCONS on another Boost.Python project and it worked well as a replacement
> for
> > Bjam and gmake.  I am no SCONS expert, but it is supposed to make cross platform building and
> > install really easy.
> 
> > I do not know much about distutils, so please fill me in on that.  If distutils can build
> PyODE,
> > and install it, then we should use that since it is a standard part of Python.
> 
> As far as I gathered from looking a bit at SCONS it seems in principle 
> it works the same as distutils. You specify the source files and the 
> build tools do the rest for you.
> Using the distutils you have to write a setup.py script that's basically 
> a replacement for a makefile. In that file you list the source files 
> that make up the module/package. The distutils then do all the 
> compilation stuff, so you don't have to bother about a specific compiler 
> (unless you need extra options for a particular compiler) which makes 
> the build process platform independent. Apart from compiling a module 
> the distutils can also install it which is also rather painess as the 
> destination is determined by the distutils itself (unless you override 
> the destination dir using options).
> Furthermore, you can have the distutils create binary packages (e.g. a 
> setup file on Windows or RPM on Linux) which makes installation for 
> other users particularly easy.
> 
> I've tried to build PyODE using the distutils and MSVC6. Writing the 
> setup script is no big deal, however the whole thing won't compile right 
> now, instead I get a weird internal compiler error.
> Anyway, it's not clear to me right now what's actually required from all 
> the files in the distribution. What's located in "include"? There are a 
> couple of ODE headers *and* implementation files. IS the goal to include 
> the ODE tree right into the PyODE tree? Or is ODE supposed to reside 
> elsewhere? (that's what I did in my binding). What's "module_tail.*"? 
> Obviously something from Boost, but why did you stick it into the PyODE 
> directory?
> 
> >>- Will Boost be statically linked into the package? If not, how will you 
> >>set up the package? Will the boost shared library be part of the package 
> >>or is it up to the user to get the proper version of the boost library? 
> >>[...]
> >  
> > This is a good question.  What do you think Tim?  My thoughts are it should be as easy as
> possible
> > to install and use on all platforms.  Static linking to libboost_python.dll/so would be ideal,
> but
> > is it that simple?  libboost_python may be dependent on the rest of the boost package. 
> Perhaps we
> > can just supply the windows users with a zip file of the whole boost package that gets unziped
> to
> > a new directory "c:/usr/local"
> 
> As far as I can tell Boost.Python only needs boost_python.dll to run and 
> is not dependent on any other Boost stuff. Providing a separate zip file 
> should be only the last resort if there's really no other way. On 
> Windows, the goal should be to have one installer that contains 
> everything to run PyODE (either it's statically linked or it includes 
> the dll which will then be stored somewhere in site-packages where it 
> doesn't interfere with other packages).
> 
> > Good point, i've removed the 'd' from the class names
> 
> By the same argument I'd suggest to drop the "Py" in the module name, so 
> that it just gets "ode" or "ODE". It'll be imported from a Python 
> program, so it's clear it's the Python version of ODE...
> (but admittedly, this quite a minor issue... :)
> 
> > One major thing is - i don't have any real experience using ODE, i am just wrapping in the
> dark -
> > not totally sure what is or is not important, another problem is my lack of experience with
> c++
> > and boost.  Your help is needed just by your understanding of the system.
> 
> I haven't yet seen how collision handling will be done. By a first 
> glance I didn't see the collide() function. I take it the "near 
> callback" function can just be a Python function, right?
> 
> - Matthias -
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Pyode-user] ODE c++ API

[brett h. <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

[Pyode-user] Re: Boost-PyODE

[Matthias B. <ba...@ir...>]

brett hartshorn wrote:
> I just started using SCONS on another Boost.Python project and it worked well as a replacement for
> Bjam and gmake.  I am no SCONS expert, but it is supposed to make cross platform building and
> install really easy.

> I do not know much about distutils, so please fill me in on that.  If distutils can build PyODE,
> and install it, then we should use that since it is a standard part of Python.

As far as I gathered from looking a bit at SCONS it seems in principle 
it works the same as distutils. You specify the source files and the 
build tools do the rest for you.
Using the distutils you have to write a setup.py script that's basically 
a replacement for a makefile. In that file you list the source files 
that make up the module/package. The distutils then do all the 
compilation stuff, so you don't have to bother about a specific compiler 
(unless you need extra options for a particular compiler) which makes 
the build process platform independent. Apart from compiling a module 
the distutils can also install it which is also rather painess as the 
destination is determined by the distutils itself (unless you override 
the destination dir using options).
Furthermore, you can have the distutils create binary packages (e.g. a 
setup file on Windows or RPM on Linux) which makes installation for 
other users particularly easy.

I've tried to build PyODE using the distutils and MSVC6. Writing the 
setup script is no big deal, however the whole thing won't compile right 
now, instead I get a weird internal compiler error.
Anyway, it's not clear to me right now what's actually required from all 
the files in the distribution. What's located in "include"? There are a 
couple of ODE headers *and* implementation files. IS the goal to include 
the ODE tree right into the PyODE tree? Or is ODE supposed to reside 
elsewhere? (that's what I did in my binding). What's "module_tail.*"? 
Obviously something from Boost, but why did you stick it into the PyODE 
directory?

>>- Will Boost be statically linked into the package? If not, how will you 
>>set up the package? Will the boost shared library be part of the package 
>>or is it up to the user to get the proper version of the boost library? 
>>[...]
>  
> This is a good question.  What do you think Tim?  My thoughts are it should be as easy as possible
> to install and use on all platforms.  Static linking to libboost_python.dll/so would be ideal, but
> is it that simple?  libboost_python may be dependent on the rest of the boost package.  Perhaps we
> can just supply the windows users with a zip file of the whole boost package that gets unziped to
> a new directory "c:/usr/local"

As far as I can tell Boost.Python only needs boost_python.dll to run and 
is not dependent on any other Boost stuff. Providing a separate zip file 
should be only the last resort if there's really no other way. On 
Windows, the goal should be to have one installer that contains 
everything to run PyODE (either it's statically linked or it includes 
the dll which will then be stored somewhere in site-packages where it 
doesn't interfere with other packages).

> Good point, i've removed the 'd' from the class names

By the same argument I'd suggest to drop the "Py" in the module name, so 
that it just gets "ode" or "ODE". It'll be imported from a Python 
program, so it's clear it's the Python version of ODE...
(but admittedly, this quite a minor issue... :)

> One major thing is - i don't have any real experience using ODE, i am just wrapping in the dark -
> not totally sure what is or is not important, another problem is my lack of experience with c++
> and boost.  Your help is needed just by your understanding of the system.

I haven't yet seen how collision handling will be done. By a first 
glance I didn't see the collide() function. I take it the "near 
callback" function can just be a Python function, right?

- Matthias -

Re: [Pyode-user] PyODE 0.1.4

[brett h. <bha...@ya...>]

Hi Tim,

Are you using ode-0.039, if so that is likely the cause of your build problem.
I've been making the wrappers around cvs from about 3 days ago.
http://sourceforge.net/cvs/?group_id=24884

The thin wrappers are just temporary, for building and testing.
To return python lists or tuples would be nice.  How do we do that?  I looked at some of your code
in the CVS and it seemed you were doing something like this already.

I aggree, the ode c++ wrappers are a pain in the ass; although they are good becuase they are a
standard part of osg.  Is there a way we can easily swap them out for your classes?  How should we
go about merging our code?  Maybe we can work with the ODE crew and make their c++ wrappers
better? 

Python's C interface looks too verbose for me.  Boost has made me lazy i think.  It could be
something to fall back on later.  I think we are close to having something working well with
boost, lets not give up on it now.

later,
-brett


--- Timothy Stranex <ti...@st...> wrote:
> Hey,
> 
> On Wed, 2004-03-24 at 06:21, brett hartshorn wrote:
> > get the new PyODE 0.1.4 here:
> > http://opart.org/pyode/
> 
> I get these errors when building:
> 
> $ scons
> scons: Reading SConscript files ...
> WARNING: ODE_ROOT env var not set!
> Defaulting to: /usr/local
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -Wall -ansi -fPIC -DNDEBUG -DBOOST_PYTHON_DYNAMIC_LIB
> -I/usr/include/python2.2 -I/usr/local/include -Iinclude -c -o
> PyODE/odecpp.os PyODE/odecpp.cpp
> PyODE/odecpp.cpp: In function `void pyODE::init_odecpp()':
> PyODE/odecpp.cpp:247: error: `setParam' is not a member of type `
>    dUniversalJoint'
> PyODE/odecpp.cpp:254: error: `getParam' is not a member of type `
>    dUniversalJoint'
> scons: *** [PyODE/odecpp.os] Error 1
> scons: building terminated because of errors.
> 
> > Tomorrow i will likey have completed doing all of the 'thin wrappers' for the get functions
> > returning a dReal.
> 
> Your 'thin wrappers' are just dereferencing dReal pointers but some
> methods like dBody's getPosition are returning an arrays of dReal, as
> far as I can tell. I'm guessing that these are just temporary to get it
> to build?
> 
> > Should we make our own vector and matrix classes and stick those into the thin wrappers,
> > or should we subclass all the classes from the ode c++ wrappers and overload them. Or
> > should we just scrap the ode c++ wrappers and make our own?
> 
> I think that whether we use the ODE C++ wrapper or write our own, we
> should write thin wrappers to convert vectors and matrices in simple
> Python lists. This will allow the user to choose whether they want to
> manipulate them using Numeric or their own vector and matrix classes.
> 
> I /feel/ that using the ODE's C++ interface is causing too much trouble
> and it would be easier to use its C API and wrap it so that it seems
> object-orientated to Python.
> 
> > and boost is very picky about things.
> 
> I played around with Python's C interface today. It is actually quite
> straightforward albeit verbose. It doesn't compare with Boost's elegance
> in the code but it has other advantages: the building system is simple
> and well-known by most Python users and dependency requirements (and the
> hassles that come with them) are reduced.
> 
> I'm unsure whether these advantages outweigh those of Boost, but I think
> we should consider it. I've attached a simple module using the C
> interface. You can build it by running 'python setup.py build'.
> 
> -- 
> Timothy Stranex <ti...@st...>
> http://www.stranex.com/~perspex/
> > #include <Python.h>
> 
> int isPrime(int num)
> {
>   int n, prime;
> 
>   prime = 1;
>   for (n=2; n < num; n++) {
>     if (num % n == 0) {
>       prime = 0;
>       break;
>     }
>   }
> 
>   return prime;
> }
> 
> static PyObject *nums_isPrime(PyObject *self, PyObject *args)
> {
>   int num;
> 
>   if (!PyArg_ParseTuple(args, "i", &num)) {
>     return NULL;
>   }
> 
>   return Py_BuildValue("i", isPrime(num));
> }
> 
> static PyObject *nums_factors(PyObject *self, PyObject *args)
> {
>   int num, i;
>   PyObject *list;
> 
>   if (!PyArg_ParseTuple(args, "i", &num)) {
>      return NULL;
>    }
> 
>    list = PyList_New(0);
>    if (!list) {
>      return NULL;
>    }
> 
>    for (i=1; i<=num; i++) {
>      if (num % i == 0) {
>        PyList_Append(list, Py_BuildValue("i", i));
>      }
>    }
> 
>    return list;
>  }
> 
>  static PyObject *nums_pfactors(PyObject *self, PyObject *args)
>  {
>    int num, i;
>    PyObject *f;
>    PyObject *pf;
>    PyObject *n;
> 
>    f = nums_factors(self, args);
>    if (!f) {
>      return NULL;
>    }
> 
>    pf = PyList_New(0);
>    for (i=0; i<PyList_Size(f); i++) {
>      n = PyList_GetItem(f, i);
>      if (isPrime((int) PyInt_AsLong(n))) {
>        PyList_Append(pf, n);
>      }
>    }
> 
>    Py_DECREF(f);
> 
>    return pf;
> }
> 
> void initnums(void)
> {
>   static PyMethodDef NumsMethods[] = {
>     {"isPrime", nums_isPrime, METH_VARARGS, "Check if an integer is prime."},
>     {"factors", nums_factors, METH_VARARGS, "Find the factors or an integer."},
>     {"pfactors", nums_pfactors, METH_VARARGS,
>      "Find the prime factors of an integer."},
>     {NULL, NULL, 0, NULL}
>   };
> 
>   (void) Py_InitModule("nums", NumsMethods);
> }
> > #!/usr/bin/env python
> 
> from distutils.core import setup, Extension
> 
> numsModule = Extension('nums', sources=['numsmodule.c'])
> 
> setup(name='Nums',
>       version='0.1',
>       description='Numbers',
>       ext_modules=[numsModule])
> 

> ATTACHMENT part 2 application/pgp-signature name=signature.asc



__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Pyode-user] PyODE 0.1.4

[brett h. <bha...@ya...>]

Yo,

get the new PyODE 0.1.4 here:
http://opart.org/pyode/

So it's kinda working, i guess the question is now how do we move forward?  Tomorrow i will likey
have completed doing all of the 'thin wrappers' for the get functions returning a dReal.  Should
we make our own vector and matrix classes and stick those into the thin wrappers, or should we
subclass all the classes from the ode c++ wrappers and overload them.  Or should we just scrap the
ode c++ wrappers and make our own?

I had to do an ugly hack with the header files in odecpp_collision.cpp, have a look at the file
and you'll see what i'm talking about.  I think we need to talk to the ODE guys, it seems like ODE
is not setup well for wrapping, and boost is very picky about things.

-brett

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Pyode-user] PyODE 0.1.1

[brett h. <bha...@ya...>]

Hi Tim,

How do i sign up as a sourceforge developer?

I worked out the problem with including odecpp.h, turns out that you need to also include ode.h,
and that includes just about everything else.

After alot of hacking today, i got it to build properly, although there are still problems with
the linker, and i had to comment out all of the 'get' functions becuase they return that funny
dReal type, which boost does not like at all.  Either we will have to: overload all of the classes
with get functions to return doubles, rewrite the c++ wrappers, or find a more elegant boost
solution.  I just signed up for the boostpython mailing list, and i am getting some good help
there, i hope there is some magic boost solution so that we do not have to rewrite any of the c++
wrappers.

I've posted the new build here:
http://opart.org/pyode/

later,
-brett


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Pyode-user] CVS down?

[brett h. <bha...@ya...>]

Hello,

Is the pyode cvs working?  When i try to login it just hangs after i enter nothing for the
password.

Do you need any help with the project?  I maybe able to help write some of the code.  I am helping
out now with the wrappers for OSG, http://opart.org/pyosg/pyosg.html
i've started to learn boost python, it is a great.

-brett



__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools