Mailman 3 September 2002 - Cplusplus-sig

compilation problems with mingw v2.0
by gideon may Oct. 14, 2002

Oct. 14, 2002

Hi, Has anyone succeeded in compiling bpl v1 or v2 with the current mingw compiler (v2.0) under windows ? This version is based on gcc 3.2. The rest of the boost libraries compile cleanly. When I try to compile bpl v2 I get the following message : ...found 585 targets... ...updating 24 targets... mingw-C++-action ..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj In file included from src/list.cpp:6: C:/cvs_rep/boost/boost/python/list.hpp:17: declaration does not declare anything C:/cvs_rep/boost/boost/python/list.hpp:17: parse error before `)' token src/list.cpp:19: parse error before `)' token src/list.cpp:23: parse error before `)' token c:\SDKs\MinGW\bin\g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE -g -O0 -fno-inline -I"..\..\libs\python" -isystem "C:\cvs_rep\boost" -isystem "c:\Python22\include" -isystem "c:\SDKs\MinGW\inc lude" -o "..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj" "src\list.cpp" ...failed mingw-C++-action ..\..\libs\python\bin\bpl.dll\mingw\debug\runtime-link-dynamic\list.obj... My environment : Win2K Python 2.2.1 (ActiveState) Latest CVS update of Boost COMSPEC=C:\WINNT\system32\cmd.exe MINGW_ROOT_DIRECTORY=c:\SDKs\MinGW NUMBER_OF_PROCESSORS=1 OS=Windows_NT PYTHON_ROOT=c:\Python22 PYTHON_VERSION=2.2 SYSTEMROOT=C:\WINNT TMP=/cygdrive/c/DOCUME~1/gideon/LOCALS~1/Temp WINDIR=C:\WINNT bjam command : bjam -sTOOLS=mingw ciao, gideon

4 6

char '\0' -> "\0" or ""?
by Ralf W. Grosse-Kunstleve Oct. 1, 2002

Oct. 1, 2002

Consider char foo() { return '\0'; } def("foo", foo); Python with Boost.Python V1: foo() == "" Python with Boost.Python V2: foo() == "\0" Is this difference intentional? I'd prefer the V1 result. Opinions? Thanks, Ralf __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

Anyone tried BGL with BoostPython 2 yet?
by Robert Oschler Oct. 1, 2002

Oct. 1, 2002

Anybody been adventurous enough to try the Boost Graph Library with Boost Python v 2? Just wondering what I might be getting myself into (difficulty-wise). thx

3 6

stage rule and version in .so name
by Leonardo Rochael Almeida Sept. 30, 2002

Sept. 30, 2002

Hi, I'm trying to make it easier to test stuff I built with boost python, so I created some stage rules to gather all stuff I need so that I could, say, just copy them over to /usr/local and have them work. For instance, I added the following snipped to boost/libs/python/example/Jamfile: stage distrib/lib/python$(PYTHON_VERSION)/site-packages : # extensions <pyd>getting_started1 ; stage distrib/lib : # needed libraries <dll>../build/boost_python ; This same Jamfile has this extension rule: # Declare a Python extension called getting_started1 extension getting_started1 : # sources getting_started1.cpp # dependencies <dll>../build/boost_python ; The stage rules above generate the following directory tree: distrib/ distrib/lib distrib/lib/python2.1 distrib/lib/python2.1/site-packages distrib/lib/python2.1/site-packages/getting_started1.so distrib/lib/libboost_python.so which is mostly what I expected, except that: $ ldd distrib/lib/python2.1/site-packages/getting_started1.so libboost_python.so.1.29.0 => not found libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40021000) libm.so.6 => /lib/libm.so.6 (0x4006a000) libc.so.6 => /lib/libc.so.6 (0x4008b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) The "not found" above is not important, what's important is that the same <dll>../build/boost_python, when in the "stage" rule, generates a libboost_python.so, but in the "extension" rule, makes the extesion depend on libboost_python.so.1.29.0 which I think is a bug. I believe the correct behaviour would be for the "stage" rule to copy/generate the same thing that the extension rule make getting_started1.so depend on, that is, to generate a libboost_python.so.1.29.0 in the distrib/lib directory. But I have no idea how to go about it. Any thoughts? -- Ideas don't stay in some minds very long because they don't like solitary confinement.

