Mailman 3 January 2012 - Cplusplus-sig

boost::python embedding error - runtime - Mac OS X - 1.38
by Igor Karpov Oct. 1, 2014

Oct. 1, 2014

Hi, I am trying to run the following program: #include <iostream> #include <Python.h> #include <boost/python.hpp> using namespace boost::python; using namespace std; int main(int argc, char** argv) { { // Using Python/C Py_Initialize(); PyObject* main_module = PyImport_ImportModule("__main__"); PyObject* globals = PyEval_GetGlobals(); PyObject* locals = PyEval_GetLocals(); PyRun_SimpleString("print 'Hello World, from Python/C!'\n"); Py_Finalize(); } { // Using boost::python Py_Initialize(); object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); try { object ignored = exec("print 'Hello World, from boost::python!'\n", main_namespace); Py_Finalize(); } catch (error_already_set const& e) { PyErr_Print(); return 1; } } return 0; } on Linux (both x86 and x86_64), with Ubuntu's default version of Boost (1.34.1) installed, I am able to do so as expected: $ ./embed Hello World, from Python/C! Hello World, from boost::python! on Mac OS X, I get a runtime error: $ ./embed Hello World, from Python/C! Bus Error Running with gdb, this is the stack trace: Hello World, from Python/C! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x00bb618f in PyEval_GetGlobals () #2 0x00bce0dd in PyImport_Import () #3 0x00bce2b0 in PyImport_ImportModule () #4 0x008127d4 in boost::python::import (name=@0xbffff4a8) at libs/python/src/import.cpp:20 #5 0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22 For this Mac, boost version is latest (1.38) and python version is: Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Is this a bug? I attached the source and the cmake file I am using to build, for convenience. Thanks, --Igor.

4 6

wrapped std::vector slice affecting items in a python list
by babak April 2, 2012

April 2, 2012

Hi, I've come across some unusual behaviour that I was hoping some one might be able to explain to me. In python I have a list and a wrapped std::vector<MyCustomType> (using the vector_indexing_suite) where the list contains the items in the vector. If I slice insert items into the vector then the items in the python list change. The attached example illustrates this. Is this behaviour expected ? I'm quite confused as to what's going on so any help clarifying this would be greatly appreciated. thanks, Babak http://boost.2283326.n4.nabble.com/file/n3738972/test.py test.py http://boost.2283326.n4.nabble.com/file/n3738972/source.cpp source.cpp -- View this message in context: http://boost.2283326.n4.nabble.com/wrapped-std-vector-slice-affecting-items… Sent from the Python - c++-sig mailing list archive at Nabble.com.

3 7

Boost converter for passing std::vector object by reference into a function??
by DeVico, Mike Feb. 12, 2012

Feb. 12, 2012

Hello, I would like to wrap a class that looks like below (taken from an example I found on another site) #include <boost/python.hpp> #include <boost/python/suite/indexing/vector_indexing_suite.hpp> #include <boost/python/suite/indexing/map_indexing_suite.hpp> typedef std::vector<std::string> MyList; class MyClass { public: MyList myFuncGet() { return MyList(); } void myFuncSet(MyList& list) { list.push_back("Hello"); } // stuff }; BOOST_PYTHON_MODULE(MyModule) { class_<MyList>("MyList") .def(vector_indexing_suite<MyList>() ); class_<MyClass>("MyClass") .def("myFuncGet", &MyClass::myFuncGet) .def("myFuncSet", &MyClass::myFuncSet) ; } However, this is what I get when I try to use it from python: Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from MyModule import * >>> mc = MyClass() >>> p = [] >>> mc.myFuncSet(p) Traceback (most recent call last): File "<stdin>", line 1, in <module> Boost.Python.ArgumentError: Python argument types in MyClass.myFuncSet(MyClass, list) did not match C++ signature: myFuncSet(MyClass {lvalue}, std::vector<std::string, std::allocator<std::string> > {lvalue}) >>> I know I'm missing a converter function, but I'm new to boost and I don't know what the converter should look like in this case. I've found lots of working examples of how to return a vector, but I want to be able to pass the vector into the function by reference and modify it. I would really appreciate it if someone could complete the example by adding the necessary converter code. Thanks in advance. --Mike

3 2

Odd dlopen behavior
by Davidson, Josh Feb. 2, 2012

Feb. 2, 2012

