Hi Uwe,
1) During build/translation there were several errors
like "undefined reference to `Reflex::Member::~Member()".
This was caused by not linking against libReflex.
With some modifications (some insertions of
(lib,"Reflex") e.g. ) in pypy/translator/tool/cbuild.py
i got a working (but see later) module. But what's the correct
way of doing the build. The "cppyy use case question" thread
mentions the problem but i didn't see the solution.
the original command that you had works for me, and I've not yet see any
missing symbols problem. W/o being able to reproduce, it's hard to say
anything sensible. There's probably something differently setup.
Now that CFFI is in PyPy default, though, I hope to be able to completely
get rid of the need to link pypy-c with libReflex (the library shouldn't be
needed until "import cppyy" is done).
2) On importing some wrapped "c++ libs" the displayed error is very
generic. The following patch gave me some hints what's wrong .
diff -r 26b81a6d9365 pypy/module/cppyy/interp_cppyy.py
--- a/pypy/module/cppyy/interp_cppyy.py Fri Jun 29 12:26:46 2012 +0200
+++ b/pypy/module/cppyy/interp_cppyy.py Fri Aug 10 23:30:30 2012 +0200
@@ -22,7 +22,7 @@
try:
cdll = capi.c_load_dictionary(name)
except rdynload.DLOpenError, e:
- raise OperationError(space.w_RuntimeError, space.wrap(str(e)))
+ raise OperationError(space.w_RuntimeError,space.wrap(str(e.msg)))
Thanks! I'll add this, together with a test to test_fragile.py, shortly. Most
of the time, I use the automatic class loader these days, though. Saves on
typing and fewer errors.
3) playing with operators.h in pypy/module/cppyy/test/:
(m_int made public before test)
the following lines results with the expected output "10"
import cppyy
cppyy.load_reflection_info('operatorsDict.so')
number = cppyy.gbl.number
n=number(10)
print n.m_int
but if i add "virtual" to "operator==" like
virtual bool operator==(const number& n) const {return m_int == n.m_int;
}
It's not clear to me why this is so, but the problem shows up if some method
is virtual while the destructor is not. Add a virtual dtor, and the problem
goes away.
Thanks, I'll look into this. It's easy to test.
4) During one test i got the following error:
TypeError: none of the 1 overloaded methods succeeded. Full details :
A* B::C::methodName() =>
AttributeError: '<type '::'>' has no attribute ''
I'd like to have such a failing example to add to test_fragile.py and get a
better diagnostic, but for this:
(A and C are types (classes), B is a namespace)
Generally speaking: What's the best way for debugging this problem.
Most likely "A" isn't known or can not be build for some other reason. The
__dir__ method on namespaces is implemented to show the string names of all
known classes. If what I think is the case, then this:
>>>> dir(cppyy.gbl)
should show 'A', but this:
>>>> cppyy.gbl.A
will fail.
Another possibility is that the code is really looking for the global namespace
(which has name '', i.e. empty string, on the global namespace '::'), and that'd
be a bug.
But again, I'd really like the example so that a better diagnostic can be given.
Thanks,
Wim
--
[email protected] -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
