Mailman 3 May 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

CMake and getting starting with boost.python
by Braddock Gaskill Aug. 5, 2011

Aug. 5, 2011

Yesterday I became a boost.python user, after years of heavy SWIG usage. I would have started using boost.python years ago except for the bjam learning curve. I spent hours TRYING on multiple occasions, but got lost every time trying to get the page one example to build with bjam. Here is how to build the "greet" example with a four line CMake file: cat >>CMakeLists.txt <<EOF LINK_LIBRARIES(boost_python) INCLUDE_DIRECTORIES("/usr/include/python2.5") LINK_DIRECTORIES("/usr/lib/python2.5") # Not needed? ADD_LIBRARY(hello SHARED hello.cpp) EOF You WILL have to `mv libhello.so hello.so` after building. Works for me under Ubuntu Linux 6.10 after apt-get install cmake python2.5-dev boost-python-dev cmake make mv libhello.so hello.so ipython In [1]: import hello In [2]: hello.greet() Out[2]: 'hello, world' Boost.Python has been a joy to learn and use since I got past bjam. I had a moderately large API wrapped in just my first couple hours of learning (less time than I spent messing with bjam). Any additional advice for using CMake to build boost.python? Braddock Gaskill

4 4

How to import a boost::python dll in windows?
by ichijoji Aug. 5, 2011

Aug. 5, 2011

I'm trying to port some research code that uses boost::python to expose a library to python to windows, but I'm having trouble importing the dll into python. I'm compiling using msvc 2005 and using python 2.5, but when I try to import the module I get this: Traceback (most recent call last): File "main.py", line 1, in <module> import object File "c:\code\sge\code\scripts\object.py", line 1, in <module> import sge ImportError: No module named sge My module is named sge and I'm compiling to sge.dll. Is there some obvious reason why python wouldn't be able to find my dll? When I compile on linux into an so this code works fine. -- View this message in context: http://www.nabble.com/How-to-import-a-boost%3A%3Apython-dll-in-windows--tf3… Sent from the Python - c++-sig mailing list archive at Nabble.com.

4 4

Miscellaneous Boost.Python Utilities
by Jim Bosch July 6, 2011

July 6, 2011

In the hope that others might find them useful, and perhaps contribute some of their own, I've posted a collection of miscellaneous Boost.Python extensions I've been using at the Boost sandbox: http://svn.boost.org/svn/boost/sandbox/python_extensions Features include: - Conversions between STL containers and Boost.Range iterator ranges and Python builtins like list, tuple, and dict. - Conversions between Boost.Fusion sequences and Python tuples. - A third solution to the const shared_ptr problem (see http://language-binding.net/pyplusplus/troubleshooting_guide/shared_ptr/sha…) that isn't evil (I don't think) and doesn't involve changing the Boost.Python library itself - it simply doesn't use register_ptr_to_python to register the conversion. More info is available in the README file. Also, I'm sure many of the regulars on this list have their own similar extensions, and I'd love to see them collected in one place. If you'd like to add your collection to mine, or have a suggestion for some other place I should put my collection, please let me know. I would like to limit this collection to simple things that don't depend on non-Boost libraries, however. Jim Bosch

2 1

BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS default args core dump
by Holger Joukl June 13, 2011

June 13, 2011