2 4

Container support
by Achim Domma Sept. 30, 2002

Sept. 30, 2002

Hi Dave, what's the current status of container support (something like the functionality implemented in Ralfs bplutils)? Is it currently available or will it be available in the future? What's currently the best way to return a std::vector<T>, where T is some class already wrapped by boost.python? Achim

4 3

Preparations for release
by David Abrahams Sept. 29, 2002

Sept. 29, 2002

Ladies & Gentlemen, I'm working on the Boost.Python v2 docs now, and not touching the code until further notice. If you want to help get Boost.Python v2 ready for release, aid with any or all of the following would be greatly appreciated (some of these jobs seem to require CVS write permission, but actually you can do everything up to the commit without write permission, and that would still be highly valuable): 1. Merge everything that's happened on the main trunk of libs/python and boost/python into the RC_1_29_0 branch and test it. I think this just amounts to: cd $BOOST_ROOT cvs up -P -d -rRC_1_29_0 cvs up -P -d -jHEAD libs/python boost/python # Run tests and let me know if there are any problems cvs commit cvs tag -F RC_1_29_0_last_merge libs/python boost/python 1a. You could also start testing the merged RC_1_29_0 branch against the Python release22-maint cvs branch. Quoth Guido: If you check out the release22-maint branch of Python from CVS and subscribe to the python-checkins list (http://mail.python.org/mailman/listinfo/python-checkins) you should be able to track the work leading up to 2.2.2 pretty closely. (2.2.2 will be released approximately concurrently with Boost 1.29.0) 2. Sort out which files are only part of Boost.Python v1 and create two archives, .zip and .tgz, then cvs remove the v1-only files test Boost.Python v2 to make sure it still works cvs commit 3. Think about providing some alternate approaches to building Boost.Python. I have really mixed feelings about this since I don't want to maintain multiple build systems, but I also think: 1. Windows users really expect a MS Visual studio project file that generates a differently-named lib/dll for debug-python builds, and the current Boost.Build strategy of renaming the libraries doesn't actually work because the original name of the dll gets encoded in the object file dynamic linking fails. 2. Some of the platforms we don't currently support in Boost.Build might be handled automatically by distutils. I'm thinking, for example of MacOS X. I seem to recall someone sending me distutils scripts for building Boost.Python as part of a bug report long ago but I don't know where they went :(. Any distutils experts out there? 4. Help to prepare documentation. Achim Domma has generously contributed a bunch of documentation templates available at www.procoders.net/dave/boostdocs.zip. These include many more automatically-generated pages than we have public headers, so you could ignore most of it. Even if you can't fill in everything, there's a lot of structure and rote editing which you could do to prepare these for inclusion into the distro. Let me know if you'd like to help and we can negotiate a task. Thanks, Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

2 2

Boost.Python v2: keyword arguments
by David Abrahams Sept. 28, 2002

Sept. 28, 2002

