[Wrapper] no matching function for call to ‘convert_from_python(PyObject*&)

opeil commented 8 years ago

The following error(s) are produced when trying to compile the wrapped c++ code:

/home/opeil/Codes/triqs/triqs1.4/applications/dft_tools/dev_build/python/converters/plovasp/dft_tools/atm_wrap.cpp: In instantiation of ‘int converter_for_parser_non_wrapped_type(PyObject*, T*) [with T = triqs::arrays::array<double, 1>; PyObject = _object]’:
/home/opeil/Codes/triqs/triqs1.4/applications/dft_tools/dev_build/python/converters/plovasp/dft_tools/atm_wrap.cpp:112:191:   required from here
/home/opeil/Codes/triqs/triqs1.4/applications/dft_tools/dev_build/python/converters/plovasp/dft_tools/atm_wrap.cpp:78:33: error: no matching function for call to ‘convert_from_python(PyObject*&)’
   *p = convert_from_python<T>(ob);

Code snippet:

 static PyObject* atm_tet_dos3d(PyObject *self, PyObject *args, PyObject *keywds) {

  PyObject * py_result; //final result

  // If no overload, we avoid the err_list and let the error go through (to save some code).
    {// overload tet_dos3d(double en, array<double,1> eigk, array<int,2> itt, int ntet, array<double,2> cti) -> void
     // define the variable to be filled by the parsing method
     // wrapped types are converted to a pointer, other converted types to a value or a view
       double en ; //  double is a regular type
       array<double,1> eigk; //  array<double,1> is a regular type
       array<int,2> itt; //  array<int,2> is a regular type
       int ntet ; //  int is a regular type
       array<double,2> cti; //  array<double,2> is a regular type
     static char *kwlist[] = {"en","eigk","itt","ntet","cti",NULL};
     static const char * format = "di|O&O&O&";
     if (PyArg_ParseTupleAndKeywords(args, keywds, format, kwlist  ,&en,converter_for_parser_non_wrapped_type<array<double,1>> ,&eigk,converter_for_parser_non_wrapped_type<array<int,2>> ,&itt ,&ntet,converter_for_parser_non_wrapped_type<array<double,2>> ,&cti))
     {
      try {
          tet_dos3d(en,eigk,itt,ntet,cti); // the call is here. It sets up "result" : sets up in the python layer.
         Py_INCREF(Py_None);
         py_result = Py_None;
        goto post_treatment; // eject, computation is done
      }
      CATCH_AND_RETURN(".. calling C++ overload \n.. tet_dos3d(double en, array<double,1> eigk, array<int,2> itt, int ntet, array<double,2> cti) -> void \n.. in implementation of function atm.tet_dos3d", NULL);
     }
    } // end overload tet_dos3d(double en, array<double,1> eigk, array<int,2> itt, int ntet, array<double,2> cti) -> void

   goto error_return;

  post_treatment:

   return py_result;

  error_return :
   return NULL;
 }

parcollet commented 8 years ago

again, I need a complete example on which I can work ...

opeil commented 8 years ago

https://gist.github.com/opeil/396ba90fab1c610c703f

Three issues are demonstrated there:

c++2py produces a wrong path to include files (see 'testlib_wrap.py')
issue #304
issue #305

CMake files are also attached. They need to be placed in respective directories ('c++' and 'python').

On Mon, Feb 15, 2016 at 5:56 PM, Olivier Parcollet <notifications@github.com

wrote:

again, I need a complete example on which I can work ...

— Reply to this email directly or view it on GitHub https://github.com/TRIQS/triqs/issues/305#issuecomment-184299231.

Dr. Oleg E. Peil Department of Quantum Matter Physics Universite de Geneve CH-1211 Geneve 4 Switzerland Tel :+41 (0)22 379 3571

opeil commented 8 years ago

UPDATE: It does not always work. There is still a problem with convert_from_python<T>(ob).

I found out that the issue #305 (this issue) is resolved if one puts the proper header (#include <triqs/python_tools/converters/arrays.hpp>) into the 'add_preamble()'. So all these three issues are related to bugs in c++2py.

krivenko commented 8 years ago

Hi Oleg,

Your testlib_wrap.py exhibits two problems with c++2py:

../c++ prefix is (erroneously?) removed from an argument of module.add_include(). Commit cd4fd40629ed5e45901be50f82a8a4b9cf558019 is responsible for this behavior.
As you correctly pointed out, #include <triqs/python_tools/converters/arrays.hpp> is missing from add_preamble(). This is because half of the converters we have in triqs/python_tools/converters are not listed in converters_to_include mapping. arrays.hpp is one of them.

opeil commented 8 years ago

Igor, /c++ prefixed was not removed, it was not there from the very beginning. I added it by hands (a commented line above the wrong one) but then left the original line to point out a potential bug in c++2py.

As to the include ../converters/arrays.hpp I also added it by hands but it helped only in the case of the little example that I put on gist. When I did this in the full source file I still got the error message given in the title of the issue. Admittedly, a reference to a pointer, PyObject *&, looks suspicious to me. Is it meant to be like that?

krivenko commented 8 years ago

Igor, /c++ prefixed was not removed, it was not there from the very beginning. I added it by hands (a commented line above the wrong one) but then left the original line to point out a potential bug in c++2py.

I understand, I meant that it was removed by c++2py in the first place. For a reason, which is not clear to me.

As to the include ../converters/arrays.hpp I also added it by hands but it helped only in the case of the little example that I put on gist. When I did this in the full source file I still got the error message given in the title of the issue. Admittedly, a reference to a pointer, PyObject *&, looks suspicious to me. Is it meant to be like that?

In general, PyObject *& is a perfectly valid argument type for convert_from_python(). You are saying that your short example compiles after adding #include <triqs/python_tools/converters/arrays.hpp> to add_preamble(), but the full application still fails. Does it fail with exactly the same error message?

opeil commented 8 years ago

Concerning the include path generated by c++2py: In this simple example it just removes the path completely. But in my full code it does a very strange thing: instead of putting a correct path ../../../c++/plovasp/atm/dos_tetra3d.cpp it adds ../../plovasp/atm/dos_tetra3d.cpp. Perhaps this would help to identify the problem.
I seem to resolve issue #305. The problem was that c++2py tries to convert all functions present in the source file, to which I did not pay attention before. However, most of them are internal and some of them take arguments such as double *. Obviously, there is not converter for this type of arguments and the wrapper fails to compile. To fix this I just removed from _desc.py all functions that are not meant to be converted and the compilation worked (have not checked yet whether the code runs, though).

My question is the following: Is there a legal way to tell c++2py not to touch certain (static) functions which are supposed to be internal to a library?

krivenko commented 8 years ago

Perhaps this would help to identify the problem

The problem is in commit cd4fd40629ed5e45901be50f82a8a4b9cf558019, as I wrote above (see the changes made to tools/cpp2py/mako/xxx_desc.py). I guess Olivier @parcollet can explain what and why he did in that commit.

My question is the following: Is there a legal way to tell c++2py not to touch certain (static) functions which are supposed to be internal to a library?

First of all, you should normally run c++2py.py on the header file, dos_tetra3d.hpp in your example. dos_tetra3d.cpp may contain as many internal functions as you like; they will not be seen by c++2py.py.

Second, there is a special macro TRIQS_CPP2PY_IGNORE. You can put it in front of a function declaration in the header file and effectively hide that declaration from c++2py. Here is an example of use: https://github.com/TRIQS/cthyb/blob/master/c++/atom_diag.hpp

TRIQS / triqs

[Wrapper] no matching function for call to ‘convert_from_python(PyObject*&) #305