I'm wrapping a C++ project with Py++/Boost.Python under Windows and Linux. Everything in Windows is working fine, but I'm a bit confused over the behavior in Linux. The C++ project is built into a single shared library called libsimif, but I'd like to split it up into 3 separate extension modules. For simplicity, I'll only discuss two of them, since the behavior for the third is identical. The first, called storage contains definitions of data structures. It has no dependencies on anything defined in either of the other two extension modules. The second module, control, uses data structures that are defined in storage. On the C++ side of things, the headers and source files for storage and control are in entirely different directories. I've tried a number of different configurations to build the extensions, but one thing that has remained consistent is that for storage, I am only generating Py++ wrappers for the headers included in the storage directory and only building source files in that directory along with the Py++ generated sources. Ditto for the control extension. The current configuration that I am using that works passes in libsimif as a library to the distutils.Extension constructor. Then before starting Python, I need to ensure that libsimif is found in LD_LIBRARY_PATH. Then I can launch Python and import either module (or from them) and everything works as-expected. Here is some sample output from this working configuration: >>> import ast.simif.model_io.storage as storage >>> import ast.simif.model_io.control as control >>> dir(storage) ['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__'] >>> dir(control) ['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', '__doc__', '__file__', '__name__', '__package__'] >>> storage.__file__ 'ast/simif/model_io/storage.so' >>> control.__file__ 'ast/simif/model_io/control.so' As you can see, both modules have their own shared library and unique set of symbols. Now here is why I am confused. In Linux, we've always set the dlopen flags to include RTLD_NOW and RTLD_GLOBAL. If I do that, this is what happens: >>> import sys >>> import DLFCN >>> sys.setdlopenflags(DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL) >>> import ast.simif.model_io.storage as storage >>> import ast.simif.model_io.control as control __main__:1: RuntimeWarning: to-Python converter for DiscreteStore::FrameData already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for PulseStore::FrameData already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for RtStore::Link already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for RtStore::FrameData already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for RtStore::RtData already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for SerialStore::FrameData already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for SharedMemoryBuilder already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for SharedMemoryDeleter already registered; second conversion method ignored. >>> dir(storage) ['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__'] >>> dir(control) ['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', '__doc__', '__file__', '__name__', '__package__'] >>> storage.__file__ 'ast/simif/model_io/storage.so' >>> control.__file__ 'ast/simif/model_io/control.so' So, here storage imports ok, but control complains about a bunch of duplicate registrations. Then when inspecting the modules, control is completely wrong. It's like it tried to import storage twice even though __file__ reports the correct shared libraries. Perhaps not surprising, if I change the import order and import control ahead of storage, this is what happens: >>> import sys >>> import DLFCN >>> sys.setdlopenflags(DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL) >>> import ast.simif.model_io.control as control >>> dir(control) ['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', '__doc__', '__file__', '__name__', '__package__'] >>> import ast.simif.model_io.storage as storage __main__:1: RuntimeWarning: to-Python converter for DiscreteController already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for PulseController already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for RtController already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for SerialController already registered; second conversion method ignored. __main__:1: RuntimeWarning: to-Python converter for SpaceWireController already registered; second conversion method ignored. >>> dir(storage) ['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__'] Similar behavior, but now the storage import is FUBAR. Does anyone understand what is going on here? I'm using x64 Python 2.6.6 on x64 RHEL 6. Gcc version 4.4.6. Thanks, Josh

2 5

Boost.Python property definition question
by Michael Wild Jan. 31, 2012

Jan. 31, 2012

Hi all I can't seem to figure out how to wrap this in Boost.Python without the need for auxiliary functions: #include <string> #include <boost/python.hpp> using std::string; using namespace boost::python; class A { string m_s; public: A(string const& s) : m_s(s) {} // read-only access ( string const& s() const { return m_s; } // read-write access string& s() { return m_s; } }; BOOST_PYTHON_MODULE(A) { class_<A> ("A", init<std::string const&>()) .add_property("s", // this getter works fine make_function( (string const&(A::*)()const)&A::s, return_value_policy<copy_const_reference>()), // this setter fails make_function( (string&(A::*)())&A::s, return_internal_reference<>())) ; } When I try to run the following: import A a = A.A("Hello") a.s = "World!" I get below error message: ArgumentError: Python argument types in None.None(A, str) did not match C++ signature: None(A {lvalue}) How do I solve this problem? Thanks for any advice Michael

2 7

Python 3
by Cromwell Enage Jan. 31, 2012

Jan. 31, 2012

Hi, everyone! On my Mac OS X 10.7.2, I had to edit the bootstrap-generated project-config.jam file so that it contained the following directive: using python : 3.2 : /Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2 : /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/ : /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ ; When running "sudo ./b2 install --with-python --debug-configuration", I read errors stating that bjam (still) couldn't find the Python header files. Do I have to install Python 3.2 differently from how the GUI package works? Cromwell D. Enage

1 0

Properly handling prints and feedback when automatically executing a script
by Adam Preble Jan. 31, 2012

Jan. 31, 2012

I have opted to have my C++ main call an autoexec.py script by default when compiled to support the interpreter. Ultimately, I will want to run some Python code w/o user intervention to do it. I have come up with this somewhat naive implementation: http://pastebin.com/NTytF6iQ It starts the script but isn't handling prints inside the script. They just get completely suppressed. How can I get them to come out to the console? For this matter, this naive implementation just runs in a console. I'd love to be able to embed a prettier UI element but it looks like I'd have to come up with a lot of code myself. I'm trying to do this for a 3d project, so it would make some sense to have a console UI embedded in I could tilde into. Ultimately, I'd want to be able to autoexec the script, while having this other console for similarly manipulating state--with appropriate concurrency controls. Is there a known path for doing that kind of thing? The only place I really saw something like this happening at all was with Blender, and the code for doing that in particularly didn't just pop right out at me, and in the IRC channel I wasn't given any other hints than to look at the code.