Hi, this is basically a re-post of a problem I posted 5 weeks ago, on which there's been no echo whatsoever. Now, I'm unsure if this is because I posted on April 1st, nobody has ever seen this problem on his platform, nobody ever uses the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro this way or I'm doing s.th. blatantly stupid. What nags me is that I don't think I'm doing something exotic and, moreover, that I see different behaviour depending on execution context, i.e. run in a script with or without previous method call(s) vs interactive interpreter session. I'll try to summarize the problem a bit more(see below for a link to the original post for reference): I'm having trouble wrapping a very simple member function with Boost.Python using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro, getting a segmentation fault (sometimes a bus error). I run into the problem both with Boost 1.44.0 and 1.46.1, running on Solaris 10/Sparc using gcc 4.5.1 and Python 2.7.1. I can reproducibly avoid the segfault and see an (expected) exception iff the code is * not run in an interactive interpreter session and * if there is a boost-induced exception succesfully raised before the critical call (which I don't understand at all). ##### wrapped class // file default_arguments_class.hpp class DefaultArgs { public: // member functions int foo(int arg1=100, int arg2=10) { return arg1 - arg2; }; }; ##### wrapper code // file default_arguments_wrap.cpp #include <boost/python.hpp> #include "default_arguments_class.hpp" namespace bp = boost::python; BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(DefaultArgs_foo_overloads, DefaultArgs::foo, 0, 2) BOOST_PYTHON_MODULE(defaultargs) { bp::class_<DefaultArgs>("DefaultArgs", "DefaultArgs class docstring") .def("foo_macro_a2", &DefaultArgs::foo, DefaultArgs_foo_overloads((bp::arg("arg2")))) ; }; ##### In use in interactive interpreter session: >>> import defaultargs >>> d = defaultargs.DefaultArgs() >>> >>> try: ... print "d.foo_macro_a2(1, 2, 3):", d.foo_macro_a2(1, 2, 3) ... except Exception, e: ... print e ... d.foo_macro_a2(1, 2, 3): Python argument types in DefaultArgs.foo_macro_a2(DefaultArgs, int, int, int) did not match C++ signature: foo_macro_a2(DefaultArgs {lvalue}) foo_macro_a2(DefaultArgs {lvalue}, int) foo_macro_a2(DefaultArgs {lvalue}, int, int arg2) >>> print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60) Bus Error (core dumped) ##### In use within a script: $ cat foo.py import defaultargs d = defaultargs.DefaultArgs() try: print "d.foo_macro_a2(1, 2, 3):", d.foo_macro_a2(1, 2, 3) except Exception, e: print e print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60) $ PYTHONPATH=/var/tmp/boost_apps/boost/build/boost_1_46_1/py2.7/minimal/gcc-4.5.1 /debug/ /apps/local/gcc/4.5.1/bin/python2.7 foo.py d.foo_macro_a2(1, 2, 3): Python argument types in DefaultArgs.foo_macro_a2(DefaultArgs, int, int, int) did not match C++ signature: foo_macro_a2(DefaultArgs {lvalue}) foo_macro_a2(DefaultArgs {lvalue}, int) foo_macro_a2(DefaultArgs {lvalue}, int, int arg2) d.foo_macro_a2(arg2=60): Traceback (most recent call last): File "/ae/data/tmp/hjoukl/foo.py", line 9, in <module> print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60) Boost.Python.ArgumentError: Python argument types in DefaultArgs.foo_macro_a2(DefaultArgs) did not match C++ signature: foo_macro_a2(DefaultArgs {lvalue}) foo_macro_a2(DefaultArgs {lvalue}, int) foo_macro_a2(DefaultArgs {lvalue}, int, int arg2) My original post complete with bjam etc. can be found here: http://article.gmane.org/gmane.comp.python.c%2B%2B/15163 Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart

4 5

boost::python - how to pass by reference/pointer to python overriden class functions
by Jay Riley May 25, 2011

May 25, 2011

