Mailman 3 February 2013 - 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

sendkeys method
by sam Sept. 30, 2013

Sept. 30, 2013

Hello, Is there away(method) in C/C++ programming that make the software think that someone pressed the OK button, similar to sendkeys in VBS (WshShell.SendKeys ("{Enter}")) Thank you, Sam

4 5

CallPolicy for operators
by Michael Wild March 15, 2013

March 15, 2013

Hi all Is there a way to apply a CallPolicy to operator definitions? In particular, I'm interested in the inplace operators (+=, -=, *=, /= and friends). To give a bit more context: The library I'm trying to wrap exposes some static const objects. So far, I have been able to wrap modifying function by having a registration facility for these static const objects and a custom CallPolicy that raises an AttributError when one tries to modify one of the registered objects. One option I see is to directly define __iadd__ etc. instead of using the built-in convenience operators. However, I'm not sure whether that has unintended side-effects. I haven't completely understood the operators implementation in bp, but it looks fairly involved. Thanks Michael

3 3

[Boost.Python] Patch to add post-initialization hooks for value_holder
by Aaron Wishnick March 14, 2013

March 14, 2013

Hello, We are using Boost.Python to embed a Python interpreter. We have some existing classes whose ownership semantics don't play very nicely with being instantiated from Python, which we really want to do. It's unfortunately not possible for us to improve this, due to a large existing codebase; we don't want to harm our existing projects in the process of adding Python support. However, what we can do, is tell these instances when they have been instantiated from within Python, and then everything will work great. We were able to use no_init and make_constructor to use a custom constructor that would construct the object, and then call an extra function. However, we wanted to make this happen globally for all classes that inherit from a base class that we have, since requiring people to remember to do this every time a new class is exposed is likely to lead to bugs. I was able to accomplish this by having value_holder call a function after constructing its held object. The function, boost_python_value_holder_post_init(), is called with a pointer to the newly constructed object, without namespace qualification (to enable ADL), and the default implementation takes a bool as its parameter, in order to be the worst possible candidate in overload resolution. This allows us to implement void boost_python_value_holder_post_init(BaseClass*) within the same namespace that BaseClass is defined in, and then our version of the function will get called any time that a subclass of BaseClass is constructed from within Boost.Python. I'm attaching my patch below. I would really appreciate any feedback as to whether this general concept is something Boost.Python would consider merging in, and if so, if there's anything I can do in terms of how my patch is implemented in order to make it more suitable. I'd also be happy (and interested!) to discuss any alternate ways to accomplish what I want. To reiterate, it's really important to us that we be able to do this for all subclasses of a certain class, automatically, and this was the only apparent mechanism to me. The patch follows below. Thanks for your time! Best regards, Aaron Wishnick --- a/boost/python/object/value_holder.hpp +++ b/boost/python/object/value_holder.hpp @@ -33,6 +33,17 @@ namespace boost { namespace python { namespace objects { +// After a value_holder initializes its held object, this +// function will be called with a pointer to the held object. +// Note that it will be called with ADL, so you should define +// it in the same namespace as that of the object you want to +// have this called on. This function takes a bool as a catchall +// because pointer to bool conversion is the "worst" standard +// conversion, and any other custom overload written by a client +// should be called instead. +inline void boost_python_value_holder_post_init(bool) { +} + # if BOOST_WORKAROUND(__GNUC__, == 2) # define BOOST_PYTHON_UNFORWARD_LOCAL(z, n, _) BOOST_PP_COMMA_IF(n) (typename unforward<A##n>::type)objects::do_unforward(a##n,0) # else @@ -137,6 +148,7 @@ void* value_holder_back_reference<Value,Held>::holds( BOOST_PP_REPEAT_1ST(N, BOOST_PYTHON_UNFORWARD_LOCAL, nil) ) { + boost_python_value_holder_post_init(&m_held); python::detail::initialize_wrapper(self, boost::addressof(this->m_held)); }

2 1

Check if object is of type Boost.Python.enum
by Davidson, Josh Feb. 19, 2013

Feb. 19, 2013

I'm trying to find a clean way to test if an object in Python is of type Boost.Python.enum: >>> myEnum.__bases__ (<type 'Boost.Python.enum'>,) The easiest way would probably just be isinstance, but I can't seem to find a way to import Boost.Python.enum. Anyone know how to import the necessary module or have a better idea? For what I'm doing, I can't simply rely on duck typing. Thanks, Josh

2 1

GC error due to stl_input_iterator
by Wichert Akkerman Feb. 7, 2013

Feb. 7, 2013

I am running into some unexpected errors when using stl_input_iterator. I have a fairly simple converter registered to convert an iterable list of values (custom enum) to a unordered_set. The code looks like this: struct advicetype_set_from_python { advicetype_set_from_python() { converter::registry::push_back(&convertible, &construct, type_id<std::unordered_set<AdviceType>>()); } static void* convertible(PyObject *obj) { if (obj==Py_None) return obj; PyObject* iter = PyObject_GetIter(obj); if (iter==NULL) { throw_error_already_set(); return 0; } Py_DECREF(iter); return obj; } static void construct(PyObject* obj, converter::rvalue_from_python_stage1_data *data) { std::unordered_set<AdviceType> result; if (obj!=Py_None) { object o = object(handle<>(obj)); stl_input_iterator<AdviceType> begin(o), end; result.insert(begin, end); } void *storage = ((converter::rvalue_from_python_storage<std::unordered_set<AdviceType>>*)data)->storage.bytes; new (storage) std::unordered_set<AdviceType>(result); data->convertible = storage; } }; When using this code we were seeing segfaults due to what appears to be invalid reference counters. Since I suspected a problem in this convertor I wrote a simple test which triggers the converter a number of times: for i in range(5000): my_func({AdviceType.one, AdviceType.two}) Which had an interesting result: the tests immediately aborted with a "Fatal Python error: GC object already tracked" error. Commenting out the contents of the if-statement in construct() made the problem go away, which makes we think the bug is in the stl_input_iterator used there. Am I doing something wrong here, or is this a boost bug? FWIW I am seeing this under both Boost 1.48 on an Ubuntu 12.04 machine and Boost 1.52 on OSX 10.8. I am not sure if this is related, but clang outputs an interesting warning for the in-place new that is required here: warning: cast from 'converter::rvalue_from_python_stage1_data *' to 'converter::rvalue_from_python_storage<std::unordered_set<AdviceType> > *' increases required alignment from 8 to 16 [-Wcast-align] void *storage = ((converter::rvalue_from_python_storage<std::unordered_set<AdviceType>>*)data)->storage.bytes; Wichert.

1 1