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

[Alex Pyattaev]

Distro is latest gentoo, amd64 with sse2 and sse3 (core i5).
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. Anyway, default binary pypy works fine. 

Currently i have only one typemap in my *.i file for swig, and it allows 
PyObject* pointers to go through to c++ side. Otherwise no special features 
are used, so migration should be pretty painless.

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.

BR,
Alex
PS: sorry for using 2 emails - one is work other home, screwd company policy.

maanantai 23 huhtikuu 2012 07:52:49 wlavrijsen at lbl.gov kirjoitti:
> Hi Alexander,
> 
> > An important question from userland - would it be benefitial to switch
> > from
> > SWIG to the new interface? When can that be done?
> 
> there are no many major differences between SWIG and this on the Python side
> (nothing that can't be captured in a compatibility layer). I'm thinking of
> such things like cvar that is needed in SWIG, but not in cppyy, and the use
> of templates which need to be named in the .i's in SWIG but are have a more
> "instantiable" syntax in cppyy (for when the Cling backend becomes
> available). Also, Reflex can parse more code than can SWIG, so you'd have
> to be careful in which direction you use things.
> 
> > Right now the main problem with SWIG is the object ownership, i.e. with
> > pypy one has to set thisown=False for all objects to avoid crashes
> > related to GC code. The problem occurs only for long-living objects
> > though.
> 
> The GC and cppyy work fine for those objects clearly owned by PyPy. Of
> course, if the C++ side takes ownership, that would need to be patched up
> "by hand" or with a rule (if the C++ API is consistent).
> 
> > PS: I would have gladly tested an alpha-beta quality version of the lib (i
> > have some unittests for SWIG bindings, so they should work with new lib
> > also i suppose), but I can not build pypy from sources, not enuf RAM =)
> > Maybe someone could send me a build with new feature for testing?
> 
> What distro (in particular, 32b or 64b and which version of libssl)? I've
> never distributed a binary version of PyPy, but could give it a try.
> 
> Best regards,
>             Wim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120423/a0be803a/attachment-0001.html>