Hi Wim, Am 18.01.2017 um 18:34 schrieb wlavrijsen@lbl.gov:
Hi Tobias,
unknown type code: P 1 unknown type code: ??? -178968160 77
that falls in the category "should never happen." Arguments are passed as a patch of memory, with a type code indicating how the individual arguments should be treated. The only way this can be wrong, is if the offset is wrong. I don't understand how that can happen: the offset is provided at run-time by the backend, where it is compiled in. The pypy-side module then uses that offset, so there should be only one value throughout.
Still, is pypy-c build with a different compiler than the pip? Not that I
Yes. I am using https://github.com/squeaky-pl/portable-pypy and this is built with GCC 6.2.0. As there isn't a standard C++ ABI, this would explain all sorts of weird things happening. Or does clang deliberately try to follow gcc ABI? I am aware that the term "C++ ABI" is an oxymoron in a way .. what's the ABI of a templated template? =)
Also, can you try the following (this is not a public interface):
import cppyy cppyy.gbl.gInterpreter.Declare(""" .... class MyClass { .... public: .... MyClass(int i = -99) : m_myint(i) {} .... int GetMyInt() { return m_myint; } .... void SetMyInt(int i) { m_myint = i; } .... public: .... int m_myint; .... };""") Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: <class '__main__.::'> object has no attribute 'gInterpreter' (details: "function 'cppyy_get_template' not found in
Doesn't work for me: oberstet@thinkpad-t430s:~/scm/oberstet/scratchbox/cpp/capnproto/test1$ pypy MyClass.py unknown type code: � 1 unknown type code: 1294245728 77 oberstet@thinkpad-t430s:~/scm/oberstet/scratchbox/cpp/capnproto/test1$ pypy Python 2.7.12 (aff251e543859ce4508159dd9f1a82a2f553de00, Nov 12 2016, 08:50:18) [PyPy 5.6.0 with GCC 6.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. library 'libcppyy_backend.so'")
-- Given all these problems even running a basic example (I haven't even got to capnproto generated C++ .. and this is heavily templated code, so even more will go wrong), and given that I have a specific use case (captnproto) rather than a general need to wrap C++, I think I will evaluate capnpy .. -- But I think we didn't waste time: - 2 bugs identified and fixed in cppyy - using clang _might_ work, but pypy binaries are gcc most of the time, and that leads to more issues So I think gcc 5 support is more important: "Found GCC compiler with new ABI. Cling does not support the GCC 5 ABI yet" The bundled Cling is too old? I am totally guessing here .. in fact I don't really know what I am doing;) Cheers, /Tobias