[pypy-dev] cppyy: C++ bindings for PyPy

[wlavrijsen at lbl.gov]

Hi Alex,

> Distro is latest gentoo, amd64 with sse2 and sse3 (core i5).

there's an older version of (Py)ROOT distributed with gentoo:

    http://packages.gentoo.org/package/sci-physics/root

Do you want to use that package, or pick up a more recent version (doesn't
matter for Reflex, I think, as it has been mostly stable)? The pypy binary
below is against 5.32, as I had it available.

> libssl is in 2 versions:
> dev-libs/openssl-0.9.8u:0.9.8
> dev-libs/openssl-1.0.0h:0
> so pick one that suits you better.

Okay; the machine that I had a binary ready for and is probably closest (I'm
not sure whether I can find an amd64 box, but Intel binary should do), has
0.9.8e, so that should work.

First attempt, build against ROOT 5.32 (latest stable version):

   http://cern.ch/wlav/pypy-reflex-support-042312.tar.bz2

with md5sum:

   c6ae683605658fa43e0089a99c82c49b  pypy-reflex-support-042312.tar.bz2

> Anyway, default binary pypy works fine.

Different machines, different people, etc. :) This will be a little trial and
error, I'm afraid, since I haven't distributed PyPy in binary before (for CERN,
I simply installed binaries on the global file system, which makes it available
to most institutes, by building it on a typical worker node).

Btw., if there'll be a number of iterations necessary, then we can take this
off the list.

> Currently i have only one typemap in my *.i file for swig, and it allows
> PyObject* pointers to go through to c++ side.

Passing PyObject* is in PyROOT, not yet in cppyy, as I wasn't sure about its
representation (I'll probably have to pass it through cpyext first to build
an actual PyObject* with the guaranteed expected layout). It's on the TODO
list, though.

> so migration should be pretty painless.

Also depends on the specific C++ features used of course. Actually, what I
hope to gain from this exercise is more that cppyy gives proper and clear
diagnostics if features are missing, rather than just crash.

Furthermore, any answers to questions you may have can be turned into docs,
so that's useful as well.

> And of course if there are bugs they would most likely arise, especially if
> they are in memory management, because the c++ code is executed millions of
> times during the program run.

What we do in the unit tests, is to call the gc explicitly and then see whether
cleanup was done as expected (by having an instance counter on the C++ side).

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net