pyode-user

[Pyode-user] The Pyrex version is ready to be checked in

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

Hi,

I've brought my files into a state that makes them ready to be checked 
in. Here's what I did:

- The main Pyrex file "ode.pyx" is split into into several parts:

   body.pyx - Contains the Body class

   contact.pyx - Contains the Contact class

   declarations.pyx - Contains all external declarations (mainly the 
stuff from ode.h. Hopefully, there will be a time some day when this 
file can be generated automatically).

   geoms.pyx - Contains all geom classes

   joints.pyx - Contains all joint classes and the JointGroup class

   mass.pyx - Contains the Mass class

   ode.pyx - Main file. All the other files are included here. All 
constants and functions are still in this file

   space.pyx - Contains the Space class and the C part of the collision 
callback

   world.pyx - Contains the World class

- The German comments are removed or translated (I hope I got them all)

- The geoms and joints have been restructured so that geoms and joints 
have a common base class now (this wasn't possible in earlier versions 
of Pyrex). The base classes are GeomObject and Joint.

- I've added Bernie's modifications (by the way, you have added 
setData()/getData() to the sphere geom. In Python the 
setData()/getData() aren't necessary as you can add arbitrary data as 
new attributes to the objects. So instead of geom.setData(spam) you can 
do geom.spam = spam on any geom object)

- The World object now contains the quickStep stuff.

- The setup script determines ODE's precision setting automatically by 
reading the user-settings file and create a file "_precision.pyx" that 
contains the declaration of "dReal" (which has to be either float or 
double). This generated file is included in declarations.pyx.

- Sporadically I added some doc strings or error checks.

Everything compiles fine here on Windows using the latest binaries from 
the ODE site (I didn't bother to recompile ODE myself). I've tried both, 
SINGLE and DOUBLE precision and both works fine. So I'd say the files 
can be checked in and then we can all work on the same repository.

Now how should we organize the cvs repository? Currently I have a main 
directory where the setup script is and a subdirectory "src" where the 
.pyx files are. My tutorial source files (which serve as a "regression 
test" right now) are in a subdirectory "examples". So shall I commit 
everything into a new top level directory "pyode2" or would you rather 
like to reuse the current pyode directory?

By the way, what license are we using? GPL? BSD? Or both (as ODE is doing)?

- Matthias -

Re: [Pyode-user] The Pyrex version is ready to be checked in

[Bernie R. <br...@ec...>]

I'm in a rush today (spending time with family), so this will be brief...

First off -- great work, Matthias!  It sounds like things will be much 
easier to maintain now.

Yes, I had originally started adding the setData() routines before I 
noticed how you had done things.  I went back and removed the routines I'd 
added, but I must have missed one.  Thanks for catching it!   :-)

I like your proposed organization of the repository.  I would suggest 
moving the code that's there now into something like "pyode_previous" and 
making the Pyrex version the "pyode" one (with perhaps a readme.txt file 
explaining things).

As to licensing, I think it makes sense to use the exact same licensing as 
ODE itself.  Being more restrictive would just make it less likely for 
people to use PyODE, and being less restrictive is pointless (since PyODE 
won't work without ODE).

Anyway, I'm off... will try to check my email later...


At 04:32 PM 6/27/2004 +0200, Matthias Baas wrote:
>[...]
>
>Now how should we organize the cvs repository? Currently I have a main 
>directory where the setup script is and a subdirectory "src" where the 
>.pyx files are. My tutorial source files (which serve as a "regression 
>test" right now) are in a subdirectory "examples". So shall I commit 
>everything into a new top level directory "pyode2" or would you rather 
>like to reuse the current pyode directory?
>
>By the way, what license are we using? GPL? BSD? Or both (as ODE is doing)?
>
>- Matthias -

--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: br...@ec...   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl 

Re: [Pyode-user] The Pyrex version is ready to be checked in

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

Cool, looks like things are moving fast!  As far as the license is concerned, i'd recommend doing
it the ODE way (GPL and BSD dual license).
Thanks Matthias and everbody,
-brett



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [Pyode-user] The Pyrex version is ready to be checked in

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

Timothy Stranex wrote:
> I agree with Bernie: move the existing code to "pyode_previous" and put
> the new code into "pyode".

ok, done.
I just noticed a slight disadvantage in reusing the pyode directory. 
There's the subdirectory "include" which isn't necessary anymore, 
however as cvs doesn't allow to remove directories it will remain 
there... oh, well.

The text files README, INSTALL, etc. are still the old ones, they have 
to be updated eventually.

Here's an incomplete list of things that still have to be done:

- Check the ODE API for new (or so far unsupported) functions and add 
them to the respective class

- Trimesh support

- Add some __str__() methods that output useful data

- Make the documentation (doc strings) complete. By the way, I noticed 
that the epydoc markup @param can't be used because epydoc doesn't see 
the argument names. Is there a way to get around this?

- Add AMotor class

- Add CylinderClass (not the capped one). Is that already officially 
available? There's no section in the docs, but it's mentioned as a geom 
type.

- Do more error checking. Currently, it's still possible to crash the 
interpreter if you do "wrong" calls.

- Review the design and improve whatever has to be improved (like the 
global lookup dictionary).

- Make the objects pickleable?

- XODE reader

- Update all the files that are necessary for a proper release (readme, 
license, changelog, ...)

- Add a proper file header on all the .pyx files

- Write more examples, demos, tutorials. :)

But at least the current version can be compiled and is fully 
functional. I hope it'll also compile on Linux. To compile you can just 
call "setup.py build" (by the way, as I've checked in the stuff on 
Windows the setup script won't have the executable flag set.... darn, 
and I believe now it's too late to change that in the repository. Oh, 
and you have to set the proper path to ODE in the setup script (the 
variable ODE_BASE)...)

- Matthias -

Re: [Pyode-user] The Pyrex version is ready to be checked in

[Bernie R. <br...@ec...>]

I've taken Matthias' list and organized it into related activities...

New Features:
- Add AMotor class
- Add Cylinder class (not the capped one)
- Trimesh support
- XODE reader

Review:
- Check the ODE API for new (or so far unsupported) functions and add them 
to the respective class
- Review the design and improve whatever has to be improved (like the 
global lookup dictionary).

Cleanup:
- Do more error checking.
- Add some __str__() methods that output useful data
- Make the documentation (doc strings) complete
- Add a proper file header on all the .pyx files

Packaging:
- Update all the files that are necessary for a proper release (readme, 
license, changelog, ...)
- Write more examples, demos, tutorials. :)

I would propose that we proceed in roughly the order given above.  I know 
Timothy is working on
an XODE reader, and I have an interest in adding trimesh support.  Perhaps 
Matthias would be able
to look at AMotor and CylinderClass?  Once all that is done, we can all 
participate in the review phase,
and then look at who would like to help with the cleanup and packaging.

The only item that I didn't put into the list above is:
- Make the objects pickleable?

I'm not sure if this is necessary or not, and would be inclined to not 
bother with it unless someone
asks for it.

How does all that sound?


--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: br...@ec...   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl 

Re: [Pyode-user] The Pyrex version is ready to be checked in

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

Bernie Roehl wrote:
> I would propose that we proceed in roughly the order given above.  I 
> know Timothy is working on
> an XODE reader, and I have an interest in adding trimesh support.  
> Perhaps Matthias would be able
> to look at AMotor and CylinderClass?  Once all that is done, we can all 
> participate in the review phase,
> and then look at who would like to help with the cleanup and packaging.

Sounds good to me. I'll see if I can add the AMotor and Cylinder (if I 
find some info about it) somewhen this week.

