Hello, I've been looking at cppyy a bit (with the goal of using an existing project based on it). I haven't gotten far though. When I try to use cppyy with the Ubuntu-packaged PyPy (on Ubuntu 14.04), I get this: Python 2.7.3 (2.2.1+dfsg-1, Nov 28 2013, 05:13:10) [PyPy 2.2.1 with GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``Is it a cactus bug or problem with my war?'' problem? Thanks, Jean-Paul
Jean-Paul,
at issue is that cppyy needs to be linked with libReflex.so and since PyPy builds in all modules, it in turned would need to be linked with that lib. That would not be good. So, to work around that, cppyy resolves the methods it needs dynamically, but it then needs that extra lib. It can be found through here: http://doc.pypy.org/en/latest/cppyy.html#installation HTH, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On 04:59 am, wlavrijsen@lbl.gov wrote:
Hi Wim, First off, thanks for your work on cppyy. I don't /like/ having to interface with C++ libraries but it's nice to have an option for doing so. :) Thanks for this pointer about this dependency, too. I've built Reflex and now I can import `cppyy` on PyPy. I had read the installation instructions but I don't find it clear from that page that building Reflex is a requirement. It sounds more like Reflex is something you need to build if you're building PyPy yourself and want the cppyy module. Maybe that could be clarified on the page. Also, I wonder if Reflex could turn into a "real" project - or maybe it is one already. Does it have a version control system or issue tracker (eg on bitbucket, like PyPy)? Downloading a source tarball from a user directory on a random host makes it look ... fly-by-night? I'm a little worried about building software on this - will it suddenly disappear, is there any development activity, etc. Thanks
Hi all, exarkun@twistedmatrix.com writes:
I've been thinking about this. Reflex is part of ROOT[1], so I think it does count as a 'real project'; Wim will clarify, I'm sure. But my thinking is as follows: currently, it is hard to build an extension using a C++ library for both CPython and PyPy. Reflex makes this easier, but it is only available on CPython via PyCintex, which means (I think) you need to build ROOT, or at least dig into the ROOT build system, which is not particularly convenient. Currently, I have a CPython extension that uses Boost.Python, and I would like to find a Python-C-API-agnostic way of wrapping it. Reflex would seem to be a good step in that direction, but it is a shame that it and PyCintex are (it seems) rather locked into ROOT. It would be great if -- like the Reflex tarball distributed for use with cppyy -- these bits could all be distributed and built separately, so that building portable C++ extensions could be a lot easier, and that this could be done widely. Right now it would be very hard for me to switch from boost.python, because it is very easy to build and distribute extensions using boost.python, without requiring the user has complex dependencies installed. [1] http://root.cern.ch/drupal/content/reflex Cheers, Toby -- Toby St Clere Smithe http://tsmithe.net
Jean-Paul, to follow-up on what Toby already said ... For us it's not so much differences between CPython and PyPy (there is cpyext, after all). Even with CPython one has to deal with different Python versions, and Reflex let's one get away from that. The larger point is scaling. The idea behind something like SWIG (or even CFFI), is that the authors of their own packages use it, and can customize it as needed (because they are willing and able to do so). We OTOH need to throw a couple of million lines of code at it, with no author support, and also have it all work seamlessly. Full automation is then the only way to go. Yes, Reflex is mature and supported, but part of ROOT, and not packaged independently (other than the tar ball that the instructions point at). With PyCintex.py (now called cppyy.py) it's even worse as it requires certain ROOT libraries. Reflex is no longer developed, however. (For bugs and other support, root.cern.ch is available.) What we are working on is Cling (http://root.cern.ch/drupal/content/cling), which is also mature and supported, but beyond that, it is actively being developed. The benefits are support for C++14, and it being a true C++ compiler can munch pretty much anything you throw at it, including massively templated boost headers (there's a caveat for inline asm, which doesn't work, the rest is fine). All our cycles, however, are being soaked up by migrating legacy C++ codes that made use of the Reflex (and other deprecated) APIs directly. A lot of that code is orphaned (no docs, tests, and authors unreachable). In ATLAS, we had two guys working on that, but both have left, so I got pulled into that. Until the fog clears on that account, there's little I can do to reduce dependencies and repackage, simply due to lack of time. But hey, it's all open source and the most restrictive license you'll run into is LGPL (for ROOT code; the python bits can be made available under modified BSD). So, if anyone does have spare cycles, they're more than welcome to contribute. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi exarkun (2014.10.06_01:15:11_+0200)
Thanks, I should probably build that extension in the Debian/Ubuntu PyPy package. I filed http://bugs.debian.org/767546 to remind me. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Jean-Paul,
at issue is that cppyy needs to be linked with libReflex.so and since PyPy builds in all modules, it in turned would need to be linked with that lib. That would not be good. So, to work around that, cppyy resolves the methods it needs dynamically, but it then needs that extra lib. It can be found through here: http://doc.pypy.org/en/latest/cppyy.html#installation HTH, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
On 04:59 am, wlavrijsen@lbl.gov wrote:
Hi Wim, First off, thanks for your work on cppyy. I don't /like/ having to interface with C++ libraries but it's nice to have an option for doing so. :) Thanks for this pointer about this dependency, too. I've built Reflex and now I can import `cppyy` on PyPy. I had read the installation instructions but I don't find it clear from that page that building Reflex is a requirement. It sounds more like Reflex is something you need to build if you're building PyPy yourself and want the cppyy module. Maybe that could be clarified on the page. Also, I wonder if Reflex could turn into a "real" project - or maybe it is one already. Does it have a version control system or issue tracker (eg on bitbucket, like PyPy)? Downloading a source tarball from a user directory on a random host makes it look ... fly-by-night? I'm a little worried about building software on this - will it suddenly disappear, is there any development activity, etc. Thanks
Hi all, exarkun@twistedmatrix.com writes:
I've been thinking about this. Reflex is part of ROOT[1], so I think it does count as a 'real project'; Wim will clarify, I'm sure. But my thinking is as follows: currently, it is hard to build an extension using a C++ library for both CPython and PyPy. Reflex makes this easier, but it is only available on CPython via PyCintex, which means (I think) you need to build ROOT, or at least dig into the ROOT build system, which is not particularly convenient. Currently, I have a CPython extension that uses Boost.Python, and I would like to find a Python-C-API-agnostic way of wrapping it. Reflex would seem to be a good step in that direction, but it is a shame that it and PyCintex are (it seems) rather locked into ROOT. It would be great if -- like the Reflex tarball distributed for use with cppyy -- these bits could all be distributed and built separately, so that building portable C++ extensions could be a lot easier, and that this could be done widely. Right now it would be very hard for me to switch from boost.python, because it is very easy to build and distribute extensions using boost.python, without requiring the user has complex dependencies installed. [1] http://root.cern.ch/drupal/content/reflex Cheers, Toby -- Toby St Clere Smithe http://tsmithe.net
Jean-Paul, to follow-up on what Toby already said ... For us it's not so much differences between CPython and PyPy (there is cpyext, after all). Even with CPython one has to deal with different Python versions, and Reflex let's one get away from that. The larger point is scaling. The idea behind something like SWIG (or even CFFI), is that the authors of their own packages use it, and can customize it as needed (because they are willing and able to do so). We OTOH need to throw a couple of million lines of code at it, with no author support, and also have it all work seamlessly. Full automation is then the only way to go. Yes, Reflex is mature and supported, but part of ROOT, and not packaged independently (other than the tar ball that the instructions point at). With PyCintex.py (now called cppyy.py) it's even worse as it requires certain ROOT libraries. Reflex is no longer developed, however. (For bugs and other support, root.cern.ch is available.) What we are working on is Cling (http://root.cern.ch/drupal/content/cling), which is also mature and supported, but beyond that, it is actively being developed. The benefits are support for C++14, and it being a true C++ compiler can munch pretty much anything you throw at it, including massively templated boost headers (there's a caveat for inline asm, which doesn't work, the rest is fine). All our cycles, however, are being soaked up by migrating legacy C++ codes that made use of the Reflex (and other deprecated) APIs directly. A lot of that code is orphaned (no docs, tests, and authors unreachable). In ATLAS, we had two guys working on that, but both have left, so I got pulled into that. Until the fog clears on that account, there's little I can do to reduce dependencies and repackage, simply due to lack of time. But hey, it's all open source and the most restrictive license you'll run into is LGPL (for ROOT code; the python bits can be made available under modified BSD). So, if anyone does have spare cycles, they're more than welcome to contribute. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
Hi exarkun (2014.10.06_01:15:11_+0200)
Thanks, I should probably build that extension in the Debian/Ubuntu PyPy package. I filed http://bugs.debian.org/767546 to remind me. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
participants (4)
-
exarkun＠twistedmatrix.com -
Stefano Rivera -
Toby St Clere Smithe -
wlavrijsen＠lbl.gov