[pypy-dev] cppyy and callbacks

[Alex Stewart]

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 <rymg19 at 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 <foogod at 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 at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
>
>
> --
> Ryan
> When your hammer is C++, everything begins to look like a thumb.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20140109/621acc5d/attachment-0001.html>