Hi Alex,
I have to say, I'm pretty impressed with how smoothly it all works!
good to hear.
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.
Indeed. I've had two occasions (not with Reflex, but with CINT) where I
needed to call the other way around: fitting of data distributions with
python functions, and callbacks when C++ objects get deleted. I've used a
custom piece of rpython for both.
Overriding of virtual functions can only be done with a helper class
deriving from the callback interface on the C++ side. There's no other
(portable) way.
For global functions, I've found helper with void* + cffi (the way you've
described in your mail) enough. Yes, that isn't satisfactory, but last
year the priority has been Cling.
Which answers this:
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?)
The status is that we'd way underestimated the amount of work. When working
with CINT or Reflex, it was always possible to have something functional, as
parts that were not working yet, could be handled gracefully. Not so with
Clang: if you don't handle something, it will exit one way or another (as it
is supposed to do: a compiler stops on bad input).
As such, it all took about a year longer, but since end of November last
year, we now have a working bindings generator for Cling, but only on
CPython. I've only just started (this week) with the groundwork of getting a
back-end for cppyy into shape.
(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?
Calling from Cling into Python has always been part of it. From there,
creating callable function pointers with a wrapper is not so much work.
Derived classes is somewhat more convoluted, but also straightforward (has
been done before, after all).
(The bigger point of using Clang/LLVM was C++11, though, so that has some
priority, although so far it seems to be in a rather good shape.)
Best regards,
Wim
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
