On Mon, Apr 23, 2012 at 7:08 AM, <wlavrij...@lbl.gov> wrote: > Hi, > > as detailed in a couple of blog posts in the past (*), for some time now we > have been working on making C++ bindings through the Reflex package > available > on PyPy, in the form of the "cppyy" module. Software is never done, and > that > is true also in this case, but it has reached a level of maturity at which > it > can be said to be usable. Initial docs are now up on: > > > http://doc.pypy.org/en/latest/**cppyy.html<http://doc.pypy.org/en/latest/cppyy.html> > > with instructions on how to setup the reflex-support branch and how to test > it out. The documentation will be updated with more advanced and detailed > topics in the next couple of weeks or so. > > There's a sizable (non-PyPy) set of unit tests that still need to be worked > through, thus development will steadily continue at its current pace. > Still, > if you find that cppyy almost works for you except for a particular > feature, > feel free to ask for it to be prioritized. > > The biggest obstacle for most people (that are not in the field of HEP) > will > be the current set of dependencies. Although the dependency set for cppyy > is > really only Reflex, which could be distributed separately, for the CPython > equivalent code, the dependency set is a large portion of the ROOT class > library. The medium-term plan then is to use Cling, which is based on CLang > from llvm > (http://root.cern.ch/drupal/**content/cling<http://root.cern.ch/drupal/content/cling>) > as the back-end. For > this, there will be a PyCling on CPython, and all as stand-alone projects > to > remove the large dependency set. > > More interesting though, having Cling on the back of the bindings allows > far more advanced features, such as dynamic setup of callbacks and cross > language inheritance to put Python code into C++ frameworks. This has been > prototyped successfully in Clings predecessor (CINT), but would be very > hard > to do in Reflex. > > Of course, an important reason for pushing this code out to the community > somewhat early, is that it allows anyone so interested to start hacking on > it and help shape it! > > Best regards, > Wim > > (*) http://morepypy.blogspot.com/**2011/08/wrapping-c-libraries-** > with-reflection.html<http://morepypy.blogspot.com/2011/08/wrapping-c-libraries-with-reflection.html> > http://morepypy.blogspot.com/**2010/07/cern-sprint-report-** > wrapping-c-libraries.html<http://morepypy.blogspot.com/2010/07/cern-sprint-report-wrapping-c-libraries.html> > -- > wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net > ______________________________**_________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/**mailman/listinfo/pypy-dev<http://mail.python.org/mailman/listinfo/pypy-dev> >
Quick question - if it's mature, why not merge it to default? I presume it should be turned off, since there is a sizeable dependency, but still having it in default can be good. Cheers, fijal
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