Hi all, Hopefully this is the correct way to post a question, If not I apologize as I haven't used mailing lists before. Anyways, here is my problem: I have some class functions that takes in parameters by pointer. However, when I expose and override this class/these functions in boost::python, any changes I make to the parameters are not reflected back to the original, meaning it isn't being passed by pointer as I expect. I previously had them as pass-by-reference, but the same problem still occurred. For an example of what I mean, here's some of my code with unimportant functions and details omitted. class StatusEffect { public: virtual void TickCharacter(Character::BaseCharacter* character, Battles::BattleField *field, int ticks = 1); } //In my Scripting Code header file struct StatusEffectWrapper : Game::StatusEffects::StatusEffect { virtual void TickCharacter(Game::Character::BaseCharacter* character, Game::Battles::BattleField *field, int ticks = 1); virtual void TickCharacterDefault(Game::Character::BaseCharacter* character, Game::Battles::BattleField *field, int ticks = 1); } //In the actual scripting code void StatusEffectWrapper::TickCharacter(Game::Character::BaseCharacter* character, Game::Battles::BattleField *field, int ticks) { call_method<void>(self, "TickCharacter", character, field, ticks); } void StatusEffectWrapper::TickCharacterDefault(Game::Character::BaseCharacter* character, Game::Battles::BattleField *field, int ticks) { this->StatusEffect::TickCharacter(character, field, ticks); } class_<StatusEffects::StatusEffect, boost::shared_ptr<StatusEffectWrapper> >("StatusEffect") .def("TickCharacter", &StatusEffect::TickCharacter, &StatusEffectWrapper::TickCharacterDefault) and finally in my Python file, I try and do something like this class StatCreepEffect(StatusEffect): def __init__(self, name, stat_, rate_, descript, uid, turns, prior, canrefresh, poseffect, cats, conds, flgs, sep, pers): StatusEffect.__init__(self, name, descript, uid, turns, prior, canrefresh, poseffect, cats, conds, flgs, sep, pers) self.rate = rate_ self.stat = stat_ def TickCharacter(self, Character, Field, Ticks): if (self.stat == Stat.HP): Character.SetHP(int(round(Character.GetHP() + Character.GetInBattleStat(self.stat) * self.rate))) print("HP Regenerated on character " + Character.GetName() + " New HP: " + str(Character.GetHP())) elif (self.stat == Stat.MP): Character.SetMP(int(round(Character.GetMP() + Character.GetInBattleStat(self.stat) * self.rate))) elif (self.stat == Stat.SP): Character.SetSP(int(round(Character.SetSP() + Character.GetInBattleStat(self.stat) * self.rate))) Regen = StatCreepEffect("Regen", Stat.HP, 0.05, "Regenerates a small amount of HP every turn", PrimaryEngine.GetUID(), 14, 0, True, True, StatusCategories.SC_Regen, 0, StatusFlags.TickEffect, True, StatusPersistence.SP_Timer_Cure) SELibrary.AddPythonEffect(Regen); If it matters, the AddPythonEffect is defined as follows: void StatusEffectsLibrary::AddPythonEffect(boost::shared_ptr<StatusEffect> effect) { if (effect.get() != nullptr) { NameToSEMap[effect->GetName()] = effect; IDToSEMap[effect->GetUID()] = effect; } } I call the effect like so in my C++ code StatusEffect* regen = game.GetSELibrary().GetStatusEffect(std::string("Regen")); //This simply does a lookup to the NameToSEMap inside the StatusEffectLibrary and does a .get() on the shared_ptr while(character->GetHP() < 600) { regen->TickCharacter(character, field, 1); std::cout << "Character HP: " << character->GetHP() << std::endl; } The script compiles and the effect is added correctly. The print line in the python script prints the correct value. The character object starts with 400 HP and the print line outputs 430. However, the std::cout line in my C++ code always outputs 400, meaning the extra 30 HP added by the script is not reflected back in the original object. For clarity, here's the console output from the above C++ code fragment: HP Regenerated on character Arian New HP: 430 Character HP: 400 I've tried adding boost::non_copyable to the class wrapper but to no effect. I've replaced my pointers with pass by reference to no effect. I've switched between shared_ptr, auto_ptr, and a straight reference for the HeldType to no effect. I can confirm using shared_ptrs over regular pointers in the function does work, but I'd prefer to avoid using them unless there really isn't another way as it would be tedious and time consuming to do so. Can someone tell me how to get the behaviour I expect? To be clear, I'm not looking for the python script to take ownership of any of the parameters, nor will I be returning anything. I just want the changes made in the function to be reflected back to the passed in object. Thanks

3 3