2 1

Re: [C++-sig] langbinding questions
by Jim Bosch Jan. 29, 2012

Jan. 29, 2012

Thanks...it sounds like I understand things better than I thought I did. Though I'm still worried that I'm confusing which is the "accept" and which is the "visit" class somehow. More questions/replies below. >> As I understand it, the basic idea is: >> >> 1) We build a language-agnostic front-end "module definition" data >> structure that gets stored in a static object. > > I don't know what you mean by "static object," but the rest is dead on. > I just meant a namespace-scope variable, static data member, or static function-scope variable. Is there a good catch-all term for such variables? >> I can see, roughly, how this would work if there's only one module >> builder class (i.e. one target language). The polymorphic classes in >> the module definition would have virtual functions that just take a >> module_builder instance, and then they can call templated visit member >> functions on the module_builder. >> >> But I don't think that model is what was intended - it doesn't scale >> well to multiple target languages, > > In what way? > In the sense that all the frontend classes seem to need to enumerate all the possible backends, because they each have a different module_builder class. Some super-simplified code for what I'm imagining: class frontend_function { public: virtual visit(python_builder & b) = 0; virtual visit(lua_builder & b) = 0; }; template <typename FunctionPointer> class frontend_function_t : public frontend_function { public: virtual visit(python_builder & b) { b.wrap_function(m_name, m_func); } virtual visit(lua_builder & b) { b.wrap_function(m_name, m_func); } private: std::string m_name; FunctionPointer m_func; }; class python_builder : public module_builder { public: template <typename FunctionPointer> void wrap_function(std::string const & name, FunctionPointer p); }; This isn't horrible, and "doesn't scale" is the wrong phrase, but it doesn't allow you to add new backends without modifying the core library, and I had (perhaps naively) assumed that was part of the design. >> and it doesn't explain why the module_builder classes in the proposal >> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use >> CRTP. > > I don't see any CRTP. There's some prototype code in SVN that might explain > details such as module_builder's template parameter. > It's probably just a red-herring of some sort, but the section 3.2 of the above doc starts with "Module builders must be instances of a class derived from a CRTP base class". I've looked at the langbinding code in the boost svn sandbox, and I'm it seem to be mostly utility code at the moment (though I admit I don't understand how a lot of it fits together, so maybe I'm missing the forrest for the trees). Thanks! Jim

1 0

Re: [C++-sig] langbinding questions
by Dave Abrahams Jan. 25, 2012

Jan. 25, 2012

Hi Jim, Sorry this is so late. Sick, work, sick, work... you know how it can be. on Sun Jan 15 2012, Jim Bosch <talljimbo-AT-gmail.com> wrote: > I've been trying to wrap my head around some Boost.Langbinding > concepts as part of my (slow, but not dead) work on an eventual > Boost.Python v3. I've got some questions - and if there are others who > I should be sending this email to, please let me know and/or forward. Yeah, you should send it to the langbinding list and/or Cc: Daniel Wallin. > As I understand it, the basic idea is: > > 1) We build a language-agnostic front-end "module definition" data > structure that gets stored in a static object. I don't know what you mean by "static object," but the rest is dead on. > 2) That data structure hides all the type information somehow Hides it at compile-time; represents it at runtime. > - I'm imagining a polymorphic non-template base class with templated > derived classes, or something equivalent. But I get the sense that > this may be an incorrect assumption. I don't know why; sounds like a classic type erasure pattern. > 3) We pass in a target-language-specific "module builder" to the > "module definition", which goes through itself and calls visit member > functions on the "module builder", which in turn creates the > target-language wrapper. That sounds right. > I can see, roughly, how this would work if there's only one module > builder class (i.e. one target language). The polymorphic classes in > the module definition would have virtual functions that just take a > module_builder instance, and then they can call templated visit member > functions on the module_builder. > > But I don't think that model is what was intended - it doesn't scale > well to multiple target languages, In what way? > and it doesn't explain why the module_builder classes in the proposal > (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use > CRTP. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

A few questions on Boost.Python
by Bo Jensen Jan. 24, 2012

Jan. 24, 2012

Hi, I have been looking into the best way for me to make a python wrapper for a C++ library. Boost.Python looks nice and seem to fit my needs, but I have a few questions before I dig in deep and do the implementation. What I want to do : I have a very thin header only C++ library, which is an extension on top of a c library i.e some of the C++ functions call functions in a C dll/so. So the C++ library only provides a nice way of using the C library with operators and overloading etc. For this library I want to make an python interface, which only should mimic the C++ classes and functions i.e there will be a 1:1 mapping. Questions : 1) Would Boost.Python be suited for such a task ? 2) What kind of speed can I expect ? I read somewhere that cython was much faster (but it seems to be less portable and flexible). 3) Will I experience problems with types like wchar or long long ? 4) How do I link to my C library ? 5) I also read that Boost.Python is not thread safe, is that true and if yes can it be fixed/hacked ? 6) Regarding portability, will I have to recompile for each python version ? 7) 64 bit is supported right ? Thanks to anybody providing some insight. /Bo

5 4