I have just checked in keyword argument support for Boost.Python v2 Boost.Python v2 is now feature-complete for release! Synopsis: Keywords are specified as: args("param1", "param2", "param3") If N keywords are supplied, they specify the argument names of the last N parameters to the function. The following interfaces: def("function_name", function, ... ) class_<T>() .def("method_name", &T::method, ... ) Now accept up to 3 arguments in any order in place of ... docstring (a string literal) call policies keywords Keywords can also be supplied in: init<T1, T2...>("docstring", keywords) init<T1, T2...>(keywords, "docstring") init<T1, T2...>(keywords) and likewise in the constructor of overload dispatchers defined with BOOST_PYTHON_FUNCTION_OVERLOADS(...) and BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(...) See libs/python/test/args.[py/cpp] for examples. Note that keyword arguments are really useful for cases like this: >>> def f(a = 1, b = 2, c = 3, d = 4, e = 5, f = 6): ... >>> f(1, 2, f = 99) # ** But we can't support that with the BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS mechanism. It's a limitation of C++. Our current default argument mechanism creates overloaded Python functions which invoke a C++ function call expression, and they have no access to the expressions used for any default arguments to the C++ function. So: void ff(int a = 1, int b = 2, int c = 3, int d = 4, int e = 5, int f = 6) Challenge: now write down a piece of valid C++ code which corresponds to **. You can't do it without knowing and using the default argument expressions for c, d, e. But remember, the library has no access to those. We can allow you to specify any initial section of the total argument set in any order, but how useful is that? So, I plan to allow this instead: def("f", &f, (arg("a") = 1, arg("b") = 2, arg("c") = 3, ...)); // *** which gets around that problem by supplying defaults up-front. The downside, of course, is that you have to keep those expressions in-synch with your C++ code. This feature will be added shortly after the first release. All the infrastructure is already there. Enjoy, Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

1 0

bjam gcc3.2 boost_python compile problem
by lieven vanholme Sept. 27, 2002

Sept. 27, 2002

Hi, I tried to compile boost_python(latest CVS) with gcc3.2 using bjam3.1.0 (os=linux) invoking with; bjam -sBUILD=release -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/home/lvholme got first this kind of error: ------------------------------------------------- ...found 818 targets... ...updating 31 targets... MkDir1 ../../libs/python/bin : command not found MkDir1 ../../libs/python/bin/libbpl.so : is a directory mkdir: cannot create directory `\r': File exists mkdir ../../libs/python/bin/libbpl.so ...failed MkDir1 ../../libs/python/bin/libbpl.so... ...skipped <directory-grist>../../libs/python/bin/libbpl.so/gcc for lack of <directory-grist>. ./../libs/python/bin/libbpl.so... ... -------------------------------------------------- and after repeating the command for about five times (directory structure got finally build), i got another list of errors, looking all the same: -------------------------------------------------- gcc-C++-action ../../libs/python/bin/libbpl.so/gcc/release/inlining-on/runtime-link-dynamic/sh ared-linkable-true/numeric.o : is a directory g++: cannot specify -o with -c or -S and multiple compilations ... -------------------------------------------------- Is this a gcc3.2-compiler problem? thanx! Lieven

2 2

py_interface in v2?
by Greg Hawkins Sept. 27, 2002

Sept. 27, 2002

Dave, I've just had occasion to use the Python api wrapping code in py_interface.[h|cpp] for the first time and realised that it isn't being built at the moment. What's happening with this stuff? Is it going to be in before the release? Are there outstanding issues with it? best, Greg

2 1

Boost.Python v2: Numeric/numarray support
by David Abrahams Sept. 26, 2002

Sept. 26, 2002

I've just checked in changes which give some support for Numeric and numarray arrays. Summary: #include <boost/python/numeric.hpp> using namespace boost::python; // a function accepting a numeric array argument object f(numeric::array x) { return x + x[make_tuple(3,3,4)]; // return x + x[3,3,4]; } numeric::array g(object sequence) { // numeric::array() constructor maps to the 'array' // factory function. return numeric::array(sequence); } Since numeric::array derives from boost::python::object, all the usual operators are defined by default. The default is to use the facilities of the numarray module, if it is installed. Otherwise, we fall back to the Numeric module. If you have both installed, and you want Numeric, or one of them is installed elsewhere in your package path, you can tell Boost.Python which one to use explicitly: numeric::set_module_and_type("Numeric", "ArrayType"); numeric::set_module_and_type("numarray", "NDArray"); I implemented all of the interface of numarray.NumArray, except that the constructor is replaced by the interface of the array() factory function. That means the C++ class has lots of interface that will just throw exceptions if you try to use it with Numeric, e.g: x.diagonal(1, 2); // works with numarray, throws with Numeric It seems as though Numeric users will probably want C++ wrappers for all of the regular Numeric free functions and ufuncs, but that will probably have to wait until after release (unless some kindly volunteer shows up who wants to do it). Enjoy, Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com

1 0