compiling python extensions to work for multiple versions of python
by Karl Kuehn May 25, 2011

May 25, 2011

I am working on compiling a python extension (specifically libtorrent-rasterbar), and would like to wind up with a single executable that I can use on multiple versions of MacOS X (specifically 10.5 and 10.6) without having to force the version of python used on each version (10.5 has 2.5, 10.6 has 2.5 and 2.6, but defaults to 2.6). When I compile using bjam: bjam debug-symbols=on dht-support=on boost=source architecture=combined toolset=darwin address-model=32_64 (with BOOST_BUILD and BOOST_ROOT set approrpiatly) I get a working binary (libtorrent.so) that works great on the platform I am working on, and is a "Universal binary" (ppc/ppc64/i386/x86_64), but when I try to "import" it on the other platform without specifying the version of python I get: Fatal Python error: Interpreter not initialized (version mismatch?) Abort trap Forcing the version of python (so forcing 10.6 to use 2.5) allows the module to be imported and used without problem. After an evening of searching around on mailing lists I almost came to the conclusion that it is not possible to compile python modules that work with multiple versions of python... except that I have built a version of the MySQL module that does exactly that. It runs without complaint on 10.5 (ppc and intel), and 10.6 (intel only), on both python 2.5 and 2.6. So my questions: 1) Is this a limitation of Boost.Python? A trick from MySQL that I can emulate? Am I missing something obvious? I have tried a large number of variations in build commands using combinations of the following: link=shared --layout=versioned --enable-framework --build-type=complete link=shared,static macosx-version=10.5 macosx-version-min=10.5 2) If this is not a possibility with Boost.Python-built modules, what would be the best work-around. I can probably build separate modules with the target python version in their names, and play games with importing them. But that is obviously a less-desired version of things, since it would require: a) multiple 60Meg binaries, and b) having 2 at the moment, and presumably a third when 10.7 ships. Note: I am using Boost 1.46.1 and libtorrent-rasterbar 0.15.6, the latest releases of both as of a couple of days ago. -- Karl Kuehn larkost(a)softhome.net

2 2

[Py++] Bug in balanced file writer
by Kirill Lapshin May 22, 2011

May 22, 2011

Hi Roman/all, Today I've found what I believe a bug in balanced file writer. Suppose you have 24 class_creators and trying to split them into 10 buckets. What it currently does is: - how many creators per bucket? 24/10 = 2. uhm, ok. - split_sequence of 24 creators by 2, this returns 12 buckets - is actual number of buckets greater than requested? yes 12>10. Ok lets peel of last bucket and merge it into one before last. Now we've got 11 buckets, and we happily write 11 files... but user asked for 10. Here is a patch to fix it, it simply distributes class creators over buckets in round robin. Any chance to get it applied? --- balanced_files.py.orig 2011-05-19 15:58:24.000000000 +0800 +++ balanced_files.py 2011-05-19 16:44:12.000000000 +0800 @@ -13,7 +13,6 @@ from pygccxml import declarations from pyplusplus import decl_wrappers from pyplusplus import code_creators -from pyplusplus.utils import split_sequence #TODO: to add namespace_alias_t classes class balanced_files_t(multiple_files.multiple_files_t): @@ -52,10 +51,11 @@ class_creators = filter( lambda cc: not cc.declaration.already_exposed , class_creators ) - buckets = split_sequence(class_creators, len(class_creators)/self.number_of_buckets ) - if len(buckets) > self.number_of_buckets: - buckets[len(buckets)-2] += buckets[len(buckets)-1] - buckets = buckets[:len(buckets)-1] + buckets = [[]] * self.number_of_buckets + i = 0 + for c in class_creators: + buckets[i].append( c ) + i = (i+1) % self.number_of_buckets for index, bucket in enumerate( buckets ):

2 2

[Py++] shared_ptr registration
by Kirill Lapshin May 21, 2011

May 21, 2011

