Open fiedl opened 4 years ago
When reverting the options struct and going back to a regular function signature, I'm getting the original error again:
[2020-04-20 20:45:53] fiedl@fiedl-mbp ~/icecube/builds/2020-04-15_combo_merge-clsim-hole-ice
▶ ./env-shell.sh make -j 4
[ 98%] Building CXX object clsim/CMakeFiles/clsim-pybindings.dir/private/pybindings/I3CLSimModuleHelper.cxx.o
In file included from <built-in>:1:
In file included from /Users/fiedl/icecube/builds/2020-04-15_combo_merge-clsim-hole-ice/CMakeFiles/I3.h:62:
In file included from /usr/local/include/boost/python.hpp:18:
In file included from /usr/local/include/boost/python/class.hpp:17:
In file included from /usr/local/include/boost/python/data_members.hpp:15:
/usr/local/include/boost/python/make_function.hpp:76:11: error: no matching function for call to 'get_signature'
, detail::get_signature(f)
^~~~~~~~~~~~~~~~~~~~~
By experimenting, I'm seeing that the error does occur when the signature has more than 15 arguments.
https://stackoverflow.com/a/8312525/2066546
Yes there is a limit. You can find those limits here. It appears to be 15, though I believe you can change it, according to the link.
Without variadic templates(in the new standard) you would have to hand write each version, so you would have to stop somewhere. As far as ability to change those numbers using different values of these macros when compiling different libraries (including extension modules and the Boost.Python library itself) is a violation of the ODR. However, we know of no C++ implementations on which this particular violation is detectable or causes any problems.
https://www.boost.org/doc/libs/1_41_0/libs/python/doc/v2/configuration.html
BOOST_PYTHON_MAX_ARITY 15 The maximum arity of any function, member function, or constructor to be wrapped, invocation of a Boost.Python function wich is specified as taking arguments x1, x2,...Xn. This includes, in particular, callback mechanisms such as object::operator()(...) or call_method
(... ).
How can I set BOOST_PYTHON_MAX_ARITY
?
https://stackoverflow.com/a/30516216/2066546
#define BOOST_PYTHON_MAX_ARITY 16
If I set this directly in I3CLSimModuleHelper.cxx
, I'm getting:
[2020-04-20 22:31:51] fiedl@fiedl-mbp ~/icecube/builds/2020-04-15_combo_merge-clsim-hole-ice
▶ ./env-shell.sh make -j 8
[ 98%] Building CXX object clsim/CMakeFiles/clsim-pybindings.dir/private/pybindings/I3CLSimModuleHelper.cxx.o
/Users/fiedl/icecube/combo/clsim/private/pybindings/I3CLSimModuleHelper.cxx:30:9: warning: 'BOOST_PYTHON_MAX_ARITY'
macro redefined [-Wmacro-redefined]
#define BOOST_PYTHON_MAX_ARITY 25
^
/usr/local/include/boost/python/detail/preprocessor.hpp:29:11: note: previous definition is here
# define BOOST_PYTHON_MAX_ARITY 15
Maybe, I have to set it before the preprocessor.hpp
of boost is included.
[2020-04-20 22:36:09] fiedl@fiedl-mbp ~/icecube/combo fiedl/merge-clsim-hole-ice ⚡
▶ g preprocessor.hpp
This leads to ./clsim/private/pybindings/module.cxx
:
// ./clsim/private/pybindings/module.cxx
// https://github.com/fiedl/hole-ice-study/issues/121
#define BOOST_PYTHON_MAX_ARITY 25
using namespace boost::python;
namespace bp = boost::python;
#include <boost/preprocessor.hpp>
And it does not resolve the issue. :(
Setting the macro in /usr/local/include/boost/python/detail/preprocessor.hpp
fixes the issue.
# ifndef BOOST_PYTHON_MAX_ARITY
# define BOOST_PYTHON_MAX_ARITY 35
# endif
But where would I set this within combo?
➝ https://icecube-spno.slack.com/archives/C02KQL9KN/p1587418792173700
From our slack discussion:
If we really need #define BOOST_PYTHON_MAX_ARITY
, this should be done in https://github.com/IceCube-SPNO/IceTrayCombo/blob/master/cmake/tool-patches/common/pybindings.hpp, which gets included in all pybindings targets. To modify the master-control header https://github.com/IceCube-SPNO/IceTrayCombo/blob/master/cmake/I3.h.in is discouraged.
We should find an alternative to increasing the signature maximum. Increasing this number would also increase the number of required pre-processor slowing down compilation.
The options struct is a good idea.
Defining a boost-python setter for
struct OpenCLInitOptions {
const I3CLSimOpenCLDevice &device;
}
would mean that one would want to set a constant reference.
here you’re trying to assign to a const reference, which is a thing you cannot do, because assignment invokes the operator= of there referenced object in c++, and there is no const operator=
a shared_ptr
to the device
would work
I also was thinking about leaving device
a const reference separate from the options struct. This depends on how the python code uses the device
.
I have used an options struct to pass on parameters to
I3CLSimModuleHelper::initializeOpenCL
. But now, after merging with a recent version of combo, this approach does not work anymore.https://github.com/fiedl/clsim/commit/f6c0ed7502c20f4b9b8bc8bfb9109f8c13bc071d:
What was the original intent of the options struct?
https://github.com/fiedl/clsim/commit/9c7f0e4ab90713e0ee41cda262b536e2ad67723a#commitcomment-6518341
Introducing the options struct did resolve the original issue.
Where does it break now?
In order to define the struct
in boost python, I've tried:
But this raised: