Mailman 3 February 2005 - Cplusplus-sig

Building
by Pedro Bola�os Feb. 14, 2005

Feb. 14, 2005

Hi, I've been trying to build Boost.Python, without success, both, using bjam(3.1.10), and the visual studio project. When I use bjam, I set the following environment variables: VC7_ROOT = C:\Archivos de programa\Microsoft Visual Studio .NET\Vc7 PYTHON_ROOT = c:\desarrollo\python23 PYTHON_VERSION = 2.3 and invoke the command in "C:\Desarrollo\boost_1_32_0\libs\python\build" as follows: bjam "-sTOOLS=vc7" When using the visual studio project I get the following output: ------ Build started: Project: boost_python, Configuration: Release Win32 ------ Compiling... type_id.cpp tuple.cpp str.cpp registry.cpp pickle_support.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled object_protocol.cpp object_operators.cpp numeric.cpp module.cpp long.cpp list.cpp life_support.cpp iterator.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled inheritance.cpp ../../../../boost\pending\detail\property.hpp(80) : error C2039: 'result<`template-parameter258'>' : is not a member of 'boost::detail::property_value_end<PropertyList>' ../../../../boost\pending\detail\property.hpp(80) : fatal error C1507: previous user errors and subsequent error recovery halt further compilation function.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled from_python.cpp errors.cpp enum.cpp dict.cpp class.cpp Generating Code... Compiling... builtin_converters.cpp \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(77) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(70) : while compiling class-template member function 'void boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T,SlotPolicy>::construct(PyObject *,boost::python::converter::rvalue_from_python_stage1_data *)' with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_from_python ] \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(396) : see reference to class template instantiation 'boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T,SlotPolicy>' being compiled with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_from_python ] arg_to_python_base.cpp aix_init_module.cpp Generating Code... Build log was saved at "file://c:\Desarrollo\boost_1_32_0\libs\python\build\VisualStudio\release-obj\BuildLog.htm" boost_python - 5 error(s), 1 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped What can I do about it? Am I missing any step? Thank you very much. Sebastian Bolaños. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

1 0

boost python: How to convert a class X object to class Y object automatically
by Liwei Peng Feb. 13, 2005

Feb. 13, 2005

Hi, Can someone give me some suggestion on how I can convert a class X object to a class Y object automatically through boost python? class Y { ... }; class X { public: Y get_y(); ... }; While in C++, I can do this: X x; Y y = x.get_y(); In python, I'd like to convert X object automatically, transparently to Y object without having to call "get_y()". Any comments are welcome, Thanks, Liwei __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0

Exporting __stdcall functions in Boost.Python
by Mike Feb. 12, 2005

Feb. 12, 2005

Hi, I am trying to use Boost.Python (via pyste) to export the __stdcall f() below, but get a compile time error (using MSVC 7.1, boost 1.32). #include <boost/python.hpp> void __stdcall f() { } void Export_Test() { boost::python::def("f", &f); } The compilation error is: C:\Boost\include\boost-1_32\boost\python\make_function.hpp(104): error C2664: 'boost::mpl::vector1<T0> boost::python::detail::get_signature<void>(RT (__cdecl *)(void),void *)' : cannot convert parameter 1 from 'void (__stdcall *)(void)' to 'void (__cdecl *)(void)' with [ T0=void, RT=void ] It appears that the problem is with the __stdcall modifier. A better description of the problem is also given in: http://mail.python.org/pipermail/c++-sig/2003-April/003811.html I was wondering the best way of wrapping f() (and many more like it) so that the above program compiles (The only way I could do it (due to my lack of skill) is via macros). Any help gratefully received. Regards, Mike

1 0

Wrapping C++ class with unnamed union
by Kevin Vance Feb. 11, 2005

Feb. 11, 2005

Hi, I am new to boost.python, so there may be a very simple answer to this. I would like to access the OGRE graphics library from python. But it has several classes with data like this: union { struct { Real r,g,b,a; }; Real val[4]; }; And I cannot access e.g. 'r' with a statement like: .def_readwrite("r", &Ogre::ColourValue::r) I'm assuming this is because there is an unnamed union and unnamed struct in between the class and the 'r'. I could write a new C++ class to wrap this one, and then use boost to wrap *that*. But if there is a simpler way, I would rather use it. Thanks for your advice, kvance

3 2

Re: Boost.Python appears to be catching Fortran READ "exceptions".
by Mike Feb. 8, 2005

Feb. 8, 2005

Thanks for your quick reply Ralf. Thinking along your suggested line of exceptions, and given that I know that this _does_ work as expected... #include <iostream> extern "C" void __stdcall FortDll(); int main(int ,char** ) { FortDll( ); // performs a Fortran READ(33,*,END=999) I std::cout << "FortDll worked with no exceptions.\n"; // this line gets executed! } ...I then had the idea of trying this: #include <iostream> #include <Python.h> extern "C" void __stdcall FortDll(); int main(int, char**) { // Call Fortran function FortDll FortDll(); // Line #A - ensures Fortran RTL is loaded first. Py_Initialize(); // Now call FortDll again PyRun_SimpleString("import hello\n" "hello.call_fortran()\n"); // this calls FortDll() Py_Finalize(); } The output is: 1 2 3 4 999 reached 1 2 3 4 999 reached No exceptions! If I remove Line #A then I get my 1\n2\n3\n4 follwed by the "RuntimeError: unidentifiable C++ exception" message (no "999 reached"). The aboves points to one possible solution (ensure the Fortran RTL is loaded before Python which is called via my "main" program), but it would be nice to be able to do a similar sort of thing starting from the Python prompt. I'll have a further look at the FORTRAN docs & see if that provides any clues. Thanks again, Mike > > > From: "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> > Subject: Re: [C++-sig] Boost.Python appears to be catching Fortran > READ "exceptions". > To: Development of Python/C++ integration <c++-sig(a)python.org> > Message-ID: <20050206204018.58393.qmail(a)web20226.mail.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > --- Mike <mike(a)thewilsonfamily.freeserve.co.uk> wrote: >> My app I want to prototype in Python has several C++ classes that >> rely on some routines written in FORTRAN. Can I stop Python >> handling the errors that would have been handled in any case by the >> FORTRAN run time system? > > It is not Python or Boost.Python doing anything special, it depends > on your Fortran compiler how I/O errors are dealt with. It must be > the Fortran runtime-library throwing the exception. I'd look at the > Fortran documentation to find out about the interrelation of Fortran > I/O errors and C++ exceptions. Ralf > P.S.: I always found it easier to translate Fortran code to C++ > rather than dealing with inter-language complications. > P.S. I did translate the routine based on the given code, but it may not be possible in other cases.

1 0

Boost.Python appears to be catching Fortran READ "exceptions".
by Mike Feb. 6, 2005

Feb. 6, 2005

Hi, I am a new Boost.Python user. Summary --------- I have created a Boost.Python module (named 'hello') that calls a FORTRAN subroutine (named FortDll) via a C++ function (named call_fortran ). The FORTRAN code, which reads a data file, has the line: READ(....,END=999) ! goto line labled 999 when eof reached to handle the end of file condition. In non-Python environment it works as expected, but under Python the eof condition is being caught by Boost.Python as a "RuntimeError: unidentifiable C++ exception". If I create my module without Boost.Python then I just get a crash. Details ------- I have the following Boost.Python module: ----Start of C++ code ---- // Using MS.NET 7.1.3088, Python 2.4, boost 1.31 // creates hello.dll #include <boost/python.hpp> extern "C" void __stdcall FortDll(); void call_fortran() { FortDll(); } using namespace boost::python; BOOST_PYTHON_MODULE(hello) { def("call_fortran", call_fortran); } ----End of C++ code ---- The code for FortDll is as follows: ----Start of FORTRAN (F90) code ---- ! !Built using Intel(R) Fortran Compiler for MS.NET 2003, Version 8.0.1877.2003 ! SUBROUTINE FortDll ! Export subroutine into Dll !DEC$ATTRIBUTES DLLEXPORT, DEFAULT, STDCALL, DECORATE, ALIAS:'FortDll' ::FortDll INTEGER*4 I OPEN(UNIT=33, FILE='INTS.DAT', ACCESS='SEQUENTIAL', STATUS='OLD') DO WHILE(.TRUE.) 777 READ(33,*,END=999) I ! When the eof is reached the above line causes ! an exception in Python,so that ..... PRINT *,I ENDDO 999 CONTINUE ! <<<<<< ...this line isn't reached!!! PRINT *,'999 reached' CLOSE(33) END SUBROUTINE ----End of FORTRAN (F90) code ---- The test data file ints.dat is ----Start of ints.dat---- 1 2 3 4 ---EOF---- The results from testing are as follows: ----Start of Python session in debugger---- Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import hello >>> hello.call_fortran() 1 2 3 4 Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: unidentifiable C++ exception >>> ----End of Python session---- The problem appears at line labled 777 in the Fortran code. As shown above in the Python test case, when the FORTRAN hits a read error it appears that the normal execution of code, as specified by READ(..., END= 999) I ! goto line 999 when eof is reached is not getting a chance to be executed. When I catch the exception in the debugger, I get First-chance exception at 0x00b58ca9 (FortDll.dll) in python.exe: 0xC0000005: Access violation reading location 0x00000000 My initial thought that this was to do with Boost.Python, however I get a crash/core dump using a Python module built around: static PyObject * call_fortran(PyObject *self, PyObject *args) { FortDll(); // causes Python to crash when eof is reached. return Py_BuildValue("i", 0); } Note that in a 'non-Python' environment, similar to this: int main(int ,char** ) { FortDll( ); } the output is : 1 2 3 4 999 reached ie. FortDll() works as expected. My app I want to prototype in Python has several C++ classes that rely on some routines written in FORTRAN. Can I stop Python handling the errors that would have been handled in any case by the FORTRAN run time system? Regards Mike

2 1

Callbacks with internal references as arguments
by Daniel Lewis Feb. 5, 2005

Feb. 5, 2005

Hello, I'm trying to write a module using boost::python that can deliver callbacks, but I'm having trouble with declaring my intentions with regards to object ownership. A simple example of what I am trying to achieve is this: struct Foo { }; struct Bar { Foo& get_foo() { return foo; } void foo_callback() { callback(foo); } Foo foo; object callback; }; BOOST_PYTHON_MODULE (foobar) { class_<Foo>("Foo", init<>()); class_<Bar>("Bar", init<>()) .def("get_foo", &Bar::get_foo, return_internal_reference<>()) .def("foo_callback", &Bar::foo_callback) .def_readwrite("callback", &Bar::callback); } So when calling Bar::get_foo() from Python, I get the desired behaviour: the same Python object is returned every time, and Bar::foo is not destroyed when the Python object is. When using Bar::foo_callback(), like this: def callback(foo): print foo bar.callback = callback bar.foo_callback() I get a different object, and ~Foo() is called when the Python object is destroyed. Is there any way to achieve the "internal reference" behaviour when delivering the object as a callback argument? Thanks, Dan.

1 0

bad interactions between weak_ptrs and boost.python
by Arthur Peters Feb. 4, 2005

Feb. 4, 2005

Hello all, Thanks for boost.python in all its greatness. I am having 2 problems caused by boost.python's way of handling holders that are shared_ptrs. Sorry for how verbose this is. I could not figure out how to make it more concise. They are both related to the way boost.python converts a python object to a shared_ptr. It creates a completely new temporary shared_ptr that is managing a reference to the PyObject, instead of copying the holder (which is a shared_ptr) so that the shared_ptr is managing the actual C++ object. The following walks through the problems as they are demonstrated by the attached cpp file. If you look over the cpp file first it will be easier to understand. In fact, it may be easier to read the cpp file and not read this stuff at all. The first problem is as follows: >>> v = Derived() Here a Derived object is created and put in a shared_ptr<Derived>. >>> SavesWeakPtrDerived( v ) Here boost.python simply passes the holder as the argument to function because they are both of type shared_ptr<Derived>. That means that the weak_ptr<Base> that is created does not expire ... >>> UsesSavedWeakPtr() # works ... and the function that uses it works. >>> SavesWeakPtr( v ) Here, however, boost.python creates a temporary shared_ptr<Base> that only manages a reference to the python object. That means that the weak_ptr<Base> that is created will expire as soon as the function exits and the temporary shared_ptr goes out of scope. Because of this ... >>> UsesSavedWeakPtr() # fails even though v still exists. This chrashes the program ... UsesSavedWeakPtr now fails. The second problem is basically caused by the first and looks like this: >>> v = Derived() Here a Derived object is create and put in a shared_ptr<Dervied> holder. Since Base is dervied from enable_shared_from_this, the shared_ptr constructor updates _internal_weak_this to be connected to it. >>> v.MemberUsingSharedFromThis() # works MemberUsingSharedFromThis works fine, since shared_from_this() will return a shared_ptr connected to the holder of the python object (which is a shared_ptr). >>> SavesWeakPtr( v ) Now a shared_ptr<Base> needs to be created, so boost.python creates a temporary shared_ptr as I described above. The problem is that again the shared_ptr constructor updates _internal_weak_this to be connected to it, but in this case the shared_ptr only lasts until the function call finishes, causing _internal_weak_this to expire early. >>> v.MemberUsingSharedFromThis() # fails with "RuntimeError: boost::bad_weak_ptr" Now when we call MemberUsingSharedFromThis it throws because _internal_weak_this has expired even though original shared_ptr in the python object still exists. The best way I can see to fix this is to make the from-python conversion of objects with a shared_ptr as a holder go directly from the holder (a shared_ptr) to the argument (a shared_ptr) instead of converting the shared_ptr to a dumb pointer in between (as it does now). This way the shared_ptr that appears in C++ land is a actually associated (shares a reference count) with the holder. In the case of classes derived from enable_shared_from_this, the conversion to a dumb pointer isn't even a problem. All boost.python would need to do would be to get the shared_ptr using shared_from_this. But this is not a general solution. If someone has a speific idea for a solution I would be willing to give coding it a try. However, I don't know the boost.python code so that might not work well. Thanks very much for your time. -Arthur PS: Yes I did post about this a couple of months ago, but I did not get back into working on it until now, so now there are complete examples and such.

1 0

problem with constructor/implicitly_convertible
by Benjamin Schmeling Feb. 4, 2005

Feb. 4, 2005

Hi, I have defined the following: bigint* bigint_constructor(long_ l){ return new bigint(to_bigint(l)); } class_<bigint>("bigint") .def("__init__", make_constructor(bigint_constructor)) .... .... implicitly_convertible<boost::python::long_, bigint>(); Now I want to have a implicit conversion from long_ to bigint. My original c++ class has no constructor with long_ but my python-bigint class. The compiler tries to find one on c++ bigint and doesn't find it. How should I use implicitly_convertible to reach my goal? Benjamin

3 5

How to access live C++ objects from Python
by Ercan SAHAN Feb. 4, 2005

Feb. 4, 2005

Hi all, I am not sure if this is the right group to ask this 'zero beginner' question but what I wonder is how I can make my python scripts to be able to access the live objects of my C++ application at run-time. I've used SWIG to wrap my C++ functions and variables, nevertheless I couldn't manage what I wanted. Regards, Ercan Sahan, METU --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term'

1 0