[pypy-dev] cppyy comments/questions

[wlavrijsen at lbl.gov]

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
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net