Mailman 3 May 2008 - Cplusplus-sig

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

Bug and patch for boost.python with enable_shared_from_this
by Chad Austin March 26, 2009

March 26, 2009

Hi all, A month ago or so we discovered a bug in Boost.Python that manifests when using enable_shared_from_this. Here is a test case that demonstrates the bug: #include <boost/python.hpp> #include <boost/enable_shared_from_this.hpp> using namespace boost; using namespace boost::python; class Test; typedef shared_ptr<Test> TestPtr; class Test : public enable_shared_from_this<Test> { public: static TestPtr construct() { return TestPtr(new Test); } void act() { TestPtr kungFuDeathGrip(shared_from_this()); } void take(TestPtr t) { } }; void Export_test() { class_<Test, TestPtr, noncopyable>("Test") .def("construct", &Test::construct) .staticmethod("construct") .def("act", &Test::act) .def("take", &Test::take) ; } And here is the Python: x = Test.construct() x.take(x) x.act() The bug (as I understand it) is that the shared_ptr_from_python converter creates a new shared_ptr for the Test instance to pass it into C++. This new shared_ptr has a nop deleter, except that it keeps the Python object alive as long as the new shared_ptr is alive. The problem here is that creating a shared_ptr to an object of type T when T is enable_shared_from_this<T> resets the weak pointer inside of enable_shared_from_this<T>. (See shared_ptr's constructors for the details of the implementation.) A fix that passes the test above and has worked for us is to change shared_ptr's constructor to accept a dont_enable_shared_from_this argument and pass that in from the shared_ptr_from_python converter. The patch is attached (against boost 1.33, but the bug didn't look fixed in 1.34 either). Cheers, Chad p.s. I have seen other people with this problem as well. Googling for bad_weak_ptr turns up several results.

3 2

Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this
by Ralf W. Grosse-Kunstleve Dec. 23, 2008

Dec. 23, 2008

No news that I'm aware of. I'd be happy to check in patches, but someone else has to take the lead in communicating with Peter, and updating the unit tests. Ralf ----- Original Message ---- From: Edson Tadeu <e.tadeu(a)gmail.com> To: Development of Python/C++ integration <c++-sig(a)python.org> Sent: Thursday, February 28, 2008 11:45:32 AM Subject: Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this Any news on this issue? Will this patch get into Boost 1.35? Thanks, Edson On Wed, Feb 13, 2008 at 5:27 PM, Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> wrote: Hi Chad, Could you at least ask Peter Dimov if he thinks the dont_enable_shared_from_this patch could be generally useful? Maybe he's OK adding it, then it wouldn't be a big deal fixing Boost.Python, which would probably prevent a lot of confusion and lost time in the future. http://www.boost.org/people/peter_dimov.htm p-d-i-m-o-v-at-m-m-l-t-d-dot-n-e-t Ralf ----- Original Message ---- From: Chad Austin <chad(a)imvu.com> To: Development of Python/C++ integration <c++-sig(a)python.org> Sent: Monday, February 11, 2008 10:10:31 PM Subject: Re: [C++-sig] Bug and patch for boost.python with enable_shared_from_this There probably is a way to prevent boost.python from creating shared_ptrs with a null deleter like it does, but it would require far more knowledge than I have. :) I agree that it would be a better fix, though. On 2/11/08, Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> wrote: > > > > Thanks for the patch! I'd love to check this in for you, but for the > change in shared_ptr.hpp you'll need Peter Dimov's approval, and the > shared_ptr documentation would have to be updated. Also, your reproducer > should be turned into a unit test (in boost/libs/python/test). > > Is there any chance that the shared_ptr patch could somehow be avoided? > > Ralf > > > > ----- Original Message ---- > From: Chad Austin <chad(a)imvu.com> > To: c++-sig(a)python.org > Sent: Sunday, February 10, 2008 5:14:45 PM > Subject: [C++-sig] Bug and patch for boost.python with enable_shared_from_this > > Hi all, > > A month ago or so we discovered a bug in Boost.Python that manifests when using enable_shared_from_this. Here is a test case that demonstrates the bug: > > ... -----Inline Attachment Follows----- _______________________________________________ C++-sig mailing list C++-sig(a)python.org http://mail.python.org/mailman/listinfo/c++-sig

3 5

Base class defined in other header file not included in bp::bases<>
by Haridev, Meghana Sept. 14, 2008

Sept. 14, 2008

