Mailman 3 August 2011 - 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

New Major-Release Boost.Python Development
by Jim Bosch Oct. 4, 2011

Oct. 4, 2011

I'd like to start work on a new major release of Boost.Python. While the library is currently well-maintained in terms of bugfixes, I get the sense that neither the original developers nor the current maintainer have the time or inclination to work on new features. I'd also like to propose some changes that are slightly backwards-incompatible, as well as some that mess with the internals to an extent that I'd feel better about doing it outside Boost itself, to make it easier for adventurous users to play with the new version without affecting people who depend on having an extremely stable library in Boost. To that end, I'm inclined to copy the library to somewhere else (possibly the boost sandbox, but more likely a separate site), work on it, produce some minor releases, and re-submit it to Boost for review. Perhaps the external site would continue on as the home of more fine-grained releases, or maybe we would fully reintegrate with Boost at that point (especially if Boost addresses some of its own project management and release control issues by that point, which I know is being discussed but to my knowledge doesn't really have a timeline yet). I am willing to take the lead on this project; I have a number of features that exist as extensions in the boost sandbox already that would work better if they could be more fully integrated into the Boost.Python core, and I think I have the necessary understanding of the full code base to coordinate things. I'd like to save a full discussion of what features a new version would include for another thread, but I am hoping other people on the list might volunteer some time to work on aspects they have coded up elsewhere - I know many such extensions exist. So I have a few questions for anyone who's paying attention: - For the original Boost.Python developers and current maintainers, and other people familiar with developing Boost libraries: do you have any preference on how to approach this? I don't want to step on any toes, especially toes attached to people who are responsible for the excellent library we already have. - For other Boost.Python experts on this list: do you have existing code or development time you'd like to contribute? Thanks! Jim Bosch

9 37

sending a c++ class to a python function
by Josh Stratton Sept. 1, 2011

Sept. 1, 2011

I'm getting an error when I try to pass down my object that results in a seg fault. I've registered my class I'm sending down, but when I actually send it, my program exits at this line in the library right after I call the importFile() function... return call<obj>(get_managed_object(self, tag), BOOST_PP_ENUM_PARAMS_Z(1, N, a)); // here's the class I'm trying to send down class Scene { public: MeshP mesh(int key); void clearScene(); CameraP createCamera(QString name); MeshP createMesh(QString name); void setMesh(int meshKey, MeshP mesh) { _meshes[meshKey] = mesh; } QHashIterator<int, MeshP> meshes() { return QHashIterator<int,MeshP>(_meshes); } QHashIterator<int, CameraP> cameras() { return QHashIterator<int,CameraP>(_cameras); } CameraP fetchCamera(QString name); QList<QString> importExtensions(); void importFile(QString fileName); void evalPythonFile(QString fileName); Scene(); protected: int uniqueCameraKey(); int uniqueMeshKey(); QString uniqueName(QString prefix); private: QHash<int,MeshP> _meshes; QHash<int,CameraP> _cameras; //QHash<int,Light*> _lights; QSet<QString> _names; // PythonQtObjectPtr _context; object _pyMainModule; object _pyMainNamespace; public slots: void pythonStdOut(const QString &s) { std::cout << s.toStdString() << std::flush; } void pythonStdErr(const QString &s) { std::cout << s.toStdString() << std::flush; } }; // first I create the mapping, which I'm not sure is correct, trying to follow: http://misspent.wordpress.com/2009/09/27/how-to-write-boost-python-converte… struct SceneToPython { static PyObject* convert(Scene const& scene) { return boost::python::incref(boost::python::object(scene).ptr()); } }; // then I register it boost::python::to_python_converter<Scene,SceneToPython>(); // then I send it down from inside my Scene object try { object processFileFunc = _pyMainModule.attr("MeshImporter").attr("processFile"); processFileFunc(this, fileName); // seems to error here } catch (boost::python::error_already_set const &) { QString perror = parse_python_exception(); std::cerr << "Error in Python: " << perror.toStdString() << std::endl; } I'm not really sure what actually is wrong besides something being setup incorrectly. Do I need to make a python-to-C++ converter as well even if I'm not sending it back to C++? Or is my convert() function just improperly implemented? I wasn't sure how much I need to actually get it to map correctly. Thanks.

2 4

getting a list of strings from a static method
by Josh Stratton Aug. 30, 2011

Aug. 30, 2011

I'm very new to boost python and trying to figure out how to properly get a list of strings from a static method in my main namespace. I'm not sure if I need to extract the list from the object or if it's already a list. boost::python::object list = exec("Foo.extensions()", _pyMainNamespace); // where Foo.extensions() is a static method returning a list of strings My end goal is to have a QList of QStrings, but if I can somehow get them to a boost list of std::strings I can take it from there.

3 7

Re: [C++-sig] New Major-Release Boost.Python Development
by Hans Meine Aug. 29, 2011

Aug. 29, 2011

Am 26.08.2011 um 20:25 schrieb Jim Bosch: > - … the rvalue converters in particular don't seem to have been intended as part of the public API originally, and I think they're an important part of the library. Correct, great! > - Automatic conversions for newer boost libraries (Fusion, Pointer Container, and Filesystem are at the top of my list), and more for the STL and iostreams standard libraries. I'd like to integrate the indexing suite (v2) into Boost.Python proper. Probably makes sense, in particular the STL part is an often (understandibly) expected feature. > - Allow Boost.Python wrapped classes to inherit from Python classes. Yes yes yes! (list/dict inheritence in particular is /so/ useful.) > - Some limited degree of priority-based overload matching. Not sure how best to approach this one yet, though. A related goal (also template-related) is better support for error messages in the face of overloaded functions. In our VIGRA library [1], we have a lot of overloaded functions performing image analysis tasks on NumPy arrays. Currently, we face the following problems: - The automatically generated signatures in the docstrings are hard to read. Don’t know if there is a better way of presenting signatures of heavily templated code (improvements from the error messages of modern compilers or STLfilt come to my mind), or if there should simply be a hook for custom postprocessing. (Maybe just __doc__ being writeable from Python?) - The same goes for error messages when calling with the wrong arguments. - Furthermore, we have custom converters that check certain properties of the passed arrays, e.g. dimensionality, memory layout, or dtype. With overloading, all variants are tried in turn, but there’s no good way to "collect" error messages, and tell the user why no registered overload would match. (The C++ signatures don’t necessarily give the user enough information.) My feeling is that all this is strongly related to the features you already have in mind, but hopefully my notes help in steering this into an even better, more general direction. Oh, and there’s another missing feature: - Better support for introspection, e.g. by the ’inspect’ module or documentation tools. Looking forward to a "more accessible" BPL, Hans^ [1] http://hci.iwr.uni-heidelberg.de/vigra/doc/vigranumpy/index.html

1 0

question about implicit type conversion of vector to a custom type
by Grant Tang Aug. 18, 2011

Aug. 18, 2011

This is a question about using implicitly_convertible to convert vector to another custom class type. I already have boost python type conversion code to convert Python list/tuple to c++ vector, which works fine. There is another custom class EMObject, which is a thin wrapper to many builit-in type. It takes a built-in type like int, float, string, and vector as a single constructor argument and return type. So those built-in type can convert to and from EMObject implicitly. The functions in c++ which takes this EMObject as an argument are expose to Python. Now I need call these functions in Python with argument from Python list or tuple. Since I already convert python list/tuple to c++ vector, I just need declare implicit type conversion from vector to EMObject like following: implicitly_convertible<vector<float>, EMAN::EMObject>(); implicitly_convertible<vector<int>, EMAN::EMObject>(); implicitly_convertible<vector<std::string>, EMAN::EMObject>(); This seems a perfect solution to my question. But unfortunately I find out only the first one working, regardless which one is the first. Could anybody tell me why this happen? -- Grant

2 5

void* (void pointer) function arguments
by Holger Joukl Aug. 16, 2011

Aug. 16, 2011

Hi, I'm trying to wrap a C++-API that uses void* to pass around arbitrary, application-specific stuff. I am a bit unsure about how to work the void-pointers. A viable way seems to wrap the original API functions with thin wrappers that take a boost::python::object and hand the "raw" PyObject* into the original function: // Expose the method as taking any bp::object and hand the "raw" PyObject pointer to // the void-ptr-expecting API-function int Worker_destroy2_DestructionCallbackPtr_constVoidPtr( Worker* worker, DestructionCallback* cb, bp::object& closure) { return worker->destroy2(cb, closure.ptr()); } The information available is then retrieved by some callback function (which is pure virtual in the API and needs to be overridden in Python). Before calling into Python I then cast the void* back to a PyObject*, make a boost::python::object from it and invoke the Python override: class DestructionCallbackWrap : public DestructionCallback, public bp::wrapper<DestructionCallback> { virtual void callback(Worker* worker, void* closure) { std::cout << ">>> " << __PRETTY_FUNCTION__ << std::endl; // everything ending up here from Python side is a PyObject bp::handle<> handle(bp::borrowed(reinterpret_cast<PyObject*> (closure))); bp::object closureObj(handle); this->get_override("callback")(bp::ptr(worker), closureObj); std::cout << "<<< " << __PRETTY_FUNCTION__ << std::endl; } }; As I've tried to gather information about void* handling with boost.python back and forth without finding much (an FAQ entry seems to have existed once upon a time?) - is this a sane approach? Or is there some automagical void* or const void* handling in boost.python that I am totally missing? Any hint much appreciated, Holger P.S.: Here's a full minimal example for reference: // file void_ptr_cb.hpp // API to wrap class Worker; class DestructionCallback { public: DestructionCallback() {} virtual ~DestructionCallback() {} virtual void callback(Worker* worker, void* closure) = 0; }; class Worker { public: Worker() {} virtual ~Worker() {} virtual int destroy() { return 0; } int destroy2(DestructionCallback* cb, const void* closure=NULL) { std::cout << ">>> " << __PRETTY_FUNCTION__ << std::endl; cb->callback(this, const_cast<void*>(closure)); std::cout << "<<< " << __PRETTY_FUNCTION__ << std::endl; return 0; } private: Worker(const Worker& worker); }; // file wrap_void_ptr_cb.cpp #include <boost/python.hpp> #include <iostream> #include "void_ptr_cb.hpp" namespace bp = boost::python; // Helper classes needed for boost.python wrapping class DestructionCallbackWrap : public DestructionCallback, public bp::wrapper<DestructionCallback> { virtual void callback(Worker* worker, void* closure) { std::cout << ">>> " << __PRETTY_FUNCTION__ << std::endl; // everything ending up here from Python side is a PyObject bp::handle<> handle(bp::borrowed(reinterpret_cast<PyObject*> (closure))); bp::object closureObj(handle); this->get_override("callback")(bp::ptr(worker), closureObj); std::cout << "<<< " << __PRETTY_FUNCTION__ << std::endl; } }; class WorkerWrap : public Worker, public bp::wrapper<Worker> { public: virtual int destroy() { if (bp::override f = this->get_override("destroy")) return f(); // *note* return Worker::destroy(); } int default_destroy() { return this->Worker::destroy(); } }; // Expose the method as taking any bp::object and hand the "raw" PyObject pointer to // the void-ptr-expecting API-function int Worker_destroy2_DestructionCallbackPtr_constVoidPtr( Worker* worker, DestructionCallback* cb, bp::object& closure) { return worker->destroy2(cb, closure.ptr()); } BOOST_PYTHON_MODULE(void_ptr_cb) { bp::class_<DestructionCallbackWrap, boost::noncopyable> ("DestructionCallback", bp::init<>()) .def("callback", bp::pure_virtual(&DestructionCallback::callback)) ; bp::class_<WorkerWrap, boost::noncopyable>("Worker") .def("destroy", &Worker::destroy, &WorkerWrap::default_destroy) .def("destroy2", &Worker_destroy2_DestructionCallbackPtr_constVoidPtr, (bp::arg("cb"), bp::arg("closure")=bp::object())) ; }; # file Jamroot # Run with: # BOOST_ROOT=/var/tmp/lb54320/boost_apps/boost_1_46_1 BOOST_BUILD_PATH=/var/tmp/lb54320/boost_apps/boost_1_46_1 \ # /var/tmp/$USER/boost_apps/boost_1_46_1/bjam -d+2 toolset=gcc-4.5.1 \ # --build-dir=/var/tmp/$USER/boost_apps/boost_1_46_1/build/py2.7/boost/1.46.1/ cxxflags="-DDEBUG_HIGH \ # -DBOOST_PYTHON_TRACE_REGISTRY" link=shared threading=multi variant=release void_ptr_cb # # get the environment variable "USER" import os ; local _USER = [ os.environ USER ] ; #ECHO $(_USER) ; local _WORKDIR = /var/tmp/$(_USER)/boost_apps ; local _BOOST_MODULE = boost_1_46_1 ; local _BOOST_ROOT = $(_WORKDIR)/$(_BOOST_MODULE) ; local _BOOST_VERSION = 1.46.1 ; #ECHO $(_BOOST_ROOT) ; use-project boost : $(_BOOST_ROOT) ; # Set up the project-wide requirements that everything uses the # boost_python library from the project whose global ID is # /boost/python. project minimal_void_ptr_cb : requirements <library>/boost/python//boost_python <dll-path><variant>debug:$(_BOOST_ROOT)/stage/py2.7/boost/$ (_BOOST_VERSION)/debug/lib <dll-path><variant>release:$(_BOOST_ROOT)/stage/py2.7/boost/$ (_BOOST_VERSION)/lib ; python-extension void_ptr_cb : # sources + // Add all files here otherwise we get undefined symbol errors like wrap_void_ptr_cb.cpp : # requirements * : # default-build * : # usage-requirements * ; #!/apps/local/gcc/4.5.1/bin/python2.7 # file test.py import os import sys _USER = os.getenv("USER") EXPATH = ('/var/tmp/%s/boost_apps/boost_1_46_1/build/py2.7/boost/1.46.1/' 'minimal_void_ptr_cb/gcc-4.5.1/release/threading-multi' % (_USER)) sys.path.insert(1, EXPATH) import void_ptr_cb class MyDestructionCallback(void_ptr_cb.DestructionCallback): def callback(self, worker, closure): print "MyDestructionCallback.callback(%s, %s, %s)" % (self, worker, closure) class MyDestructionCallback2(void_ptr_cb.DestructionCallback): def callback(self, worker, closure): print "MyDestructionCallback.callback2(%s, %s, %s)" % (self, worker, closure) closure.do('what?') class SomeClass(object): def do(self, something=None): print "SomeClass.do(something=%s)" % repr(something) md = MyDestructionCallback() md.callback('worker', 'closure') print w = void_ptr_cb.Worker() w.destroy() w.destroy2(md, None) print some = SomeClass() w = void_ptr_cb.Worker() w.destroy() w.destroy2(md, some) some.do('else') print md2 = MyDestructionCallback2() w = void_ptr_cb.Worker() w.destroy() w.destroy2(md2, SomeClass()) Test run output: 0 holger@devel .../minimal_void_ptr_cb $ ./test.py MyDestructionCallback.callback(<__main__.MyDestructionCallback object at 0x2a6cc0>, worker, closure) >>> int Worker::destroy2(DestructionCallback*, const void*) >>> virtual void DestructionCallbackWrap::callback(Worker*, void*) MyDestructionCallback.callback(<__main__.MyDestructionCallback object at 0x2a6cc0>, <void_ptr_cb.Worker object at 0x2a6cf0>, None) <<< virtual void DestructionCallbackWrap::callback(Worker*, void*) <<< int Worker::destroy2(DestructionCallback*, const void*) >>> int Worker::destroy2(DestructionCallback*, const void*) >>> virtual void DestructionCallbackWrap::callback(Worker*, void*) MyDestructionCallback.callback(<__main__.MyDestructionCallback object at 0x2a6cc0>, <void_ptr_cb.Worker object at 0x2a6d20>, <__main__.SomeClass object at 0x2b7710>) <<< virtual void DestructionCallbackWrap::callback(Worker*, void*) <<< int Worker::destroy2(DestructionCallback*, const void*) SomeClass.do(something='else') >>> int Worker::destroy2(DestructionCallback*, const void*) >>> virtual void DestructionCallbackWrap::callback(Worker*, void*) MyDestructionCallback.callback2(<__main__.MyDestructionCallback2 object at 0x2a6cf0>, <void_ptr_cb.Worker object at 0x2a6d50>, <__main__.SomeClass object at 0x2b7730>) SomeClass.do(something='what?') <<< virtual void DestructionCallbackWrap::callback(Worker*, void*) <<< int Worker::destroy2(DestructionCallback*, const void*) Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart

2 2

automatic conversion from python unicode object to C++ std::string?
by John Reid Aug. 12, 2011

Aug. 12, 2011

I recently upgraded to ipython 0.11. In 0.11 sys.argv entries are of type unicode rather than string. All of my scripts that call into boost.python extensions fail as my exposed functions expect arguments of type std::string. Presumably I could recode all my functions to use std::wstring and everything would work. This would be a lot of work so for the moment, I'm encoding everything in python from unicode to strings. I was wondering if there is a simple way to tell my boost.python extensions to do this encoding automatically. Thanks, John.

2 1

arguments to c++ functions
by Josh Stratton Aug. 12, 2011

Aug. 12, 2011

Where can I find docs for sending arguments to C\C++ functions? I've followed the hello world example, which seems to automatically convert a python string to a char*, but I'm going to need more conversions later like how to handle a char**. Something like ["a","b","c"] doesn't seem to work.

2 1