Jean-Sébastien Guay wrote:
Hello Troy,
I've been doing a bunch of work with osg recently. I like it and
badly miss some boost.python bindings. I'd be very interested to
have a look at the code here, maybe pitch in a bit. Is there a git
archive I can clone, and a failing test I can run?
I was thinking of setting up a googlecode project for this work, because
there is at least one other person who might be interested in working
with me on it (Paul Melis). I'll see if I can do that soon.
I prefer to work with svn though (used to be CVS was oldschool, now it's
SVN, I know I'm behind the times), hope that's not a problem for you.
Doesn't really matter to me.
I would have liked to get the basic functionality working before setting
that up because there's already another project trying to wrap OSG to
python (osgSwig), so I'd like to be able to prove that my solution is
competitive with that one.
Competitive isn't an issue, as swig and boost.python bindings aren't
really compatible (or is that 'sip' bindings that aren't compatible?).
Personally I prefer a manual approach over automatically generated
bindings; apparently for the same reasons that some compiler writers
insist on handwritten recursive descent parsers. I know there are smart
people around that have worked long and hard on generators, I don't want
to start any fights. YMMV.
For reference, osgSwig have been having trouble lately wrapping the
classes derived (multiply) from osg::MixinVector<T>, and have relied on
patches to OSG that remove that derivation (essentially going back to
the OSG 2.6 versions of those classes). On the other hand, using
boost.python I can wrap things as I want, and I don't have any problem
wrapping classes derived from MixinVector<T>, so I think it's a better
route in the long run.
Yes exactly. Being intrusive is just not an option, for one. More
examples are easy to come up with, e.g. wants fine-grained control over
the python interface to provide things like conversions to native python
types (datetime, numpy arrays), or to provide slicing notation and
iterators on a node's children, say
node.children[2:7]
Anyways, yeah, I'll set up that project so you can run the actual code
and see the problem firsthand, hopefully that will make it easier to
help out.
Looking forward to it.
-t
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