Hi Folks, I'm having some trouble generating boost-python wrapper code using pyplusplus for a derived class which has one of its base classes defined in another file. Simple scenario: mydir/ other.hpp: class baseB{ }; hierarchy.hpp: #include "other.hpp" class baseA{ }; class derivedC: public baseA, public baseB{ }; generate_code.py: import os from pyplusplus import module_builder mb = module_builder.module_builder_t( files=['hierarchy.hpp'] ) mb.build_code_creator( module_name='inherit' ) mb.code_creator.user_defined_directories.append( os.path.abspath('.') ) mb.write_module('boost_hierarchy.cpp') ------------------------------------------------------------------------ ------------------------------------------------- Generated code (boost_hierarchy.cpp) looks like this: // This file has been generated by pyplusplus. #include "boost/python.hpp" #include "hierarchy.hpp" namespace bp = boost::python; BOOST_PYTHON_MODULE(inherit){ bp::class_< baseA >( "baseA" ); bp::class_< derivedC, bp::bases< baseA > >( "derivedC" ); } How can I get pyplusplus to add 'baseB' to bp::bases<> for 'derivedC' class when 'baseB' class is defined in another file (present in the same directory or different directory)? When I move the definition of 'baseB' class to hierarchy.hpp, boost wrapper for 'derivedC' is correctly generated as: bp::class_< derivedC, bp::bases< baseA, baseB > >( "derivedC" ); Thanks, -Meghana.

3 9

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro June 3, 2008

June 3, 2008