Hello Roman/All, I used Py++ before, and was very happy with it, now I'm working on a new project and trying to introduce Py++ here as well. Naturally I decided to get a latest version (was using a bit outdated version before), and noticed that there was no release in quite some time, so here is a first question: - I've seen a message on this list from Mar 25 saying that project is alive and kicking -- that was quite a relief. Any plans for new release? I've ran into some problems with 1.0, as in Py++ failed with traceback during code generation, so decided to give latest trunk a go (using r1856 atm). This one worked quite a bit better, but I'm running into some weirdness around shared_ptr registration. The codebase I'm wrapping uses them heavily, and for whatever reason some of them get registered, while others not, and any attempt to for example call a function returning such unregistered shared_ptr unsurprisingly results in "No to_python (by-value) converter" error. I've reproduced this problem on small example. Before we go there though I'd like to formulate another question: - How shared_ptr registration supposed to work? Is client expected to manually add calls to bp::register_ptr_to_python, or is it something Py++ supposed to do automagically? Is there any way to force Py++ to add such registration? Here is a promised example: ----------------- #include <boost/shared_ptr.hpp> class foo1; typedef boost::shared_ptr<foo1> foo1_ptr_t; class foo1 { public: foo1_ptr_t parent() const{return foo1_ptr_t(new foo1);} }; class foo2; typedef boost::shared_ptr<const foo2> foo2_ptr_t; class foo2 { public: virtual ~foo2() {} foo2_ptr_t parent() const{return foo2_ptr_t(new foo2);} }; ------------------ As you can see there are two slightly different cases. The only difference is that foo2_ptr_t is a pointer to const foo2. However from Python I can only call foo1::parent, foo2::parent fails with "No to_python (by-value) converter". The code generated by Py++ is: ------------------ { //::foo1 typedef bp::class_< foo1 > foo1_exposer_t; foo1_exposer_t foo1_exposer = foo1_exposer_t( "foo1" ); bp::scope foo1_scope( foo1_exposer ); { //::foo1::parent typedef ::foo1_ptr_t ( ::foo1::*parent_function_type )( ) const; foo1_exposer.def( "parent" , parent_function_type( &::foo1::parent ) ); } bp::register_ptr_to_python< boost::shared_ptr< foo1 > >(); } bp::class_< foo2 >( "foo2" ) .def( "parent" , (::foo2_ptr_t ( ::foo2::* )( ) const)( &::foo2::parent ) ); ------------------ Why code is so different for these two cases? Why foo2 doesn't have bp::register_to_python? During code generation I get W1040 warnings saying that "shared_ptr<fooX> The declaration is unexposed, but there are other declartions which refer to it". I get them for both foo1 and foo2, even though Py++ did expose shared_ptr<foo1>. Why the warning is generated for foo1? While we are on warnings topic, another thing I've noticed. Suppose I have function referring std::vector<std::string> >, Py++ will happily export this vector of strings but will give it ugly name. If I want to rename it, I can explicitly find declaration .include() and .rename() it. In this case however I start getting some weird warnings: WARNING: std::basic_string<char,std::char_traits<char>,std::allocator<char> > * std::vector<std::string, std::allocator<std::string> >::data() [member function] > compilation error W1050: The function returns "std::basic_string<char,std::char_traits<char>,std::allocator<char> > *" type. You have to specify a > call policies.Be sure to take a look on `Py++` defined call policies WARNING: std::basic_string<char,std::char_traits<char>,std::allocator<char> > const * std::vector<std::string, std::allocator<std::string> >::data() const [member function] > compilation error W1050: The function returns "std::basic_string<char,std::char_traits<char>,std::allocator<char> > const *" type. You have to specify > a call policies.Be sure to take a look on `Py++` defined call policies Regards, Kirill

2 5

Re: [C++-sig] boost.python call_method+thread => wrong exceptionhandling?
by Nox 7Bitfaster May 21, 2011

May 21, 2011

I removed the windows.h include and placed the boost/python.hpp include at the first place but the behavior did not change.

1 0