> The only item that I didn't put into the list above is:
> - Make the objects pickleable?

Well, I also don't know if this is really necessary. The idea occured 
when we were talking about the trimesh geom. I thought maybe even when 
the mesh creation code is written in Python and creating a mesh is 
rather slow, then maybe it would be useful to be able to dump the final 
mesh to disk using the pickle module and then just load that again later 
on. Another thing might be to be able to dump the current state of a 
simulation to disk and continue or redo the simulation later.
But it's really low priority and I also think we can wait until someone 
really needs it.

By the way, I was reading the documentation of the trimesh class. How 
about doing it analogous to ODE? There could be a TriMeshData class that 
has the responsibility to provide the actual mesh data and a GeomTriMesh 
class that represents the geom object and that takes a TriMeshData as input.
Using Python's array module sounds like a good idea to me. So the 
TriMeshData could be provided with the vertices and faces stored in an 
array object. If we keep a reference to those arrays we can be sure that 
the memory won't get deleted and we can use the raw pointer into the 
array. If the floating point type in the array doesn't match the ODE 
type then the TriMeshData has to convert the array. I'd also suggest to 
have convenience methods to build the mesh from ordinary Python lists 
containing the vertices and faces as ordinary Python tuples or other 
3-sequences. The TriMeshData would then just create the array objects 
internally and proceed in the same way as above.
With this scheme you could also pass a pointer to the very same data 
that is used by a rendering engine if this is desired. All you have to 
do is to write a class that has the same interface than the array class 
and that just returns the pointer when the buffer_info() method is 
returned. Of course, then you have to make sure that the data remains 
valid during the simulation.
Any thoughts?

- Matthias -