The other day I released PyBindGen 0.8. Main news is that it features a new experimental header file scanner based on pygccxml (i.e., it's similar to py++ in scope, if not in maturity, but does not use boost.pythonunderneath). == What == PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write, and does not depend on any library or header files besides Python itself. == Where == https://launchpad.net/pybindgen/ == NEWS == - Support C++ instance attributes through getter/setter methods - Support functions as methods of C++ classes - Support the PyObject* type - Support unsigned int, C strings (char*) (from Mark Lee) - Add basic support for enum types - New experimental automatic module generator based on C/C++ header file scanner and annotations in comments, using pygccxml - Some bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

3 6

Incref / Decref Question
by Michael Wieher June 2, 2008

June 2, 2008

OK. Same problem for the last week. Not boost-related but rather Python Extension / C C++ fundamental issue. Please tell me if this looks OK or if its terribly, terribly stupid. mainfile.cpp ---------------------------------------------------------------------------------- myClass instanceOfMyClass; //----global data structure, accessible to all functions PyObject * function() { modifies, initliaizes, mallocs, etc. "instanceOfMyClass" } --------------------------------------------------------------------------------- That is the entire program. It executes fine, if I call it from within python.py script, but if I load the library.so into python interpreter >>> on exit, the interpreter seg-faults. Python 2.4.3 (#1, Mar 14 2007, 18:51:08) [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pymem >>> pymem.initData() 0 >>> Segmentation fault (checking log-files I can be sure that all functionality is OK, and it is executing correctly) this is being run on a CentOS platform. on Ubuntu, there is no seg-fault, and all else is the same. However, when Valgrind reviews the library (on both CentOS and Ubuntu) I get the same message: $>valgrind ./pymem.so ==5844== Process terminating with default action of signal 11 (SIGSEGV) ==5844== Bad permissions for mapped region at address 0x38156080 ==5844== at 0x1: (within /home/michael/proj/pydata/src/pymem.so) Now, I see this as a memory-address issue, which seems ridiculous to me, since the library.so is compiled with -fPIC, thus removing it from conflicting memory issues. So, my logical conclusion is that somehow, when this global-instance is modified, a reference-count is either incremented or decremented incorrectly, and that when the python interpreter exits, it seg-faults because it is either trying to clean up something that does not exist, or thinking something doesn't exist when it does. Any tips or ideas how to further debug this?

2 2

Boost.Python hello tutorial issue ?
by Aurélien MAIGNAN May 30, 2008

May 30, 2008

Hi I have just started to see wrapping C++/Python and choose to use boost.Python libs and further Py++ once mastered boost.Python. So I read their tutorial introduction : http://www.boost.org/doc/libs/1_35_0/libs/python/doc/tutorial/doc/html/inde… Ok so i install Boost and choose Python lib at setup and msvc 8.0 as compiler. (got 2005 express version). Boost has been installed in this abs path : C:\Program Files\boost\boost_1_35_0 Then i build the BJam tools usign the .bat isued with the Boost.Python package. I add the path in PATH Env Var. Next and prior to use the bjam command in the tutorial directory (where hello.cpp, hello.py and Jamroot files are) i modified the user-config.jam file according to the tutorial : This file is located in : C:\Program Files\boost\boost_1_35_0\tools\build\v2 here is the modifications : i added this : # Configure msvc (default version, searched in standard location # and PATH). using msvc : 8.0 ; and this : # Python configuration using python : 2.5 : C:/Python25 ; the rest of the file hasn't change at all. I doesn't touch the Jamroot file either ( **** note you can ignore the following it is another minor issue : **** ok it is not totally right : i wish to change the default use-project rule from : use-project boost : ../../../.. ; => default one to use-project boost : "$(BOOST_ROOT) ; where BOOST_ROOT is a user Env Var which store the path : C:\Program Files\boost\boost_1_35_0 But that doesn't build using bjam command : the following error happend : *** argument error * rule use-project ( id : where ) * called with: ( boost : ) * missing argument where so finally i changed it to use-project boost : "C:/Program Files/boost/boost_1_35_0" ; but i would rather use the Env Var if possible **** end of the minor issue description **** ) so ok I launched bjam and after a while it finnished building the lib files, and make me use the param *--preserve-test-targets* to bjam as indicated in the tutorial for the 1.35 version. --> But the problem is that usign hello.py doesn't work due to the fact the library weren't found by python. Indeed the libs are generated in this paths : C:\Program Files\boost\boost_1_35_0\bin.v2\libs\python\build\msvc-8.0\debug\threading-multi\boost_python-vc80-mt-gd-1_35.dll and : C:\Program Files\boost\boost_1_35_0\libs\python\example\tutorial\bin\msvc-8.0\debug\threading-multi\hello_ext.exp C:\Program Files\boost\boost_1_35_0\libs\python\example\tutorial\bin\msvc-8.0\debug\threading-multi\hello_ext.pyd C:\Program Files\boost\boost_1_35_0\libs\python\example\tutorial\bin\msvc-8.0\debug\threading-multi\hello_ext.lib There is no way Python are aware of this new Libs ! Maybe i wrong but i though that bjam automated the creation of the library for python and put the files where they need to be, A clue of this is the fact that we needed to add : # Python configuration using python : 2.5 : C:/Python25 ; in the user-config.jam file, so i guessed that bjam would create automatically the directory of the new module and put the libs there. In order to make it work i had to copying the hello_ext.lib file to the Python lib directory : C:\Python25\libs and i had to create manually this directory : C:\Python25\Lib\site-packages\hello_ext In this directory I copied our libs files : hello_ext.exp hello_ext.pyd boost_python-vc80-mt-gd-1_35.dll And create also another file : __init__.py that contain the following : import sys sys.path.append('..\..') # this brings in the DLL (pyd) from hello_ext import * And after this the new module was known from python and hello.py work ! to sum up : does bjam automatically generate the module directory and plant in the lib needed (and the __init__.py file) as I though it was Or does i need to do this manually (and create another script/make like file to automatize this) ? Note 1 : this not my idea, in order to resolve my issue i found this on the web wich is a similar case : http://mail.python.org/pipermail/c++-sig/2007-November/013059.html /Note 1 Note 2 : in this thread one advise to modified the Jamroot file and add this : # Declare a Python extension python-extension _**name of ext goes here** # Declare a Python extension : **name of CPP with wrapper class(es) goes here** # Source : <include>**your includes go here** <define>**your defines go here** : <library-path>**your lib path goes here**<library-path>$(BOOST_ROOT)/stage/lib ; so i putted this : # Declare a Python extension python-extension hello_ext # Declare a Python extension : hello.cpp # Source #: <include>**your includes go here** # <define>**your defines go here** #: <library-path>**your lib path goes here** <library-path>$(BOOST_ROOT)/stage/lib ; But bjam doesn't work anymore (some error that imply some core .jam file that is not from me) so I removed this and return to the the default vesion : # Declare the three extension modules. You can specify multiple # source files after the colon separated by spaces. python-extension hello_ext : hello.cpp ; /Note 2 THANKs for considering this post, a little long ^^ and excuse my english ;) MAIGNAN Aurélien

1 0

Re: [C++-sig] projects using boost::python
by Ralf W. Grosse-Kunstleve May 29, 2008

May 29, 2008

I've checked this in to the boost svn trunk (revision 45920). Thanks for the contribution! Sorry it took so long to get to this. Ralf ----- Original Message ---- From: Michael Brickenstein <brickenstein(a)mfo.de> To: c++-sig(a)python.org Cc: Alexander Dreyer <alexander.dreyer(a)itwm.fraunhofer.de> Sent: Sunday, April 20, 2008 11:25:26 PM Subject: [C++-sig] projects using boost::python Hi! I have an additional project using BOOST::python. PolyBoRi: http://polybori.sourceforge.net/ The core of PolyBoRi is a C++ library, which provides high-level data types for Boolean polynomials and monomials, exponent vectors, as well as for the underlying polynomial rings and subsets of the powerset of the Boolean variables. As a unique approach, binary decision diagrams are used as internal storage type for polynomial structures. On top of this C++-library we provide a Python interface. This allows parsing of complex polynomial systems, as well as sophisticated and extendable strategies for Gröbner basis computation. Boost::python has helped us to create this interface in a very clean way. Best regards, Michael Brickenstein _______________________________________________ C++-sig mailing list C++-sig(a)python.org http://mail.python.org/mailman/listinfo/c++-sig

1 0

Re: [C++-sig] object.attr(object& attrname) proposa
by Ralf W. Grosse-Kunstleve May 29, 2008

May 29, 2008

Hi Koichi, I've checked in your patches to the boost svn trunk, revision 45918. Ralf ----- Original Message ---- From: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> To: Development of Python/C++ integration <c++-sig(a)python.org> Sent: Tuesday, May 27, 2008 11:36:48 AM Subject: Re: [C++-sig] object.attr(object& attrname) proposa Hi Koichi, I got the patches, thanks! The doc changes look good to me. I'll only change the revision and copyright date. I manually tested compilation with gcc 4.1 and EDG 245. It will take a day to try them in our local multi-platform build system. Ralf

1 0