From RaoulGough at yahoo.co.uk Sun Jun 1 16:04:13 2008 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Sun, 01 Jun 2008 15:04:13 +0100 Subject: [C++-sig] Incref / Decref Question In-Reply-To: References: Message-ID: <4842AC5D.1050507@yahoo.co.uk> Michael Wieher wrote: > 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 > I would expect this message to read "Segmentation fault (core dumped)". The most common reason for not dumping core is that you have a zero corefile ulimit. Try "ulimit -c" to show the limit your shell is using, and "ulimit -c unlimited" to change it to what you (probably) want. That's how you do it in ksh or bash, anyway. If you manage to get a coredump you can see what happened with gdb (e.g. gdb /usr/bin/python my_core_file) and try "where" to see the stack traceback as a first step. [snip] > 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? > That sounds like a reasonable theory. You could also start python under the debugger (e.g. "gdb /usr/bin/python" and then "run") in which case the debugger will catch the SEGV and you can see where this occurs (and what shared libraries are currently loaded). I can't say I remember the rules for managing Python object reference counts, but it's probably documented somewhere - maybe somebody else can comment, or say more if you post a stack trace. -- Cheers, Raoul. From meine at informatik.uni-hamburg.de Sun Jun 1 21:45:36 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Sun, 1 Jun 2008 21:45:36 +0200 Subject: [C++-sig] ANNOUNCE: PyBindGen 0.8 In-Reply-To: References: Message-ID: <200806012145.42100.meine@informatik.uni-hamburg.de> Hi! On Dienstag 04 Dezember 2007, Gustavo Carneiro wrote: > 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). This all sounded very interesting, so I have just tried pybindgen out. First, I noticed, that void return type is handled with Py_BuildValue, which is slight overkill, isn't it (since one of PyBindGen's design goals is to write lean, nearly-handwritten style code)? I have registered on launchpad to be able to submit a patch when I would have managed to make it return Py_None directly, but I have more serious problems when trying to wrap the following simple type declaration: union Word { short word; struct { char low, high; }; }; The gccxml module does not seem to recognize the "short" return value: .../word.h:6: Warning: Return value 'short int' error (used in Word::word [variable]): TypeLookupError('short int',) short word; However, when looking at pybindgen/typehandlers/inttype.py, fixing this seems to be possible, but I wonder if a more general approach than adding one class for each combination of const/ptr/ref/unsigned/width integer type would be more sensible? Obviously, I'd better leave this decision & fix to the original authors. Finally, the anonymous struct inside the union is not yet supported. AFAICS, PyBindGen would "simply" need to descend into the struct and export its members like direct members of the surrounding type. Right now, it produces illegal code because it tries to wrap a data member with an empty string as name: static PyObject* _wrap_PyWord__get_(PyWord *self) { PyObject *py_retval; PyWord *py_Word; py_Word = PyObject_New(PyWord, &PyWord_Type); py_Word->obj = new Word(self->obj->); py_retval = Py_BuildValue("N", py_Word); return py_retval; } [...] static PyGetSetDef PyWord__getsets[] = { { "", /* attribute name */ (getter) _wrap_PyWord__get_, /* C function to get the attribute */ (setter) _wrap_PyWord__set_, /* C function to set the attribute */ NULL, /* optional doc string */ NULL /* optional additional data for getter and setter */ }, { NULL, NULL, NULL, NULL, NULL } }; Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From gjcarneiro at gmail.com Sun Jun 1 22:09:45 2008 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Sun, 1 Jun 2008 21:09:45 +0100 Subject: [C++-sig] ANNOUNCE: PyBindGen 0.8 In-Reply-To: <200806012145.42100.meine@informatik.uni-hamburg.de> References: <200806012145.42100.meine@informatik.uni-hamburg.de> Message-ID: On 01/06/2008, Hans Meine wrote: > > Hi! > > > On Dienstag 04 Dezember 2007, Gustavo Carneiro wrote: > > 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). > > > This all sounded very interesting, so I have just tried pybindgen out. > > First, I noticed, that void return type is handled with Py_BuildValue, > which > is slight overkill, isn't it (since one of PyBindGen's design goals is to > write lean, nearly-handwritten style code)? True. But I think special-casing for when only None is returned makes sense and should be relatively simple to implement. I have registered on launchpad > to be able to submit a patch when I would have managed to make it return > Py_None directly, but I have more serious problems when trying to wrap the > following simple type declaration: > > union Word > { > short word; > struct > { > char low, high; > }; > }; > > The gccxml module does not seem to recognize the "short" return value: > > .../word.h:6: Warning: Return value 'short int' error (used in Word::word > [variable]): TypeLookupError('short int',) > short word; > > However, when looking at pybindgen/typehandlers/inttype.py, fixing this > seems > to be possible, but I wonder if a more general approach than adding one > class > for each combination of const/ptr/ref/unsigned/width integer type would be > more sensible? I'm not sure. Maybe it's possible to find a common base class for all int-like types. Obviously, I'd better leave this decision & fix to the > original authors. > > Finally, the anonymous struct inside the union is not yet > supported. AFAICS, > PyBindGen would "simply" need to descend into the struct and export its > members like direct members of the surrounding type. Right now, it > produces > illegal code because it tries to wrap a data member with an empty string as > name: > > static PyObject* _wrap_PyWord__get_(PyWord *self) > { > PyObject *py_retval; > PyWord *py_Word; > > py_Word = PyObject_New(PyWord, &PyWord_Type); > py_Word->obj = new Word(self->obj->); > py_retval = Py_BuildValue("N", py_Word); > return py_retval; > } > [...] > static PyGetSetDef PyWord__getsets[] = { > { > "", /* attribute name */ > (getter) _wrap_PyWord__get_, /* C function to get the attribute */ > (setter) _wrap_PyWord__set_, /* C function to set the attribute */ > NULL, /* optional doc string */ > NULL /* optional additional data for getter and setter */ > }, > { NULL, NULL, NULL, NULL, NULL } > }; Ugh.. right, I guess it's a bug. But I am curious, how do you access anonymous structures from C? It does not seem possible, unless I am missing something, and if so, what would be the point in wrapping them? Maybe it's better to just ignore it? Thanks for your feedback. Although I have not made any PyBindGen release in a very long time, development is far from stagnated, in case anyone is wondering... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From meine at informatik.uni-hamburg.de Mon Jun 2 14:01:00 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Mon, 2 Jun 2008 14:01:00 +0200 Subject: [C++-sig] Pyplusplus: Support for anonymous structs? Message-ID: <200806021401.00631.meine@informatik.uni-hamburg.de> Hi Roman, after reporting to Gustavo that pybindgen does not support unnamed structs, I tried pyplusplus and found the same (OK, not the same - pyplusplus gracefully skips the members with the two warnings "Py++ can not export unnamed variables" and "Py++ can not export unnamed classes"). Actually, there are two problems: 1) py++ generates the following code, which does not mention the "low" and "high" members wrapped in the struct: bp::class_< Word >( "Word" ) .def_readwrite( "word", &Word::word ); This should be "easy to fix" - py++ would need to descend into the struct and add .def_readwrite( "low", &Word::low ) .def_readwrite( "high", &Word::high ) However, the next problem is fatal: 2) boost::python::class_ only works for structs and classes, but not for unions. I am getting an error from is_polymorphic: /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp: At global scope: /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp: In instantiation of 'boost::detail::is_polymorphic_imp1::d1': /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp:56: instantiated from 'const bool boost::detail::is_polymorphic_imp1::value' /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp:91: instantiated from 'const bool boost::detail::is_polymorphic_imp::value' /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp:96: instantiated from 'boost::is_polymorphic' /software/boost-1.34.1/include/boost-1_34/boost/mpl/if.hpp:67: instantiated from 'boost::mpl::if_, boost::python::objects::polymorphic_id_generator, boost::python::objects::non_polymorphic_id_generator >' /software/boost-1.34.1/include/boost-1_34/boost/python/object/inheritance.hpp:65: instantiated from 'boost::python::objects::dynamic_id_generator' /software/boost-1.34.1/include/boost-1_34/boost/python/object/inheritance.hpp:72: instantiated from 'void boost::python::objects::register_dynamic_id(T*) [with T = Word]' /software/boost-1.34.1/include/boost-1_34/boost/python/object/class_metadata.hpp:97: instantiated from 'void boost::python::objects::register_shared_ptr_from_python_and_casts(T*, Bases) [with T = Word, Bases = boost::python::bases]' /software/boost-1.34.1/include/boost-1_34/boost/python/object/class_metadata.hpp:225: instantiated from 'static void boost::python::objects::class_metadata::register_aux2(T2*, Callback) [with T2 = Word, Callback = boost::integral_constant, T = Word, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /software/boost-1.34.1/include/boost-1_34/boost/python/object/class_metadata.hpp:219: instantiated from 'static void boost::python::objects::class_metadata::register_aux(void*) [with T = Word, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /software/boost-1.34.1/include/boost-1_34/boost/python/object/class_metadata.hpp:205: instantiated from 'static void boost::python::objects::class_metadata::register_() [with T = Word, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /software/boost-1.34.1/include/boost-1_34/boost/python/class.hpp:496: instantiated from 'void boost::python::class_::initialize(const DefVisitor&) [with DefVisitor = boost::python::init, W = Word, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /software/boost-1.34.1/include/boost-1_34/boost/python/class.hpp:629: instantiated from 'boost::python::class_::class_(const char*, const char*) [with W = Word, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' foomodule.cxx:26: instantiated from here /software/boost-1.34.1/include/boost-1_34/boost/type_traits/is_polymorphic.hpp:28: error: base type 'Word' fails to be a struct or class type -- Ciao, / / /--/ / / ANS From meine at informatik.uni-hamburg.de Mon Jun 2 11:12:53 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Mon, 2 Jun 2008 11:12:53 +0200 Subject: [C++-sig] ANNOUNCE: PyBindGen 0.8 In-Reply-To: References: <200806012145.42100.meine@informatik.uni-hamburg.de> Message-ID: <200806021112.54702.meine@informatik.uni-hamburg.de> Am Sonntag, 01. Juni 2008 22:09:45 schrieb Gustavo Carneiro: > > The gccxml module does not seem to recognize the "short" return value: > > .../word.h:6: Warning: Return value 'short int' error (used in Word::word > > [variable]): TypeLookupError('short int',) > > short word; > > > > However, when looking at pybindgen/typehandlers/inttype.py, fixing this > > seems > > to be possible, but I wonder if a more general approach than adding one > > class > > for each combination of const/ptr/ref/unsigned/width integer type would > > be more sensible? > > I'm not sure. Maybe it's possible to find a common base class for all > int-like types. That could be a start. Right now, I wonder - why some CTYPES contain 'int', but not 'int32_t', some the other way round, some both - why some CTYPES contain variants with "const" postfixes, but quite randomly AFAICS - why UInt8PtrParam has "uint8_t const *" in CTYPES and DIRECTION_OUT in DIRECTIONS - why signed values are only value-checked for the upper, but not the lower bound, at least in the places I saw Maybe the whole file should be generated by a script, e.g. from a template for N bits, that would still make eight hand-written classes AFAICS (e.g. {Unsigned,}Int{{,Ref,Ptr}Param,Return} ) which seem to be hard enough to get right.. > > Finally, the anonymous struct inside the union is not yet > > supported. [...] > > Ugh.. right, I guess it's a bug. But I am curious, how do you access > anonymous structures from C? It does not seem possible, unless I am > missing something, and if so, what would be the point in wrapping them? I would simply compile the generated code with g++ instead of gcc, or am I missing something? From your question, I fear pybindgen.gccxmlparser would need to be extended to support template instances, too?! (And probably a switch to write extern "C" around the module init function.) -- Ciao, / / /--/ / / ANS From meine at informatik.uni-hamburg.de Mon Jun 2 16:42:50 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Mon, 2 Jun 2008 16:42:50 +0200 Subject: [C++-sig] How to officially wrap a pointer into boost::python::object? Message-ID: <200806021642.51497.meine@informatik.uni-hamburg.de> Hi! This seems to be such a simple task: Given a (e.g factory) function that wants to return a new object as boost::python::object, what is the correct code? For instance: boost::python::object myFactory() { Foo *result = new Foo(); boost::python::object pyresult = ..... result .....; // <- PLEASE FILL IN // e.g. set python attribute on pyresult.. return pyresult; } As far as I know, something like this was in the tutorial in the past, but has been deleted without being reproduced in any other place I know of. What I am doing right now is a little bit clumsy: boost::python::object pyresult = boost::python::object( boost::python::detail::new_reference( // ugly: private/"detail" API boost::python::manage_new_object::apply::type()(result))); I have looked at the implementation of manage_new_object to find a nicer shortcut, which leads to a is_polymorphic-if branch using detail::wrapper_base_::owner or detail::make_owning_holder respectively. I refrained from using make_owning_holder directly, not only because it is also in the detail namespace, but also because of the second if-branch which I completely do not understand. Also, I would like to not take the detour via an intermediate PyObject * which has to be wrapped again; make_owning_holder suggests that using std::auto_ptr could be a way, but I am unsure if this works with the special-cased Intel5 and VC 6 Dinkum library and whether I may leave out the above is_polymorphic stuff. In the end, I would like to know a) what is the right way(tm) for common end users, b) where this is (prominently) documented, and c) what is the perfectly-fine-in-all-cases way for code that should eventually go into the BPL. -- Ciao, / / /--/ / / ANS From michael.wieher at gmail.com Mon Jun 2 17:29:40 2008 From: michael.wieher at gmail.com (Michael Wieher) Date: Mon, 2 Jun 2008 10:29:40 -0500 Subject: [C++-sig] Incref / Decref Question In-Reply-To: <4842AC5D.1050507@yahoo.co.uk> References: <4842AC5D.1050507@yahoo.co.uk> Message-ID: Thank you. I had been wondering why/how/where the core dump was (or was not happening) but thought it was my OS that was maybe dumping it to some different place than I was used to and had gotten tired of looking. Appreciate it! Now at least I have a point to investigate from. On Sun, Jun 1, 2008 at 9:04 AM, Raoul Gough wrote: > Michael Wieher wrote: >> >> 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 >> > > I would expect this message to read "Segmentation fault (core dumped)". The > most common reason for not dumping core is that you have a zero corefile > ulimit. Try "ulimit -c" to show the limit your shell is using, and "ulimit > -c unlimited" to change it to what you (probably) want. That's how you do it > in ksh or bash, anyway. > > If you manage to get a coredump you can see what happened with gdb (e.g. gdb > /usr/bin/python my_core_file) and try "where" to see the stack traceback as > a first step. > > [snip] > >> 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? >> > > That sounds like a reasonable theory. You could also start python under the > debugger (e.g. "gdb /usr/bin/python" and then "run") in which case the > debugger will catch the SEGV and you can see where this occurs (and what > shared libraries are currently loaded). I can't say I remember the rules for > managing Python object reference counts, but it's probably documented > somewhere - maybe somebody else can comment, or say more if you post a stack > trace. > > -- > Cheers, > Raoul. > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From gjcarneiro at gmail.com Tue Jun 3 02:08:21 2008 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 3 Jun 2008 01:08:21 +0100 Subject: [C++-sig] ANNOUNCE: PyBindGen 0.8 In-Reply-To: <200806021112.54702.meine@informatik.uni-hamburg.de> References: <200806012145.42100.meine@informatik.uni-hamburg.de> <200806021112.54702.meine@informatik.uni-hamburg.de> Message-ID: On 02/06/2008, Hans Meine wrote: > > Am Sonntag, 01. Juni 2008 22:09:45 schrieb Gustavo Carneiro: > > > > The gccxml module does not seem to recognize the "short" return value: > > > .../word.h:6: Warning: Return value 'short int' error (used in > Word::word > > > [variable]): TypeLookupError('short int',) > > > short word; > > > > > > However, when looking at pybindgen/typehandlers/inttype.py, fixing this > > > seems > > > to be possible, but I wonder if a more general approach than adding one > > > class > > > for each combination of const/ptr/ref/unsigned/width integer type would > > > be more sensible? > > > > I'm not sure. Maybe it's possible to find a common base class for all > > int-like types. > > > That could be a start. Right now, I wonder > - why some CTYPES contain 'int', but not 'int32_t', some the other way > round, > some both > - why some CTYPES contain variants with "const" postfixes, but quite > randomly > AFAICS > - why UInt8PtrParam has "uint8_t const *" in CTYPES and DIRECTION_OUT in > DIRECTIONS > - why signed values are only value-checked for the upper, but not the lower > bound, at least in the places I saw > > Maybe the whole file should be generated by a script, e.g. from a template > for > N bits, that would still make eight hand-written classes AFAICS (e.g. > {Unsigned,}Int{{,Ref,Ptr}Param,Return} ) which seem to be hard enough to > get > right.. OK, this is all very abstract, and kind of beside the point. If you really care about this issue (personally I don't care that much, but...) could you open a bug report so we can stop bothering these nice c++-sig folks? > > Finally, the anonymous struct inside the union is not yet > > > > supported. [...] > > > > > Ugh.. right, I guess it's a bug. But I am curious, how do you access > > anonymous structures from C? It does not seem possible, unless I am > > missing something, and if so, what would be the point in wrapping them? > > > I would simply compile the generated code with g++ instead of gcc, or am I > missing something? From your question, I fear pybindgen.gccxmlparser would > need to be extended to support template instances, too?! (And probably a > switch to write extern "C" around the module init function.) Maybe is my lack of knowledge of some C++ dark corner, but: union Word { short word; struct { char low, high; }; }; Word foo; What would be the C++ code that accesses the field 'low' from inside 'foo'? I honestly have no idea. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Tue Jun 3 07:07:19 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 3 Jun 2008 08:07:19 +0300 Subject: [C++-sig] How to officially wrap a pointer into boost::python::object? In-Reply-To: <200806021642.51497.meine@informatik.uni-hamburg.de> References: <200806021642.51497.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806022207w4d4c8d2fyc7789d024782624f@mail.gmail.com> On Mon, Jun 2, 2008 at 5:42 PM, Hans Meine wrote: > Hi! > > This seems to be such a simple task: Given a (e.g factory) function that > wants to return a new object as boost::python::object, what is the correct > code? > > For instance: > > boost::python::object > myFactory() > { > Foo *result = new Foo(); > boost::python::object pyresult = ..... result .....; // <- PLEASE FILL IN > // e.g. set python attribute on pyresult.. > return pyresult; > } > > As far as I know, something like this was in the tutorial in the past, but has > been deleted without being reproduced in any other place I know of. > What I am doing right now is a little bit clumsy: > > boost::python::object pyresult = > boost::python::object( > boost::python::detail::new_reference( // ugly: private/"detail" API > boost::python::manage_new_object::apply::type()(result))); > > I have looked at the implementation of manage_new_object to find a nicer > shortcut, which leads to a is_polymorphic-if branch using > detail::wrapper_base_::owner or detail::make_owning_holder respectively. > I refrained from using make_owning_holder directly, not only because it is > also in the detail namespace, but also because of the second if-branch which > I completely do not understand. > > Also, I would like to not take the detour via an intermediate PyObject * which > has to be wrapped again; make_owning_holder suggests that using std::auto_ptr > could be a way, but I am unsure if this works with the special-cased Intel5 > and VC 6 Dinkum library and whether I may leave out the above is_polymorphic > stuff. > > In the end, I would like to know > a) what is the right way(tm) for common end users, > b) where this is (prominently) documented, and > c) what is the perfectly-fine-in-all-cases way for code that should eventually > go into the BPL. std::auto_ptr< Foo > result( new Foo() ); boost::python::object pyresult( result ); You will have to add somewhere in your registration code next line: boost::python::register_ptr_to_python< std::auto_ptr< Foo > >(); -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Tue Jun 3 07:32:09 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 3 Jun 2008 08:32:09 +0300 Subject: [C++-sig] Pyplusplus: Support for anonymous structs? In-Reply-To: <200806021401.00631.meine@informatik.uni-hamburg.de> References: <200806021401.00631.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806022232x54c7acdem481dad9cd167752b@mail.gmail.com> On Mon, Jun 2, 2008 at 3:01 PM, Hans Meine wrote: > Hi Roman, > > after reporting to Gustavo that pybindgen does not support unnamed structs, I > tried pyplusplus and found the same (OK, not the same - pyplusplus gracefully > skips the members with the two warnings "Py++ can not export unnamed > variables" and "Py++ can not export unnamed classes"). Actually, there are > two problems: > > 1) py++ generates the following code, which does not mention the "low" > and "high" members wrapped in the struct: > > bp::class_< Word >( "Word" ) > .def_readwrite( "word", &Word::word ); > > This should be "easy to fix" - py++ would need to descend into the struct and > add > .def_readwrite( "low", &Word::low ) > .def_readwrite( "high", &Word::high ) py++ is not going support unnamed classes, unless someone will submit the patch. Next code does the job (taken as-is from Python-Ogre project) def fix_unnamed_classes( classes, namespace ): for unnamed_cls in classes: named_parent = unnamed_cls.parent if not named_parent.name: named_parent = named_parent.parent if not named_parent or named_parent.ignore: continue for mvar in unnamed_cls.public_members: if not mvar.name: continue if mvar.ignore: continue if declarations.is_array (mvar.type): template = '''def_readonly("%(mvar)s", &%(ns)s::%(parent)s::%(mvar)s)''' else: template = '''def_readwrite("%(mvar)s", &%(ns)s::%(parent)s::%(mvar)s)''' named_parent.add_code( template % dict( ns=namespace, mvar=mvar.name, parent=named_parent.name ) ) It takes list of unnamed classes. > However, the next problem is fatal: > > 2) boost::python::class_ only works for structs and classes, but not for > unions. I am getting an error from is_polymorphic: Thanks for bug reporting. I fixed this problem, by excluding unions from being exposed :-) -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From meine at informatik.uni-hamburg.de Tue Jun 3 14:21:04 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Tue, 3 Jun 2008 14:21:04 +0200 Subject: [C++-sig] How to officially wrap a pointer into boost::python::object? In-Reply-To: <7465b6170806022207w4d4c8d2fyc7789d024782624f@mail.gmail.com> References: <200806021642.51497.meine@informatik.uni-hamburg.de> <7465b6170806022207w4d4c8d2fyc7789d024782624f@mail.gmail.com> Message-ID: <200806031421.06983.meine@informatik.uni-hamburg.de> Am Dienstag, 03. Juni 2008 07:07:19 schrieb Roman Yakovenko: > > In the end, I would like to know > > a) what is the right way(tm) for common end users, > > b) where this is (prominently) documented, and > > c) what is the perfectly-fine-in-all-cases way for code that should > > eventually go into the BPL. > > std::auto_ptr< Foo > result( new Foo() ); > boost::python::object pyresult( result ); > > You will have to add somewhere in your registration code next line: > > boost::python::register_ptr_to_python< std::auto_ptr< Foo > >(); OK, this is obviously the answer to a), but what about c)? Background: I want to try to provide a patch for automatic __copy__/__deepcopy__ support using the code I posted in the past (cf. "How about class_<...>.enable_copy() ?" thread). I do not want to register auto_ptr conversions for every class automatically, or is this considered to be the right way for BPL code? Interestingly, as I mentioned, manage_new_object eventually uses a std::auto_ptr holder, too. Obviously, I could go the same route and use detail::make_owning_holder, but I would still get a PyObject * which I would need to wrap in a bp::object. -- Ciao, / / /--/ / / ANS From amaignan at gmail.com Tue Jun 3 18:18:39 2008 From: amaignan at gmail.com (=?ISO-8859-1?Q?Aur=E9lien_MAIGNAN?=) Date: Tue, 3 Jun 2008 18:18:39 +0200 Subject: [C++-sig] boost.python embedding tutorial doesn't work ? Message-ID: <2131ea990806030918v43c56243x363bf14f9364bd5d@mail.gmail.com> Hi I tried to executed the simple embedding tutorial from here : http://www.boost.org/doc/libs/1_35_0/libs/python/doc/tutorial/doc/html/python/embedding.html here is my C++ code : Py_Initialize(); object main_module = import("__main__"); object main_dict = main_module.attr("__dict__"); try{ object result = exec("result = 5 + 5",main_dict); int five_squared = extract(main_dict["result"]); cout<<"extract value : "<>ij; } catch(error_already_set){ PyErr_Print(); cin>>ij; } doesn't work here is the python exception printed : Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object does not support item assignment although other test work : Py_Initialize(); object main_module = import("__main__"); object main_dict = main_module.attr("__dict__"); try{ handle<> ignored((PyRun_String( "result = 5 ** 2" , Py_file_input , main_dict.ptr() , main_dict.ptr()) )); int five_squared = extract(main_dict["result"]); cout<<"extract value : "<>ij; } catch(error_already_set){ PyErr_Print(); cin>>ij; } => WORK and Py_Initialize(); object main_module = import("__main__"); object main_dict = main_module.attr("__dict__"); try{ object result = eval("5 + 5",main_dict); int five_squared = extract(result); cout<<"extract value : "<>ij; } catch(error_already_set){ PyErr_Print(); cin>>ij; } => WORK TOO thanks, Aur?lien MAIGNAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From meine at informatik.uni-hamburg.de Tue Jun 3 19:20:04 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Tue, 3 Jun 2008 19:20:04 +0200 Subject: [C++-sig] Pyplusplus: operators <> not supported? Message-ID: <200806031920.06252.meine@informatik.uni-hamburg.de> Hi Roman, I have defined a class with shift operators: <<,>>,<<=,>>= Only the latter two in-place assignment-shift operators are recognized by py++. I have looked in the test suite and found pyplusplus_dev/unittests/data/operators_to_be_exported.hpp with the comment "Boost.Python does not support member operator<<", which indicates that you left them out for a purpose. However, it seems to work fine with boost 1.34.1 when I manually add the (self << int) def's, so maybe this is an old bug of boost::python which has been fixed since 2004? -- Ciao, / / /--/ / / ANS From roman.yakovenko at gmail.com Tue Jun 3 19:43:37 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 3 Jun 2008 20:43:37 +0300 Subject: [C++-sig] Pyplusplus: operators <> not supported? In-Reply-To: <200806031920.06252.meine@informatik.uni-hamburg.de> References: <200806031920.06252.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806031043p3b1dde58j6d5f00bb5abe29e3@mail.gmail.com> On Tue, Jun 3, 2008 at 8:20 PM, Hans Meine wrote: > Hi Roman, > > I have defined a class with shift operators: <<,>>,<<=,>>= > Only the latter two in-place assignment-shift operators are recognized by > py++. I have looked in the test suite and found > pyplusplus_dev/unittests/data/operators_to_be_exported.hpp with the > comment "Boost.Python does not support member operator<<", which indicates > that you left them out for a purpose. > > However, it seems to work fine with boost 1.34.1 when I manually add the (self > << int) def's, so maybe this is an old bug of boost::python which has been > fixed since 2004? I think there is small confusion, but it doesn't change the facts. Py++ doesn't support operators << and >> which write to some stream. I did not know that it is possible to define shift operators for classes. Can you point me to the relevant documentation? Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From matthew.scouten at gmail.com Tue Jun 3 21:24:13 2008 From: matthew.scouten at gmail.com (Matthew Scouten) Date: Tue, 3 Jun 2008 14:24:13 -0500 Subject: [C++-sig] inheritance and virtual callbacks Message-ID: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> So I have 2 classes, foo and bar. bar is a subclass of foo. Both bar and foo have virtual functions intended to be overridden form python. struct foo { foo(){} ; foo(int init_x, int init_y){x=init_x;y=init_y;}; int x; int y; virtual void FooCallback(){std::cout << "default foo called" << std::endl;}; }; struct bar : foo { bar(){} ; bar(int init_x, int init_y, int init_z):foo(init_x,init_y){z = init_z;}; virtual void BarCallback(){std::cout << "default bar called" << std::endl;}; int z; }; struct foo_wrapper : foo , wrapper { foo_wrapper(); foo_wrapper(const foo& f); foo_wrapper(int init_x, int init_y); virtual void FooCallback(); }; void foo_wrapper::FooCallback() { std::cout << "atemptting foo callback" << std::endl; if (override func = this->get_override("FooCallback")) { func(); return; } else std::cout << "foo callback function not found" << std::endl; } foo_wrapper::foo_wrapper(const foo& exch): foo(exch), wrapper(){} foo_wrapper::foo_wrapper(): foo(), wrapper(){} foo_wrapper::foo_wrapper(int init_x, int init_y) : foo(init_x,init_y), wrapper(){} struct bar_wrapper: bar, wrapper { bar_wrapper(); bar_wrapper(const bar& b); bar_wrapper(int init_x, int init_y, int init_z); virtual void BarCallback(); }; bar_wrapper::bar_wrapper(const bar& exch): bar(exch), wrapper(){} bar_wrapper::bar_wrapper(): bar(), wrapper(){} bar_wrapper::bar_wrapper(int init_x, int init_y, int init_z) : bar(init_x, init_y, init_z), wrapper(){} void bar_wrapper::BarCallback() { std::cout << "atemptting bar callback" << std::endl; if (override func = this->get_override("BarCallback")) { func(); return; } else std::cout << "bar callback function not found" << std::endl; } void backcaller(bar& b) { b.BarCallback(); b.FooCallback(); } BOOST_PYTHON_MODULE(busybox) { class_("foo") .def(init<>()) .def(init()) .ENABLE_COPY(foo) .def_readwrite("x", &foo::x ) .def_readonly ("y", &foo::y ) ; class_ >("bar") .def(init<>()) .def(init()) .ENABLE_COPY(bar) .def_readwrite("z", &bar::z) ; def("backcaller", &backcaller); } in python: >>> import busybox >>> class myBar(busybox.bar): ... def FooCallback(self): ... print "this is a foo callback" ... def BarCallback(self): ... print "this is a bar callback" ... >>> b = myBar() >>> busybox.backcaller(b) atemptting bar callback this is a bar callback default foo called >>> So the question is: why is the default FooCallback in foo getting called rather then the FooCallback in myBar? What can I do about it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Tue Jun 3 21:28:55 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 3 Jun 2008 22:28:55 +0300 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> Message-ID: <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> 2008/6/3 Matthew Scouten : > So I have 2 classes, foo and bar. bar is a subclass of foo. Both bar and foo > have virtual functions intended to be overridden form python. > > struct foo > { > foo(){} ; > foo(int init_x, int init_y){x=init_x;y=init_y;}; > int x; > int y; > > virtual void FooCallback(){std::cout << "default foo called" << > std::endl;}; > }; > > struct bar : foo > { > bar(){} ; > bar(int init_x, int init_y, int init_z):foo(init_x,init_y){z = init_z;}; > > virtual void BarCallback(){std::cout << "default bar called" << > std::endl;}; > > int z; > }; > > struct foo_wrapper : foo , wrapper > { > foo_wrapper(); > foo_wrapper(const foo& f); > foo_wrapper(int init_x, int init_y); > > virtual void FooCallback(); > }; > > void foo_wrapper::FooCallback() > { > std::cout << "atemptting foo callback" << std::endl; > if (override func = this->get_override("FooCallback")) > { > func(); > return; > } > else > std::cout << "foo callback function not found" << std::endl; > } > > foo_wrapper::foo_wrapper(const foo& exch): foo(exch), wrapper(){} > foo_wrapper::foo_wrapper(): foo(), wrapper(){} > foo_wrapper::foo_wrapper(int init_x, int init_y) : foo(init_x,init_y), > wrapper(){} > > struct bar_wrapper: bar, wrapper > { > bar_wrapper(); > bar_wrapper(const bar& b); > bar_wrapper(int init_x, int init_y, int init_z); > > virtual void BarCallback(); > }; > > bar_wrapper::bar_wrapper(const bar& exch): bar(exch), wrapper(){} > bar_wrapper::bar_wrapper(): bar(), wrapper(){} > bar_wrapper::bar_wrapper(int init_x, int init_y, int init_z) : bar(init_x, > init_y, init_z), wrapper(){} > > void bar_wrapper::BarCallback() > { > std::cout << "atemptting bar callback" << std::endl; > if (override func = this->get_override("BarCallback")) > { > func(); > return; > } > else > std::cout << "bar callback function not found" << std::endl; > } > > void backcaller(bar& b) > { > b.BarCallback(); > b.FooCallback(); > } > > BOOST_PYTHON_MODULE(busybox) > { > class_("foo") > .def(init<>()) > .def(init()) > .ENABLE_COPY(foo) > .def_readwrite("x", &foo::x ) > .def_readonly ("y", &foo::y ) > ; > > class_ >("bar") > .def(init<>()) > .def(init()) > .ENABLE_COPY(bar) > .def_readwrite("z", &bar::z) > ; > > def("backcaller", &backcaller); > } > > in python: >>>> import busybox >>>> class myBar(busybox.bar): add __init__ def __init__( self ): busybox.bar.__init__( self ) > ... def FooCallback(self): > ... print "this is a foo callback" > ... def BarCallback(self): > ... print "this is a bar callback" > ... >>>> b = myBar() >>>> busybox.backcaller(b) > atemptting bar callback > this is a bar callback > default foo called >>>> > > So the question is: why is the default FooCallback in foo getting called > rather then the FooCallback in myBar? > What can I do about it? > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From matthew.scouten at gmail.com Tue Jun 3 22:09:26 2008 From: matthew.scouten at gmail.com (Matthew Scouten) Date: Tue, 3 Jun 2008 15:09:26 -0500 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> Message-ID: <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> all right, yes. I forgot that. mea culpa. but it did not fix the problem : >>> import busybox >>> class myBar(busybox.bar): ... def __init__( self ): ... busybox.bar.__init__( self ) ... def FooCallback(self): ... print "this is a foo callback" ... def BarCallback(self): ... print "this is a bar callback" ... >>> b = myBar() >>> busybox.backcaller(b) atemptting bar callback this is a bar callback default foo called >>> See? still calls the wrong function. On Tue, Jun 3, 2008 at 2:28 PM, Roman Yakovenko wrote: > 2008/6/3 Matthew Scouten : > > So I have 2 classes, foo and bar. bar is a subclass of foo. Both bar and > foo > > have virtual functions intended to be overridden form python. > > > > struct foo > > { > > foo(){} ; > > foo(int init_x, int init_y){x=init_x;y=init_y;}; > > int x; > > int y; > > > > virtual void FooCallback(){std::cout << "default foo called" << > > std::endl;}; > > }; > > > > struct bar : foo > > { > > bar(){} ; > > bar(int init_x, int init_y, int init_z):foo(init_x,init_y){z = > init_z;}; > > > > virtual void BarCallback(){std::cout << "default bar called" << > > std::endl;}; > > > > int z; > > }; > > > > struct foo_wrapper : foo , wrapper > > { > > foo_wrapper(); > > foo_wrapper(const foo& f); > > foo_wrapper(int init_x, int init_y); > > > > virtual void FooCallback(); > > }; > > > > void foo_wrapper::FooCallback() > > { > > std::cout << "atemptting foo callback" << std::endl; > > if (override func = this->get_override("FooCallback")) > > { > > func(); > > return; > > } > > else > > std::cout << "foo callback function not found" << std::endl; > > } > > > > foo_wrapper::foo_wrapper(const foo& exch): foo(exch), wrapper(){} > > foo_wrapper::foo_wrapper(): foo(), wrapper(){} > > foo_wrapper::foo_wrapper(int init_x, int init_y) : foo(init_x,init_y), > > wrapper(){} > > > > struct bar_wrapper: bar, wrapper > > { > > bar_wrapper(); > > bar_wrapper(const bar& b); > > bar_wrapper(int init_x, int init_y, int init_z); > > > > virtual void BarCallback(); > > }; > > > > bar_wrapper::bar_wrapper(const bar& exch): bar(exch), wrapper(){} > > bar_wrapper::bar_wrapper(): bar(), wrapper(){} > > bar_wrapper::bar_wrapper(int init_x, int init_y, int init_z) : > bar(init_x, > > init_y, init_z), wrapper(){} > > > > void bar_wrapper::BarCallback() > > { > > std::cout << "atemptting bar callback" << std::endl; > > if (override func = this->get_override("BarCallback")) > > { > > func(); > > return; > > } > > else > > std::cout << "bar callback function not found" << std::endl; > > } > > > > void backcaller(bar& b) > > { > > b.BarCallback(); > > b.FooCallback(); > > } > > > > BOOST_PYTHON_MODULE(busybox) > > { > > class_("foo") > > .def(init<>()) > > .def(init()) > > .ENABLE_COPY(foo) > > .def_readwrite("x", &foo::x ) > > .def_readonly ("y", &foo::y ) > > ; > > > > class_ >("bar") > > .def(init<>()) > > .def(init()) > > .ENABLE_COPY(bar) > > .def_readwrite("z", &bar::z) > > ; > > > > def("backcaller", &backcaller); > > } > > > > in python: > >>>> import busybox > >>>> class myBar(busybox.bar): > > > add __init__ > > def __init__( self ): > busybox.bar.__init__( self ) > > > > ... def FooCallback(self): > > ... print "this is a foo callback" > > ... def BarCallback(self): > > ... print "this is a bar callback" > > ... > >>>> b = myBar() > >>>> busybox.backcaller(b) > > atemptting bar callback > > this is a bar callback > > default foo called > >>>> > > > > So the question is: why is the default FooCallback in foo getting called > > rather then the FooCallback in myBar? > > What can I do about it? > > > > > > _______________________________________________ > > C++-sig mailing list > > C++-sig at python.org > > http://mail.python.org/mailman/listinfo/c++-sig > > > > > > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Wed Jun 4 06:32:51 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 07:32:51 +0300 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> Message-ID: <7465b6170806032132g5a6aed5v331117a3cff3bba8@mail.gmail.com> 2008/6/3 Matthew Scouten : > all right, yes. I forgot that. mea culpa. > but it did not fix the problem : > See? still calls the wrong function. I missed that you didn't registered the functions. This is the code that was generated by Py++: #include "boost/python.hpp" #include "yyy.h" namespace bp = boost::python; struct foo_wrapper : foo, bp::wrapper< foo > { foo_wrapper(foo const & arg ) : foo( arg ) , bp::wrapper< foo >(){ // copy constructor } foo_wrapper( ) : foo( ) , bp::wrapper< foo >(){ // null constructor } foo_wrapper(int init_x, int init_y ) : foo( init_x, init_y ) , bp::wrapper< foo >(){ // constructor } virtual void FooCallback( ) { if( bp::override func_FooCallback = this->get_override( "FooCallback" ) ) func_FooCallback( ); else this->foo::FooCallback( ); } void default_FooCallback( ) { foo::FooCallback( ); } }; struct bar_wrapper : bar, bp::wrapper< bar > { bar_wrapper(bar const & arg ) : bar( arg ) , bp::wrapper< bar >(){ // copy constructor } bar_wrapper( ) : bar( ) , bp::wrapper< bar >(){ // null constructor } bar_wrapper(int init_x, int init_y, int init_z ) : bar( init_x, init_y, init_z ) , bp::wrapper< bar >(){ // constructor } virtual void BarCallback( ) { if( bp::override func_BarCallback = this->get_override( "BarCallback" ) ) func_BarCallback( ); else this->bar::BarCallback( ); } void default_BarCallback( ) { bar::BarCallback( ); } virtual void FooCallback( ) { if( bp::override func_FooCallback = this->get_override( "FooCallback" ) ) func_FooCallback( ); else this->foo::FooCallback( ); } void default_FooCallback( ) { foo::FooCallback( ); } }; BOOST_PYTHON_MODULE(pyplusplus){ bp::class_< foo_wrapper >( "foo" ) .def( bp::init< >() ) .def( bp::init< int, int >(( bp::arg("init_x"), bp::arg("init_y") )) ) .def( "FooCallback" , (void ( ::foo::* )( ) )(&::foo::FooCallback) , (void ( foo_wrapper::* )( ) )(&foo_wrapper::default_FooCallback) ) .def_readwrite( "x", &foo::x ) .def_readwrite( "y", &foo::y ); bp::class_< bar_wrapper, bp::bases< foo > >( "bar" ) .def( bp::init< >() ) .def( bp::init< int, int, int >(( bp::arg("init_x"), bp::arg("init_y"), bp::arg("init_z") )) ) .def( "BarCallback" , (void ( ::bar::* )( ) )(&::bar::BarCallback) , (void ( bar_wrapper::* )( ) )(&bar_wrapper::default_BarCallback) ) .def_readwrite( "z", &bar::z ) .def( "FooCallback" , (void ( ::foo::* )( ) )(&::foo::FooCallback) , (void ( bar_wrapper::* )( ) )(&bar_wrapper::default_FooCallback) ); { //::backcaller typedef void ( *backcaller_function_type )( ::bar & ); bp::def( "backcaller" , backcaller_function_type( &::backcaller ) , ( bp::arg("b") ) ); } } -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From meine at informatik.uni-hamburg.de Wed Jun 4 11:41:38 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 11:41:38 +0200 Subject: [C++-sig] Pyplusplus: operators <> not supported? In-Reply-To: <7465b6170806031043p3b1dde58j6d5f00bb5abe29e3@mail.gmail.com> References: <200806031920.06252.meine@informatik.uni-hamburg.de> <7465b6170806031043p3b1dde58j6d5f00bb5abe29e3@mail.gmail.com> Message-ID: <200806041141.40136.meine@informatik.uni-hamburg.de> Am Dienstag, 03. Juni 2008 19:43:37 schrieb Roman Yakovenko: > I think there is small confusion, but it doesn't change the facts. > Py++ doesn't support operators << and >> > which write to some stream. > > I did not know that it is possible to define shift operators for > classes. Can you point me to the relevant documentation? For Python or C++? Sorry if I state something obvious, but I am not sure what you're asking about, so here is both: In Python, it's __[i][l/r]shift__, in C++ it's simply a matter of defining operator<>/<<=/>>= like all other operators. Given your C++ skills, you probably meant the former, for which the docs are at http://docs.python.org/ref/numeric-types.html -- Ciao, / / /--/ / / ANS From roman.yakovenko at gmail.com Wed Jun 4 12:31:08 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 13:31:08 +0300 Subject: [C++-sig] Pyplusplus: operators <> not supported? In-Reply-To: <200806041141.40136.meine@informatik.uni-hamburg.de> References: <200806031920.06252.meine@informatik.uni-hamburg.de> <7465b6170806031043p3b1dde58j6d5f00bb5abe29e3@mail.gmail.com> <200806041141.40136.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806040331v65ef7c3eu2effee3e617c292b@mail.gmail.com> On Wed, Jun 4, 2008 at 12:41 PM, Hans Meine wrote: > Am Dienstag, 03. Juni 2008 19:43:37 schrieb Roman Yakovenko: >> I think there is small confusion, but it doesn't change the facts. >> Py++ doesn't support operators << and >> >> which write to some stream. >> >> I did not know that it is possible to define shift operators for >> classes. Can you point me to the relevant documentation? > > For Python or C++? Sorry if I state something obvious, but I am not sure what > you're asking about, so here is both: > > In Python, it's __[i][l/r]shift__, in C++ it's simply a matter of defining > operator<>/<<=/>>= like all other operators. Given your C++ skills, you > probably meant the former, for which the docs are at > http://docs.python.org/ref/numeric-types.html No, I meant C++ :-) I found some definitions in MSDN for shift operators, but I didn't see how I can redefine them for class. Py++ has to distinct between shift and stream operators. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From meine at informatik.uni-hamburg.de Wed Jun 4 13:23:35 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 13:23:35 +0200 Subject: [C++-sig] Pyplusplus: operators <> not supported? In-Reply-To: <7465b6170806040331v65ef7c3eu2effee3e617c292b@mail.gmail.com> References: <200806031920.06252.meine@informatik.uni-hamburg.de> <200806041141.40136.meine@informatik.uni-hamburg.de> <7465b6170806040331v65ef7c3eu2effee3e617c292b@mail.gmail.com> Message-ID: <200806041323.35912.meine@informatik.uni-hamburg.de> Am Mittwoch, 04. Juni 2008 12:31:08 schrieb Roman Yakovenko: > No, I meant C++ :-) > > I found some definitions in MSDN for shift operators, but I didn't see > how I can redefine them for class. > Py++ has to distinct between shift and stream operators. There is no technical distinction. Operators are like normal functions, i.e. you may decide yourself which argument and return types they have, and you may overload them. STL stream operators simply "abuse" the shift operator syntax for their purpose. HTH, / / /--/ / / ANS From meine at informatik.uni-hamburg.de Wed Jun 4 15:55:41 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 15:55:41 +0200 Subject: [C++-sig] Py++: automatic type aliases Message-ID: <200806041555.41696.meine@informatik.uni-hamburg.de> Hi Roman, I looked at the py++ source code in order to fix the fact that my classes often get the wrong alias. For instance, template class Vector2 {}; typedef Vector2 ShortVector2; class SomeOther { typedef Vector2 Vector; // class-internal typedef! }; Since "Vector" is shorter than "ShortVector2", it wins in the "be_smart" mode. Also, I am getting W1047 (There are two or more classes that use same alias("Base"). ...) because I often typedef complex base classes to "Base" in order to refer to Base::foo. Can py++ be made more "intelligent" by discarding scoped typedefs if there are global ones? (I did not find where self.aliases is filled and how to fix this.) I will send a separate post for proper class nesting.. -- Ciao, / / /--/ / / ANS From matthew.scouten at gmail.com Wed Jun 4 17:37:44 2008 From: matthew.scouten at gmail.com (Matthew Scouten) Date: Wed, 4 Jun 2008 10:37:44 -0500 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <7465b6170806032132g5a6aed5v331117a3cff3bba8@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> <7465b6170806032132g5a6aed5v331117a3cff3bba8@mail.gmail.com> Message-ID: <3dc9bcf00806040837o9625829n4c3062ca8c30126e@mail.gmail.com> Ah, I see that is going on. The important thing is not the registration. Registration is irrelevant unless things are getting called from python. My callbacks are only called from c++, and are overridden in python. The important difference to note here is that in the py++ code, FooCallback is separately wrapped in both foo and bar. That is exactly what I had hoped to avoid. I was afraid that would be the case. Thank you. On Tue, Jun 3, 2008 at 11:32 PM, Roman Yakovenko wrote: > 2008/6/3 Matthew Scouten : > > all right, yes. I forgot that. mea culpa. > > but it did not fix the problem : > > See? still calls the wrong function. > > I missed that you didn't registered the functions. > > This is the code that was generated by Py++: > #include "boost/python.hpp" > > #include "yyy.h" > > namespace bp = boost::python; > > struct foo_wrapper : foo, bp::wrapper< foo > { > > foo_wrapper(foo const & arg ) > : foo( arg ) > , bp::wrapper< foo >(){ > // copy constructor > > } > > foo_wrapper( ) > : foo( ) > , bp::wrapper< foo >(){ > // null constructor > > } > > foo_wrapper(int init_x, int init_y ) > : foo( init_x, init_y ) > , bp::wrapper< foo >(){ > // constructor > > } > > virtual void FooCallback( ) { > if( bp::override func_FooCallback = this->get_override( > "FooCallback" ) ) > func_FooCallback( ); > else > this->foo::FooCallback( ); > } > > > void default_FooCallback( ) { > foo::FooCallback( ); > } > > }; > > struct bar_wrapper : bar, bp::wrapper< bar > { > > bar_wrapper(bar const & arg ) > : bar( arg ) > , bp::wrapper< bar >(){ > // copy constructor > > } > > bar_wrapper( ) > : bar( ) > , bp::wrapper< bar >(){ > // null constructor > > } > > bar_wrapper(int init_x, int init_y, int init_z ) > : bar( init_x, init_y, init_z ) > , bp::wrapper< bar >(){ > // constructor > > } > > virtual void BarCallback( ) { > if( bp::override func_BarCallback = this->get_override( > "BarCallback" ) ) > func_BarCallback( ); > else > this->bar::BarCallback( ); > } > > > void default_BarCallback( ) { > bar::BarCallback( ); > } > > virtual void FooCallback( ) { > if( bp::override func_FooCallback = this->get_override( > "FooCallback" ) ) > func_FooCallback( ); > else > this->foo::FooCallback( ); > } > > > void default_FooCallback( ) { > foo::FooCallback( ); > } > > }; > > BOOST_PYTHON_MODULE(pyplusplus){ > bp::class_< foo_wrapper >( "foo" ) > .def( bp::init< >() ) > .def( bp::init< int, int >(( bp::arg("init_x"), > bp::arg("init_y") )) ) > .def( > "FooCallback" > , (void ( ::foo::* )( ) )(&::foo::FooCallback) > , (void ( foo_wrapper::* )( ) > )(&foo_wrapper::default_FooCallback) ) > .def_readwrite( "x", &foo::x ) > .def_readwrite( "y", &foo::y ); > > bp::class_< bar_wrapper, bp::bases< foo > >( "bar" ) > .def( bp::init< >() ) > .def( bp::init< int, int, int >(( bp::arg("init_x"), > bp::arg("init_y"), bp::arg("init_z") )) ) > .def( > "BarCallback" > , (void ( ::bar::* )( ) )(&::bar::BarCallback) > , (void ( bar_wrapper::* )( ) > )(&bar_wrapper::default_BarCallback) ) > .def_readwrite( "z", &bar::z ) > .def( > "FooCallback" > , (void ( ::foo::* )( ) )(&::foo::FooCallback) > , (void ( bar_wrapper::* )( ) > )(&bar_wrapper::default_FooCallback) ); > > { //::backcaller > > typedef void ( *backcaller_function_type )( ::bar & ); > > bp::def( > "backcaller" > , backcaller_function_type( &::backcaller ) > , ( bp::arg("b") ) ); > > } > } > > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meine at informatik.uni-hamburg.de Wed Jun 4 17:31:22 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 17:31:22 +0200 Subject: [C++-sig] Nesting classes in boost::python Message-ID: <200806041731.23398.meine@informatik.uni-hamburg.de> Hi again, [note: this is not really about py++!] I wondered why py++ does not properly scope the nested classes. For example, in order to expose a nested class Foo::Bar, I use bp::scope in my own code like this: { scope foo( class_("Foo") .def ... ); // normal class export decl. class_("Bar") .def ... ; } // close scope foo (i.e. "Foo") The only reason why I could imagine that py++ does not do so is that AFAIK this breaks pickling (and possibly more things?), since Foo.Bar.__name__ is "Bar" in Python, which does not allow the pickle module to locate the class correctly. :-( This is the reason for the more general subject I chose, because this may deserve a discussion and/or fix within the BPL?! -- Ciao, / / /--/ / / ANS From meine at informatik.uni-hamburg.de Wed Jun 4 17:36:01 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 17:36:01 +0200 Subject: [C++-sig] Nesting classes in boost::python In-Reply-To: <200806041731.23398.meine@informatik.uni-hamburg.de> References: <200806041731.23398.meine@informatik.uni-hamburg.de> Message-ID: <200806041736.02108.meine@informatik.uni-hamburg.de> Am Mittwoch, 04. Juni 2008 17:31:22 schrieb Hans Meine: > The only reason why I could imagine that py++ does not do so is that AFAIK > this breaks pickling (and possibly more things?), since Foo.Bar.__name__ > is "Bar" in Python, which does not allow the pickle module to locate the > class correctly. :-( Stupid me - I already pondered this in the past, experimented, and came to realize that this is not a BPL bug, but holds the same for pure Python. :-( Nevertheless, one could at least add a switch to py++ for optionally nesting classes, no? -- Ciao, / / /--/ / / ANS From roman.yakovenko at gmail.com Wed Jun 4 19:31:21 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 20:31:21 +0300 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <3dc9bcf00806040837o9625829n4c3062ca8c30126e@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> <7465b6170806032132g5a6aed5v331117a3cff3bba8@mail.gmail.com> <3dc9bcf00806040837o9625829n4c3062ca8c30126e@mail.gmail.com> Message-ID: <7465b6170806041031kb753a32m20f40144b81570f8@mail.gmail.com> 2008/6/4 Matthew Scouten : > Ah, I see that is going on. > > The important thing is not the registration. Registration is irrelevant > unless things are getting called from python. My callbacks are only called > from c++, and are overridden in python. > > The important difference to note here is that in the py++ code, FooCallback > is separately wrapped in both foo and bar. That is exactly what I had hoped > to avoid. I was afraid that would be the case. Don't afraid - use the right tool for the job :-) > Thank you. You are welcome. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Wed Jun 4 19:34:05 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 20:34:05 +0300 Subject: [C++-sig] Pyplusplus: operators <> not supported? In-Reply-To: <200806041356.26431.meine@informatik.uni-hamburg.de> References: <200806031920.06252.meine@informatik.uni-hamburg.de> <200806041141.40136.meine@informatik.uni-hamburg.de> <7465b6170806040331v65ef7c3eu2effee3e617c292b@mail.gmail.com> <200806041356.26431.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806041034x74a640e0sb3725783dbbd0e1e@mail.gmail.com> On Wed, Jun 4, 2008 at 2:56 PM, Hans Meine wrote: > Am Mittwoch, 04. Juni 2008 12:31:08 schrieb Roman Yakovenko: >> I found some definitions in MSDN for shift operators, but I didn't see >> how I can redefine them for class. >> Py++ has to distinct between shift and stream operators. > > BTW: currently I am using the following manual patch to add the operators: > .def( bp::self <<= bp::other< int >() ) > + .def( bp::self << bp::other< int >() ) > .def( bp::self == bp::self ) > .def( bp::self >>= bp::other< int >() ) > + .def( bp::self >> bp::other< int >() ) > > (Obviously, this would better be done with an appropriate py++ script, but > this is the first time I am using py++ and I do not yet know how this works.) Can you send me link to the shift operator definition within a class? It could be nice to see your class too. Take a look on next link, it will help you to modify generated code via Py++: http://language-binding.net/pyplusplus/documentation/inserting_code.html HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From meine at informatik.uni-hamburg.de Wed Jun 4 19:41:25 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Wed, 4 Jun 2008 19:41:25 +0200 Subject: [C++-sig] Pyplusplus: operators <> not supported? Message-ID: <200806041941.26052.meine@informatik.uni-hamburg.de> Hi Roman! Am Mittwoch, 04. Juni 2008 19:34:05 schrieben Sie: > Can you send me link to the shift operator definition within a class? I do not know any specific link to that. > It could be nice to see your class too. Attached is a simple variant of what I am doing. BTW: Note the double warning from py++ - the ugly-name-warning should IMHO be removed, since the operator is ignored anyway. > Take a look on next link, it will help you to modify generated code via > Py++: > http://language-binding.net/pyplusplus/documentation/inserting_code.html Thanks. I have already found that page in the meantime and successfully exploited the beauty of pygccxml. :-) -- Ciao, / / /--/ / / ANS -------------- next part -------------- #ifndef VECTOR_HXX #define VECTOR_HXX template class Vector2 { public: T x, y; Vector2(T ix, T iy) : x(ix), y(iy) {} Vector2 operator+(Vector2 const &other) const { return Vector2(x + other.x, y + other.y); } Vector2 operator<<(int shift) const { return Vector2(x << shift, y << shift); } Vector2 operator>>(int shift) const { return Vector2(x >> shift, y >> shift); } }; typedef Vector2 SVector2; #endif // VECTOR_HXX From roman.yakovenko at gmail.com Wed Jun 4 19:50:42 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 20:50:42 +0300 Subject: [C++-sig] Py++: automatic type aliases In-Reply-To: <200806041555.41696.meine@informatik.uni-hamburg.de> References: <200806041555.41696.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806041050vb1c704dxb65ac7e927cbacb1@mail.gmail.com> On Wed, Jun 4, 2008 at 4:55 PM, Hans Meine wrote: > Hi Roman, > > I looked at the py++ source code in order to fix the fact that my classes > often get the wrong alias. For instance, > > template > class Vector2 > {}; > > typedef Vector2 ShortVector2; > > class SomeOther > { > typedef Vector2 Vector; // class-internal typedef! > }; > > Since "Vector" is shorter than "ShortVector2", it wins in the "be_smart" mode. > Also, I am getting W1047 (There are two or more classes that use same > alias("Base"). ...) because I often typedef complex base classes to "Base" in > order to refer to Base::foo. Can py++ be made more "intelligent" by > discarding scoped typedefs if there are global ones? (I did not find where > self.aliases is filled and how to fix this.) There are few ways to rename class: 1. To use "rename" function: mb = module_builder_t( ... ) v = mb.class_( Vector< short > ) v.rename( 'Vector' ) 2. To define the alias within the source code: http://language-binding.net/pyplusplus/documentation/how_to/hints.html#pyplusplus-aliases-namespace HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Wed Jun 4 20:12:47 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 4 Jun 2008 21:12:47 +0300 Subject: [C++-sig] Nesting classes in boost::python In-Reply-To: <200806041736.02108.meine@informatik.uni-hamburg.de> References: <200806041731.23398.meine@informatik.uni-hamburg.de> <200806041736.02108.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806041112n302a66b0v63efd75ad9a90777@mail.gmail.com> On Wed, Jun 4, 2008 at 6:36 PM, Hans Meine wrote: > Am Mittwoch, 04. Juni 2008 17:31:22 schrieb Hans Meine: >> The only reason why I could imagine that py++ does not do so is that AFAIK >> this breaks pickling (and possibly more things?), since Foo.Bar.__name__ >> is "Bar" in Python, which does not allow the pickle module to locate the >> class correctly. :-( > > Stupid me - I already pondered this in the past, experimented, and came to > realize that this is not a BPL bug, but holds the same for pure Python. :-( > > Nevertheless, one could at least add a switch to py++ for optionally nesting > classes, no? I don't understand you - Py++ perfectly supports nested classes, no user action is needed. I attach example: C++ code and generated code. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.h Type: text/x-chdr Size: 2138 bytes Desc: not available URL: From dobbelsteen56 at hotmail.com Thu Jun 5 12:59:54 2008 From: dobbelsteen56 at hotmail.com (Alex Hartog) Date: Thu, 5 Jun 2008 10:59:54 +0000 (UTC) Subject: [C++-sig] Including C++ classes Message-ID: I am trying to include my own class in a C++ file which is used by boost. For some reason this does not work. I am certain this is not a C++ issue, because when I compile it without using boost, it does work. I am trying to include a simple class: "camera.h": #include using namespace std; class camera { public: camera(); string imagePath; }; "camera.cpp": #include "camera.h" camera::camera(){ } "main.cpp": #include "camera.h" .... camera *c = new camera; .... When is use bjam, I get the following error message: E:\Studie\Bachelor Afstudeer Project\Code\voxel_coloring>bjam warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 1176 targets... ...updating 2 targets... msvc.link.dll bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.pyd Creating library bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.lib an d object bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.exp voxel_coloring.obj : error LNK2019: unresolved external symbol "public: __thisca ll camera::camera(void)" (??0camera@@QAE at XZ) referenced in function "int __cdecl voxel_coloring2(class boost::python::list)" (? voxel_coloring2@@YAHVlist at python@ boost@@@Z) bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.pyd : fatal error LNK1120: 1 unresolved externals call "C:\Program Files (x86)\Microsoft Visual Studio 9.0 \VC\vcvarsall.ba t" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /subsystem:console /out:"bin\msvc-9.0 \d ebug\threading-multi\voxel_coloring_ext.pyd" /IMPLIB:"bin\msvc-9.0 \debug\threadi ng-multi\voxel_coloring_ext.lib" /LIBPATH:"C:\python25\libs" @"bin\msvc-9.0 \de bug\threading-multi\voxel_coloring_ext.pyd.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% if exist "bin\msvc-9.0\debug\threading- multi\voxel_coloring_ext.pyd.mani fest" ( mt -nologo -manifest "bin\msvc-9.0\debug\threading- multi\voxel_color ing_ext.pyd.manifest" "-outputresource:bin\msvc-9.0\debug\threading- multi\voxel_ coloring_ext.pyd;2" ) ...failed msvc.link.dll bin\msvc-9.0\debug\threading- multi\voxel_coloring_ext.py d bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.lib... ...removing bin\msvc-9.0\debug\threading-multi\voxel_coloring_ext.lib ...failed updating 2 targets... If I just declare the class inside my main file, it does not give any problems. Can anyone help me with this problem? From dobbelsteen56 at hotmail.com Thu Jun 5 16:16:08 2008 From: dobbelsteen56 at hotmail.com (Alex Hartog) Date: Thu, 5 Jun 2008 14:16:08 +0000 (UTC) Subject: [C++-sig] Including C++ classes References: Message-ID: I could simplify my problem by just asking: "How can I add a .cpp file to my project or do something like this?" From seefeld at sympatico.ca Thu Jun 5 16:35:26 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 05 Jun 2008 10:35:26 -0400 Subject: [C++-sig] Including C++ classes In-Reply-To: References: Message-ID: <4847F9AE.20309@sympatico.ca> Alex Hartog wrote: > I could simplify my problem by just asking: > "How can I add a .cpp file to my project or do something like this?" > I believe you are asking in the wrong forum. This list is about C++ / Python integration (mainly via boost.python), not about boost.build. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From dobbelsteen56 at hotmail.com Thu Jun 5 16:45:22 2008 From: dobbelsteen56 at hotmail.com (Alex Hartog) Date: Thu, 5 Jun 2008 14:45:22 +0000 (UTC) Subject: [C++-sig] Including C++ classes References: <4847F9AE.20309@sympatico.ca> Message-ID: Stefan Seefeld sympatico.ca> writes: > > I believe you are asking in the wrong forum. This list is about C++ / > Python integration (mainly via boost.python), not about boost.build. > > Regards, > Stefan > Okay, thanks, I am sorry, I will try asking there. From garyrob at mac.com Thu Jun 5 19:34:00 2008 From: garyrob at mac.com (Gary Robinson) Date: Thu, 05 Jun 2008 13:34:00 -0400 Subject: [C++-sig] ctypes newbie question Message-ID: <20080605133400421586.e9d22cd6@mac.com> On OS X 10.5.3, with Python 2.5.2, I have the following C function, called test2.c: ============== double testreturn(void) { return 105.0; } ============== I also have the following Python script: ============== from ctypes import * testreturnproto = CFUNCTYPE(c_double) testreturn = testreturnproto(CDLL('test2.dylib').testreturn) print 'prototype version returned: ', testreturn() testdll = CDLL('test2.dylib') testdll.testreturn.restype = c_double print 'non-prototype version returned:', testdll.testreturn() ============= Based on reading the ctypes docs, I would expect the output of the script to be: prototype version returned: 105.0 non-prototype version returned: 105.0 However, what I actually get is: prototype version returned: 872440.0 non-prototype version returned: 105.0 If I modify the python script by commenting out the assignment to restype, the new script and results are: ================ from ctypes import * testreturnproto = CFUNCTYPE(c_double) testreturn = testreturnproto(CDLL('test2.dylib').testreturn) print 'prototype version returned: ', testreturn() testdll = CDLL('test2.dylib') #testdll.testreturn.restype = c_double print 'non-prototype version returned:', testdll.testreturn() ================ prototype version returned: 872440.0 non-prototype version returned: 872440 I assume that this means that the double 105.0 is being interpreted as if it were an int, since the default result type as an int. What I don't understand is why the line testreturnproto = CFUNCTYPE(c_double) is apparently not causing the return type to be properly interpreted as a double. We know that it's ultimately causing a Python float to be created, since the printed output ends with .0. So it has received the information that the number is supposed to be a float. But it's still interpreting it as an int before instantiating it as a float. The ctypes reference describes CFUNCTYPE as follows: > CFUNCTYPE(restype, *argtypes) > The returned function prototype creates functions that use the > standard C calling convention. I am passing c_double as restype. So why is it apparently interpreting the result as an int? I guess I don't understand the purpose of instantiating a prototype with CFUNCTYPE if it doesn't take care of interpreting the result as the type you give it. Any insight/help would be appreciated. Thanks, Gary -- Gary Robinson CTO Emergent Music, LLC personal email: garyrob at mac.com work email: grobinson at emergentmusic.com Company: http://www.emergentmusic.com Blog: http://www.garyrobinson.net From matthew.scouten at gmail.com Thu Jun 5 20:07:02 2008 From: matthew.scouten at gmail.com (Matthew Scouten) Date: Thu, 5 Jun 2008 13:07:02 -0500 Subject: [C++-sig] inheritance and virtual callbacks In-Reply-To: <7465b6170806041031kb753a32m20f40144b81570f8@mail.gmail.com> References: <3dc9bcf00806031224u3ceca638k4775a0dc868ffa44@mail.gmail.com> <7465b6170806031228p42501230tfc514352bdc49117@mail.gmail.com> <3dc9bcf00806031309p62cf2433p252b68cffdae9285@mail.gmail.com> <7465b6170806032132g5a6aed5v331117a3cff3bba8@mail.gmail.com> <3dc9bcf00806040837o9625829n4c3062ca8c30126e@mail.gmail.com> <7465b6170806041031kb753a32m20f40144b81570f8@mail.gmail.com> Message-ID: <3dc9bcf00806051107x1ab32b00te60f58b8c8a7060a@mail.gmail.com> I would love to use the right tool, but as I mentioned in another thread ( http://mail.python.org/pipermail/c++-sig/2007-November/013078.html) our library code is too spicy for gccxml. It gets an internal compiler error. On Wed, Jun 4, 2008 at 12:31 PM, Roman Yakovenko wrote: > 2008/6/4 Matthew Scouten : > > Ah, I see that is going on. > > > > The important thing is not the registration. Registration is irrelevant > > unless things are getting called from python. My callbacks are only > called > > from c++, and are overridden in python. > > > > The important difference to note here is that in the py++ code, > FooCallback > > is separately wrapped in both foo and bar. That is exactly what I had > hoped > > to avoid. I was afraid that would be the case. > > Don't afraid - use the right tool for the job :-) > > > Thank you. > > You are welcome. > > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Thu Jun 5 20:33:04 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 5 Jun 2008 21:33:04 +0300 Subject: [C++-sig] ctypes newbie question In-Reply-To: <20080605133400421586.e9d22cd6@mac.com> References: <20080605133400421586.e9d22cd6@mac.com> Message-ID: <7465b6170806051133p47b3b016v79c4d25d021526a7@mail.gmail.com> On Thu, Jun 5, 2008 at 8:34 PM, Gary Robinson wrote: > On OS X 10.5.3, with Python 2.5.2, I have the following C function, called test2.c: > > ============== > double testreturn(void) > { > return 105.0; > } > ============== > > I also have the following Python script: > > ============== > from ctypes import * > > testreturnproto = CFUNCTYPE(c_double) > testreturn = testreturnproto(CDLL('test2.dylib').testreturn) > print 'prototype version returned: ', testreturn() > > testdll = CDLL('test2.dylib') > testdll.testreturn.restype = c_double > print 'non-prototype version returned:', testdll.testreturn() > ============= > > Based on reading the ctypes docs, I would expect the output of the script to be: > > prototype version returned: 105.0 > non-prototype version returned: 105.0 > > However, what I actually get is: > > prototype version returned: 872440.0 > non-prototype version returned: 105.0 > > If I modify the python script by commenting out the assignment to restype, the new script and results are: > > ================ > from ctypes import * > > testreturnproto = CFUNCTYPE(c_double) > testreturn = testreturnproto(CDLL('test2.dylib').testreturn) > print 'prototype version returned: ', testreturn() > > testdll = CDLL('test2.dylib') > #testdll.testreturn.restype = c_double > print 'non-prototype version returned:', testdll.testreturn() > ================ > > prototype version returned: 872440.0 > non-prototype version returned: 872440 > > I assume that this means that the double 105.0 is being interpreted as if it were an int, since the default result type as an int. > > What I don't understand is why the line > > testreturnproto = CFUNCTYPE(c_double) > > is apparently not causing the return type to be properly interpreted as a double. We know that it's ultimately causing a Python float to be created, since the printed output ends with .0. So it has received the information that the number is supposed to be a float. But it's still interpreting it as an int before instantiating it as a float. > > The ctypes reference describes CFUNCTYPE as follows: > >> CFUNCTYPE(restype, *argtypes) >> The returned function prototype creates functions that use the >> standard C calling convention. > > I am passing c_double as restype. So why is it apparently interpreting the result as an int? > > I guess I don't understand the purpose of instantiating a prototype with CFUNCTYPE if it doesn't take care of interpreting the result as the type you give it. > > Any insight/help would be appreciated. > You'd better ask this question on ctypes mailing list ( https://lists.sourceforge.net/lists/listinfo/ctypes-users ). You also can take a look on one of my projects( http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/pygccxml/msvc/bsc/ ). I use ctypes to wrap bsc ( browse source code ) API. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From amaignan at gmail.com Fri Jun 6 15:31:43 2008 From: amaignan at gmail.com (=?ISO-8859-1?Q?Aur=E9lien_MAIGNAN?=) Date: Fri, 6 Jun 2008 15:31:43 +0200 Subject: [C++-sig] Problem extending python (using external DLL) Message-ID: <2131ea990806060631w241f42c6s16d59990322cc6a8@mail.gmail.com> Hi I've got a problem that need an more exp person than me to deal with it : I've got a naive class for testing interfacing with python using boost.python. Since we use OSG 1.2 for our work, I also wanted to do basic stuff using this library (http://www.openscenegraph.org/projects/osg/wiki/Downloads/PreviousReleasessee 1.2 version of OSG) problem is that doesn't work anymore when using this lib. So i worked around this issue and after a while (up to now in fact) it result in this more simple problem (minimize the code to highlight the problem) : I have a code like this in C++ : .h #ifndef HELLOMONDE_H #define HELLOMONDE_H #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include using namespace std; using namespace boost::python; class PyCpp { private : string _s; bool misFileNameNativeStyle(const std::string& fileName) { #ifdef WIN32 return fileName.find('/') == std::string::npos; // return true if no unix style slash exist #else return fileName.find('\\') == std::string::npos; // return true if no windows style slash exist #endif }; public : PyCpp(string s); void call_myfunc(); void set(string s); string get(); }; inline void PyCpp::set(string s){_s = s;} inline string PyCpp::get(){return _s;} #endif .c++ #include "PyCpp.h" using namespace std; PyCpp::PyCpp(string s):_s(s){} void PyCpp::call_myfunc() { std::string ap = "C:/WINDOWS/Fonts/impact.ttf"; misFileNameNativeStyle(ap); // * LINE 1 * osgDB::isFileNameNativeStyle(ap);// * LINE 2 * } wrapping file : .cpp // This file has been generated by Py++. #include "boost/python.hpp" #include "f:/testpythoncpp/pycpp/pycpp.h" namespace bp = boost::python; BOOST_PYTHON_MODULE(PyCpp_ext){ bp::class_< PyCpp >( "PyCpp", bp::init< std::string >(( bp::arg("s") )) ) .def( "get" , &::PyCpp::get ) .def( "set" , &::PyCpp::set , ( bp::arg("s") ) ) .def( "call_myfunc" , &::PyCpp::call_myfunc ); bp::implicitly_convertible< std::string, PyCpp >(); } .py (for the local test) import PyCpp_ext myPy = PyCpp_ext.PyCpp("bonjour monde") print myPy.get() myPy.call_myfunc() osgDB::FileNameUtils.cpp .... blablabla .... bool osgDB::isFileNameNativeStyle(const std::string& fileName) { #ifdef WIN32 return fileName.find('/') == std::string::npos; // return true if no unix style slash exist #else return fileName.find('\\') == std::string::npos; // return true if no windows style slash exist #endif } .... blablabla .... So as you can see i rewrote my own osgDB::isFileNameNativeStyle() function (called misFileNameNativeStyle()) and the inner code is the same and finally the jamroot file : # Copyright David Abrahams 2006. Distributed under the Boost # Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) # Specify the path to the Boost project. If you move this project, # adjust this path to refer to the Boost root directory. use-project boost : "C:/Program Files/boost/boost_1_35_0" ; # Set up the project-wide requirements that everything uses the # boost_python library from the project whose global ID is # /boost/python. project : requirements /boost/python//boost_python C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/osg.lib C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/osgProducer.lib C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/osgText.lib C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/osgGA.lib C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/osgDB.lib C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/lib/Producer.lib : requirements C:/libs/OSG_OP_OT-1.2/OpenSceneGraph/include ; # Declare the three extension modules. You can specify multiple # source files after the colon separated by spaces. python-extension PyCpp_ext : bindings.cpp PyCpp.h PyCpp.cpp ; # A little "rule" (function) to clean up the syntax of declaring tests # of these extension modules. local rule run-test ( test-name : sources + ) { import testing ; testing.make-test run-pyd : $(sources) : : $(test-name) ; } # Declare test targets run-test hello : PyCpp_ext PyCpp.py ; So what's happen when using the bjam tools ? : --> When * LINE 1 * is commented (/* */) or not the local test crash : you can see a beautiful "send me a report" Microsoft style from python .exe with this AppName: python.exe AppVer: 0.0.0.0 ModName: msvcr80.dll ModVer: 8.0.50727.1433 Offset: 000503e2 --> When * LINE 2 * is commented (/* */) it works ! Ok so i gone further in this and since I've access to the osg sources i decided to recompile and rebuild the osgDB.dll osgDB::FileNameUtils.cpp has been modified like this : bool osgDB::isFileNameNativeStyle(const std::string& fileName) { fileName.find('/'); // * LINE 3 * return true; } and the resulting new osdDB.dll generated used for the local test Again what's happen ? : --> When * LINE 3 * is commented (/* */) it works ! --> When * LINE 3 * isn't commented (/* */) it crash in the same way !!! My guess is it's about the std::string::find(char) function .... but if so, why does it work when called in my own function misFileNameNativeStyle() ???? If anyone could help me with this ;) thanks, Aur?lien MAIGNAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From meine at informatik.uni-hamburg.de Sun Jun 8 22:28:04 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Sun, 8 Jun 2008 22:28:04 +0200 Subject: [C++-sig] Py++ exposing default constructors twice? Message-ID: <200806082228.13430.meine@informatik.uni-hamburg.de> Hi, py++ generates code like this: bp::class_< Foo >( "Foo" ) .def( bp::init< >() ) ... AFAIK, the first like already exposes the default constructor (since no_init was not given), thus I would expect the second line to be superfluous?! Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From pyspuc at gmail.com Mon Jun 9 17:25:20 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Mon, 9 Jun 2008 08:25:20 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 Message-ID: Hi, My c++ code that worked fine for Boost_1_33_1 (building with v1 system) is now giving the following error with 1_35_0: Boost.Python.ArgumentError: Python argument types in spucb.butterworth_iir.butterworth_iir(iir_coeff, float) did not match C++ signature: butterworth_iir(iir_coeff {lvalue}, float) I done a lot of searching to find out what changed in the newer Boost/boost build system and could not figure out what to do. Below is all of the code for a simple testcase. Since I have lots of code that is broken in this way, I'm wondering if there is an easy change that can be made to the boost wrapping code (or source itself) to make this functional. Is there a simple example of how this problem is solved. Was there a fundamental reason this is no longer supported? Thanks Tony ------------------------------------------ class iir_coeff { public: long order; public: iir_coeff(long ord=1); ~iir_coeff(); }; ------------------------------------------ #include "iir_coeff.h" iir_coeff::iir_coeff(long ord) { order = ord; } iir_coeff::~iir_coeff() {} ------------------------------------------ // Boost Includes ============================================================== #include #include // Includes ==================================================================== #include "iir_coeff.h" // Using ======================================================================= using namespace boost::python; // Module ====================================================================== BOOST_PYTHON_MODULE(iir_coeff) { class_< iir_coeff >("iir_coeff", init< const iir_coeff& >()) .def(init< optional< long int > >()) .def_readwrite("order", &iir_coeff::order) ; } ------------------------------------------ #include "iir_coeff.h" void butterworth_iir(iir_coeff& filt, float fcd); ------------------------------------------ #include "butterworth_iir.h" void butterworth_iir(iir_coeff& filt, float fcd) { long order = filt.order; filt.order = order+1; } ------------------------------------------ // Boost Includes ============================================================== #include #include // Includes ==================================================================== #include "butterworth_iir.h" // Using ======================================================================= using namespace boost::python; // Module ====================================================================== BOOST_PYTHON_MODULE(butterworth_iir) { def("butterworth_iir", &butterworth_iir); } ------------------------------------------ use-project boost : ../../boost_1_35_0 ; project : requirements /boost/python//boost_python/static : usage-requirements ../../boost_1_35_0 . ; lib spuc : butterworth_iir.cpp iir_coeff.cpp : . ../../boost_1_35_0 ; alias staticspuc : spuc/static ; import python ; python-extension butterworth_iir : py_butterworth_iir.cpp : . ../../boost_1_35_0 : staticspuc ; python-extension iir_coeff : py_iir_coeff.cpp : . ../../boost_1_35_0 : staticspuc ; install dist : __init__.py butterworth_iir iir_coeff : /usr/lib/python2.4/site-packages/spucb ; ------------------------------------------ boost-build ../../boost_1_35_0/tools/build/v2 ; ------------------------------------------ from spucb.butterworth_iir import * from spucb.iir_coeff import * x=iir_coeff(8) butterworth_iir(x,0.24) print x.order ------------------------------------------ Traceback (most recent call last): File "tes.py", line 4, in ? butterworth_iir(x,0.24) Boost.Python.ArgumentError: Python argument types in spucb.butterworth_iir.butterworth_iir(iir_coeff, float) did not match C++ signature: butterworth_iir(iir_coeff {lvalue}, float) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwgk at yahoo.com Mon Jun 9 19:36:07 2008 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Mon, 9 Jun 2008 10:36:07 -0700 (PDT) Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 Message-ID: <188492.25493.qm@web31102.mail.mud.yahoo.com> I stared at your code for a few minutes but I don't have an answer for you. It looks like it should work. I'm not aware of changes in Boost.Python that could make your code fail. I'd probably try to reverse the import order: from spucb.iir_coeff import * from spucb.butterworth_iir import * although I don't expect this to make a difference. Ralf ----- Original Message ---- From: Tony Kirke To: c++-sig at python.org Sent: Monday, June 9, 2008 8:25:20 AM Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 Hi, My c++ code that worked fine for Boost_1_33_1 (building with v1 system) is now giving the following error with 1_35_0: Boost.Python.ArgumentError: Python argument types in spucb.butterworth_iir.butterworth_iir(iir_coeff, float) did not match C++ signature: butterworth_iir(iir_coeff {lvalue}, float) I done a lot of searching to find out what changed in the newer Boost/boost build system and could not figure out what to do. Below is all of the code for a simple testcase. Since I have lots of code that is broken in this way, I'm wondering if there is an easy change that can be made to the boost wrapping code (or source itself) to make this functional. Is there a simple example of how this problem is solved. Was there a fundamental reason this is no longer supported? Thanks Tony ------------------------------------------ class iir_coeff { public: long order; public: iir_coeff(long ord=1); ~iir_coeff(); }; ------------------------------------------ #include "iir_coeff.h" iir_coeff::iir_coeff(long ord) { order = ord; } iir_coeff::~iir_coeff() {} ------------------------------------------ // Boost Includes ============================================================== #include #include // Includes ==================================================================== #include "iir_coeff.h" // Using ======================================================================= using namespace boost::python; // Module ====================================================================== BOOST_PYTHON_MODULE(iir_coeff) { class_< iir_coeff >("iir_coeff", init< const iir_coeff& >()) .def(init< optional< long int > >()) .def_readwrite("order", &iir_coeff::order) ; } ------------------------------------------ #include "iir_coeff.h" void butterworth_iir(iir_coeff& filt, float fcd); ------------------------------------------ #include "butterworth_iir.h" void butterworth_iir(iir_coeff& filt, float fcd) { long order = filt.order; filt.order = order+1; } ------------------------------------------ // Boost Includes ============================================================== #include #include // Includes ==================================================================== #include "butterworth_iir.h" // Using ======================================================================= using namespace boost::python; // Module ====================================================================== BOOST_PYTHON_MODULE(butterworth_iir) { def("butterworth_iir", &butterworth_iir); } ------------------------------------------ use-project boost : ../../boost_1_35_0 ; project : requirements /boost/python//boost_python/static : usage-requirements ../../boost_1_35_0 . ; lib spuc : butterworth_iir.cpp iir_coeff.cpp : . ../../boost_1_35_0 ; alias staticspuc : spuc/static ; import python ; python-extension butterworth_iir : py_butterworth_iir.cpp : . ../../boost_1_35_0 : staticspuc ; python-extension iir_coeff : py_iir_coeff.cpp : . ../../boost_1_35_0 : staticspuc ; install dist : __init__.py butterworth_iir iir_coeff : /usr/lib/python2.4/site-packages/spucb ; ------------------------------------------ boost-build ../../boost_1_35_0/tools/build/v2 ; ------------------------------------------ from spucb.butterworth_iir import * from spucb.iir_coeff import * x=iir_coeff(8) butterworth_iir(x,0.24) print x.order ------------------------------------------ Traceback (most recent call last): File "tes.py", line 4, in ? butterworth_iir(x,0.24) Boost.Python.ArgumentError: Python argument types in spucb.butterworth_iir.butterworth_iir(iir_coeff, float) did not match C++ signature: butterworth_iir(iir_coeff {lvalue}, float) -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Mon Jun 9 19:54:39 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Mon, 9 Jun 2008 20:54:39 +0300 Subject: [C++-sig] Py++ exposing default constructors twice? In-Reply-To: <200806082228.13430.meine@informatik.uni-hamburg.de> References: <200806082228.13430.meine@informatik.uni-hamburg.de> Message-ID: <7465b6170806091054s6f064698k1d67901789e2e269@mail.gmail.com> 2008/6/8 Hans Meine : > Hi, > > py++ generates code like this: > > bp::class_< Foo >( "Foo" ) > .def( bp::init< >() ) > ... > > AFAIK, the first like already exposes the default constructor (since no_init > was not given), thus I would expect the second line to be superfluous?! You are right . There few cases, where Py++ generates not optimal code. This specific case is one of them. Class registration and construction is tricky. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From grant.tang at gmail.com Tue Jun 10 01:12:53 2008 From: grant.tang at gmail.com (Grant) Date: Mon, 9 Jun 2008 18:12:53 -0500 Subject: [C++-sig] boost.python not working in Visual Studio 2005? Message-ID: Hi, I am using Python 2.5.2 installed from msi file downloaded from pyhton.org. I have a project which compiles and works in Visual Studio 2003 C++ on WinXP. Now I switch to Visual Studio 2005 C++ compiler. I compiled my boost.python 1.34.1 with VS2005, then compiled my project with this boost.python library. The compilation goes OK, but I can not import any library into python. The Python interpreter just complian no such library file exist. I check the path should be fine. I even change to the library path to import it, but still no luck. Then I tried boost.python 1.35, compiled it with VS2005. But it's the same result. I checked my dll library and the python library, I notice the python2.5 library is compiled with VS2003, since it linked to VS2003 runtime. Could that be the problem? Should I compile Python 2.5.2 from source with VS2005? Thanks for your help, Grant From nat at lindenlab.com Tue Jun 10 02:04:06 2008 From: nat at lindenlab.com (Nat Goodspeed) Date: Mon, 09 Jun 2008 20:04:06 -0400 Subject: [C++-sig] boost.python not working in Visual Studio 2005? In-Reply-To: References: Message-ID: <484DC4F6.4000602@lindenlab.com> Grant wrote: > The compilation goes OK, but I can not import any > library into python. The Python interpreter just complian no such library > file exist. I check the path should be fine. > > I checked my dll library and the python library, I notice the python2.5 > library is compiled with VS2003, since it linked to VS2003 runtime. Could > that be the problem? Should I compile Python 2.5.2 from source with VS2005? Did you just change to Python 2.5? You said you're building a .dll library? Try renaming that to .pyd. See the last item on this page: http://docs.python.org/whatsnew/ports.html#SECTION0001510000000000000000 If Python finds the extension module but detects a version mismatch, you usually get a different error. From pyspuc at gmail.com Tue Jun 10 03:58:28 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Mon, 9 Jun 2008 18:58:28 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: <188492.25493.qm@web31102.mail.mud.yahoo.com> References: <188492.25493.qm@web31102.mail.mud.yahoo.com> Message-ID: Thanks Ralf, I tried reversing the order to no avail. I'm attached a gzipped tar file of the example, if anyone would like to try it. I'd be grateful to confirm if there is an issue or not. Only things that may need to be edited would be path to boost_1_35_0 and python 2.4/2.5 Tony 2008/6/9 Ralf W. Grosse-Kunstleve : > I stared at your code for a few minutes but I don't have an answer > for you. It looks like it should work. I'm not aware of changes in > Boost.Python that could make your code fail. > I'd probably try to reverse the import order: > > from spucb.iir_coeff import * > from spucb.butterworth_iir import * > > although I don't expect this to make a difference. > > Ralf > > > ----- Original Message ---- > From: Tony Kirke > To: c++-sig at python.org > Sent: Monday, June 9, 2008 8:25:20 AM > Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to > 1_35_0 > > Hi, > My c++ code that worked fine for Boost_1_33_1 (building with v1 system) is > now giving the following error with 1_35_0: > > Boost.Python.ArgumentError: Python argument types in > spucb.butterworth_iir.butterworth_iir(iir_coeff, float) > did not match C++ signature: > butterworth_iir(iir_coeff {lvalue}, float) > > I done a lot of searching to find out what changed in the newer Boost/boost > build system and could not figure out what to do. > Below is all of the code for a simple testcase. Since I have lots of code > that is broken in this way, I'm wondering if there is an easy change that > can be made to the boost wrapping code (or source itself) to make this > functional. Is there a simple example of how this problem is solved. Was > there a fundamental reason this is no longer supported? > Thanks > > Tony > > ------------------------------------------ > class iir_coeff > { > public: > long order; > > public: > iir_coeff(long ord=1); > ~iir_coeff(); > }; > ------------------------------------------ > #include "iir_coeff.h" > iir_coeff::iir_coeff(long ord) { > order = ord; > } > iir_coeff::~iir_coeff() {} > ------------------------------------------ > // Boost Includes > ============================================================== > #include > #include > > // Includes > ==================================================================== > #include "iir_coeff.h" > > // Using > ======================================================================= > using namespace boost::python; > > // Module > ====================================================================== > BOOST_PYTHON_MODULE(iir_coeff) > { > class_< iir_coeff >("iir_coeff", init< const iir_coeff& >()) > .def(init< optional< long int > >()) > .def_readwrite("order", &iir_coeff::order) > ; > > } > ------------------------------------------ > #include "iir_coeff.h" > void butterworth_iir(iir_coeff& filt, float fcd); > ------------------------------------------ > #include "butterworth_iir.h" > void butterworth_iir(iir_coeff& filt, float fcd) { > long order = filt.order; > filt.order = order+1; > } > ------------------------------------------ > // Boost Includes > ============================================================== > #include > #include > > // Includes > ==================================================================== > #include "butterworth_iir.h" > > // Using > ======================================================================= > using namespace boost::python; > > // Module > ====================================================================== > BOOST_PYTHON_MODULE(butterworth_iir) > { > def("butterworth_iir", &butterworth_iir); > } > > ------------------------------------------ > use-project boost : ../../boost_1_35_0 ; > > project > : requirements /boost/python//boost_python/static > : usage-requirements ../../boost_1_35_0 . > ; > > lib spuc : > butterworth_iir.cpp > iir_coeff.cpp > : > . > ../../boost_1_35_0 > > ; > > alias staticspuc : spuc/static ; > > import python ; > > > python-extension butterworth_iir : py_butterworth_iir.cpp : . > ../../boost_1_35_0 : staticspuc ; > python-extension iir_coeff : py_iir_coeff.cpp : . > ../../boost_1_35_0 : staticspuc ; > > install dist : > __init__.py > butterworth_iir > iir_coeff > : > /usr/lib/python2.4/site-packages/spucb > ; > > ------------------------------------------ > boost-build ../../boost_1_35_0/tools/build/v2 ; > ------------------------------------------ > > from spucb.butterworth_iir import * > from spucb.iir_coeff import * > x=iir_coeff(8) > butterworth_iir(x,0.24) > print x.order > > ------------------------------------------ > Traceback (most recent call last): > File "tes.py", line 4, in ? > butterworth_iir(x,0.24) > Boost.Python.ArgumentError: Python argument types in > spucb.butterworth_iir.butterworth_iir(iir_coeff, float) > did not match C++ signature: > butterworth_iir(iir_coeff {lvalue}, float) > > > > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase.tar.gz Type: application/x-gzip Size: 1620 bytes Desc: not available URL: From pyspuc at gmail.com Tue Jun 10 05:05:47 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Mon, 9 Jun 2008 20:05:47 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: References: <188492.25493.qm@web31102.mail.mud.yahoo.com> Message-ID: Sorry, couldn't attach file. It is available here: http://pyspuc.com/testcase.tar.gz On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: > Thanks Ralf, > I tried reversing the order to no avail. I'm attached a gzipped tar file of > the example, if anyone would like to try it. I'd be grateful to confirm if > there is an issue or not. Only things that may need to be edited would be > path to boost_1_35_0 and python 2.4/2.5 > Tony > > 2008/6/9 Ralf W. Grosse-Kunstleve : > >> I stared at your code for a few minutes but I don't have an answer >> for you. It looks like it should work. I'm not aware of changes in >> Boost.Python that could make your code fail. >> I'd probably try to reverse the import order: >> >> from spucb.iir_coeff import * >> from spucb.butterworth_iir import * >> >> although I don't expect this to make a difference. >> >> Ralf >> >> >> ----- Original Message ---- >> From: Tony Kirke >> To: c++-sig at python.org >> Sent: Monday, June 9, 2008 8:25:20 AM >> Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to >> 1_35_0 >> >> Hi, >> My c++ code that worked fine for Boost_1_33_1 (building with v1 system) is >> now giving the following error with 1_35_0: >> >> Boost.Python.ArgumentError: Python argument types in >> spucb.butterworth_iir.butterworth_iir(iir_coeff, float) >> did not match C++ signature: >> butterworth_iir(iir_coeff {lvalue}, float) >> >> I done a lot of searching to find out what changed in the newer >> Boost/boost build system and could not figure out what to do. >> Below is all of the code for a simple testcase. Since I have lots of code >> that is broken in this way, I'm wondering if there is an easy change that >> can be made to the boost wrapping code (or source itself) to make this >> functional. Is there a simple example of how this problem is solved. Was >> there a fundamental reason this is no longer supported? >> Thanks >> >> Tony >> >> ------------------------------------------ >> class iir_coeff >> { >> public: >> long order; >> >> public: >> iir_coeff(long ord=1); >> ~iir_coeff(); >> }; >> ------------------------------------------ >> #include "iir_coeff.h" >> iir_coeff::iir_coeff(long ord) { >> order = ord; >> } >> iir_coeff::~iir_coeff() {} >> ------------------------------------------ >> // Boost Includes >> ============================================================== >> #include >> #include >> >> // Includes >> ==================================================================== >> #include "iir_coeff.h" >> >> // Using >> ======================================================================= >> using namespace boost::python; >> >> // Module >> ====================================================================== >> BOOST_PYTHON_MODULE(iir_coeff) >> { >> class_< iir_coeff >("iir_coeff", init< const iir_coeff& >()) >> .def(init< optional< long int > >()) >> .def_readwrite("order", &iir_coeff::order) >> ; >> >> } >> ------------------------------------------ >> #include "iir_coeff.h" >> void butterworth_iir(iir_coeff& filt, float fcd); >> ------------------------------------------ >> #include "butterworth_iir.h" >> void butterworth_iir(iir_coeff& filt, float fcd) { >> long order = filt.order; >> filt.order = order+1; >> } >> ------------------------------------------ >> // Boost Includes >> ============================================================== >> #include >> #include >> >> // Includes >> ==================================================================== >> #include "butterworth_iir.h" >> >> // Using >> ======================================================================= >> using namespace boost::python; >> >> // Module >> ====================================================================== >> BOOST_PYTHON_MODULE(butterworth_iir) >> { >> def("butterworth_iir", &butterworth_iir); >> } >> >> ------------------------------------------ >> use-project boost : ../../boost_1_35_0 ; >> >> project >> : requirements /boost/python//boost_python/static >> : usage-requirements ../../boost_1_35_0 . >> ; >> >> lib spuc : >> butterworth_iir.cpp >> iir_coeff.cpp >> : >> . >> ../../boost_1_35_0 >> >> ; >> >> alias staticspuc : spuc/static ; >> >> import python ; >> >> >> python-extension butterworth_iir : py_butterworth_iir.cpp : . >> ../../boost_1_35_0 : staticspuc ; >> python-extension iir_coeff : py_iir_coeff.cpp : . >> ../../boost_1_35_0 : staticspuc ; >> >> install dist : >> __init__.py >> butterworth_iir >> iir_coeff >> : >> /usr/lib/python2.4/site-packages/spucb >> ; >> >> ------------------------------------------ >> boost-build ../../boost_1_35_0/tools/build/v2 ; >> ------------------------------------------ >> >> from spucb.butterworth_iir import * >> from spucb.iir_coeff import * >> x=iir_coeff(8) >> butterworth_iir(x,0.24) >> print x.order >> >> ------------------------------------------ >> Traceback (most recent call last): >> File "tes.py", line 4, in ? >> butterworth_iir(x,0.24) >> Boost.Python.ArgumentError: Python argument types in >> spucb.butterworth_iir.butterworth_iir(iir_coeff, float) >> did not match C++ signature: >> butterworth_iir(iir_coeff {lvalue}, float) >> >> >> >> >> >> >> _______________________________________________ >> C++-sig mailing list >> C++-sig at python.org >> http://mail.python.org/mailman/listinfo/c++-sig >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Rougier at loria.fr Tue Jun 10 09:01:55 2008 From: Nicolas.Rougier at loria.fr (Nicolas Rougier) Date: Tue, 10 Jun 2008 09:01:55 +0200 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: References: <188492.25493.qm@web31102.mail.mud.yahoo.com> Message-ID: <1213081317.29944.5.camel@sulfur.loria.fr> I tested the code on linux using the attached makefile (I'm not familiar with bjam) and things are working ok (got 9 as a result of tes.py). Is there any chance you're not loading the module you think you're loading (from a previous installation of your python modules for example) ? Nicolas Makefile: --------- all: g++ butterworth_iir.cpp -shared -o libbutterworth_iir.so g++ py_butterworth_iir.cpp -I/usr/include/python2.5 -L . -lboost_python -lbutterworth_iir -shared -o butterworth_iir.so g++ iir_coeff.cpp -shared -o libiir_coeff.so g++ py_iir_coeff.cpp -I/usr/include/python2.5 -L . -liir_coeff -lboost_python -shared -o iir_coeff.so clean: rm *.so On Mon, 2008-06-09 at 20:05 -0700, Tony Kirke wrote: > Sorry, couldn't attach file. It is available here: > > http://pyspuc.com/testcase.tar.gz > > On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: > Thanks Ralf, > I tried reversing the order to no avail. I'm attached a > gzipped tar file of the example, if anyone would like to try > it. I'd be grateful to confirm if there is an issue or not. > Only things that may need to be edited would be path to > boost_1_35_0 and python 2.4/2.5 > Tony > > 2008/6/9 Ralf W. Grosse-Kunstleve : > > I stared at your code for a few minutes but I don't > have an answer > for you. It looks like it should work. I'm not aware > of changes in > Boost.Python that could make your code fail. > I'd probably try to reverse the import order: > > > from spucb.iir_coeff import * > from spucb.butterworth_iir import * > > > although I don't expect this to make a difference. > > Ralf > > > > ----- Original Message ---- > From: Tony Kirke > To: c++-sig at python.org > Sent: Monday, June 9, 2008 8:25:20 AM > Subject: [C++-sig] Help with problem caused going from > boost_1_33_1 to 1_35_0 > > Hi, > My c++ code that worked fine for Boost_1_33_1 > (building with v1 system) is now giving the following > error with 1_35_0: > > Boost.Python.ArgumentError: Python argument types in > spucb.butterworth_iir.butterworth_iir(iir_coeff, > float) > did not match C++ signature: > butterworth_iir(iir_coeff {lvalue}, float) > > I done a lot of searching to find out what changed in > the newer Boost/boost build system and could not > figure out what to do. > Below is all of the code for a simple testcase. Since > I have lots of code that is broken in this way, I'm > wondering if there is an easy change that can be made > to the boost wrapping code (or source itself) to make > this functional. Is there a simple example of how > this problem is solved. Was there a fundamental reason > this is no longer supported? > Thanks > > Tony > > ------------------------------------------ > class iir_coeff > { > public: > long order; > > public: > iir_coeff(long ord=1); > ~iir_coeff(); > }; > ------------------------------------------ > #include "iir_coeff.h" > iir_coeff::iir_coeff(long ord) { > order = ord; > } > iir_coeff::~iir_coeff() {} > ------------------------------------------ > // Boost Includes > ============================================================== > #include > #include > > // Includes > ==================================================================== > #include "iir_coeff.h" > > // Using > ======================================================================= > using namespace boost::python; > > // Module > ====================================================================== > BOOST_PYTHON_MODULE(iir_coeff) > { > class_< iir_coeff >("iir_coeff", init< const > iir_coeff& >()) > .def(init< optional< long int > >()) > .def_readwrite("order", &iir_coeff::order) > ; > > } > ------------------------------------------ > #include "iir_coeff.h" > void butterworth_iir(iir_coeff& filt, float fcd); > ------------------------------------------ > #include "butterworth_iir.h" > void butterworth_iir(iir_coeff& filt, float fcd) { > long order = filt.order; > filt.order = order+1; > } > ------------------------------------------ > // Boost Includes > ============================================================== > #include > #include > > // Includes > ==================================================================== > #include "butterworth_iir.h" > > // Using > ======================================================================= > using namespace boost::python; > > // Module > ====================================================================== > BOOST_PYTHON_MODULE(butterworth_iir) > { > def("butterworth_iir", &butterworth_iir); > } > > ------------------------------------------ > use-project boost : ../../boost_1_35_0 ; > > project > : requirements > /boost/python//boost_python/static > : usage-requirements ../../boost_1_35_0 > . > ; > > lib spuc : > butterworth_iir.cpp > iir_coeff.cpp > : > . > ../../boost_1_35_0 > > ; > > alias staticspuc : spuc/static ; > > import python ; > > > python-extension butterworth_iir : > py_butterworth_iir.cpp : . > ../../boost_1_35_0 : staticspuc ; > python-extension iir_coeff : py_iir_coeff.cpp : > . ../../boost_1_35_0 : > staticspuc ; > > install dist : > __init__.py > butterworth_iir > iir_coeff > : > > /usr/lib/python2.4/site-packages/spucb > ; > > ------------------------------------------ > boost-build ../../boost_1_35_0/tools/build/v2 ; > ------------------------------------------ > > from spucb.butterworth_iir import * > from spucb.iir_coeff import * > x=iir_coeff(8) > butterworth_iir(x,0.24) > print x.order > > ------------------------------------------ > Traceback (most recent call last): > File "tes.py", line 4, in ? > butterworth_iir(x,0.24) > Boost.Python.ArgumentError: Python argument types in > spucb.butterworth_iir.butterworth_iir(iir_coeff, > float) > did not match C++ signature: > butterworth_iir(iir_coeff {lvalue}, float) > > > > > > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From david at ar.media.kyoto-u.ac.jp Tue Jun 10 08:43:07 2008 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Tue, 10 Jun 2008 15:43:07 +0900 Subject: [C++-sig] boost.python not working in Visual Studio 2005? In-Reply-To: References: Message-ID: <484E227B.4040708@ar.media.kyoto-u.ac.jp> Grant wrote: > > I checked my dll library and the python library, I notice the python2.5 > library is compiled with VS2003, since it linked to VS2003 runtime. Could > that be the problem? Should I compile Python 2.5.2 from source with VS2005? Not that I know what your error is, but you will get problems using extensions built with 2005 on a python built with 2003: http://msdn.microsoft.com/en-us/library/ms235460(VS.80).aspx It is likely to bit you for most non trivial extensions, David From j.reid at mail.cryst.bbk.ac.uk Tue Jun 10 09:49:15 2008 From: j.reid at mail.cryst.bbk.ac.uk (John Reid) Date: Tue, 10 Jun 2008 08:49:15 +0100 Subject: [C++-sig] boost.python not working in Visual Studio 2005? In-Reply-To: References: Message-ID: Grant wrote: > I checked my dll library and the python library, I notice the python2.5 > library is compiled with VS2003, since it linked to VS2003 runtime. Could > that be the problem? Should I compile Python 2.5.2 from source with VS2005? > boost.python works just fine for me with a VS2003 built python 2.5 and my extensions built under VS2005. Are you using boost.build to build your extensions? If not perhaps you're linking against boost.python dlls from your older compiler. John. From pyspuc at gmail.com Tue Jun 10 16:55:17 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Tue, 10 Jun 2008 07:55:17 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: <1213081317.29944.5.camel@sulfur.loria.fr> References: <188492.25493.qm@web31102.mail.mud.yahoo.com> <1213081317.29944.5.camel@sulfur.loria.fr> Message-ID: Thank Nicolas, I tried your makefile and am still getting a problem. I can only imagine that there is something wrong with my libboost_python.a file or a g++ issue. I also am running on linux with gcc 4.1.2 Tony On Tue, Jun 10, 2008 at 12:01 AM, Nicolas Rougier wrote: > > > I tested the code on linux using the attached makefile (I'm not familiar > with bjam) and things are working ok (got 9 as a result of tes.py). > > Is there any chance you're not loading the module you think you're > loading (from a previous installation of your python modules for > example) ? > > > Nicolas > > > > Makefile: > --------- > > all: > g++ butterworth_iir.cpp -shared -o libbutterworth_iir.so > g++ py_butterworth_iir.cpp -I/usr/include/python2.5 -L . > -lboost_python > -lbutterworth_iir -shared -o butterworth_iir.so > > g++ iir_coeff.cpp -shared -o libiir_coeff.so > g++ py_iir_coeff.cpp -I/usr/include/python2.5 -L . -liir_coeff > -lboost_python -shared -o iir_coeff.so > > clean: > rm *.so > > > > On Mon, 2008-06-09 at 20:05 -0700, Tony Kirke wrote: > > Sorry, couldn't attach file. It is available here: > > > > http://pyspuc.com/testcase.tar.gz > > > > On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: > > Thanks Ralf, > > I tried reversing the order to no avail. I'm attached a > > gzipped tar file of the example, if anyone would like to try > > it. I'd be grateful to confirm if there is an issue or not. > > Only things that may need to be edited would be path to > > boost_1_35_0 and python 2.4/2.5 > > Tony > > > > 2008/6/9 Ralf W. Grosse-Kunstleve : > > > > I stared at your code for a few minutes but I don't > > have an answer > > for you. It looks like it should work. I'm not aware > > of changes in > > Boost.Python that could make your code fail. > > I'd probably try to reverse the import order: > > > > > > from spucb.iir_coeff import * > > from spucb.butterworth_iir import * > > > > > > although I don't expect this to make a difference. > > > > Ralf > > > > > > > > ----- Original Message ---- > > From: Tony Kirke > > To: c++-sig at python.org > > Sent: Monday, June 9, 2008 8:25:20 AM > > Subject: [C++-sig] Help with problem caused going from > > boost_1_33_1 to 1_35_0 > > > > Hi, > > My c++ code that worked fine for Boost_1_33_1 > > (building with v1 system) is now giving the following > > error with 1_35_0: > > > > Boost.Python.ArgumentError: Python argument types in > > spucb.butterworth_iir.butterworth_iir(iir_coeff, > > float) > > did not match C++ signature: > > butterworth_iir(iir_coeff {lvalue}, float) > > > > I done a lot of searching to find out what changed in > > the newer Boost/boost build system and could not > > figure out what to do. > > Below is all of the code for a simple testcase. Since > > I have lots of code that is broken in this way, I'm > > wondering if there is an easy change that can be made > > to the boost wrapping code (or source itself) to make > > this functional. Is there a simple example of how > > this problem is solved. Was there a fundamental reason > > this is no longer supported? > > Thanks > > > > Tony > > > > ------------------------------------------ > > class iir_coeff > > { > > public: > > long order; > > > > public: > > iir_coeff(long ord=1); > > ~iir_coeff(); > > }; > > ------------------------------------------ > > #include "iir_coeff.h" > > iir_coeff::iir_coeff(long ord) { > > order = ord; > > } > > iir_coeff::~iir_coeff() {} > > ------------------------------------------ > > // Boost Includes > > > ============================================================== > > #include > > #include > > > > // Includes > > > ==================================================================== > > #include "iir_coeff.h" > > > > // Using > > > ======================================================================= > > using namespace boost::python; > > > > // Module > > > ====================================================================== > > BOOST_PYTHON_MODULE(iir_coeff) > > { > > class_< iir_coeff >("iir_coeff", init< const > > iir_coeff& >()) > > .def(init< optional< long int > >()) > > .def_readwrite("order", &iir_coeff::order) > > ; > > > > } > > ------------------------------------------ > > #include "iir_coeff.h" > > void butterworth_iir(iir_coeff& filt, float fcd); > > ------------------------------------------ > > #include "butterworth_iir.h" > > void butterworth_iir(iir_coeff& filt, float fcd) { > > long order = filt.order; > > filt.order = order+1; > > } > > ------------------------------------------ > > // Boost Includes > > > ============================================================== > > #include > > #include > > > > // Includes > > > ==================================================================== > > #include "butterworth_iir.h" > > > > // Using > > > ======================================================================= > > using namespace boost::python; > > > > // Module > > > ====================================================================== > > BOOST_PYTHON_MODULE(butterworth_iir) > > { > > def("butterworth_iir", &butterworth_iir); > > } > > > > ------------------------------------------ > > use-project boost : ../../boost_1_35_0 ; > > > > project > > : requirements > > /boost/python//boost_python/static > > : usage-requirements ../../boost_1_35_0 > > . > > ; > > > > lib spuc : > > butterworth_iir.cpp > > iir_coeff.cpp > > : > > . > > ../../boost_1_35_0 > > > > ; > > > > alias staticspuc : spuc/static ; > > > > import python ; > > > > > > python-extension butterworth_iir : > > py_butterworth_iir.cpp : . > > ../../boost_1_35_0 : staticspuc ; > > python-extension iir_coeff : py_iir_coeff.cpp : > > . ../../boost_1_35_0 : > > staticspuc ; > > > > install dist : > > __init__.py > > butterworth_iir > > iir_coeff > > : > > > > /usr/lib/python2.4/site-packages/spucb > > ; > > > > ------------------------------------------ > > boost-build ../../boost_1_35_0/tools/build/v2 ; > > ------------------------------------------ > > > > from spucb.butterworth_iir import * > > from spucb.iir_coeff import * > > x=iir_coeff(8) > > butterworth_iir(x,0.24) > > print x.order > > > > ------------------------------------------ > > Traceback (most recent call last): > > File "tes.py", line 4, in ? > > butterworth_iir(x,0.24) > > Boost.Python.ArgumentError: Python argument types in > > spucb.butterworth_iir.butterworth_iir(iir_coeff, > > float) > > did not match C++ signature: > > butterworth_iir(iir_coeff {lvalue}, float) > > > > > > > > > > > > > > > > > > _______________________________________________ > > C++-sig mailing list > > C++-sig at python.org > > http://mail.python.org/mailman/listinfo/c++-sig > > > > > > > > _______________________________________________ > > C++-sig mailing list > > C++-sig at python.org > > http://mail.python.org/mailman/listinfo/c++-sig > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grant.tang at gmail.com Tue Jun 10 17:34:46 2008 From: grant.tang at gmail.com (Grant) Date: Tue, 10 Jun 2008 10:34:46 -0500 Subject: [C++-sig] boost.python not working in Visual Studio 2005? References: <484DC4F6.4000602@lindenlab.com> Message-ID: "Nat Goodspeed" wrote in message news:484DC4F6.4000602 at lindenlab.com... > Grant wrote: > >> The compilation goes OK, but I can not import any library into python. >> The Python interpreter just complian no such library file exist. I check >> the path should be fine. >> >> I checked my dll library and the python library, I notice the python2.5 >> library is compiled with VS2003, since it linked to VS2003 runtime. Could >> that be the problem? Should I compile Python 2.5.2 from source with >> VS2005? > > Did you just change to Python 2.5? You said you're building a .dll > library? Try renaming that to .pyd. See the last item on this page: > http://docs.python.org/whatsnew/ports.html#SECTION0001510000000000000000 > > If Python finds the extension module but detects a version mismatch, you > usually get a different error. Thank you Nat. This solves my problem. Grant From pyspuc at gmail.com Tue Jun 10 17:51:21 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Tue, 10 Jun 2008 08:51:21 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: References: <188492.25493.qm@web31102.mail.mud.yahoo.com> <1213081317.29944.5.camel@sulfur.loria.fr> Message-ID: Any suggestions on how to debug this with gdb? I had trouble trying to set breakpoints and resorted to adding printf statements. It's definitely getting the newest built libboost_python file and the local shared objects newly created. On Tue, Jun 10, 2008 at 7:55 AM, Tony Kirke wrote: > Thank Nicolas, > I tried your makefile and am still getting a problem. I can only imagine > that there is something wrong with my libboost_python.a file or a g++ issue. > I also am running on linux with gcc 4.1.2 > Tony > > > On Tue, Jun 10, 2008 at 12:01 AM, Nicolas Rougier < > Nicolas.Rougier at loria.fr> wrote: > >> >> >> I tested the code on linux using the attached makefile (I'm not familiar >> with bjam) and things are working ok (got 9 as a result of tes.py). >> >> Is there any chance you're not loading the module you think you're >> loading (from a previous installation of your python modules for >> example) ? >> >> >> Nicolas >> >> >> >> Makefile: >> --------- >> >> all: >> g++ butterworth_iir.cpp -shared -o libbutterworth_iir.so >> g++ py_butterworth_iir.cpp -I/usr/include/python2.5 -L . >> -lboost_python >> -lbutterworth_iir -shared -o butterworth_iir.so >> >> g++ iir_coeff.cpp -shared -o libiir_coeff.so >> g++ py_iir_coeff.cpp -I/usr/include/python2.5 -L . -liir_coeff >> -lboost_python -shared -o iir_coeff.so >> >> clean: >> rm *.so >> >> >> >> On Mon, 2008-06-09 at 20:05 -0700, Tony Kirke wrote: >> > Sorry, couldn't attach file. It is available here: >> > >> > http://pyspuc.com/testcase.tar.gz >> > >> > On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: >> > Thanks Ralf, >> > I tried reversing the order to no avail. I'm attached a >> > gzipped tar file of the example, if anyone would like to try >> > it. I'd be grateful to confirm if there is an issue or not. >> > Only things that may need to be edited would be path to >> > boost_1_35_0 and python 2.4/2.5 >> > Tony >> > >> > 2008/6/9 Ralf W. Grosse-Kunstleve : >> > >> > I stared at your code for a few minutes but I don't >> > have an answer >> > for you. It looks like it should work. I'm not aware >> > of changes in >> > Boost.Python that could make your code fail. >> > I'd probably try to reverse the import order: >> > >> > >> > from spucb.iir_coeff import * >> > from spucb.butterworth_iir import * >> > >> > >> > although I don't expect this to make a difference. >> > >> > Ralf >> > >> > >> > >> > ----- Original Message ---- >> > From: Tony Kirke >> > To: c++-sig at python.org >> > Sent: Monday, June 9, 2008 8:25:20 AM >> > Subject: [C++-sig] Help with problem caused going from >> > boost_1_33_1 to 1_35_0 >> > >> > Hi, >> > My c++ code that worked fine for Boost_1_33_1 >> > (building with v1 system) is now giving the following >> > error with 1_35_0: >> > >> > Boost.Python.ArgumentError: Python argument types in >> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >> > float) >> > did not match C++ signature: >> > butterworth_iir(iir_coeff {lvalue}, float) >> > >> > I done a lot of searching to find out what changed in >> > the newer Boost/boost build system and could not >> > figure out what to do. >> > Below is all of the code for a simple testcase. Since >> > I have lots of code that is broken in this way, I'm >> > wondering if there is an easy change that can be made >> > to the boost wrapping code (or source itself) to make >> > this functional. Is there a simple example of how >> > this problem is solved. Was there a fundamental reason >> > this is no longer supported? >> > Thanks >> > >> > Tony >> > >> > ------------------------------------------ >> > class iir_coeff >> > { >> > public: >> > long order; >> > >> > public: >> > iir_coeff(long ord=1); >> > ~iir_coeff(); >> > }; >> > ------------------------------------------ >> > #include "iir_coeff.h" >> > iir_coeff::iir_coeff(long ord) { >> > order = ord; >> > } >> > iir_coeff::~iir_coeff() {} >> > ------------------------------------------ >> > // Boost Includes >> > >> ============================================================== >> > #include >> > #include >> > >> > // Includes >> > >> ==================================================================== >> > #include "iir_coeff.h" >> > >> > // Using >> > >> ======================================================================= >> > using namespace boost::python; >> > >> > // Module >> > >> ====================================================================== >> > BOOST_PYTHON_MODULE(iir_coeff) >> > { >> > class_< iir_coeff >("iir_coeff", init< const >> > iir_coeff& >()) >> > .def(init< optional< long int > >()) >> > .def_readwrite("order", &iir_coeff::order) >> > ; >> > >> > } >> > ------------------------------------------ >> > #include "iir_coeff.h" >> > void butterworth_iir(iir_coeff& filt, float fcd); >> > ------------------------------------------ >> > #include "butterworth_iir.h" >> > void butterworth_iir(iir_coeff& filt, float fcd) { >> > long order = filt.order; >> > filt.order = order+1; >> > } >> > ------------------------------------------ >> > // Boost Includes >> > >> ============================================================== >> > #include >> > #include >> > >> > // Includes >> > >> ==================================================================== >> > #include "butterworth_iir.h" >> > >> > // Using >> > >> ======================================================================= >> > using namespace boost::python; >> > >> > // Module >> > >> ====================================================================== >> > BOOST_PYTHON_MODULE(butterworth_iir) >> > { >> > def("butterworth_iir", &butterworth_iir); >> > } >> > >> > ------------------------------------------ >> > use-project boost : ../../boost_1_35_0 ; >> > >> > project >> > : requirements >> > /boost/python//boost_python/static >> > : usage-requirements ../../boost_1_35_0 >> > . >> > ; >> > >> > lib spuc : >> > butterworth_iir.cpp >> > iir_coeff.cpp >> > : >> > . >> > ../../boost_1_35_0 >> > >> > ; >> > >> > alias staticspuc : spuc/static ; >> > >> > import python ; >> > >> > >> > python-extension butterworth_iir : >> > py_butterworth_iir.cpp : . >> > ../../boost_1_35_0 : staticspuc ; >> > python-extension iir_coeff : py_iir_coeff.cpp : >> > . ../../boost_1_35_0 : >> > staticspuc ; >> > >> > install dist : >> > __init__.py >> > butterworth_iir >> > iir_coeff >> > : >> > >> > /usr/lib/python2.4/site-packages/spucb >> > ; >> > >> > ------------------------------------------ >> > boost-build ../../boost_1_35_0/tools/build/v2 ; >> > ------------------------------------------ >> > >> > from spucb.butterworth_iir import * >> > from spucb.iir_coeff import * >> > x=iir_coeff(8) >> > butterworth_iir(x,0.24) >> > print x.order >> > >> > ------------------------------------------ >> > Traceback (most recent call last): >> > File "tes.py", line 4, in ? >> > butterworth_iir(x,0.24) >> > Boost.Python.ArgumentError: Python argument types in >> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >> > float) >> > did not match C++ signature: >> > butterworth_iir(iir_coeff {lvalue}, float) >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > C++-sig mailing list >> > C++-sig at python.org >> > http://mail.python.org/mailman/listinfo/c++-sig >> > >> > >> > >> > _______________________________________________ >> > C++-sig mailing list >> > C++-sig at python.org >> > http://mail.python.org/mailman/listinfo/c++-sig >> >> _______________________________________________ >> C++-sig mailing list >> C++-sig at python.org >> http://mail.python.org/mailman/listinfo/c++-sig >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtang at bcm.tmc.edu Tue Jun 10 17:33:41 2008 From: gtang at bcm.tmc.edu (Tang, Guang) Date: Tue, 10 Jun 2008 10:33:41 -0500 Subject: [C++-sig] boost.python not working in Visual Studio 2005? Message-ID: "Nat Goodspeed" wrote in message news:<484DC4F6.4000602 at lindenlab.com>... > Grant wrote: > > > The compilation goes OK, but I can not import any > > library into python. The Python interpreter just complian no such library > > file exist. I check the path should be fine. > > > > I checked my dll library and the python library, I notice the python2.5 > > library is compiled with VS2003, since it linked to VS2003 runtime. Could > > that be the problem? Should I compile Python 2.5.2 from source with VS2005? > > Did you just change to Python 2.5? You said you're building a .dll > library? Try renaming that to .pyd. See the last item on this page: > http://docs.python.org/whatsnew/ports.html#SECTION0001510000000000000000 > > If Python finds the extension module but detects a version mismatch, you > usually get a different error. Thank you nat. This solves my problem. Grant From jason.kankiewicz at gmail.com Wed Jun 11 16:58:40 2008 From: jason.kankiewicz at gmail.com (Jason Kankiewicz) Date: Wed, 11 Jun 2008 07:58:40 -0700 Subject: [C++-sig] Py++: Class registration code insertion order (patch) Message-ID: In order to solve a registration order problem, I needed to make my hand-written method overload get registered prior to the method overloads generated by Py++. I have patched the pyplusplus.decl_wrappers.class_t class to provide the same control over registration code insertion order that the pyplusplus.module_builder.module_builder_t class provides. I have also patched the pyplusplus.module_creator.creator_t class to utilize the new registration code retrieval properties of the pyplusplus.decl_wrappers.class_t class. The attached patch is against r1326 of pyplusplus_dev. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pyplusplus_class_registration_code.patch URL: From pyspuc at gmail.com Thu Jun 12 01:31:15 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Wed, 11 Jun 2008 16:31:15 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: References: <188492.25493.qm@web31102.mail.mud.yahoo.com> <1213081317.29944.5.camel@sulfur.loria.fr> Message-ID: Still trying to figure out what is wrong here. Using Nicholas's makefile on a newer Ubuntu system with python2.5 and libboost_python binaries installed (1.34.1), I got this to work (Thanks Nicolas) I've narrowed it down to the fact that linking to installed static library works but locally built libboost_python fails. Not sure if this is a 1_35_0 vs 1_34_1 issue or something else Thanks On Tue, Jun 10, 2008 at 8:51 AM, Tony Kirke wrote: > Any suggestions on how to debug this with gdb? I had trouble trying to set > breakpoints and resorted to adding printf statements. It's definitely > getting the newest built libboost_python file and the local shared objects > newly created. > > > On Tue, Jun 10, 2008 at 7:55 AM, Tony Kirke wrote: > >> Thank Nicolas, >> I tried your makefile and am still getting a problem. I can only imagine >> that there is something wrong with my libboost_python.a file or a g++ issue. >> I also am running on linux with gcc 4.1.2 >> Tony >> >> >> On Tue, Jun 10, 2008 at 12:01 AM, Nicolas Rougier < >> Nicolas.Rougier at loria.fr> wrote: >> >>> >>> >>> I tested the code on linux using the attached makefile (I'm not familiar >>> with bjam) and things are working ok (got 9 as a result of tes.py). >>> >>> Is there any chance you're not loading the module you think you're >>> loading (from a previous installation of your python modules for >>> example) ? >>> >>> >>> Nicolas >>> >>> >>> >>> Makefile: >>> --------- >>> >>> all: >>> g++ butterworth_iir.cpp -shared -o libbutterworth_iir.so >>> g++ py_butterworth_iir.cpp -I/usr/include/python2.5 -L . >>> -lboost_python >>> -lbutterworth_iir -shared -o butterworth_iir.so >>> >>> g++ iir_coeff.cpp -shared -o libiir_coeff.so >>> g++ py_iir_coeff.cpp -I/usr/include/python2.5 -L . -liir_coeff >>> -lboost_python -shared -o iir_coeff.so >>> >>> clean: >>> rm *.so >>> >>> >>> >>> On Mon, 2008-06-09 at 20:05 -0700, Tony Kirke wrote: >>> > Sorry, couldn't attach file. It is available here: >>> > >>> > http://pyspuc.com/testcase.tar.gz >>> > >>> > On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: >>> > Thanks Ralf, >>> > I tried reversing the order to no avail. I'm attached a >>> > gzipped tar file of the example, if anyone would like to try >>> > it. I'd be grateful to confirm if there is an issue or not. >>> > Only things that may need to be edited would be path to >>> > boost_1_35_0 and python 2.4/2.5 >>> > Tony >>> > >>> > 2008/6/9 Ralf W. Grosse-Kunstleve : >>> > >>> > I stared at your code for a few minutes but I don't >>> > have an answer >>> > for you. It looks like it should work. I'm not aware >>> > of changes in >>> > Boost.Python that could make your code fail. >>> > I'd probably try to reverse the import order: >>> > >>> > >>> > from spucb.iir_coeff import * >>> > from spucb.butterworth_iir import * >>> > >>> > >>> > although I don't expect this to make a difference. >>> > >>> > Ralf >>> > >>> > >>> > >>> > ----- Original Message ---- >>> > From: Tony Kirke >>> > To: c++-sig at python.org >>> > Sent: Monday, June 9, 2008 8:25:20 AM >>> > Subject: [C++-sig] Help with problem caused going from >>> > boost_1_33_1 to 1_35_0 >>> > >>> > Hi, >>> > My c++ code that worked fine for Boost_1_33_1 >>> > (building with v1 system) is now giving the following >>> > error with 1_35_0: >>> > >>> > Boost.Python.ArgumentError: Python argument types in >>> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >>> > float) >>> > did not match C++ signature: >>> > butterworth_iir(iir_coeff {lvalue}, float) >>> > >>> > I done a lot of searching to find out what changed in >>> > the newer Boost/boost build system and could not >>> > figure out what to do. >>> > Below is all of the code for a simple testcase. Since >>> > I have lots of code that is broken in this way, I'm >>> > wondering if there is an easy change that can be made >>> > to the boost wrapping code (or source itself) to make >>> > this functional. Is there a simple example of how >>> > this problem is solved. Was there a fundamental reason >>> > this is no longer supported? >>> > Thanks >>> > >>> > Tony >>> > >>> > ------------------------------------------ >>> > class iir_coeff >>> > { >>> > public: >>> > long order; >>> > >>> > public: >>> > iir_coeff(long ord=1); >>> > ~iir_coeff(); >>> > }; >>> > ------------------------------------------ >>> > #include "iir_coeff.h" >>> > iir_coeff::iir_coeff(long ord) { >>> > order = ord; >>> > } >>> > iir_coeff::~iir_coeff() {} >>> > ------------------------------------------ >>> > // Boost Includes >>> > >>> ============================================================== >>> > #include >>> > #include >>> > >>> > // Includes >>> > >>> ==================================================================== >>> > #include "iir_coeff.h" >>> > >>> > // Using >>> > >>> ======================================================================= >>> > using namespace boost::python; >>> > >>> > // Module >>> > >>> ====================================================================== >>> > BOOST_PYTHON_MODULE(iir_coeff) >>> > { >>> > class_< iir_coeff >("iir_coeff", init< const >>> > iir_coeff& >()) >>> > .def(init< optional< long int > >()) >>> > .def_readwrite("order", &iir_coeff::order) >>> > ; >>> > >>> > } >>> > ------------------------------------------ >>> > #include "iir_coeff.h" >>> > void butterworth_iir(iir_coeff& filt, float fcd); >>> > ------------------------------------------ >>> > #include "butterworth_iir.h" >>> > void butterworth_iir(iir_coeff& filt, float fcd) { >>> > long order = filt.order; >>> > filt.order = order+1; >>> > } >>> > ------------------------------------------ >>> > // Boost Includes >>> > >>> ============================================================== >>> > #include >>> > #include >>> > >>> > // Includes >>> > >>> ==================================================================== >>> > #include "butterworth_iir.h" >>> > >>> > // Using >>> > >>> ======================================================================= >>> > using namespace boost::python; >>> > >>> > // Module >>> > >>> ====================================================================== >>> > BOOST_PYTHON_MODULE(butterworth_iir) >>> > { >>> > def("butterworth_iir", &butterworth_iir); >>> > } >>> > >>> > ------------------------------------------ >>> > use-project boost : ../../boost_1_35_0 ; >>> > >>> > project >>> > : requirements >>> > /boost/python//boost_python/static >>> > : usage-requirements ../../boost_1_35_0 >>> > . >>> > ; >>> > >>> > lib spuc : >>> > butterworth_iir.cpp >>> > iir_coeff.cpp >>> > : >>> > . >>> > ../../boost_1_35_0 >>> > >>> > ; >>> > >>> > alias staticspuc : spuc/static ; >>> > >>> > import python ; >>> > >>> > >>> > python-extension butterworth_iir : >>> > py_butterworth_iir.cpp : . >>> > ../../boost_1_35_0 : staticspuc ; >>> > python-extension iir_coeff : py_iir_coeff.cpp : >>> > . ../../boost_1_35_0 : >>> > staticspuc ; >>> > >>> > install dist : >>> > __init__.py >>> > butterworth_iir >>> > iir_coeff >>> > : >>> > >>> > /usr/lib/python2.4/site-packages/spucb >>> > ; >>> > >>> > ------------------------------------------ >>> > boost-build ../../boost_1_35_0/tools/build/v2 ; >>> > ------------------------------------------ >>> > >>> > from spucb.butterworth_iir import * >>> > from spucb.iir_coeff import * >>> > x=iir_coeff(8) >>> > butterworth_iir(x,0.24) >>> > print x.order >>> > >>> > ------------------------------------------ >>> > Traceback (most recent call last): >>> > File "tes.py", line 4, in ? >>> > butterworth_iir(x,0.24) >>> > Boost.Python.ArgumentError: Python argument types in >>> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >>> > float) >>> > did not match C++ signature: >>> > butterworth_iir(iir_coeff {lvalue}, float) >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > C++-sig mailing list >>> > C++-sig at python.org >>> > http://mail.python.org/mailman/listinfo/c++-sig >>> > >>> > >>> > >>> > _______________________________________________ >>> > C++-sig mailing list >>> > C++-sig at python.org >>> > http://mail.python.org/mailman/listinfo/c++-sig >>> >>> _______________________________________________ >>> C++-sig mailing list >>> C++-sig at python.org >>> http://mail.python.org/mailman/listinfo/c++-sig >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Thu Jun 12 09:13:59 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 12 Jun 2008 10:13:59 +0300 Subject: [C++-sig] Py++: Class registration code insertion order (patch) In-Reply-To: References: Message-ID: <7465b6170806120013j5f945328tebfeb742c6f5c893@mail.gmail.com> 2008/6/11 Jason Kankiewicz : > In order to solve a registration order problem, I needed to make my > hand-written method overload get registered prior to the method overloads > generated by Py++. > > I have patched the pyplusplus.decl_wrappers.class_t class to provide the > same control over registration code insertion order that the > pyplusplus.module_builder.module_builder_t class provides. > > I have also patched the pyplusplus.module_creator.creator_t class to utilize > the new registration code retrieval properties of the > pyplusplus.decl_wrappers.class_t class. > > The attached patch is against r1326 of pyplusplus_dev. Thanks for the patch. I applied it. The revision is 1336. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From brian.o'kennedy at vicon.com Thu Jun 12 18:31:17 2008 From: brian.o'kennedy at vicon.com (Brian O'Kennedy) Date: Thu, 12 Jun 2008 17:31:17 +0100 Subject: [C++-sig] Boost.Python : Protected Destructor Message-ID: <6BF44CD613458D479057BDB27207F2E0028BC782@omgsvr02.omg.local> Hi, I'm trying to wrap a class like the one below which has a protected dtor and should be destructed via the Destroy method. class Foo { public: int bar() { return 1; } void Destroy() { delete this; } protected: ~Foo() { Destroy(); } }; My Boost.Python code looks like this: class_< Foo, boost::noncopyable > ("Foo", no_init ) .def( "bar", &Foo::bar ); I had to add both the boost::noncopyable and the no_init to stop compilation errors, but this means that I have no way of creating Foo from within Python. I can get around this by creating a factory method and registering the pointer: boost::shared_ptr< Foo > FooCreator() { return boost::shared_ptr< Foo >( new Foo(), boost::bind( &Foo::Destroy, _1 ) ); } And def("FooCreator", FooCreator ); register_ptr_to_python< boost::shared_ptr< Foo > >(); This feels a little clunky though. Am I doing something very wrong? Is there an easier way to manage classes like this with protected destructors? Thanks, Brian ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zydoom at gmail.com Fri Jun 13 01:22:37 2008 From: zydoom at gmail.com (ZSS) Date: Fri, 13 Jun 2008 00:22:37 +0100 Subject: [C++-sig] [Graph] Problem Compiling BGL-Python In-Reply-To: <124907590806101820n5e1873cm4f3da268ea478a91@mail.gmail.com> References: <124907590806101820n5e1873cm4f3da268ea478a91@mail.gmail.com> Message-ID: <124907590806121622i4d857bf0nfac0891e9766275d@mail.gmail.com> Hi, I'm facing difficulty in compiling BGL-Python (which I'm not familiar with). I followed all the instructions in the README file, however, when I reach the stage where I need to run bjam I recieve this error: error: Could not find parent for project at '.' error: Did not find Jamfile.jam or Jamroot.jam in any parent directory. However, when I move the bgl-python-0.9 directory and put it under boost_1_35_0 I get a different error message: Jamfile:13: in modules.load rule project-root unknown in module Jamfile I don't know what to do, any hints are highly appreciated. Thank you, Zee From ed at edmatrix.net Fri Jun 13 06:02:41 2008 From: ed at edmatrix.net (ed at edmatrix.net) Date: Fri, 13 Jun 2008 00:02:41 -0400 Subject: [C++-sig] ED MATRIX - A magazine for Education & Development Message-ID: <4A4C655B04E84661BA0CBC9BAC70EF5D@securedc.com> Subscription Details : Year Offer Rates Subscription Rates 1 year 720/- 900/- 2 years 1350/- 1800/- 3 years 1890/- 2700/- For more details Contact : 9790977297, 044 - 25569288 e-mail : ed at edmatrix.net , edmatrix at edmatrix.net website : www.edmatrix.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From pyspuc at gmail.com Fri Jun 13 08:51:07 2008 From: pyspuc at gmail.com (Tony Kirke) Date: Thu, 12 Jun 2008 23:51:07 -0700 Subject: [C++-sig] Help with problem caused going from boost_1_33_1 to 1_35_0 In-Reply-To: References: <188492.25493.qm@web31102.mail.mud.yahoo.com> <1213081317.29944.5.camel@sulfur.loria.fr> Message-ID: I also have the same issue under WinXp with VC-8.0. So it is either the Jamfile settings or the library itself. To work around this, I'd like to set up the Jamroot to work for linking to the static binary for boost_python that has been installed as a binary rather than linking to the locally built file. I looked extensively online but couldn't find any examples of how to do this. i.e how do I change the line project : requirements /boost/python//boost_python/static so I can link to $(BOOST_ROOT)/lib/boost_python-vc80-mt-1_35.lib (under WinXP) or /usr/lib/libboost_python.a (under Ubuntu). Thanks. On Wed, Jun 11, 2008 at 4:31 PM, Tony Kirke wrote: > Still trying to figure out what is wrong here. Using Nicholas's makefile on > a newer Ubuntu system with python2.5 and libboost_python binaries installed > (1.34.1), I got this to work (Thanks Nicolas) > I've narrowed it down to the fact that linking to installed static library > works but locally built libboost_python fails. Not sure if this is a 1_35_0 > vs 1_34_1 issue or something else > Thanks > > > On Tue, Jun 10, 2008 at 8:51 AM, Tony Kirke wrote: > >> Any suggestions on how to debug this with gdb? I had trouble trying to set >> breakpoints and resorted to adding printf statements. It's definitely >> getting the newest built libboost_python file and the local shared objects >> newly created. >> >> >> On Tue, Jun 10, 2008 at 7:55 AM, Tony Kirke wrote: >> >>> Thank Nicolas, >>> I tried your makefile and am still getting a problem. I can only imagine >>> that there is something wrong with my libboost_python.a file or a g++ issue. >>> I also am running on linux with gcc 4.1.2 >>> Tony >>> >>> >>> On Tue, Jun 10, 2008 at 12:01 AM, Nicolas Rougier < >>> Nicolas.Rougier at loria.fr> wrote: >>> >>>> >>>> >>>> I tested the code on linux using the attached makefile (I'm not familiar >>>> with bjam) and things are working ok (got 9 as a result of tes.py). >>>> >>>> Is there any chance you're not loading the module you think you're >>>> loading (from a previous installation of your python modules for >>>> example) ? >>>> >>>> >>>> Nicolas >>>> >>>> >>>> >>>> Makefile: >>>> --------- >>>> >>>> all: >>>> g++ butterworth_iir.cpp -shared -o libbutterworth_iir.so >>>> g++ py_butterworth_iir.cpp -I/usr/include/python2.5 -L . >>>> -lboost_python >>>> -lbutterworth_iir -shared -o butterworth_iir.so >>>> >>>> g++ iir_coeff.cpp -shared -o libiir_coeff.so >>>> g++ py_iir_coeff.cpp -I/usr/include/python2.5 -L . -liir_coeff >>>> -lboost_python -shared -o iir_coeff.so >>>> >>>> clean: >>>> rm *.so >>>> >>>> >>>> >>>> On Mon, 2008-06-09 at 20:05 -0700, Tony Kirke wrote: >>>> > Sorry, couldn't attach file. It is available here: >>>> > >>>> > http://pyspuc.com/testcase.tar.gz >>>> > >>>> > On Mon, Jun 9, 2008 at 6:58 PM, Tony Kirke wrote: >>>> > Thanks Ralf, >>>> > I tried reversing the order to no avail. I'm attached a >>>> > gzipped tar file of the example, if anyone would like to try >>>> > it. I'd be grateful to confirm if there is an issue or not. >>>> > Only things that may need to be edited would be path to >>>> > boost_1_35_0 and python 2.4/2.5 >>>> > Tony >>>> > >>>> > 2008/6/9 Ralf W. Grosse-Kunstleve : >>>> > >>>> > I stared at your code for a few minutes but I don't >>>> > have an answer >>>> > for you. It looks like it should work. I'm not aware >>>> > of changes in >>>> > Boost.Python that could make your code fail. >>>> > I'd probably try to reverse the import order: >>>> > >>>> > >>>> > from spucb.iir_coeff import * >>>> > from spucb.butterworth_iir import * >>>> > >>>> > >>>> > although I don't expect this to make a difference. >>>> > >>>> > Ralf >>>> > >>>> > >>>> > >>>> > ----- Original Message ---- >>>> > From: Tony Kirke >>>> > To: c++-sig at python.org >>>> > Sent: Monday, June 9, 2008 8:25:20 AM >>>> > Subject: [C++-sig] Help with problem caused going from >>>> > boost_1_33_1 to 1_35_0 >>>> > >>>> > Hi, >>>> > My c++ code that worked fine for Boost_1_33_1 >>>> > (building with v1 system) is now giving the following >>>> > error with 1_35_0: >>>> > >>>> > Boost.Python.ArgumentError: Python argument types in >>>> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >>>> > float) >>>> > did not match C++ signature: >>>> > butterworth_iir(iir_coeff {lvalue}, float) >>>> > >>>> > I done a lot of searching to find out what changed in >>>> > the newer Boost/boost build system and could not >>>> > figure out what to do. >>>> > Below is all of the code for a simple testcase. Since >>>> > I have lots of code that is broken in this way, I'm >>>> > wondering if there is an easy change that can be made >>>> > to the boost wrapping code (or source itself) to make >>>> > this functional. Is there a simple example of how >>>> > this problem is solved. Was there a fundamental reason >>>> > this is no longer supported? >>>> > Thanks >>>> > >>>> > Tony >>>> > >>>> > ------------------------------------------ >>>> > class iir_coeff >>>> > { >>>> > public: >>>> > long order; >>>> > >>>> > public: >>>> > iir_coeff(long ord=1); >>>> > ~iir_coeff(); >>>> > }; >>>> > ------------------------------------------ >>>> > #include "iir_coeff.h" >>>> > iir_coeff::iir_coeff(long ord) { >>>> > order = ord; >>>> > } >>>> > iir_coeff::~iir_coeff() {} >>>> > ------------------------------------------ >>>> > // Boost Includes >>>> > >>>> ============================================================== >>>> > #include >>>> > #include >>>> > >>>> > // Includes >>>> > >>>> ==================================================================== >>>> > #include "iir_coeff.h" >>>> > >>>> > // Using >>>> > >>>> ======================================================================= >>>> > using namespace boost::python; >>>> > >>>> > // Module >>>> > >>>> ====================================================================== >>>> > BOOST_PYTHON_MODULE(iir_coeff) >>>> > { >>>> > class_< iir_coeff >("iir_coeff", init< const >>>> > iir_coeff& >()) >>>> > .def(init< optional< long int > >()) >>>> > .def_readwrite("order", &iir_coeff::order) >>>> > ; >>>> > >>>> > } >>>> > ------------------------------------------ >>>> > #include "iir_coeff.h" >>>> > void butterworth_iir(iir_coeff& filt, float fcd); >>>> > ------------------------------------------ >>>> > #include "butterworth_iir.h" >>>> > void butterworth_iir(iir_coeff& filt, float fcd) { >>>> > long order = filt.order; >>>> > filt.order = order+1; >>>> > } >>>> > ------------------------------------------ >>>> > // Boost Includes >>>> > >>>> ============================================================== >>>> > #include >>>> > #include >>>> > >>>> > // Includes >>>> > >>>> ==================================================================== >>>> > #include "butterworth_iir.h" >>>> > >>>> > // Using >>>> > >>>> ======================================================================= >>>> > using namespace boost::python; >>>> > >>>> > // Module >>>> > >>>> ====================================================================== >>>> > BOOST_PYTHON_MODULE(butterworth_iir) >>>> > { >>>> > def("butterworth_iir", &butterworth_iir); >>>> > } >>>> > >>>> > ------------------------------------------ >>>> > use-project boost : ../../boost_1_35_0 ; >>>> > >>>> > project >>>> > : requirements >>>> > /boost/python//boost_python/static >>>> > : usage-requirements ../../boost_1_35_0 >>>> > . >>>> > ; >>>> > >>>> > lib spuc : >>>> > butterworth_iir.cpp >>>> > iir_coeff.cpp >>>> > : >>>> > . >>>> > ../../boost_1_35_0 >>>> > >>>> > ; >>>> > >>>> > alias staticspuc : spuc/static ; >>>> > >>>> > import python ; >>>> > >>>> > >>>> > python-extension butterworth_iir : >>>> > py_butterworth_iir.cpp : . >>>> > ../../boost_1_35_0 : staticspuc ; >>>> > python-extension iir_coeff : py_iir_coeff.cpp : >>>> > . ../../boost_1_35_0 : >>>> > staticspuc ; >>>> > >>>> > install dist : >>>> > __init__.py >>>> > butterworth_iir >>>> > iir_coeff >>>> > : >>>> > >>>> > /usr/lib/python2.4/site-packages/spucb >>>> > ; >>>> > >>>> > ------------------------------------------ >>>> > boost-build ../../boost_1_35_0/tools/build/v2 ; >>>> > ------------------------------------------ >>>> > >>>> > from spucb.butterworth_iir import * >>>> > from spucb.iir_coeff import * >>>> > x=iir_coeff(8) >>>> > butterworth_iir(x,0.24) >>>> > print x.order >>>> > >>>> > ------------------------------------------ >>>> > Traceback (most recent call last): >>>> > File "tes.py", line 4, in ? >>>> > butterworth_iir(x,0.24) >>>> > Boost.Python.ArgumentError: Python argument types in >>>> > spucb.butterworth_iir.butterworth_iir(iir_coeff, >>>> > float) >>>> > did not match C++ signature: >>>> > butterworth_iir(iir_coeff {lvalue}, float) >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > C++-sig mailing list >>>> > C++-sig at python.org >>>> > http://mail.python.org/mailman/listinfo/c++-sig >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > C++-sig mailing list >>>> > C++-sig at python.org >>>> > http://mail.python.org/mailman/listinfo/c++-sig >>>> >>>> _______________________________________________ >>>> C++-sig mailing list >>>> C++-sig at python.org >>>> http://mail.python.org/mailman/listinfo/c++-sig >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisw at wicklein.org Mon Jun 16 17:43:00 2008 From: chrisw at wicklein.org (Christopher Wicklein) Date: Mon, 16 Jun 2008 10:43:00 -0500 Subject: [C++-sig] shared_ptr<> to Boost.Python wrapped object going out of scope early? Message-ID: <75B0514C-134D-480E-8EC2-BBA860E90382@wicklein.org> I've been having problems getting a C++ class wrapped with Boost.Python to be shared appropriately between Python and C++ library code. The Python program looks like this: class Watcher(Observer): def __init__(self): Observer.__init__(self) def onModify(self, record): print record database = Database() watcher = Watcher() database.watch(some_key, watcher) cl_service_all() The basic idea is that an instance of a wrapped database record observer is created, the observer is registered with the C++ object wrapped by database via a passed shared_ptr (the second argument of database.watch) and retained by the library as a weak_ptr, and the program drops into a C-based event loop which is integrated with the C+ + library providing the observer and database classes. The C++ library fails at runtime because the weak_ptr becomes invalid. It seems that the shared_ptr passed to database.watch isn't retained by the Python code above. To fill things out a bit, here is the Boost.Python statement used to wrap the Observer: class_("Observer") .def("onModify", pure_virtual(&Observer::onModify)) ; Here is the wrapper class: struct ObserverWrap : Observer, wrapper { onModify(Record record) { this->get_override("onModify")(record); } } Having done a little diagnostic work by printf, I believe that an instance of Oberver is created, passes as a shared_ptr to the library, and accessible to the library prior to entering the event loop. When the weak pointer which was good before entering the event loop is locked from within the event loop, the weak pointer has become invalid. I presume that what I'm trying to do (hold a wrapped object by a shared_ptr on the Python side and allow a C++ library to hold a weak_ptr to that object) isn't too strange and that there should be some idiomatic way to make this work. Is there something in particular I need to do so that the Python side doesn't drop the shared pointer, or is it clear from the code above that I have some critical misunderstanding of how to use Boost.Python? ---- Christopher Wicklein -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark.English at rbccm.com Mon Jun 16 17:57:47 2008 From: Mark.English at rbccm.com (English, Mark) Date: Mon, 16 Jun 2008 16:57:47 +0100 Subject: [C++-sig] shared_ptr<> to Boost.Python wrapped object going out ofscope early? Message-ID: <537D4B8BAB638F4596E4F985389C92701B9F1F@SXLM-101.fg.rbc.com> > -----Original Message----- > From: c++-sig-bounces at python.org > [mailto:c++-sig-bounces at python.org] On Behalf Of Christopher Wicklein > Sent: 16 June 2008 16:43 > > Python code above. To fill things out a bit, here is the > Boost.Python statement used to wrap the Observer: > > class_("Observer") > .def("onModify", pure_virtual(&Observer::onModify)) > ; > > Here is the wrapper class: > > struct ObserverWrap : Observer, wrapper { > onModify(Record record) { > this->get_override("onModify")(record); } } > What is the function signature of "onModify()" ? Should the function signature be based around shared_ptr (I've also included a void return type) ? E.g. struct ObserverWrap : Observer, wrapper { void onModify(shared_ptr record) { this->get_override("onModify")(record); } } _______________________________________________________________________ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message without copying, using, or telling anyone about its contents. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. This message does not create or change any contract. Royal Bank of Canada and its subsidiaries accept no responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. RBC Capital Markets is a business name used by branches and subsidiaries of Royal Bank of Canada, including Royal Bank of Canada, London branch and Royal Bank of Canada Europe Limited. In accordance with English law requirements, details regarding Royal Bank of Canada Europe Limited are set out below: ROYAL BANK OF CANADA EUROPE LIMITED Registered in England and Wales 995939 Registered Address: 71 Queen Victoria Street, London, EC4V 4DE. Authorised and regulated by the Financial Service Authority. Member of the London Stock Exchange -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT149302.txt URL: From chrisw at wicklein.org Mon Jun 16 19:27:21 2008 From: chrisw at wicklein.org (Christopher Wicklein) Date: Mon, 16 Jun 2008 12:27:21 -0500 Subject: [C++-sig] shared_ptr<> to Boost.Python wrapped object going out ofscope early? In-Reply-To: <537D4B8BAB638F4596E4F985389C92701B9F1F@SXLM-101.fg.rbc.com> References: <537D4B8BAB638F4596E4F985389C92701B9F1F@SXLM-101.fg.rbc.com> Message-ID: The code in my original post was missing the return type void. The actual argument to onModify is something like a shared_ptr to a record owned by the library, but I meant to leave that vague since the onModify method is not and can not ever be called by the library because the library's weak_ptr to the observer has become invalid. Something I neglected to mention before is that when I add printf statements to the destructors of Observer and ObserverWrap and even to the __del__ method of Watcher, I never see those messages displayed. The precise lifetime of the shared_ptr to my Observer wrapped through the instance watcher is not clear. struct ObserverWrap : Observer, wrapper { void onModify(Record record) { ... } } On Jun 16, 2008, at 10:57 AM, English, Mark wrote: >> -----Original Message----- >> From: c++-sig-bounces at python.org >> [mailto:c++-sig-bounces at python.org] On Behalf Of Christopher Wicklein >> Sent: 16 June 2008 16:43 >> >> Python code above. To fill things out a bit, here is the >> Boost.Python statement used to wrap the Observer: >> >> class_("Observer") >> .def("onModify", pure_virtual(&Observer::onModify)) >> ; >> >> Here is the wrapper class: >> >> struct ObserverWrap : Observer, wrapper { >> onModify(Record record) { >> this->get_override("onModify")(record); } } >> > > What is the function signature of "onModify()" ? > > Should the function signature be based around shared_ptr (I've also > included a void return type) ? > E.g. > struct ObserverWrap : Observer, wrapper { > void onModify(shared_ptr record) { > this->get_override("onModify")(record); } } > _______________________________________________________________________ > ---- Christopher Wicklein From roman.yakovenko at gmail.com Mon Jun 16 19:55:32 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Mon, 16 Jun 2008 20:55:32 +0300 Subject: [C++-sig] shared_ptr<> to Boost.Python wrapped object going out ofscope early? In-Reply-To: References: <537D4B8BAB638F4596E4F985389C92701B9F1F@SXLM-101.fg.rbc.com> Message-ID: <7465b6170806161055u4e3bc3b6wd8132c128f9226a9@mail.gmail.com> On Mon, Jun 16, 2008 at 8:27 PM, Christopher Wicklein wrote: > The code in my original post was missing the return type void. The actual > argument to onModify is something like a shared_ptr to a record owned by the > library, but I meant to leave that vague since the onModify method is not > and can not ever be called by the library because the library's weak_ptr to > the observer has become invalid. > > Something I neglected to mention before is that when I add printf statements > to the destructors of Observer and ObserverWrap and even to the __del__ > method of Watcher, I never see those messages displayed. The precise > lifetime of the shared_ptr to my Observer wrapped through the instance > watcher is not clear. > > struct ObserverWrap : Observer, wrapper { > void onModify(Record record) { ... } > } > I am not sure that next links could help you, but I suggest you to take a look: The C++ code, which is "similar" to your: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/transfer_ownership_to_be_exported.hpp?revision=968&view=markup Py++ script: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/transfer_ownership_tester.py?revision=1058&view=markup and I attach the generated code. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: transfer_ownership.cpp Type: text/x-c++src Size: 4981 bytes Desc: not available URL: From renaud.lepere at alma.fr Tue Jun 17 14:51:39 2008 From: renaud.lepere at alma.fr (Renaud Lepere) Date: Tue, 17 Jun 2008 14:51:39 +0200 Subject: [C++-sig] boost.python internal references on basic types Message-ID: <172C8EAD1ED2674D8E9A2DE544623F708CCFC9@papyrus.alma.fr> I would like to wrap member functions returning internal references on int / double. I found an example similar to my problem but not exactly the same on http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/return_internal_ reference.html Here is my simplified example class Foo { public: void set_x(int & x) { m_x = x;} const int & get_x() { return m_x; } int m_x; }; BOOST_PYTHON_MODULE(hello) { class_("Foo") .def("set_x", &Foo::set_x) .def("get_x", &Foo::get_x, return_internal_reference< >() ) ; } this leads me to the given error ..\boost/python/object/make_instance.hpp(24) : error C2027: utilisation du type non defini 'boost::STATIC_ASSERTION_FAILURE' this corresponds to BOOST_STATIC_ASSERT(is_class::value); If i replace "int" with a proxy class containing the int evrything is ok ; but i would prefer not to change the c++ code. Can someone have an idea if what i try to do is possible ? Thanks Renaud From roman.yakovenko at gmail.com Tue Jun 17 15:20:58 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 17 Jun 2008 16:20:58 +0300 Subject: [C++-sig] boost.python internal references on basic types In-Reply-To: <172C8EAD1ED2674D8E9A2DE544623F708CCFC9@papyrus.alma.fr> References: <172C8EAD1ED2674D8E9A2DE544623F708CCFC9@papyrus.alma.fr> Message-ID: <7465b6170806170620g4571a811w8c5b9c8a983ca2a5@mail.gmail.com> On Tue, Jun 17, 2008 at 3:51 PM, Renaud Lepere wrote: > > I would like to wrap member functions returning internal references on > int / double. I found an example > similar to my problem but not exactly the same on > http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/return_internal_ > reference.html > > Here is my simplified example > > class Foo > { > public: > void set_x(int & x) { m_x = x;} > const int & get_x() { return m_x; } > int m_x; > }; > BOOST_PYTHON_MODULE(hello) > { > class_("Foo") > .def("set_x", &Foo::set_x) > .def("get_x", &Foo::get_x, > return_internal_reference< >() ) > ; > } > > this leads me to the given error > ..\boost/python/object/make_instance.hpp(24) : error C2027: utilisation > du type non defini 'boost::STATIC_ASSERTION_FAILURE' > this corresponds to BOOST_STATIC_ASSERT(is_class::value); > > If i replace "int" with a proxy class containing the int evrything is ok > ; but i would prefer > not to change the c++ code. > > Can someone have an idea if what i try to do is possible ? It is not possible. Integer is immutable type in Python. Even ctypes modules returns new instance of class int. You can wrap it with a proxy class, but It will not be natural for Python users. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From Mark.English at rbccm.com Tue Jun 17 15:22:30 2008 From: Mark.English at rbccm.com (English, Mark) Date: Tue, 17 Jun 2008 14:22:30 +0100 Subject: [C++-sig] FW: boost.python internal references on basic types Message-ID: <537D4B8BAB638F4596E4F985389C92701B9F27@SXLM-101.fg.rbc.com> > -----Original Message----- > From: c++-sig-bounces at python.org > [mailto:c++-sig-bounces at python.org] On Behalf Of Renaud Lepere > Sent: 17 June 2008 13:52 > To: c++-sig at python.org > Subject: [C++-sig] boost.python internal references on basic types > > > Here is my simplified example > > class Foo > { > public: > void set_x(int & x) { m_x = x;} > const int & get_x() { return m_x; } > int m_x; > }; > BOOST_PYTHON_MODULE(hello) > { > class_("Foo") > .def("set_x", &Foo::set_x) > .def("get_x", &Foo::get_x, > return_internal_reference< >() ) > ; > } > > If I replace "int" with a proxy class containing the int > everything is ok ; but I would prefer not to change the c++ code. > > Can someone have an idea if what I try to do is possible ? Remove the "return_internal_reference". Trying to share int references isn't something Python supports without adding additional hand-crafted wrapper code. _______________________________________________________________________ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message without copying, using, or telling anyone about its contents. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. This message does not create or change any contract. Royal Bank of Canada and its subsidiaries accept no responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. RBC Capital Markets is a business name used by branches and subsidiaries of Royal Bank of Canada, including Royal Bank of Canada, London branch and Royal Bank of Canada Europe Limited. In accordance with English law requirements, details regarding Royal Bank of Canada Europe Limited are set out below: ROYAL BANK OF CANADA EUROPE LIMITED Registered in England and Wales 995939 Registered Address: 71 Queen Victoria Street, London, EC4V 4DE. Authorised and regulated by the Financial Service Authority. Member of the London Stock Exchange From soloman817 at msn.com Tue Jun 17 20:09:01 2008 From: soloman817 at msn.com (Soloman) Date: Wed, 18 Jun 2008 02:09:01 +0800 Subject: [C++-sig] py++ with template member function of template class Message-ID: Hi, I have met a problem using py++ (pyplusplus) to generate code. First, let's see this code: //////////////////////////////////////////////////////////////////////////////////// // template member function class AFunc { public: template T foo(const T& t) const { return t + 1; } }; // we can only fully specialize function template <> string AFunc::foo(const string& t) const { return "string"; }; // the following code is used to generate the instance of template functions #ifdef PYTHONWRAP void AFuncInit() { AFunc a; cout << a.foo(1) << endl; cout << a.foo(1.5f) << endl; cout << a.foo("hello") << endl; }; #endif I followed the instruction in py++ homepage->FAQ, and this works, a call to a.foo will generate an instance of that template member function. But, then, I used template class, and it won't work any more: ///////////////////////////////////////////////////////////////////////// // test template member function in template class // THIS WON'T WORK!!!!!!!!!!!!! template class BFunc { public: template T foo(const T& t) const; }; template template T BFunc::foo(const T& t) const { return t + 1; }; #ifdef PYTHONWRAP typedef BFunc BFunc_Int; void BFuncInit() { BFunc_Int a; //mem_fun(&BFunc_Int::foo); //void * p = (void *)(&BFunc::template foo); cout << a.foo(2) << endl; cout << a.foo(2.5) << endl; //cout << a.foo("hello") << endl; }; #endif Look into the generated code, I saw: bp::class_< AFunc >( "AFunc" ) .def( "foo" , (::std::string ( ::AFunc::* )( ::std::string const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ) .def( "foo" , (float ( ::AFunc::* )( float const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ) .def( "foo" , (int ( ::AFunc::* )( int const & ) const)( &::AFunc::foo ) , ( bp::arg("t") ) ); bp::class_< BFunc< int > >( "BFunc_Int" ); obviously, a call to BFunc_Int::foo hasn't create the template member function instance, can anybody help me? Regards, Xiang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.yakovenko at gmail.com Tue Jun 17 21:21:18 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Tue, 17 Jun 2008 22:21:18 +0300 Subject: [C++-sig] py++ with template member function of template class In-Reply-To: References: Message-ID: <7465b6170806171221o49847dd1s447b84b64759a169@mail.gmail.com> 2008/6/17 Soloman : > Hi, > > I have met a problem using py++ (pyplusplus) to generate code. > I followed the instruction in py++ homepage->FAQ, and this works, a call to > a.foo will generate an instance of that template member function. > > But, then, I used template class, and it won't work any more: > ///////////////////////////////////////////////////////////////////////// > // test template member function in template class > // THIS WON'T WORK!!!!!!!!!!!!! > template > class BFunc > { > public: > template > T foo(const T& t) const; > }; > > template template > T BFunc::foo(const T& t) const { return t + 1; }; > > #ifdef PYTHONWRAP Unfortunately GCC-XML doesn't dump the information. I am also not aware of any workaround :-(. You will have to create the code by yourself. Py++ allows you to integrate your code easily( http://language-binding.net/pyplusplus/documentation/inserting_code.html ) HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From renaud.lepere at alma.fr Wed Jun 18 08:24:07 2008 From: renaud.lepere at alma.fr (Renaud Lepere) Date: Wed, 18 Jun 2008 08:24:07 +0200 Subject: [C++-sig] FW: boost.python internal references on basic types Message-ID: <172C8EAD1ED2674D8E9A2DE544623F708CCFD2@papyrus.alma.fr> > > class Foo > > { > > public: > > const int & get_x() { return m_x; } > > int m_x; > > }; > > BOOST_PYTHON_MODULE(hello) > > { > > class_("Foo") > > .def("get_x", &Foo::get_x, > > return_internal_reference< >() ) > > ; > > } > > > > If I replace "int" with a proxy class containing the int > everything is > > ok ; but I would prefer not to change the c++ code. > > > > Can someone have an idea if what I try to do is possible ? > > Remove the "return_internal_reference". Trying to share int > references isn't something Python supports without adding > additional hand-crafted wrapper code. I replaced it with "return_value_policy()" and it seems to be ok in this case. The other problem is for a non const function, that can be used to modify internals such as "int & x()", but i think i will not show it in python. Thanks! From benkstein at langer-emv.de Thu Jun 19 10:55:16 2008 From: benkstein at langer-emv.de (Frank Benkstein) Date: Thu, 19 Jun 2008 10:55:16 +0200 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python Message-ID: <485A1EF4.6050803@langer-emv.de> Hi. Disclaimer: I'm quite new to Boost.Python, so I might have missed some things. If so, please tell me. Also I'm currently mostly concerned with embedding, not extending. When embedding Python with Boost.Python it is currently quite complicated to handle exceptions originating from Python code. If a Python error is detected by Boost.Python, error_already_set is thrown. Handling the original Python exception from C++ is cumbersome: using namespace boost::python; try { object value = some_dict["key"]; ... } catch (error_already_set &) { if (PyErr_ExceptionMatches(PyExc_KeyError) { // Do actual exception handling ... } else { // We can't just rethrow the exception because that would terminate // the program. PyErr_Print(); ... } } I would like to see at least the Python standard exceptions [1] to be translated to C++ exceptions by Boost.Python (possibly in the boost::python::exceptions namespace - mirroring the Python exceptions module) so the previous code could be written as follows: using namespace boost::python; try { object value = some_dict["key"]; ... } catch (exceptions::key_error &e) { BOOST_ASSERT(e.args() == make_tuple("key")); // Do actual exception handling ... } catch (exceptions::base_exception &e) { std::cerr << e.traceback << std::flush; std::cerr << e << e.flush; } Those exceptions could be automatically translated back to the original Python exceptions and the traceback restored (using PyErr_Restore). If you (the Boost.Python developers) agree to this proposal I would like to submit patches implementing the mentioned functionality through the following steps: 1. Convert all sites throwing error_already_set or calling throw_error_already_set to calls to handle_python_exception. handle_python_exception would just call throw_error_already_set itself. 2. Provide a registry for functions to be called when a specific Python exception is encountered. These functions get called with three boost::python::object arguments, the exception type, value and the traceback object when an exception is detected by handle_python_exception. As a fallback if no matching function is found error_already_set would still be thrown. 3. Provide a new namespace boost::python::exceptions with C++ exceptions that correspond to the Python standard exceptions[1] including inheritance. Each class should have a static boost::python::object member "mapped_type" wrapping the Python type object. And instance members "type", "value" and "traceback" so it can be set or restored as the Python error indicator using PyErr_Restore or PyErr_SetObject if the traceback is None. 4. Register all exceptions from 3. with the mechanism from 2. Remove the fallback throwing error_already_set from handle_python_exception because base_exception would match all unknown exceptions. Provide a runtime switch that would make handle_python_exception either use either the registry from 2. or just throw error_already_set. This is necessary to be compatible to code that is depending on error_already_set. I think it is safe to assume that this switch is guarded by the GIL and therefore thread safe. As you have probably noticed 3. and 4. will only work with Python >= 2.5. I don't think this is a problem, though, as there could be a simple compile switch around those features. Code that has to be compatible with older versions of python can still use the exception handling registry from 2. If need be 3. and 4. can also be adapted to work with older versions of Python but that is currently not important to me. Best regards, Frank Benkstein. [1] http://docs.python.org/api/standardExceptions.html -- Frank Benkstein Software Development Tel.: +49(0) 351 430093-27 Fax : +49(0) 351 430093-22 mailto:benkstein at langer-emv.de Langer EMV-Technik GmbH D-01728 Bannewitz N?thnitzer Hang 31 Germany Registergericht: Amtsgericht Dresden, HRB 15402 Gesch?ftsf?hrer: Gunter Langer www.langer-emv.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From dave at boostpro.com Thu Jun 19 15:54:36 2008 From: dave at boostpro.com (David Abrahams) Date: Thu, 19 Jun 2008 09:54:36 -0400 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python References: <485A1EF4.6050803@langer-emv.de> Message-ID: <87prqdpm1v.fsf@mcbain.luannocracy.com> on Thu Jun 19 2008, Frank Benkstein wrote: > Hi. > > Disclaimer: I'm quite new to Boost.Python, so I might have missed some > things. If so, please tell me. Also I'm currently mostly concerned > with embedding, not extending. > > When embedding Python with Boost.Python it is currently quite > complicated to handle exceptions originating from Python code. > > If a Python error is detected by Boost.Python, error_already_set is > thrown. Handling the original Python exception from C++ is cumbersome: > > > using namespace boost::python; > > try { > object value = some_dict["key"]; > ... > } catch (error_already_set &) { > if (PyErr_ExceptionMatches(PyExc_KeyError) { > // Do actual exception handling > ... > } else { > // We can't just rethrow the exception because that would terminate > // the program. > PyErr_Print(); > ... > } > } > Yep. > I would like to see at least the Python standard exceptions [1] to be > translated to C++ exceptions by Boost.Python (possibly in the > boost::python::exceptions namespace - mirroring the Python exceptions > module) so the previous code could be written as follows: Good idea; I think I always intended to do that. > > using namespace boost::python; > > try { > object value = some_dict["key"]; > ... > } catch (exceptions::key_error &e) { > BOOST_ASSERT(e.args() == make_tuple("key")); > // Do actual exception handling > ... > } catch (exceptions::base_exception &e) { > std::cerr << e.traceback << std::flush; > std::cerr << e << e.flush; > } > > > Those exceptions could be automatically translated back to the original > Python exceptions and the traceback restored (using PyErr_Restore). Also good... but what is restoring the traceback for? Doesn't the traceback that's already there work? > If you (the Boost.Python developers) agree to this proposal I would > like to submit patches implementing the mentioned functionality > through the following steps: > > 1. Convert all sites throwing error_already_set or calling > throw_error_already_set to calls to handle_python_exception. > handle_python_exception would just call throw_error_already_set > itself. We probably ought to package up this little gem, which is a little bigger than throw_error_already_set, into a single function in the library: if (PyErr_Occurred()) throw_error_already_set(); > 2. Provide a registry for functions to be called when a specific Python > exception is encountered. > These functions get called with three > boost::python::object arguments, the exception type, value and the > traceback object when an exception is detected by > handle_python_exception. As a fallback if no matching function is > found error_already_set would still be thrown. > 3. Provide a new namespace boost::python::exceptions with C++ exceptions > that correspond to the Python standard exceptions[1] including > inheritance. Good... but boost::python::exceptions::Exception should be derived from error_already_set for backward compatibility. Or maybe just typedef exceptions::Exception error_already_set; > Each class should have a static boost::python::object > member "mapped_type" wrapping the Python type object. How about "python_type?" > And instance members "type", "value" and "traceback" so it can be > set or restored as the Python error indicator using PyErr_Restore > or PyErr_SetObject if the traceback is None. Do you really need to store the type in each instance? Oh, maybe you do; it could end up being a python exception derived from one of the standard exceptions. Then what's "mapped_type" (a.k.a. "python_type") for? > 4. Register all exceptions from 3. with the mechanism from 2. Remove > the fallback throwing error_already_set from handle_python_exception > because base_exception would match all unknown exceptions. Why do we want "base_exception," and why have the fallback if you're just going to remove it? > Provide a runtime switch that would make handle_python_exception > either use either the registry from 2. or just throw > error_already_set. This is necessary to be compatible to code that > is depending on error_already_set. I think it's enough to ensure that error_already_set is a base class of all the things you're throwing. > I think it is safe to assume that this switch is guarded by the GIL > and therefore thread safe. > > As you have probably noticed 3. and 4. will only work with Python >= > 2.5. No, I didn't. Why do you say that? -- Dave Abrahams BoostPro Computing http://www.boostpro.com From benkstein at langer-emv.de Fri Jun 20 09:42:02 2008 From: benkstein at langer-emv.de (Frank Benkstein) Date: Fri, 20 Jun 2008 09:42:02 +0200 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python In-Reply-To: <87prqdpm1v.fsf@mcbain.luannocracy.com> References: <485A1EF4.6050803@langer-emv.de> <87prqdpm1v.fsf@mcbain.luannocracy.com> Message-ID: <485B5F4A.6000002@langer-emv.de> Hi, David Abrahams wrote: > on Thu Jun 19 2008, Frank Benkstein wrote: >> >> using namespace boost::python; >> >> try { >> object value = some_dict["key"]; >> ... >> } catch (exceptions::key_error &e) { >> BOOST_ASSERT(e.args() == make_tuple("key")); >> // Do actual exception handling >> ... >> } catch (exceptions::base_exception &e) { >> std::cerr << e.traceback << std::flush; >> std::cerr << e << e.flush; >> } >> >> >> Those exceptions could be automatically translated back to the original >> Python exceptions and the traceback restored (using PyErr_Restore). > > Also good... but what is restoring the traceback for? Doesn't the > traceback that's already there work? I forgot to mention the main API difference between error_already_set and this new approach: error_already_set is just a signal that the Python error indicator (exception type, value and the traceback) is set. In this approach I would fetch those three objects and clear the indicator. The reason for this is that if you wrap Py_Initialize/Py_Finalize in a RAII-Style class an exception might cause Py_Finalize to be called. Py_Finalize will terminate the application with a fatal error (calling abort()) if the error indicator is set. Also if you get another Python exception while already handling one you might want to be able to decide which one to rethrow. If you don't save the original traceback it is lost when the second exception is raised. >> If you (the Boost.Python developers) agree to this proposal I would >> like to submit patches implementing the mentioned functionality >> through the following steps: >> >> 1. Convert all sites throwing error_already_set or calling >> throw_error_already_set to calls to handle_python_exception. >> handle_python_exception would just call throw_error_already_set >> itself. > > We probably ought to package up this little gem, which is a little > bigger than throw_error_already_set, into a single function in the > library: > > if (PyErr_Occurred()) > throw_error_already_set(); I don't understead, what you mean. My plan was to ensure that error_already_set is only thrown through a single function that we have control over. This function can later decide what to do: throw error_already_set or handle the exception in a Boost.Python specific way. >> 2. Provide a registry for functions to be called when a specific Python >> exception is encountered. >> These functions get called with three >> boost::python::object arguments, the exception type, value and the >> traceback object when an exception is detected by >> handle_python_exception. As a fallback if no matching function is >> found error_already_set would still be thrown. > >> 3. Provide a new namespace boost::python::exceptions with C++ exceptions >> that correspond to the Python standard exceptions[1] including >> inheritance. > > Good... but boost::python::exceptions::Exception should be derived from > error_already_set for backward compatibility. Or maybe just > > typedef exceptions::Exception error_already_set; To reiterate: - If you catch error_already_set the error indicator is set, it is not safe to call Py_Finalize(). - If you catch exceptions::Exception the error indicator is not set, it is safe to call Py_Finalize(). >> Each class should have a static boost::python::object >> member "mapped_type" wrapping the Python type object. > > How about "python_type?" I don't care that much about the name. mapped_type was just to make it clear that this is the member that is used to find the C++ exception class belonging to a Python exception class. Also it is just the base type because the actual exception can be a subclass. I imagine the following procedure: 1. Register all your C++-mapped-exception classes in a sorted map or list somewhere in Boost.Python. When looking at the "mapped_type" member It is ensured that the subclasses come before their bases. 2. Whenever a Python exception is detected by Boost.Python (through a call to handle_python_exception) go through the map or list and throw the first C++ exception that matches. mapped_type would act as some kind of key in the map when storing the C++ exception. The actual Python exception type would act as the key when retrieving the C++ class. >> And instance members "type", "value" and "traceback" so it can be >> set or restored as the Python error indicator using PyErr_Restore >> or PyErr_SetObject if the traceback is None. > > Do you really need to store the type in each instance? Oh, maybe you > do; it could end up being a python exception derived from one of the > standard exceptions. Then what's "mapped_type" (a.k.a. "python_type") > for? > >> 4. Register all exceptions from 3. with the mechanism from 2. Remove >> the fallback throwing error_already_set from handle_python_exception >> because base_exception would match all unknown exceptions. > > Why do we want "base_exception," and why have the fallback if you're > just going to remove it? The four steps were meant to be incremental improvements (patches) so that Boost.Python stays functional between each step. I though that this would make reviewing easier. >> Provide a runtime switch that would make handle_python_exception >> either use either the registry from 2. or just throw >> error_already_set. This is necessary to be compatible to code that >> is depending on error_already_set. Code that handles error_already_set will probably expect that the Python error indicator is still set hence the neccessity for a switch. >> I think it is safe to assume that this switch is guarded by the GIL >> and therefore thread safe. >> >> As you have probably noticed 3. and 4. will only work with Python >= >> 2.5. > > No, I didn't. Why do you say that? I think I was a little confused about PEP 352 (Required Superclass for Exceptions) that was first implemented in Python 2.5. I thought that this made all exceptions instances of BaseExceptions. Unfortunately that is only the case for new-style classes and old-style classes and string exceptions will still have to be handled separately. With these special cases in place it should work with earlier Python versions, too. Best regards, Frank Benkstein. -- Frank Benkstein Software Development Tel.: +49(0) 351 430093-27 Fax : +49(0) 351 430093-22 mailto:benkstein at langer-emv.de Langer EMV-Technik GmbH D-01728 Bannewitz N?thnitzer Hang 31 Germany Registergericht: Amtsgericht Dresden, HRB 15402 Gesch?ftsf?hrer: Gunter Langer www.langer-emv.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From dave at boostpro.com Mon Jun 23 22:47:34 2008 From: dave at boostpro.com (David Abrahams) Date: Mon, 23 Jun 2008 16:47:34 -0400 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python In-Reply-To: <485B5F4A.6000002@langer-emv.de> References: <485A1EF4.6050803@langer-emv.de> <87prqdpm1v.fsf@mcbain.luannocracy.com> <485B5F4A.6000002@langer-emv.de> Message-ID: <48600BE6.8090402@boostpro.com> Frank Benkstein wrote: > Hi, > > David Abrahams wrote: >> on Thu Jun 19 2008, Frank Benkstein wrote: >>> >>> using namespace boost::python; >>> >>> try { >>> object value = some_dict["key"]; >>> ... >>> } catch (exceptions::key_error &e) { >>> BOOST_ASSERT(e.args() == make_tuple("key")); >>> // Do actual exception handling >>> ... >>> } catch (exceptions::base_exception &e) { >>> std::cerr << e.traceback << std::flush; >>> std::cerr << e << e.flush; >>> } >>> >>> >>> Those exceptions could be automatically translated back to the original >>> Python exceptions and the traceback restored (using PyErr_Restore). >> Also good... but what is restoring the traceback for? Doesn't the >> traceback that's already there work? > > I forgot to mention the main API difference between error_already_set > and this new approach: error_already_set is just a signal that the > Python error indicator (exception type, value and the traceback) is set. > In this approach I would fetch those three objects and clear the > indicator. The reason for this is that if you wrap > Py_Initialize/Py_Finalize in a RAII-Style class an exception might cause > Py_Finalize to be called. Py_Finalize will terminate the application > with a fatal error (calling abort()) if the error indicator is set. I don't know if you're aware of this, but Boost.Python is currently incompatible with the use of Py_Finalize But regardless of that, I don't understand the relationship of what you wrote just above to clearing the Python error indicator. > Also if you get another Python exception while already handling one you > might want to be able to decide which one to rethrow. If you don't save > the original traceback it is lost when the second exception is raised. I see. >>> If you (the Boost.Python developers) agree to this proposal I would >>> like to submit patches implementing the mentioned functionality >>> through the following steps: >>> >>> 1. Convert all sites throwing error_already_set or calling >>> throw_error_already_set to calls to handle_python_exception. >>> handle_python_exception would just call throw_error_already_set >>> itself. >> We probably ought to package up this little gem, which is a little >> bigger than throw_error_already_set, into a single function in the >> library: >> >> if (PyErr_Occurred()) >> throw_error_already_set(); > > I don't understead, what you mean. My plan was to ensure that > error_already_set is only thrown through a single function that we have > control over. This function can later decide what to do: throw > error_already_set or handle the exception in a Boost.Python specific > way. All I was saying was that that single function probably ought to include the PyErr_Occurred check >>> 2. Provide a registry for functions to be called when a specific Python >>> exception is encountered. >>> These functions get called with three >>> boost::python::object arguments, the exception type, value and the >>> traceback object when an exception is detected by >>> handle_python_exception. As a fallback if no matching function is >>> found error_already_set would still be thrown. >>> 3. Provide a new namespace boost::python::exceptions with C++ exceptions >>> that correspond to the Python standard exceptions[1] including >>> inheritance. >> Good... but boost::python::exceptions::Exception should be derived from >> error_already_set for backward compatibility. Or maybe just >> >> typedef exceptions::Exception error_already_set; > > To reiterate: > > - If you catch error_already_set the error indicator is set, it is not > safe to call Py_Finalize(). > - If you catch exceptions::Exception the error indicator is not set, it > is safe to call Py_Finalize(). Okay... well, I really dislike the idea of having both things in the library at once, and I was never really thrilled with error_already_set. We should think about how to replace it with your thing. My guess is that if the library starts throwing something not derived from error_already_set, regardless of whether it leaves the Python error there, it's going to break more code than if we changed the meaning of error_already_set or "lied" by deriving your thing from it. There will be transition issues, so we should discuss deprecation, compile-time checks, runtime checks, etc. >>> Each class should have a static boost::python::object >>> member "mapped_type" wrapping the Python type object. >> How about "python_type?" > > I don't care that much about the name. mapped_type was just to make it > clear that this is the member that is used to find the C++ exception > class belonging to a Python exception class. Also it is just the base > type because the actual exception can be a subclass. > > I imagine the following procedure: > > 1. Register all your C++-mapped-exception classes in a sorted map or > list somewhere in Boost.Python. When looking at the "mapped_type" > member It is ensured that the subclasses come before their bases. > 2. Whenever a Python exception is detected by Boost.Python (through a > call to handle_python_exception) go through the map or list and throw > the first C++ exception that matches. > > mapped_type would act as some kind of key in the map when storing the > C++ exception. The actual Python exception type would act as the key > when retrieving the C++ class. > >>> And instance members "type", "value" and "traceback" so it can be >>> set or restored as the Python error indicator using PyErr_Restore >>> or PyErr_SetObject if the traceback is None. >> Do you really need to store the type in each instance? Oh, maybe you >> do; it could end up being a python exception derived from one of the >> standard exceptions. Then what's "mapped_type" (a.k.a. "python_type") >> for? Inquiring minds wanna know. >>> 4. Register all exceptions from 3. with the mechanism from 2. Remove >>> the fallback throwing error_already_set from handle_python_exception >>> because base_exception would match all unknown exceptions. >> Why do we want "base_exception," and why have the fallback if you're >> just going to remove it? > > The four steps were meant to be incremental improvements (patches) so > that Boost.Python stays functional between each step. I though that > this would make reviewing easier. I think I'd prefer a single analysis and proposal of what should be done. We can talk about how to get there after I understand where we're going. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From j.reid at mail.cryst.bbk.ac.uk Tue Jun 24 10:03:26 2008 From: j.reid at mail.cryst.bbk.ac.uk (John Reid) Date: Tue, 24 Jun 2008 09:03:26 +0100 Subject: [C++-sig] boost python pickle docs are empty on boost.org Message-ID: Does anyone else not get any content at http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/pickle.html ? John. From benkstein at langer-emv.de Tue Jun 24 11:35:36 2008 From: benkstein at langer-emv.de (Frank Benkstein) Date: Tue, 24 Jun 2008 11:35:36 +0200 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python In-Reply-To: <48600BE6.8090402@boostpro.com> References: <485A1EF4.6050803@langer-emv.de> <87prqdpm1v.fsf@mcbain.luannocracy.com> <485B5F4A.6000002@langer-emv.de> <48600BE6.8090402@boostpro.com> Message-ID: <4860BFE8.9080403@langer-emv.de> Hi, David Abrahams wrote: > Frank Benkstein wrote: >> David Abrahams wrote: > I don't know if you're aware of this, but Boost.Python is currently > incompatible with the use of Py_Finalize We currently call Py_Initialize/Py_Finalize in our applications multiple times while using Boost.Python and didn't notice any problems other than ensuring that the error indicator is not set, i.e. calling PyErr_Clear/PyErr_Print. Is there a document somewhere summarizing what's expected to fail and what must be done to make it fully work? [This probably belongs into another thread.] > All I was saying was that that single function probably ought to include > the PyErr_Occurred check If don't understand how that should work. Do want to call this function after every call to the C API? The way I see it every function that calls the C API has to check for errors itself. If it detects one (through a zero or a null pointer return value or a mandatory call to PyErr_Occurred) it should call a function that knows how to translate this error to a C++ exception. Currently this translation is done by throw_error_already_set. >> To reiterate: >> >> - If you catch error_already_set the error indicator is set, it is not >> safe to call Py_Finalize(). >> - If you catch exceptions::Exception the error indicator is not set, it >> is safe to call Py_Finalize(). > > Okay... well, I really dislike the idea of having both things in the > library at once, and I was never really thrilled with error_already_set. > We should think about how to replace it with your thing. My guess is > that if the library starts throwing something not derived from > error_already_set, regardless of whether it leaves the Python error > there, it's going to break more code than if we changed the meaning of > error_already_set or "lied" by deriving your thing from it. There will > be transition issues, so we should discuss deprecation, compile-time > checks, runtime checks, etc. Yes, error_already_set should go. An intermediate solution in the deprecation phase could be a runtime switch so new and old code can coexist. In the transitional phase the base exception class could provide a restore method that puts the error indicator back. This way code that's handling the Python exceptions itself can be changed from catch (error_already_set &) { ... } to catch (exceptions::python_exception &e) { e.restore(); ... } Maybe it's possible to do some wizardry to do that automatically but I don't know about that. I also would like to think about deprecation warnings and compile time switches later when there is any code and it is in a working shape. >>>> And instance members "type", "value" and "traceback" so it can be >>>> set or restored as the Python error indicator using PyErr_Restore >>>> or PyErr_SetObject if the traceback is None. >>> Do you really need to store the type in each instance? Oh, maybe you >>> do; it could end up being a python exception derived from one of the >>> standard exceptions. Then what's "mapped_type" (a.k.a. "python_type") >>> for? > > Inquiring minds wanna know. Suppose you want to define a C++ exception class that wraps python's LookupError. This could look like the following: // Define the wrapper class. class LookupError { public: // Every wrapper class must have this member. It is a handle for the // Python type object whose instances this class will wrap. static object type; // This is the real type of the exception. It may be LookupError but // also KeyError or IndexError or something else. object real_type; // This is the exception instance. object value; // This is the traceback or None. object traceback; LookupError(PyObject *t, PyObject *v, PyObject *tb); }; LookupError::type = handle<>(borrowed(PyExc_LookupError)); To register the exception you would call something like this somewhere in your code: exceptions::register(); After that calls to the function that will replace throw_error_already_set will throw this LookupError class if PyErr_ExceptionMatches(LookupError::type.ptr()). The registry would ensure that subclasses come before their base classes. > I think I'd prefer a single analysis and proposal of what should be > done. We can talk about how to get there after I understand where we're > going. Ok, I think most of the pieces are already there but I'll try to come up with something more formal. Best regards, Frank Benkstein. -- Frank Benkstein Software Development Tel.: +49(0) 351 430093-27 Fax : +49(0) 351 430093-22 mailto:benkstein at langer-emv.de Langer EMV-Technik GmbH D-01728 Bannewitz N?thnitzer Hang 31 Germany Registergericht: Amtsgericht Dresden, HRB 15402 Gesch?ftsf?hrer: Gunter Langer www.langer-emv.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From dave at boostpro.com Tue Jun 24 20:21:13 2008 From: dave at boostpro.com (David Abrahams) Date: Tue, 24 Jun 2008 14:21:13 -0400 Subject: [C++-sig] boost python pickle docs are empty on boost.org In-Reply-To: References: Message-ID: <48613B19.7060204@boostpro.com> John Reid wrote: > Does anyone else not get any content at > http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/pickle.html > ? Not I. Looks like that page was lost in the website translation. Rene? -- Dave Abrahams BoostPro Computing http://www.boostpro.com From grafikrobot at gmail.com Tue Jun 24 20:39:10 2008 From: grafikrobot at gmail.com (Rene Rivera) Date: Tue, 24 Jun 2008 13:39:10 -0500 Subject: [C++-sig] boost python pickle docs are empty on boost.org In-Reply-To: <48613B19.7060204@boostpro.com> References: <48613B19.7060204@boostpro.com> Message-ID: <48613F4E.3040901@gmail.com> David Abrahams wrote: > John Reid wrote: >> Does anyone else not get any content at >> http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/pickle.html >> ? > > Not I. Looks like that page was lost in the website translation. Rene? I'll look into it... But a trac ticket would be appreciated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail From dave at boostpro.com Tue Jun 24 20:58:40 2008 From: dave at boostpro.com (David Abrahams) Date: Tue, 24 Jun 2008 14:58:40 -0400 Subject: [C++-sig] Proposal to improve Python exception handling in Boost.Python In-Reply-To: <4860BFE8.9080403@langer-emv.de> References: <485A1EF4.6050803@langer-emv.de> <87prqdpm1v.fsf@mcbain.luannocracy.com> <485B5F4A.6000002@langer-emv.de> <48600BE6.8090402@boostpro.com> <4860BFE8.9080403@langer-emv.de> Message-ID: <486143E0.8050402@boostpro.com> Frank Benkstein wrote: > Hi, > > David Abrahams wrote: >> Frank Benkstein wrote: >>> David Abrahams wrote: >> I don't know if you're aware of this, but Boost.Python is currently >> incompatible with the use of Py_Finalize > > We currently call Py_Initialize/Py_Finalize in our applications multiple > times while using Boost.Python and didn't notice any problems other than > ensuring that the error indicator is not set, i.e. calling > PyErr_Clear/PyErr_Print. > > Is there a document somewhere summarizing what's expected to fail and > what must be done to make it fully work? file:///tmp/todo.html#pyfinalize-safety is the best I can come up with. >> All I was saying was that that single function probably ought to include >> the PyErr_Occurred check > > If don't understand how that should work. Do want to call this function > after every call to the C API? The way I see it every function that > calls the C API has to check for errors itself. If it detects one > (through a zero or a null pointer return value or a mandatory call to > PyErr_Occurred) it should call a function that knows how to translate > this error to a C++ exception. Currently this translation is done by > throw_error_already_set. And why should a function that would only check by calling PyErr_Occurred have to check for itself? An extra call to PyErr_Occurred when you're about to throw a C++ exception anyway (e.g. because you detected a -1) isn't going to hurt anyone. > Yes, error_already_set should go. An intermediate solution in the > deprecation phase could be a runtime switch so new and old code can > coexist. In the transitional phase the base exception class could > provide a restore method that puts the error indicator back. This way > code that's handling the Python exceptions itself can be changed from > > catch (error_already_set &) { > ... > } > > to > > catch (exceptions::python_exception &e) { > e.restore(); > ... > } > > Maybe it's possible to do some wizardry to do that automatically but I > don't know about that. I also would like to think about deprecation > warnings and compile time switches later when there is any code and it > is in a working shape. Suit yourself, but I won't want to proceed until the transition issue has been carefully thought through and discussed. > Suppose you want to define a C++ exception class that wraps python's > LookupError. This could look like the following: > > > // Define the wrapper class. > class LookupError { > public: > // Every wrapper class must have this member. It is a handle for the > // Python type object whose instances this class will wrap. > static object type; > > // This is the real type of the exception. It may be LookupError but > // also KeyError or IndexError or something else. > object real_type; > // This is the exception instance. > object value; > // This is the traceback or None. > object traceback; > > LookupError(PyObject *t, PyObject *v, PyObject *tb); > }; > > LookupError::type = handle<>(borrowed(PyExc_LookupError)); > > > To register the exception you would call something like this somewhere > in your code: > > > exceptions::register(); > > Hmm. My intention had always been to implement the feature discussed in http://article.gmane.org/gmane.comp.python.c%2B%2B/3812, Is this compatible with those ideas? > After that calls to the function that will replace > throw_error_already_set will throw this LookupError class if > PyErr_ExceptionMatches(LookupError::type.ptr()). > > The registry would ensure that subclasses come before their base > classes. > >> I think I'd prefer a single analysis and proposal of what should be >> done. We can talk about how to get there after I understand where we're >> going. > > Ok, I think most of the pieces are already there but I'll try to come up > with something more formal. I don't need anything more formal; I'd just like you to leave out intermediate steps: propose where you think things should end up, not a plan for getting there over several releases of the code (or several SVN checkins), just to keep things clearer for me. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dave at boostpro.com Tue Jun 24 21:05:19 2008 From: dave at boostpro.com (David Abrahams) Date: Tue, 24 Jun 2008 15:05:19 -0400 Subject: [C++-sig] boost python pickle docs are empty on boost.org In-Reply-To: <48613F4E.3040901@gmail.com> References: <48613B19.7060204@boostpro.com> <48613F4E.3040901@gmail.com> Message-ID: <4861456F.8040005@boostpro.com> Rene Rivera wrote: > David Abrahams wrote: >> John Reid wrote: >>> Does anyone else not get any content at >>> http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/pickle.html >>> ? >> >> Not I. Looks like that page was lost in the website translation. Rene? > > I'll look into it... But a trac ticket would be appreciated. > > > http://svn.boost.org/trac/boost/ticket/2046 -- Dave Abrahams BoostPro Computing http://www.boostpro.com From CarstenHarms9368 at gmx.de Tue Jun 24 21:57:04 2008 From: CarstenHarms9368 at gmx.de (Carsten Harms) Date: Tue, 24 Jun 2008 21:57:04 +0200 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance Message-ID: <48615190.7060405@gmx.de> Hi! I'm trying to extract a C++ pointer from a boost::python::object which inherited two base classes (both python extensions). I'm using boost 1.35 under MSVC 9. KeyListener exposing: > class_("KeyListener" ) > .def("keyPressed", > pure_virtual(&OIS::KeyListener::keyPressed), > return_value_policy() ) > .def("keyReleased", > pure_virtual(&OIS::KeyListener::keyReleased), > return_value_policy() ) > ; GameState exposing: > class_("GameStateBase" ) > .def("enter", pure_virtual(&GameStateBase::enter)) > .def("exit", pure_virtual(&GameStateBase::exit)) > .def("pause", &GameStateBase::pause, &GameStateBaseWrap::pause) > .def("resume", &GameStateBase::resume, &GameStateBaseWrap::resume) > .def("frameStarted", > pure_virtual(&GameStateBaseWrap::frameStarted), > return_value_policy() ) > .def("frameEnded", > pure_virtual(&GameStateBaseWrap::frameEnded), > return_value_policy() ) > ; Please note that both c++ bases can be extracted as pointers when only _1_ is used as a base. for example: > class TestKeyListener(KeyListener): > def keyPressed(self, kevt): > print "key pressed:" > return True > > def keyReleased(self, kevt): > print "key released:" > return True > class TestState(GameStateBase): > def enter(self): > print "enter!" > def exit(self): > print "exit!" work as expected. I can extract the c++ pointer to their c++ base with > extract (_obj); or > extract (_obj); But as soon as I inherit both like > class TestState2(GameStateBase, KeyListener): > def enter(self): > print "enter!" > def exit(self): > print "exit!" > > def keyPressed(self, kevt): > print "key pressed:" > return True > > def keyReleased(self, kevt): > print "key released:" > return True I can only extract the first base, GameStateBase in this example. If I exchange GameStateBase and KeyListener, I can only extract KeyListener. This is the error which I'm getting: > TypeError: No registered converter was able to extract a C++ pointer > to type class OIS::KeyListener from this Python object of type TestState2 Well, can someone tell me if I made a mistake, if this is a bug of boost::python, or if it just isn't implemented yet. Thanks in advance Carsten Harms From seefeld at sympatico.ca Tue Jun 24 22:23:54 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Tue, 24 Jun 2008 16:23:54 -0400 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <48615190.7060405@gmx.de> References: <48615190.7060405@gmx.de> Message-ID: <486157DA.9060704@sympatico.ca> Carsten Harms wrote: > Please note that both c++ bases can be extracted as pointers when only > _1_ is used as a base. > for example: >> class TestKeyListener(KeyListener): >> def keyPressed(self, kevt): >> print "key pressed:" >> return True >> def keyReleased(self, kevt): >> print "key released:" >> return True >> class TestState(GameStateBase): >> def enter(self): >> print "enter!" >> def exit(self): >> print "exit!" > work as expected. I can extract the c++ pointer to their c++ base with >> extract (_obj); > or >> extract (_obj); > But as soon as I inherit both like >> class TestState2(GameStateBase, KeyListener): >> def enter(self): >> print "enter!" >> def exit(self): >> print "exit!" >> >> def keyPressed(self, kevt): >> print "key pressed:" >> return True >> >> def keyReleased(self, kevt): >> print "key released:" >> return True > I can only extract the first base, GameStateBase in this example. If I > exchange GameStateBase and KeyListener, I can only extract > KeyListener. This is the error which I'm getting: >> TypeError: No registered converter was able to extract a C++ pointer >> to type class OIS::KeyListener from this Python object of type >> TestState2 > Well, can someone tell me if I made a mistake, if this is a bug of > boost::python, or if it just isn't implemented yet. > I think you need to establish the parent/child relationship also at runtime, through explicit constructor calls: class TestState2(GameStateBase, KeyListener): def __init__(self): super(TestState2, self).__init__() .... I'm not sure why the single inheritance works, it should suffer the same problem. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From CarstenHarms9368 at gmx.de Tue Jun 24 22:48:49 2008 From: CarstenHarms9368 at gmx.de (Carsten Harms) Date: Tue, 24 Jun 2008 22:48:49 +0200 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <486157DA.9060704@sympatico.ca> References: <486157DA.9060704@sympatico.ca> Message-ID: <48615DB1.5070501@gmx.de> I just tried that and I'm getting exactly the same error. Maybe this information will help to solve the problem: The python script runs in an embedded python 2.5 interpreter and the c++ extensions are exposed in the same application. The script then imports them. > I'm not sure why the single inheritance works, it should suffer the same > problem. > Why should it suffer from that problem? I think boost::python is doing some magic so that it works at least with single inheritance. Any ideas? Thanks in advance Carsten Harms From CarstenHarms9368 at gmx.de Wed Jun 25 11:17:04 2008 From: CarstenHarms9368 at gmx.de (Carsten Harms) Date: Wed, 25 Jun 2008 11:17:04 +0200 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <48615DB1.5070501@gmx.de> References: <48615DB1.5070501@gmx.de> Message-ID: <48620D10.9000900@gmx.de> Here is a small app which reproduces the behaviour: -------------------------------------------------- #define BOOST_PYTHON_STATIC_LIB #include #include #include "conio.h" using namespace boost::python; class Base1 { public: virtual ~Base1() {} virtual void func1 () = 0; }; class Base1Wrap: public Base1, public wrapper { public: virtual ~Base1Wrap() {} void func1 () { this->get_override("func1")(); } }; class Base2 { public: virtual ~Base2() {} virtual void func2 () = 0; }; class Base2Wrap: public Base2, public wrapper { public: virtual ~Base2Wrap() {} void func2 () { this->get_override("func2")(); } }; void extractBase1( boost::python::object& obj) { Base1* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; Base1& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; ex1->func1(); ex2.func1(); } void extractBase2( boost::python::object& obj) { Base2* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; Base2& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; ex1->func2(); ex2.func2(); } BOOST_PYTHON_MODULE(Test_ext) { class_("Base1") .def("func1", pure_virtual(&Base1::func1)) ; class_("Base2") .def("func2", pure_virtual(&Base2::func2)) ; def("extractBase1", extractBase1); def("extractBase2", extractBase2); } int main(int, char **) { try { Py_Initialize(); initTest_ext(); object main = import("__main__"); object dictionary(main.attr("__dict__")); object result = exec_file("test.py", dictionary, dictionary ); //Py_Finalize(); } catch (error_already_set) { PyErr_Print(); } while(!kbhit()); return 0; } -------------------------------------------------- python script: -------------------------------------------------- from Test_ext import * class class1(Base1): def func1(self): print "func1 called!" class class2(Base2): def func2(self): print "func2 called!" class both1(Base1, Base2): def func1(self): print "func1 called!" def func2(self): print "func2 called!" class both2(Base2, Base1): def func1(self): print "func1 called!" def func2(self): print "func2 called!" ################################# object1 = class1() object2 = class2() extractBase1(object1) extractBase2(object2) object3 = both1() extractBase1(object3) extractBase2(object3) # doesn't work object4 = both2() extractBase1(object4) # doesn't work extractBase2(object4) From dave at boostpro.com Wed Jun 25 13:31:07 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 25 Jun 2008 07:31:07 -0400 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <48620D10.9000900@gmx.de> References: <48615DB1.5070501@gmx.de> <48620D10.9000900@gmx.de> Message-ID: <8C2B458E-F569-4B1D-B6D0-F1CEFD293B7B@boostpro.com> Thank you; could you attach this to a ticket at http://svn.boost.org? Thanks again! Sent from my iPhone On Jun 25, 2008, at 5:17 AM, Carsten Harms wrote: > Here is a small app which reproduces the behaviour: > -------------------------------------------------- > #define BOOST_PYTHON_STATIC_LIB > #include > #include > #include "conio.h" > > using namespace boost::python; > > class Base1 > { > public: > virtual ~Base1() {} > virtual void func1 () = 0; > }; > > class Base1Wrap: public Base1, public wrapper > { > public: > virtual ~Base1Wrap() {} > void func1 () { this->get_override("func1")(); } > }; > > > class Base2 > { > public: > virtual ~Base2() {} > virtual void func2 () = 0; > }; > > class Base2Wrap: public Base2, public wrapper > { > public: > virtual ~Base2Wrap() {} > void func2 () { this->get_override("func2")(); } > }; > > > > void extractBase1( boost::python::object& obj) > { > Base1* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; > Base1& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; > > ex1->func1(); > ex2.func1(); > } > > void extractBase2( boost::python::object& obj) > { > Base2* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; > Base2& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; > > ex1->func2(); > ex2.func2(); > } > > > BOOST_PYTHON_MODULE(Test_ext) > { > class_("Base1") > .def("func1", pure_virtual(&Base1::func1)) > ; > > class_("Base2") > .def("func2", pure_virtual(&Base2::func2)) > ; > > def("extractBase1", extractBase1); > def("extractBase2", extractBase2); > } > > > int main(int, char **) > { > try > { > Py_Initialize(); > initTest_ext(); > > object main = import("__main__"); > object dictionary(main.attr("__dict__")); > > object result = exec_file("test.py", dictionary, dictionary ); > //Py_Finalize(); > } > catch (error_already_set) > { > PyErr_Print(); > } > > while(!kbhit()); > > return 0; > } > -------------------------------------------------- > python script: > -------------------------------------------------- > > from Test_ext import * > > class class1(Base1): > def func1(self): > print "func1 called!" > class class2(Base2): > def func2(self): > print "func2 called!" > > class both1(Base1, Base2): > def func1(self): > print "func1 called!" > def func2(self): > print "func2 called!" > class both2(Base2, Base1): > def func1(self): > print "func1 called!" > def func2(self): > print "func2 called!" > > ################################# > object1 = class1() > object2 = class2() > > extractBase1(object1) > extractBase2(object2) > > > object3 = both1() > > extractBase1(object3) > extractBase2(object3) # doesn't work > > object4 = both2() > > extractBase1(object4) # doesn't work > extractBase2(object4) > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From dave at boostpro.com Wed Jun 25 13:32:11 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 25 Jun 2008 07:32:11 -0400 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <48620D10.9000900@gmx.de> References: <48615DB1.5070501@gmx.de> <48620D10.9000900@gmx.de> Message-ID: Hmm; do you get a different result if you leave out the virtual functions? Sent from my iPhone On Jun 25, 2008, at 5:17 AM, Carsten Harms wrote: > Here is a small app which reproduces the behaviour: > -------------------------------------------------- > #define BOOST_PYTHON_STATIC_LIB > #include > #include > #include "conio.h" > > using namespace boost::python; > > class Base1 > { > public: > virtual ~Base1() {} > virtual void func1 () = 0; > }; > > class Base1Wrap: public Base1, public wrapper > { > public: > virtual ~Base1Wrap() {} > void func1 () { this->get_override("func1")(); } > }; > > > class Base2 > { > public: > virtual ~Base2() {} > virtual void func2 () = 0; > }; > > class Base2Wrap: public Base2, public wrapper > { > public: > virtual ~Base2Wrap() {} > void func2 () { this->get_override("func2")(); } > }; > > > > void extractBase1( boost::python::object& obj) > { > Base1* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; > Base1& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; > > ex1->func1(); > ex2.func1(); > } > > void extractBase2( boost::python::object& obj) > { > Base2* ex1 = extract(obj) BOOST_EXTRACT_WORKAROUND; > Base2& ex2 = extract(obj) BOOST_EXTRACT_WORKAROUND; > > ex1->func2(); > ex2.func2(); > } > > > BOOST_PYTHON_MODULE(Test_ext) > { > class_("Base1") > .def("func1", pure_virtual(&Base1::func1)) > ; > > class_("Base2") > .def("func2", pure_virtual(&Base2::func2)) > ; > > def("extractBase1", extractBase1); > def("extractBase2", extractBase2); > } > > > int main(int, char **) > { > try > { > Py_Initialize(); > initTest_ext(); > > object main = import("__main__"); > object dictionary(main.attr("__dict__")); > > object result = exec_file("test.py", dictionary, dictionary ); > //Py_Finalize(); > } > catch (error_already_set) > { > PyErr_Print(); > } > > while(!kbhit()); > > return 0; > } > -------------------------------------------------- > python script: > -------------------------------------------------- > > from Test_ext import * > > class class1(Base1): > def func1(self): > print "func1 called!" > class class2(Base2): > def func2(self): > print "func2 called!" > > class both1(Base1, Base2): > def func1(self): > print "func1 called!" > def func2(self): > print "func2 called!" > class both2(Base2, Base1): > def func1(self): > print "func1 called!" > def func2(self): > print "func2 called!" > > ################################# > object1 = class1() > object2 = class2() > > extractBase1(object1) > extractBase2(object2) > > > object3 = both1() > > extractBase1(object3) > extractBase2(object3) # doesn't work > > object4 = both2() > > extractBase1(object4) # doesn't work > extractBase2(object4) > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From CarstenHarms9368 at gmx.de Wed Jun 25 14:40:44 2008 From: CarstenHarms9368 at gmx.de (Carsten Harms) Date: Wed, 25 Jun 2008 14:40:44 +0200 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: References: Message-ID: <48623CCC.7060907@gmx.de> just tested it without the virtual functions and it gave me exactly the same result :( From dave at boostpro.com Wed Jun 25 15:33:42 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 25 Jun 2008 09:33:42 -0400 Subject: [C++-sig] problem with boost::python::extract of c++ pointers from objects with multiple inheritance In-Reply-To: <48623CCC.7060907@gmx.de> References: <48623CCC.7060907@gmx.de> Message-ID: Then please continue to reduce it until you ch go no further and put the reduced case in the trac ticket. Thanks! Sent from my iPhone On Jun 25, 2008, at 8:40 AM, Carsten Harms wrote: > just tested it without the virtual functions and it gave me exactly > the same result :( > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From kwiecm at lunainnovations.com Wed Jun 25 17:24:39 2008 From: kwiecm at lunainnovations.com (Matthew Kwiec) Date: Wed, 25 Jun 2008 11:24:39 -0400 Subject: [C++-sig] Problem running the simple Boost Python example Message-ID: <6AC0CCE02D1B684BBC8351F15E8F781B0C454E758D@e2k7.fsdomain> I cannot seem to get a Boost.Python project to run in Python. I have compiled the project using bjam from boost_1_33_1 but I cannot seem to figure out how to run it in Python. Currently in my output folder (which is in bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/) I have a hello.so, hello.o and a hello.so.1.33.1. What commands do I use to open these files in python? I have tried using the import command but it doesn't work with these and I cannot find a suitable way to call these libraries in Python. I am using boost_1_33_1 because the folks at work here have Debian installed as the OS and they couldn't seem to get 1_34 or 1_35 to compile properly with it. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwiecm at lunainnovations.com Wed Jun 25 22:19:56 2008 From: kwiecm at lunainnovations.com (Matthew Kwiec) Date: Wed, 25 Jun 2008 16:19:56 -0400 Subject: [C++-sig] Problem running the simple Boost Python example In-Reply-To: <6AC0CCE02D1B684BBC8351F15E8F781B0C454E758D@e2k7.fsdomain> References: <6AC0CCE02D1B684BBC8351F15E8F781B0C454E758D@e2k7.fsdomain> Message-ID: <6AC0CCE02D1B684BBC8351F15E8F781B0C45531401@e2k7.fsdomain> Never mind I have solved this problem. Matt From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On Behalf Of Matthew Kwiec Sent: Wednesday, June 25, 2008 11:25 AM To: c++-sig at python.org Subject: [C++-sig] Problem running the simple Boost Python example I cannot seem to get a Boost.Python project to run in Python. I have compiled the project using bjam from boost_1_33_1 but I cannot seem to figure out how to run it in Python. Currently in my output folder (which is in bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/) I have a hello.so, hello.o and a hello.so.1.33.1. What commands do I use to open these files in python? I have tried using the import command but it doesn't work with these and I cannot find a suitable way to call these libraries in Python. I am using boost_1_33_1 because the folks at work here have Debian installed as the OS and they couldn't seem to get 1_34 or 1_35 to compile properly with it. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From cslush at gmail.com Fri Jun 27 23:58:43 2008 From: cslush at gmail.com (Craig Slusher) Date: Fri, 27 Jun 2008 17:58:43 -0400 Subject: [C++-sig] Embedded Python Message-ID: <8f59267f0806271458n7351eb4u3cccac581277489c@mail.gmail.com> I am having trouble with the following code: PyObject *module = PyImport_ImportModule(modulename); if (module == NULL) { PyObject* et, *ev, *etr; PyErr_Fetch(&et, &ev, &etr); PyObject* traceback = PyImport_ImportModule("traceback"); PyObject* tb = PyObject_CallMethodObjArgs(traceback, PyString_FromString("format_exception"), et, ev, etr, NULL); char *message = PyString_AsString(PyObject_Str(tb)); ... ... } When this code executes, it gets into the "module == NULL" condition. However, when I try to get the exception that occurred, I get the value "" copied into the "char* message" variable. Can anyone shed some light on what might cause this to happen? I thought that if I actually get into that NULL condition that an exception has occurred. -- Craig Slusher cslush at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boostpro.com Sat Jun 28 00:29:19 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 27 Jun 2008 18:29:19 -0400 Subject: [C++-sig] Embedded Python In-Reply-To: <8f59267f0806271458n7351eb4u3cccac581277489c@mail.gmail.com> References: <8f59267f0806271458n7351eb4u3cccac581277489c@mail.gmail.com> Message-ID: <486569BF.7020803@boostpro.com> Craig Slusher wrote: > I am having trouble with the following code: > > PyObject *module = PyImport_ImportModule(modulename); > if (module == NULL) { > > PyObject* et, *ev, *etr; > PyErr_Fetch(&et, &ev, &etr); > PyObject* traceback = PyImport_ImportModule("traceback"); > PyObject* tb = PyObject_CallMethodObjArgs(traceback, PyString_FromString("format_exception"), et, ev, etr, NULL); > > char *message = PyString_AsString(PyObject_Str(tb)); > ... > ... > } > > When this code executes, it gets into the "module == NULL" condition. However, when I try to get the exception that occurred, I get the value "" copied into the "char* message" variable. > > > Can anyone shed some light on what might cause this to happen? I thought that if I actually get into that NULL condition that an exception has occurred. This really has nothing to do with C++. I suggest you try comp.lang.python, where the C API experts hang out. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From cslush at gmail.com Sat Jun 28 00:46:40 2008 From: cslush at gmail.com (Craig Slusher) Date: Fri, 27 Jun 2008 18:46:40 -0400 Subject: [C++-sig] Embedded Python In-Reply-To: <486569BF.7020803@boostpro.com> References: <8f59267f0806271458n7351eb4u3cccac581277489c@mail.gmail.com> <486569BF.7020803@boostpro.com> Message-ID: <8f59267f0806271546y3d7386f2p373c8c4b00ce123e@mail.gmail.com> I'll try that. Thanks On Fri, Jun 27, 2008 at 6:29 PM, David Abrahams wrote: > Craig Slusher wrote: > > I am having trouble with the following code: > > > > PyObject *module = PyImport_ImportModule(modulename); > > if (module == NULL) { > > > > PyObject* et, *ev, *etr; > > PyErr_Fetch(&et, &ev, &etr); > > PyObject* traceback = PyImport_ImportModule("traceback"); > > PyObject* tb = PyObject_CallMethodObjArgs(traceback, > PyString_FromString("format_exception"), et, ev, etr, NULL); > > > > char *message = PyString_AsString(PyObject_Str(tb)); > > ... > > ... > > } > > > > When this code executes, it gets into the "module == NULL" condition. > However, when I try to get the exception that occurred, I get the value > "" copied into the "char* message" variable. > > > > > > Can anyone shed some light on what might cause this to happen? I thought > that if I actually get into that NULL condition that an exception has > occurred. > > This really has nothing to do with C++. I suggest you try > comp.lang.python, where the C API experts hang out. > > > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -- Craig Slusher cslush at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wieher at gmail.com Mon Jun 30 18:55:06 2008 From: michael.wieher at gmail.com (Michael Wieher) Date: Mon, 30 Jun 2008 11:55:06 -0500 Subject: [C++-sig] Set optimization level for build_ext ?? Message-ID: Hey, trying to use valgrind with some libraries generated via native python's extension capabilities (not boost) so, by default I see gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC -I/usr/include/python2.4 .... (my files) I want -O0 not -O2 so valgrind can find line numbers more correctly... I tried using "extra_complie_args" but that appends -O0 to the same line, still has -O2 ... not sure if -O0 over-rides the -O2 from earlier in the invocation or if it is ignored in favor of -O2 it looks like gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC -I/usr/include/python2.4 -c memrid.cpp -o build/temp.linux-i686-2.4/memrid.o -O0 can anyone help me to be sure that I'm using NO optimization when this is compiled (ie: how to turn it on/off?) thanks, -mike From dave at boostpro.com Mon Jun 30 19:27:41 2008 From: dave at boostpro.com (David Abrahams) Date: Mon, 30 Jun 2008 13:27:41 -0400 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: References: Message-ID: <4869178D.7060908@boostpro.com> Michael Wieher wrote: > Hey, > > trying to use valgrind with some libraries generated via native > python's extension capabilities (not boost) > > so, by default I see > > can anyone help me to be sure that I'm using NO optimization when this > is compiled (ie: how to turn it on/off?) This is neither a Python question nor a C++ question. I'm not telling you to get lost, but you might get better results in a GCC forum. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From seefeld at sympatico.ca Mon Jun 30 19:37:47 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon, 30 Jun 2008 13:37:47 -0400 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: References: Message-ID: <486919EB.7040607@sympatico.ca> Michael Wieher wrote: > Hey, > > trying to use valgrind with some libraries generated via native > python's extension capabilities (not boost) > > so, by default I see > [...] where do you see that ? What exactly are you doing ? As David points out, this doesn't appear to be related neither to Python nor C++. As your subject line suggests, it may be a problem with boost.python's build system. If no-one on this list is able to help you with that, you may have better luck asking in the boost.build list (boost-build at lists.boost.org), or on IRC ( irc://irc.freenode.net/boost) Good luck, Stefan -- ...ich hab' noch einen Koffer in Berlin... From michael.wieher at gmail.com Mon Jun 30 19:43:37 2008 From: michael.wieher at gmail.com (Michael Wieher) Date: Mon, 30 Jun 2008 12:43:37 -0500 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: <4869178D.7060908@boostpro.com> References: <4869178D.7060908@boostpro.com> Message-ID: > This is neither a Python question nor a C++ question. I'm not telling > you to get lost, but you might get better results in a GCC forum. No... maybe you're not familiar with the tool I'm trying to use. But you're WAY off. This belongs here. I think? This is the SIG for Python/C++ integration? so, for questions relating to things described on this (and related) page(s) http://www.python.org/doc/ext/intro.html I should ask here? even if it is NOT boost-related, it is DIRECTLY related to integrating C++ into Python. I'm sorry that I'm not using your software... Or, where? Obviously you didn't really read too closely, since what I'm actually talking about a binary created by the distutils module (a python module) that is directly importable into C++. that has NOTHING to do with GCC. At all, ever. My issue is the level of control distutils gives me when creating these library.so files. distutils allows one to create my-custom-library.so from C++ files that are importable into Python. I know I can do all this with boost, but at the moment I'm not trying to, I'm trying to use the built-in functionality that python provides via its (3rd time I say this) distutils module to create the library.so from C++ to be imported into python. If this list is for boost-only questions, then can anyone please point me to a place I can ask questions about Python's distutils, C++ integration. On Mon, Jun 30, 2008 at 12:27 PM, David Abrahams wrote: > Michael Wieher wrote: >> Hey, >> >> trying to use valgrind with some libraries generated via native >> python's extension capabilities (not boost) >> >> so, by default I see >> > >> can anyone help me to be sure that I'm using NO optimization when this >> is compiled (ie: how to turn it on/off?) > > This is neither a Python question nor a C++ question. I'm not telling > you to get lost, but you might get better results in a GCC forum. > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From mbiasini at bluewin.ch Mon Jun 30 19:25:57 2008 From: mbiasini at bluewin.ch (Marco Biasini) Date: Mon, 30 Jun 2008 19:25:57 +0200 Subject: [C++-sig] Boost.Python embedding fails on MacOS X Message-ID: Hi! I posted this mail on the boost users mailing list and was then pointed to this mailing-list. I've got a problem when using boost.python on MacOS X. The program exits with TypeError: attribute name must be string This happens both in boost 1.34 and 1.35. I was however able to run attached snippet without problems with boost 1.33. Code: #include using namespace boost::python; class CppClass { public: int getNum() { return 7; } }; int main( int argc, char ** argv ) { try { Py_Initialize(); object main_module(( handle<>(borrowed(PyImport_AddModule("__main__"))))); object main_namespace = main_module.attr("__dict__"); main_namespace["CppClass"] = class_("CppClass") .def("getNum",&CppClass::getNum); handle<> ignored(( PyRun_String( "cpp = CppClass();print cpp.getNum() \n", Py_file_input, main_namespace.ptr(), main_namespace.ptr() ) )); } catch( error_already_set ) { PyErr_Print(); } } Specs, if it should matter: * MacOS 10.4.11 * Compiler gcc 4.0.1 (Apple, Inc.), Python 2.4 (MacPorts) Any suggestions/directions? Please let me know if you need additional information. Best, Marco From dave at boostpro.com Mon Jun 30 19:47:49 2008 From: dave at boostpro.com (David Abrahams) Date: Mon, 30 Jun 2008 13:47:49 -0400 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: References: <4869178D.7060908@boostpro.com> Message-ID: <48691C45.7030808@boostpro.com> Michael Wieher wrote: >> This is neither a Python question nor a C++ question. I'm not telling >> you to get lost, but you might get better results in a GCC forum. > > No... maybe you're not familiar with the tool I'm trying to use. But > you're WAY off. > This belongs here. I think? This is the SIG for Python/C++ integration? > so, for questions relating to things described on this (and related) page(s) > > http://www.python.org/doc/ext/intro.html > > I should ask here? even if it is NOT boost-related, it is DIRECTLY > related to integrating C++ into Python. I'm sorry that I'm not using > your software... It has nothing to do with my software. Your command-line used "gcc," which AFAIK will not do C++ compilation unless you use the variant called "g++" > Or, where? Obviously you didn't really read too closely, since what > I'm actually talking about a binary created by the distutils module (a > python module) that is directly importable into C++. > that has NOTHING to do with GCC. At all, ever. My issue is the level > of control distutils gives me when creating these library.so files. > > distutils allows one to create my-custom-library.so from C++ files > that are importable into Python. > > I know I can do all this with boost, but at the moment I'm not trying > to, I'm trying to use the built-in functionality that python provides > via its (3rd time I say this) distutils module to create the > library.so from C++ to be imported into python. > If this list is for boost-only questions, then can anyone please point > me to a place I can ask questions about Python's distutils, C++ > integration. It's not strictly a boost-only list, but few people here are doing this kind of thing with distutils. I suggest you find a distutils-related list if you want to ask where people know the answers. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From seefeld at sympatico.ca Mon Jun 30 19:59:57 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon, 30 Jun 2008 13:59:57 -0400 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: References: <4869178D.7060908@boostpro.com> Message-ID: <48691F1D.30604@sympatico.ca> Michael Wieher wrote: > My issue is the level > of control distutils gives me when creating these library.so files. > > distutils allows one to create my-custom-library.so from C++ files > that are importable into Python. > I have found distutils to be lacking substantially support for non-trivial features. In particular, for python extension building I completely abandoned the idea of using the standard build_ext command. (In my own project I have replaced build_ext by my own version...) AFAIK distutils isn't developed (or even maintained) any more, so you may have little luck finding answers to your questions on any list. The simplest way to figure out why distutils behaves the way it does, and how to work around its limitations, may be by reading the distutils code. Good luck, Stefan -- ...ich hab' noch einen Koffer in Berlin... From greg.landrum at gmail.com Mon Jun 30 21:26:20 2008 From: greg.landrum at gmail.com (Greg Landrum) Date: Mon, 30 Jun 2008 21:26:20 +0200 Subject: [C++-sig] Set optimization level for build_ext ?? In-Reply-To: References: Message-ID: <60825b0f0806301226v20b3f1adk4dfb7105c266788f@mail.gmail.com> On Mon, Jun 30, 2008 at 6:55 PM, Michael Wieher wrote: > can anyone help me to be sure that I'm using NO optimization when this > is compiled (ie: how to turn it on/off?) I gave up on distutils a while ago, but I did at some point figure out how to exert some control over the compile flags. Two files that *may* demonstrate what you want: http://rdkit.svn.sourceforge.net/viewvc/rdkit/trunk/Python/RDBuild.py?revision=1&view=markup and http://rdkit.svn.sourceforge.net/viewvc/rdkit/trunk/Code/ChemicalFeatures/Wrap/setup.py?revision=1&view=markup Good luck, -greg