I'd looked around a bit but could only find vague references to CINT, and it wasn't even clear to me whether a full CINT backend really existed or it was just a hack/experiment. Is it actually suitable for general-purpose use?
If so, I'd certainly be happy to try it.. how would one go about switching to using the CINT backend instead of Reflex? --Alex On Thu, Jan 9, 2014 at 3:22 PM, Ryan Gonzalez <rym...@gmail.com> wrote: > What about the CINT backend? > https://bitbucket.org/pypy/pypy/src/52bbec630c1faec5ea0c1772872411de541d507f/pypy/module/cppyy/test/test_cint.py<https://bitbucket.org/pypy/pypy/src/52bbec630c1faec5ea0c1772872411de541d507f/pypy/module/cppyy/test/test_cint.py?at=default> > > > On Thu, Jan 9, 2014 at 12:14 PM, Alex Stewart <foo...@gmail.com> wrote: > >> Hi all, >> >> So I've been working on trying to develop PyPy bindings for the Bullet >> physics library (http://bulletphysics.org/) using cppyy. So far, after >> a bit of an initial learning curve, I was able to put together a >> configuration that maps almost all of the standard Bullet classes and >> functions, and worked surprisingly well "out of the box" (with no fixup >> code or anything), and have even successfully ported a basic "hello world" >> Bullet example from one of the tutorials to Python. (I have to say, I'm >> pretty impressed with how smoothly it all works!) >> >> The one main issue I'm left with at this point, however, is that for any >> sort of real application, Bullet makes substantial use of callbacks (both >> in the form of some global C++ function pointers as well as some abstract >> "callback" classes with virtual methods intended to be subclassed and >> overridden). My understanding is that cppyy does not currently support any >> form of calling Python code from C++ (only the other way around), so this >> presents a bit of a problem. >> >> From what I've read, there are currently efforts to switch cppyy to being >> cling-based, and that this change might also allow some of this. I was >> wondering (a) how far off is this likely to be? (is it a "we'll have a beta >> next week" sort of thing, or a "we haven't even started yet, and might >> never get around to it" sort of thing?) and (b) will calling Python from >> C++ automatically be an option as soon as the cling-based stuff is >> available, or is that something that would be an additional step to add >> (and thus take more time) after the basic cling-transition is done? >> >> I've been futzing around with a workaround option in the meantime which I >> think might work: >> >> 1. Wrap the C++ function pointers/virtual functions with stub code which >> calls a C function pointer instead, passing C++ objects as "void *" >> 2. Write helper C++ functions which can accept "void *" and return a >> result casted to the appropriate C++ type >> 3. Use cffi or ctypes to have the C function pointers call back into a >> Python wrapper function, which then calls the helper conversion functions >> via cppyy to convert the "void *"s back into the correct cppyy objects, and >> then calls the actual Python callback function/method with those as >> arguments. >> >> Obviously, this is kinda clunky and involves a fair bit of overhead, >> which I'd really like to avoid, so I'm also curious if anybody has any >> other suggestions for better ways to do this sort of thing? >> >> Any help would be much appreciated! >> >> --Alex >> >> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev@python.org >> https://mail.python.org/mailman/listinfo/pypy-dev >> >> > > > -- > Ryan > When your hammer is C++, everything begins to look like a thumb. >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
