From aarcenas at worldbank.org Tue Feb 1 15:35:53 2005 From: aarcenas at worldbank.org (aarcenas at worldbank.org) Date: Tue, 1 Feb 2005 09:35:53 -0500 Subject: [C++-sig] Joel de Guzman from Bacolod Message-ID: Greetings! I am trying to track down a friend whose name is Joel de Guzman from Bacolod, Philippines. I found this email address on the internet. If the recipient of this email is Joel de Guzman, a Filipino, please reply to this email. If not, kindly disregard this email message. Thank you very much. --Oggie Arcenas ******************************** Agustin Arcenas Environment Department The World Bank Washington, D.C., USA Tel. No. (202) 458-0647 Fax: (202) 522-2130 ******************************** From Steve.Knight at kbcfp.com Tue Feb 1 18:37:02 2005 From: Steve.Knight at kbcfp.com (Knight, Steve) Date: Tue, 1 Feb 2005 17:37:02 -0000 Subject: [C++-sig] boost_1.30_2 => boost_1.32.0 / Python2.2.3 => Python2.4.0 Message-ID: <8986A6DFC3761F45AE01C839D6292D4C1668FC@EXLN1-VS1.london.kbcfp.com> Hello, Hope you can help but I'm upgrading both Python and boost and have run into a specific problem. I have tried searching the archives for clues but haven't found anything, I apologise if I'm duplicating. So the problem is that I can't seem to wrap virtual functions in 1.32. To start from the beginning I have a class that I'm trying to register Python callbacks for so that when the C++ generates event messages it does so and calls back into Python code. I had this working before with something along the lines of the following (dummy class is used in place of the real underlying library class I'm trying to wrap): struct dummy { virtual void onMsg(int* arg1, int& arg2) = 0; }; struct MsgCallbackWrapper : dummy { PyObject* self; MsgCallbackWrapper(PyObject* self_) : dummy(), self(self_) {} void onMsg(int* listener, int& msg) { try { object o(msg); call_method(self, "onMsg", boost::ref(o)); } catch (...) { // There's not a lot you can do here because we probably // don't want to make our thread abort PyErr_Print(); } } }; BOOST_PYTHON_MODULE(test_boost) { class_ >("MsgCallback") .def("onMsg" , &dummy::onMsg); } So, I can build for python2.2 and boost 1.30.2 and do the following: Python 2.2.3 (#3, Sep 9 2003, 15:56:36) [GCC 3.2.2] on sunos5 >>> import test_boost >>> So, then I rebuild for Python2.4/boost_1_32_0 and try to do the same: ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#1, Nov 30 2004, 10:31:14) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import test_boost Segmentation Fault (core dumped) Seems to me that perhaps what I'm doing isn't supported under boost_1_32_0 but trying other example code for wrapping virtual functions seems to end in the same results. I also tried using the CVS head, at which point my code stops compiling, so making me think this this is something I'm doing wrong. However I can't decode the Using gdb I get a stack trace (below). Frame #1 looks suspicious to me in that MsgCallbackWrapper => dummy conversion would indeed be a downcast but I don't really know what I'm talking about so I'll leave my analysis of the situation at that! Does anyone have any idea what the problem could be and what I've missed? Thanks in advance, Steve #0 0xfe5e7c38 in std::iterator_traits > >, boost::list_edge > > const&, boost::list_edge > >*> >::difference_type std::__distance > >, boost::list_edge > > const&, boost::list_edge > >*> >(std::_List_iterator > >, boost::list_edge > > const&, boost::list_edge > >*>, std::_List_iterator > >, boost::list_edge > > const&, boost::list_edge > >*>, std::input_iterator_tag) () from /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/lib/libboost_python-gcc-1 _32.so #1 0xfe6eff20 in void boost::python::objects::register_conversion(bool, MsgCallbackWrapper*, dummy*) (is_downcast=false) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/inheritance.hpp:122 #2 0xfe6ef934 in void boost::python::objects::register_base_of::operator() (dummy*) const (this=0xffbee18f) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:56 #3 0xfe6ef3f4 in void boost::mpl::aux::for_each_impl::execute, boost::mpl::aux::sel_iter, boost::add_pointer >, boost::python::objects::register_base_of >(boost::mpl::aux::sel_iter*, boost::mpl::aux::sel_iter*, boost::add_pointer >*, boost::python::objects::register_base_of) (f={}) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ mpl/for_each.hpp:73 #4 0xfe6eebb4 in void boost::mpl::for_each, boost::add_pointer >, boost::python::objects::register_base_of >(boost::python::objects::register_base_of, boost::mpl::single_view*, boost::add_pointer >*) ( f={}) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ mpl/for_each.hpp:96 #5 0xfe6ee424 in void boost::python::objects::register_shared_ptr_from_python_and_casts >(MsgCallbackWrapper*, boost::mpl::single_view) () at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:88 #6 0xfe6ee014 in void boost::python::objects::class_metadata, boost::python::detail::not_specified>::maybe_register_callback_class(dummy*, mpl_::bool_) () ---Type to continue, or q to quit--- at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:259 #7 0xfe6edd10 in void boost::python::objects::class_metadata, boost::python::detail::not_specified>::register_aux2 >(dummy*, mpl_::bool_) () at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:216 #8 0xfe6edac8 in boost::python::objects::class_metadata, boost::python::detail::not_specified>::register_aux(void*) () at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:208 #9 0xfe6ed804 in boost::python::objects::class_metadata, boost::python::detail::not_specified>::register_() () at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/object/class_metadata.hpp:195 #10 0xfe6ed560 in void boost::python::class_, boost::python::detail::not_specified>::initialize >(boost::python::init const&) (this=0xffbee560, i=@0xffbee4d0) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/class.hpp:453 #11 0xfe6ed3a4 in boost::python::class_, boost::python::detail::not_specified>::class_(char const*, char const*) (this=0xffbee560, name=0xfe7961c0 "MsgCallback", doc=0x0) at /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/include/boost-1_32/boost/ python/class.hpp:586 #12 0xfe6ecfd4 in init_module_test_boost() () at test_boost.cpp:39 #13 0xfe5ecb74 in boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::any_pointer) () from /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/lib/libboost_python-gcc-1 _32.so #14 0xfe5ebefc in boost::python::handle_exception_impl(boost::function0 >) () from /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/lib/libboost_python-gcc-1 _32.so #15 0xfe5ec990 in boost::python::detail::init_module(char const*, void (*)()) () from /proj/cbtech/pkgs/sunos-5.8-sun4u/boost-1.32.0/lib/libboost_python-gcc-1 _32.so -------------- next part -------------- An HTML attachment was scrubbed... URL: From Benjamin_Schmeling at gmx.de Tue Feb 1 19:37:20 2005 From: Benjamin_Schmeling at gmx.de (Benjamin Schmeling) Date: Tue, 01 Feb 2005 19:37:20 +0100 Subject: [C++-sig] problem with constructor/implicitly_convertible Message-ID: <41FFCC60.7080001@gmx.de> Hi, I have defined the following: bigint* bigint_constructor(long_ l){ return new bigint(to_bigint(l)); } class_("bigint") .def("__init__", make_constructor(bigint_constructor)) .... .... implicitly_convertible(); Now I want to have a implicit conversion from long_ to bigint. My original c++ class has no constructor with long_ but my python-bigint class. The compiler tries to find one on c++ bigint and doesn't find it. How should I use implicitly_convertible to reach my goal? Benjamin From rwgk at yahoo.com Thu Feb 3 00:04:13 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 2 Feb 2005 15:04:13 -0800 (PST) Subject: [C++-sig] problem with constructor/implicitly_convertible In-Reply-To: <41FFCC60.7080001@gmx.de> Message-ID: <20050202230413.91709.qmail@web20227.mail.yahoo.com> --- Benjamin Schmeling wrote: > Now I want to have a implicit conversion from long_ to bigint. My > original c++ class has no constructor with long_ but my python-bigint > class. The compiler tries to find one on c++ bigint and doesn't find it. > How should I use implicitly_convertible to reach my goal? Maybe you can do it with implicitly_convertible, but I don't know. You can always make it work with thin wrappers for your functions taking bigint as an argument. If there are too many of these functions (say > 10) this approach becomes annoying. In that case I'd do it with a custom converter. See my old message: http://mail.python.org/pipermail/c++-sig/2003-May/004133.html This code is almost 2 years old but I believe it is still compatible with the latest Boost. The code looks very low level, but if you simply follow the recipe it should be straightforward to adapt it to your bigint type. Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From seefeld at sympatico.ca Thu Feb 3 00:15:05 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed, 02 Feb 2005 18:15:05 -0500 Subject: [C++-sig] "TypeError: No to_python (by-value) converter found for C++ type: Node" Message-ID: <42015EF9.9070508@sympatico.ca> hi there, I'v stripped down code to reproduce an issue I reported earlier. Please find attached an extension module as well as a little driver script that do the following: Exposed are a 'Node' and a 'Visitor' type. The 'Visitor' is wrapped to be subclassed in python. In python, I call node.accept(visitor) and expect my node (in C++) to invoke 'VisitorWrapper::visit(this)', which by means of 'call_method' delegates the call to the python subclass. The error suggests that the bpl runtime isn't able to find a python type for 'this'. Creating a Node via 'create' from within python worked fine, though. Does anybody have an idea what is going on here ? Thanks, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.cc Type: text/x-c++src Size: 840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: application/x-python Size: 133 bytes Desc: not available URL: From jbrandmeyer at earthlink.net Thu Feb 3 05:27:30 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Wed, 02 Feb 2005 23:27:30 -0500 Subject: [C++-sig] problem with constructor/implicitly_convertible In-Reply-To: <20050202230413.91709.qmail@web20227.mail.yahoo.com> References: <20050202230413.91709.qmail@web20227.mail.yahoo.com> Message-ID: <1107404850.4618.8.camel@illuvatar> On Wed, 2005-02-02 at 15:04 -0800, Ralf W. Grosse-Kunstleve wrote: > In that case I'd do it with a custom converter. See > my old message: > > http://mail.python.org/pipermail/c++-sig/2003-May/004133.html > > This code is almost 2 years old but I believe it is still compatible with the > latest Boost. The code looks very low level, but if you simply follow the > recipe it should be straightforward to adapt it to your bigint type. > > Cheers, > Ralf Is the construct function allowed to bomb out and throw_error_already_set? In particular, if I want to perform a custom rvalue converter for a sequence of some type, I don't want to have to iterate across the entire sequence just to perform the convertible check. Is there any way to register an implicit conversion from a Python type to a subclass, that will be invoked for functions expecting a base class? example: struct Base {}; struct Derived : Base {}; void f( const Base& b); How can I register an implicit converter for Python int -> Derived that will be picked up when f() is called from Python? Thanks, -Jonathan From amp at singingwizard.org Thu Feb 3 16:36:46 2005 From: amp at singingwizard.org (Arthur Peters) Date: Thu, 03 Feb 2005 09:36:46 -0600 Subject: [C++-sig] Re: using shared_ptrs with the vector_indexing_suite In-Reply-To: <20050108110003.88E921E4008@bag.python.org> Message-ID: Hello all, There were a couple of messages on the subject of shared_ptrs used with vector_indexing_suite. Below is the most resent email on the subject. I am having the exact same problem and I have found a solution, and I thought I'd post it for the benafit of others who run into the same thing. Turn off proxies by passing true as the NoProxy template parameter. shared_ptrs don't need proxies because calls on one a copy of the the shared_ptr will affect all of them (duh!). If you have: class_ > >("vector_CPropertySet") .def(vector_indexing_suite > >()); Change it to: class_ > >("vector_CPropertySet") .def(vector_indexing_suite >, true >()); The quoted message has a more extensive description of the initail problem. Hope this helps someone -Arthur >Date: Fri, 7 Jan 2005 14:56:55 -0800 >From: Greg Landrum >Subject: [C++-sig] using shared_ptrs with the vector_indexing_suite >To: c++-sig at python.org >Message-ID: <60825b0f05010714564d71e769 at mail.gmail.com> >Content-Type: text/plain; charset="us-ascii" > >I'm attempting to get shared_ptrs working in combination with the >vector_indexing_suite in order to make it easy to return std::vectors >of shared_ptrs from our code. > >I feel like I've got a reasonable grasp of what's required to return >shared_ptrs (given how easy that is now, this isn't much of an >accomplishment), and I've even managed to get them working with the >iterator interface, but the combination with vector_indexing_suite >eludes me. > >The attached module and testing code demonstrate the problem. When I >build this module and run the test (linux, python 2.3.4, g++ 3.2, >boost 1.32), all the tests pass except for test5 and test5b, which use >std::vectors of shared_ptrs. Both of those tests fail with the error: > >TypeError: No Python class registered for C++ class boost::shared_ptr > >Because the basic shared_ptr operations and the more complicated >iterator stuff work, I'm guessing this has something to do with the >vector_indexing_suite itself. > >Thanks in advance for any help, >-greg >-------------- next part -------------- >// Copyright Rational Discovery LLC 2005. >// 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) > > >#include >#include >#include >#include > >#include > >namespace python = boost::python; > >class DemoKlass { >public: > explicit DemoKlass(int v) : val_(v) {}; > int getVal() const { return val_; }; >private: > int val_; >}; >typedef boost::shared_ptr DemoKlassSPtr; >typedef std::vector DemoKlassPtrVect; >typedef std::vector DemoKlassSPtrVect; > >DemoKlass *buildPtr(int v) { > return new DemoKlass(v); >} >DemoKlassSPtr buildSPtr(int v) { > return DemoKlassSPtr(new DemoKlass(v)); >} > >DemoKlassPtrVect buildPtrVector(unsigned int sz){ > DemoKlassPtrVect res; > for(unsigned int i=0;i res.push_back(new DemoKlass(i)); > } > return res; >} > >DemoKlassSPtrVect buildSPtrVector(unsigned int sz){ > DemoKlassSPtrVect res; > for(unsigned int i=0;i res.push_back(DemoKlassSPtr(new DemoKlass(i))); > } > return res; >} > > >class DemoContainer { >public: > typedef DemoKlassSPtrVect::iterator iterator; > typedef DemoKlassSPtrVect::const_iterator const_iterator; > explicit DemoContainer(unsigned int sz) { > vect_ = buildSPtrVector(sz); > } > iterator begin() { > return vect_.begin(); > } > iterator end() { > return vect_.end(); > } > const_iterator begin() const { > return vect_.begin(); > } > const_iterator end() const { > return vect_.end(); > } > >private: > DemoKlassSPtrVect vect_; >}; > > > >BOOST_PYTHON_MODULE(SPtrTestModule) >{ > python::class_("DemoKlass","demo class",python::init()) > .def("GetVal",&DemoKlass::getVal) > ; > > python::def("buildPtr",buildPtr,python::return_value_policy()); > python::def("buildSPtr",buildSPtr); > > > python::class_("DemoKlassPtrVec") > .def(python::vector_indexing_suite()) > ; > python::def("buildPtrVector",buildPtrVector); > > python::class_("DemoKlassSPtrVec") > .def(python::vector_indexing_suite()) > ; > python::def("buildSPtrVector",buildSPtrVector); > > > python::class_("DemoContainer","demo container",python::init()) > .def("__iter__",python::iterator()) > ; > > >} >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: test.py >Type: text/x-python >Size: 1321 bytes >Desc: not available >Url : http://mail.python.org/pipermail/c++-sig/attachments/20050107/4ffbdf8a/test-0001.py > >------------------------------ From caustin at gmail.com Thu Feb 3 16:56:39 2005 From: caustin at gmail.com (Chad Austin) Date: Thu, 3 Feb 2005 09:56:39 -0600 Subject: [C++-sig] Re: using shared_ptrs with the vector_indexing_suite In-Reply-To: References: <20050108110003.88E921E4008@bag.python.org> Message-ID: <2096514e0502030756613f7144@mail.gmail.com> Thanks Arthur! That helps a lot! Now can we convince someone to add a note to the vector_indexing_suite documentation...? :) On Thu, 03 Feb 2005 09:36:46 -0600, Arthur Peters wrote: > > Hello all, > There were a couple of messages on the subject of shared_ptrs used with > vector_indexing_suite. > > Below is the most resent email on the subject. I am having the exact same > problem and I have found a solution, and I thought I'd post it for the > benafit of others who run into the same thing. > > Turn off proxies by passing true as the NoProxy template parameter. > shared_ptrs don't need proxies because calls on one a copy of the the > shared_ptr will affect all of them (duh!). > > If you have: > class_ > > >("vector_CPropertySet") > .def(vector_indexing_suite > > >()); > Change it to: > class_ > > >("vector_CPropertySet") > .def(vector_indexing_suite > >, > true >()); > > The quoted message has a more extensive description of the initail > problem. > > Hope this helps someone > -Arthur > > >Date: Fri, 7 Jan 2005 14:56:55 -0800 > >From: Greg Landrum > >Subject: [C++-sig] using shared_ptrs with the vector_indexing_suite > >To: c++-sig at python.org > >Message-ID: <60825b0f05010714564d71e769 at mail.gmail.com> > >Content-Type: text/plain; charset="us-ascii" > > > >I'm attempting to get shared_ptrs working in combination with the > >vector_indexing_suite in order to make it easy to return std::vectors > >of shared_ptrs from our code. > > > >I feel like I've got a reasonable grasp of what's required to return > >shared_ptrs (given how easy that is now, this isn't much of an > >accomplishment), and I've even managed to get them working with the > >iterator interface, but the combination with vector_indexing_suite > >eludes me. > > > >The attached module and testing code demonstrate the problem. When I > >build this module and run the test (linux, python 2.3.4, g++ 3.2, > >boost 1.32), all the tests pass except for test5 and test5b, which use > >std::vectors of shared_ptrs. Both of those tests fail with the error: > > > >TypeError: No Python class registered for C++ class boost::shared_ptr > > > >Because the basic shared_ptr operations and the more complicated > >iterator stuff work, I'm guessing this has something to do with the > >vector_indexing_suite itself. > > > >Thanks in advance for any help, > >-greg > >-------------- next part -------------- > >// Copyright Rational Discovery LLC 2005. > >// 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) > > > > > >#include > >#include > >#include > >#include > > > >#include > > > >namespace python = boost::python; > > > >class DemoKlass { > >public: > > explicit DemoKlass(int v) : val_(v) {}; > > int getVal() const { return val_; }; > >private: > > int val_; > >}; > >typedef boost::shared_ptr DemoKlassSPtr; > >typedef std::vector DemoKlassPtrVect; > >typedef std::vector DemoKlassSPtrVect; > > > >DemoKlass *buildPtr(int v) { > > return new DemoKlass(v); > >} > >DemoKlassSPtr buildSPtr(int v) { > > return DemoKlassSPtr(new DemoKlass(v)); > >} > > > >DemoKlassPtrVect buildPtrVector(unsigned int sz){ > > DemoKlassPtrVect res; > > for(unsigned int i=0;i > res.push_back(new DemoKlass(i)); > > } > > return res; > >} > > > >DemoKlassSPtrVect buildSPtrVector(unsigned int sz){ > > DemoKlassSPtrVect res; > > for(unsigned int i=0;i > res.push_back(DemoKlassSPtr(new DemoKlass(i))); > > } > > return res; > >} > > > > > >class DemoContainer { > >public: > > typedef DemoKlassSPtrVect::iterator iterator; > > typedef DemoKlassSPtrVect::const_iterator const_iterator; > > explicit DemoContainer(unsigned int sz) { > > vect_ = buildSPtrVector(sz); > > } > > iterator begin() { > > return vect_.begin(); > > } > > iterator end() { > > return vect_.end(); > > } > > const_iterator begin() const { > > return vect_.begin(); > > } > > const_iterator end() const { > > return vect_.end(); > > } > > > >private: > > DemoKlassSPtrVect vect_; > >}; > > > > > > > >BOOST_PYTHON_MODULE(SPtrTestModule) > >{ > > python::class_("DemoKlass","demo class",python::init()) > > .def("GetVal",&DemoKlass::getVal) > > ; > > > > python::def("buildPtr",buildPtr,python::return_value_policy()); > > python::def("buildSPtr",buildSPtr); > > > > > > python::class_("DemoKlassPtrVec") > > .def(python::vector_indexing_suite()) > > ; > > python::def("buildPtrVector",buildPtrVector); > > > > python::class_("DemoKlassSPtrVec") > > .def(python::vector_indexing_suite()) > > ; > > python::def("buildSPtrVector",buildSPtrVector); > > > > > > python::class_("DemoContainer","demo container",python::init()) > > .def("__iter__",python::iterator()) > > ; > > > > > >} > >-------------- next part -------------- > >A non-text attachment was scrubbed... > >Name: test.py > >Type: text/x-python > >Size: 1321 bytes > >Desc: not available > >Url : http://mail.python.org/pipermail/c++-sig/attachments/20050107/4ffbdf8a/test-0001.py > > > >------------------------------ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From neuroo at kouette.com Thu Feb 3 21:36:07 2005 From: neuroo at kouette.com (neuroo at kouette.com) Date: Thu, 3 Feb 2005 21:36:07 +0100 (CET) Subject: [C++-sig] Python ImportError : undefined symbol Message-ID: <33046.83.177.204.190.1107462967.squirrel@webmail.kouette.com> Hi I got a problem with boost 1.32 & gcc 3.3.4 on a debian while trying to build a dynamic library. I am building the library with a Makefile like this one (but with more sources): LINKING=-L/usr/local/lib -lpython2.2 -lboost_python -DBOOST_PYTHON_STATIC_MODULE /usr/local/lib/libboost_python-gcc.a USR_PATH=-I/usr/local/include/boost-1_32 -I/usr/include/python2.2 sample.o: sample.cpp g++ -c -Wall -O3 -fPIC sample.cpp $(USR_PATH) sample.so: sample.o g++ -shared -fPIC sample.o -o sample.so $(LINKING) The compiler does his work & when i try to import sample.so on python (2.3) i have an: ImportError: ./PL.so: undefined symbol: _ZN15LagrangianParamC1ER5ModelSs For more informations, if it's not a false compilation way, LagrangianParam::Model is a private pointer to a class (Model) defined in an other source... Regards, Romain Gaucher Ingeneer student in Calculus & Computer ISIMA (FRANCE) / Clermont-Ferrand From jbrandmeyer at earthlink.net Thu Feb 3 22:07:16 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 03 Feb 2005 16:07:16 -0500 Subject: [C++-sig] Python ImportError : undefined symbol In-Reply-To: <33046.83.177.204.190.1107462967.squirrel@webmail.kouette.com> References: <33046.83.177.204.190.1107462967.squirrel@webmail.kouette.com> Message-ID: <1107464836.3954.6.camel@localhost> On Thu, 2005-02-03 at 21:36 +0100, neuroo at kouette.com wrote: > Hi > I got a problem with boost 1.32 & gcc 3.3.4 on a debian while trying to build a dynamic library. > I am building the library with a Makefile like this one (but with more sources): > > LINKING=-L/usr/local/lib -lpython2.2 -lboost_python -DBOOST_PYTHON_STATIC_MODULE > /usr/local/lib/libboost_python-gcc.a > USR_PATH=-I/usr/local/include/boost-1_32 -I/usr/include/python2.2 > > sample.o: sample.cpp > g++ -c -Wall -O3 -fPIC sample.cpp $(USR_PATH) > > sample.so: sample.o > g++ -shared -fPIC sample.o -o sample.so $(LINKING) > > The compiler does his work & when i try to import sample.so on python (2.3) i have an: > ImportError: ./PL.so: undefined symbol: _ZN15LagrangianParamC1ER5ModelSs > For more informations, if it's not a false compilation way, LagrangianParam::Model is a private > pointer to a class (Model) defined in an other source... This problem isn't Boost.Python specific. Your plugin is not linked to the library that includes the definition of that missing symbol. Add -lmy_library_containing_the_missing_symbol to your linker flags. (Note also that c++filt decodes that undefined symbol to a different function than what you indicated.) To catch these errors at link time rather than runtime, add -lpython2.2 -Wl,-no-undefined (and possibly -Wl,--warn-once) to your linker options. HTH, -Jonathan From neuroo at kouette.com Thu Feb 3 22:10:21 2005 From: neuroo at kouette.com (neuroo at kouette.com) Date: Thu, 3 Feb 2005 22:10:21 +0100 (CET) Subject: [C++-sig] Python ImportError : undefined symbol Message-ID: <33091.83.177.204.190.1107465021.squirrel@webmail.kouette.com> > This problem isn't Boost.Python specific. Your plugin is not linked to > the library that includes the definition of that missing symbol. Add > -lmy_library_containing_the_missing_symbol to your linker flags. (Note > also that c++filt decodes that undefined symbol to a different function > than what you indicated.) But this missing symbol is define in my dynamic library (in fact, the library doesn't need other library than pythons and boosts) Romain Gaucher Ingeneer student in Calculus & Computer ISIMA (FRANCE) / Clermont-Ferrand From greg.landrum at gmail.com Fri Feb 4 01:08:56 2005 From: greg.landrum at gmail.com (Greg Landrum) Date: Thu, 3 Feb 2005 16:08:56 -0800 Subject: [C++-sig] Re: using shared_ptrs with the vector_indexing_suite In-Reply-To: References: <20050108110003.88E921E4008@bag.python.org> Message-ID: <60825b0f050203160861f39330@mail.gmail.com> Wow, thanks Arthur! This cleared up the problems in both my sample code and our real application. Dave: is the sample code that I sent to demonstrate the problem useful enough pedagogically that I should send along a version that actually works? -greg From ercan_sahan at yahoo.com Fri Feb 4 10:57:30 2005 From: ercan_sahan at yahoo.com (Ercan SAHAN) Date: Fri, 4 Feb 2005 01:57:30 -0800 (PST) Subject: [C++-sig] How to access live C++ objects from Python Message-ID: <20050204095730.38263.qmail@web50309.mail.yahoo.com> Hi all, I am not sure if this is the right group to ask this 'zero beginner' question but what I wonder is how I can make my python scripts to be able to access the live objects of my C++ application at run-time. I've used SWIG to wrap my C++ functions and variables, nevertheless I couldn't manage what I wanted. Regards, Ercan Sahan, METU --------------------------------- Do you Yahoo!? Yahoo! Search presents - Jib Jab's 'Second Term' -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwgk at yahoo.com Fri Feb 4 19:09:41 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 4 Feb 2005 10:09:41 -0800 (PST) Subject: [C++-sig] problem with constructor/implicitly_convertible In-Reply-To: <1107404850.4618.8.camel@illuvatar> Message-ID: <20050204180941.56086.qmail@web20222.mail.yahoo.com> --- Jonathan Brandmeyer wrote: > Is the construct function allowed to bomb out and > throw_error_already_set? In particular, if I want to perform a custom > rvalue converter for a sequence of some type, I don't want to have to > iterate across the entire sequence just to perform the convertible > check. Hi Jonathan, are you aware of this file? http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?view=markup The from_python_sequence::construct function uses throw_error_already_set just as you have it in mind. > Is there any way to register an implicit conversion from a Python type > to a subclass, that will be invoked for functions expecting a base > class? example: > > struct Base {}; > struct Derived : Base {}; > > void f( const Base& b); > > How can I register an implicit converter for Python int -> Derived that > will be picked up when f() is called from Python? I am not sure I know the answer to this one. I'd probably start experimenting by registering custom converters for both int -> Base and int -> Derived. Cheers, Ralf __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From jbrandmeyer at earthlink.net Fri Feb 4 21:17:50 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Fri, 04 Feb 2005 15:17:50 -0500 Subject: [C++-sig] problem with constructor/implicitly_convertible In-Reply-To: <20050204180941.56086.qmail@web20222.mail.yahoo.com> References: <20050204180941.56086.qmail@web20222.mail.yahoo.com> Message-ID: <1107548270.12090.11.camel@localhost> On Fri, 2005-02-04 at 10:09 -0800, Ralf W. Grosse-Kunstleve wrote: > > Is there any way to register an implicit conversion from a Python type > > to a subclass, that will be invoked for functions expecting a base > > class? example: > > > > struct Base {}; > > struct Derived : Base {}; > > > > void f( const Base& b); > > > > How can I register an implicit converter for Python int -> Derived that > > will be picked up when f() is called from Python? > > I am not sure I know the answer to this one. I'd probably start experimenting > by registering custom converters for both int -> Base and int -> Derived. > > Cheers, > Ralf The attached file is the only way that I can think of to register an int->Base conversion (in this case, I used a double, but that shouldn't matter since its just for demonstration). I'm concerned that storage.bytes is only guaranteed to have enough room for one Base object, and that the placement new operation may be placing a new object of Derived into an inadequate chunk of storage. This example doesn't crash, and Valgrind doesn't report any errors, but I just don't see how a converter registered for Base can possibly know how much storage to allocate for Derived. -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: rvalue_converters.cpp Type: text/x-c++src Size: 1304 bytes Desc: not available URL: From rwgk at yahoo.com Fri Feb 4 23:52:32 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 4 Feb 2005 14:52:32 -0800 (PST) Subject: [C++-sig] problem with constructor/implicitly_convertible In-Reply-To: <1107548270.12090.11.camel@localhost> Message-ID: <20050204225232.10401.qmail@web20222.mail.yahoo.com> --- Jonathan Brandmeyer wrote: > I'm concerned that storage.bytes is only guaranteed to have enough room > for one Base object, and that the placement new operation may be placing > a new object of Derived into an inadequate chunk of storage. This > example doesn't crash, and Valgrind doesn't report any errors, but I > just don't see how a converter registered for Base can possibly know how > much storage to allocate for Derived. I guess as long as XXXXXX (boost::python::converter::rvalue_from_python_storage*) data)->storage.bytes; new (storage) XXXXXX(...); data->convertible = storage; matches the memory handling should be fine. In your example you don't use inheritance even though that seems to be your original question. Did you think about making the example more like what you want in the end? I think you should be able to do what you want, but I don't know if you need to register one or two converters. To get the answer I'd simply try it out. Ralf P.S.: Every time I cook up a new converter I run it through valgrind (since is is one of the few places where Boost.Python doesn't give you any protection). __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From s_sourceforge at nedprod.com Sat Feb 5 00:24:47 2005 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 04 Feb 2005 23:24:47 -0000 Subject: [C++-sig] Pyste bug: implicit constructors Message-ID: <4204043F.4841.6A19A9B@localhost> Referring to v1.32. If you have a struct like this: struct FXProcess { struct Foo { int foo; }; }; ... and you feed it to pyste, pyste gives: class_< FXProcess::Foo, boost::noncopyable >("Foo", no_init) And that's not correct obviously. Looking at the GCC-XML output: Now the problem becomes in pyste, GCCXMLParser.py: artificial = element.get('artificial', False) if not artificial: ctor = Constructor(name, classname, params, visib) else: # we don't want artificial constructors ctor = Unknown('__Unknown_Element_%s' % id) Since the artificial flag is 1, Constructor() never gets called and thus pyste generating the boost::noncopyable. I suggest: artificial = element.get('artificial', False) ctor = Constructor(name, classname, params, visib) if artificial and not ctor.IsCopy(): # we don't want artificial constructors except copy ones ctor = Unknown('__Unknown_Element_%s' % id) ... but this may not be the right thing either. Cheers, Niall From amp at singingwizard.org Sat Feb 5 00:51:14 2005 From: amp at singingwizard.org (Arthur Peters) Date: Fri, 04 Feb 2005 18:51:14 -0500 Subject: [C++-sig] bad interactions between weak_ptrs and boost.python Message-ID: Hello all, Thanks for boost.python in all its greatness. I am having 2 problems caused by boost.python's way of handling holders that are shared_ptrs. Sorry for how verbose this is. I could not figure out how to make it more concise. They are both related to the way boost.python converts a python object to a shared_ptr. It creates a completely new temporary shared_ptr that is managing a reference to the PyObject, instead of copying the holder (which is a shared_ptr) so that the shared_ptr is managing the actual C++ object. The following walks through the problems as they are demonstrated by the attached cpp file. If you look over the cpp file first it will be easier to understand. In fact, it may be easier to read the cpp file and not read this stuff at all. The first problem is as follows: >>> v = Derived() Here a Derived object is created and put in a shared_ptr. >>> SavesWeakPtrDerived( v ) Here boost.python simply passes the holder as the argument to function because they are both of type shared_ptr. That means that the weak_ptr that is created does not expire ... >>> UsesSavedWeakPtr() # works ... and the function that uses it works. >>> SavesWeakPtr( v ) Here, however, boost.python creates a temporary shared_ptr that only manages a reference to the python object. That means that the weak_ptr that is created will expire as soon as the function exits and the temporary shared_ptr goes out of scope. Because of this ... >>> UsesSavedWeakPtr() # fails even though v still exists. This chrashes the program ... UsesSavedWeakPtr now fails. The second problem is basically caused by the first and looks like this: >>> v = Derived() Here a Derived object is create and put in a shared_ptr holder. Since Base is dervied from enable_shared_from_this, the shared_ptr constructor updates _internal_weak_this to be connected to it. >>> v.MemberUsingSharedFromThis() # works MemberUsingSharedFromThis works fine, since shared_from_this() will return a shared_ptr connected to the holder of the python object (which is a shared_ptr). >>> SavesWeakPtr( v ) Now a shared_ptr needs to be created, so boost.python creates a temporary shared_ptr as I described above. The problem is that again the shared_ptr constructor updates _internal_weak_this to be connected to it, but in this case the shared_ptr only lasts until the function call finishes, causing _internal_weak_this to expire early. >>> v.MemberUsingSharedFromThis() # fails with "RuntimeError: boost::bad_weak_ptr" Now when we call MemberUsingSharedFromThis it throws because _internal_weak_this has expired even though original shared_ptr in the python object still exists. The best way I can see to fix this is to make the from-python conversion of objects with a shared_ptr as a holder go directly from the holder (a shared_ptr) to the argument (a shared_ptr) instead of converting the shared_ptr to a dumb pointer in between (as it does now). This way the shared_ptr that appears in C++ land is a actually associated (shares a reference count) with the holder. In the case of classes derived from enable_shared_from_this, the conversion to a dumb pointer isn't even a problem. All boost.python would need to do would be to get the shared_ptr using shared_from_this. But this is not a general solution. If someone has a speific idea for a solution I would be willing to give coding it a try. However, I don't know the boost.python code so that might not work well. Thanks very much for your time. -Arthur PS: Yes I did post about this a couple of months ago, but I did not get back into working on it until now, so now there are complete examples and such. -------------- next part -------------- A non-text attachment was scrubbed... Name: weak_ptr_problem_example.cpp Type: application/octet-stream Size: 2237 bytes Desc: not available URL: From actiondan at gmail.com Sat Feb 5 22:09:55 2005 From: actiondan at gmail.com (Daniel Lewis) Date: Sat, 5 Feb 2005 21:09:55 +0000 Subject: [C++-sig] Callbacks with internal references as arguments Message-ID: Hello, I'm trying to write a module using boost::python that can deliver callbacks, but I'm having trouble with declaring my intentions with regards to object ownership. A simple example of what I am trying to achieve is this: struct Foo { }; struct Bar { Foo& get_foo() { return foo; } void foo_callback() { callback(foo); } Foo foo; object callback; }; BOOST_PYTHON_MODULE (foobar) { class_("Foo", init<>()); class_("Bar", init<>()) .def("get_foo", &Bar::get_foo, return_internal_reference<>()) .def("foo_callback", &Bar::foo_callback) .def_readwrite("callback", &Bar::callback); } So when calling Bar::get_foo() from Python, I get the desired behaviour: the same Python object is returned every time, and Bar::foo is not destroyed when the Python object is. When using Bar::foo_callback(), like this: def callback(foo): print foo bar.callback = callback bar.foo_callback() I get a different object, and ~Foo() is called when the Python object is destroyed. Is there any way to achieve the "internal reference" behaviour when delivering the object as a callback argument? Thanks, Dan. From mike at thewilsonfamily.freeserve.co.uk Sun Feb 6 18:49:22 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Sun, 6 Feb 2005 17:49:22 -0000 Subject: [C++-sig] Boost.Python appears to be catching Fortran READ "exceptions". References: <20050205110003.854E31E40C0@bag.python.org> Message-ID: <000e01c50c74$63d350e0$d4694e51@MIKESPC01> Hi, I am a new Boost.Python user. Summary --------- I have created a Boost.Python module (named 'hello') that calls a FORTRAN subroutine (named FortDll) via a C++ function (named call_fortran ). The FORTRAN code, which reads a data file, has the line: READ(....,END=999) ! goto line labled 999 when eof reached to handle the end of file condition. In non-Python environment it works as expected, but under Python the eof condition is being caught by Boost.Python as a "RuntimeError: unidentifiable C++ exception". If I create my module without Boost.Python then I just get a crash. Details ------- I have the following Boost.Python module: ----Start of C++ code ---- // Using MS.NET 7.1.3088, Python 2.4, boost 1.31 // creates hello.dll #include extern "C" void __stdcall FortDll(); void call_fortran() { FortDll(); } using namespace boost::python; BOOST_PYTHON_MODULE(hello) { def("call_fortran", call_fortran); } ----End of C++ code ---- The code for FortDll is as follows: ----Start of FORTRAN (F90) code ---- ! !Built using Intel(R) Fortran Compiler for MS.NET 2003, Version 8.0.1877.2003 ! SUBROUTINE FortDll ! Export subroutine into Dll !DEC$ATTRIBUTES DLLEXPORT, DEFAULT, STDCALL, DECORATE, ALIAS:'FortDll' ::FortDll INTEGER*4 I OPEN(UNIT=33, FILE='INTS.DAT', ACCESS='SEQUENTIAL', STATUS='OLD') DO WHILE(.TRUE.) 777 READ(33,*,END=999) I ! When the eof is reached the above line causes ! an exception in Python,so that ..... PRINT *,I ENDDO 999 CONTINUE ! <<<<<< ...this line isn't reached!!! PRINT *,'999 reached' CLOSE(33) END SUBROUTINE ----End of FORTRAN (F90) code ---- The test data file ints.dat is ----Start of ints.dat---- 1 2 3 4 ---EOF---- The results from testing are as follows: ----Start of Python session in debugger---- Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import hello >>> hello.call_fortran() 1 2 3 4 Traceback (most recent call last): File "", line 1, in ? RuntimeError: unidentifiable C++ exception >>> ----End of Python session---- The problem appears at line labled 777 in the Fortran code. As shown above in the Python test case, when the FORTRAN hits a read error it appears that the normal execution of code, as specified by READ(..., END= 999) I ! goto line 999 when eof is reached is not getting a chance to be executed. When I catch the exception in the debugger, I get First-chance exception at 0x00b58ca9 (FortDll.dll) in python.exe: 0xC0000005: Access violation reading location 0x00000000 My initial thought that this was to do with Boost.Python, however I get a crash/core dump using a Python module built around: static PyObject * call_fortran(PyObject *self, PyObject *args) { FortDll(); // causes Python to crash when eof is reached. return Py_BuildValue("i", 0); } Note that in a 'non-Python' environment, similar to this: int main(int ,char** ) { FortDll( ); } the output is : 1 2 3 4 999 reached ie. FortDll() works as expected. My app I want to prototype in Python has several C++ classes that rely on some routines written in FORTRAN. Can I stop Python handling the errors that would have been handled in any case by the FORTRAN run time system? Regards Mike From rwgk at yahoo.com Sun Feb 6 21:40:18 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Sun, 6 Feb 2005 12:40:18 -0800 (PST) Subject: [C++-sig] Boost.Python appears to be catching Fortran READ "exceptions". In-Reply-To: <000e01c50c74$63d350e0$d4694e51@MIKESPC01> Message-ID: <20050206204018.58393.qmail@web20226.mail.yahoo.com> --- Mike wrote: > My app I want to prototype in Python has several C++ classes that rely on > some routines written in FORTRAN. Can I stop Python handling the errors > that would have been handled in any case by the FORTRAN run time system? It is not Python or Boost.Python doing anything special, it depends on your Fortran compiler how I/O errors are dealt with. It must be the Fortran runtime-library throwing the exception. I'd look at the Fortran documentation to find out about the interrelation of Fortran I/O errors and C++ exceptions. Ralf P.S.: I always found it easier to translate Fortran code to C++ rather than dealing with inter-language complications. __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From mike at thewilsonfamily.freeserve.co.uk Tue Feb 8 01:07:08 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Tue, 8 Feb 2005 00:07:08 -0000 Subject: [C++-sig] Re: Boost.Python appears to be catching Fortran READ "exceptions". References: <20050207110003.678F71E4009@bag.python.org> Message-ID: <000b01c50d72$3384ef30$c3d04e51@MIKESPC01> Thanks for your quick reply Ralf. Thinking along your suggested line of exceptions, and given that I know that this _does_ work as expected... #include extern "C" void __stdcall FortDll(); int main(int ,char** ) { FortDll( ); // performs a Fortran READ(33,*,END=999) I std::cout << "FortDll worked with no exceptions.\n"; // this line gets executed! } ...I then had the idea of trying this: #include #include extern "C" void __stdcall FortDll(); int main(int, char**) { // Call Fortran function FortDll FortDll(); // Line #A - ensures Fortran RTL is loaded first. Py_Initialize(); // Now call FortDll again PyRun_SimpleString("import hello\n" "hello.call_fortran()\n"); // this calls FortDll() Py_Finalize(); } The output is: 1 2 3 4 999 reached 1 2 3 4 999 reached No exceptions! If I remove Line #A then I get my 1\n2\n3\n4 follwed by the "RuntimeError: unidentifiable C++ exception" message (no "999 reached"). The aboves points to one possible solution (ensure the Fortran RTL is loaded before Python which is called via my "main" program), but it would be nice to be able to do a similar sort of thing starting from the Python prompt. I'll have a further look at the FORTRAN docs & see if that provides any clues. Thanks again, Mike > > > From: "Ralf W. Grosse-Kunstleve" > Subject: Re: [C++-sig] Boost.Python appears to be catching Fortran > READ "exceptions". > To: Development of Python/C++ integration > Message-ID: <20050206204018.58393.qmail at web20226.mail.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > --- Mike wrote: >> My app I want to prototype in Python has several C++ classes that >> rely on some routines written in FORTRAN. Can I stop Python >> handling the errors that would have been handled in any case by the >> FORTRAN run time system? > > It is not Python or Boost.Python doing anything special, it depends > on your Fortran compiler how I/O errors are dealt with. It must be > the Fortran runtime-library throwing the exception. I'd look at the > Fortran documentation to find out about the interrelation of Fortran > I/O errors and C++ exceptions. Ralf > P.S.: I always found it easier to translate Fortran code to C++ > rather than dealing with inter-language complications. > P.S. I did translate the routine based on the given code, but it may not be possible in other cases. From nick at ilm.com Tue Feb 8 04:00:17 2005 From: nick at ilm.com (Nick Rasmussen) Date: Mon, 7 Feb 2005 19:00:17 -0800 Subject: [C++-sig] functions not showing up in pydoc Message-ID: <20050208030017.GJ3873@ewok.lucasdigital.com> I'm running into a problem with functions at the module level not showing up in pydoc. The problem is that the type of the function object in the module is: >>> type(testfoo.foo) Which isn't a sublcass of When pydoc walks the module it only documents routines that are either builtin (according to inspect.isbuiltin) or are objects whose module can be deduced via inspect.getmodule. I modified function.cpp with: --- libs/python/src/object/function.cpp.orig 2005-02-07 17:11:52.000066304 -0800 +++ libs/python/src/object/function.cpp 2005-02-07 16:55:24.000120507 -0800 @@ -608,7 +608,7 @@ 0, /* tp_methods */ 0, // func_memberlist, /* tp_members */ function_getsetlist, /* tp_getset */ - 0, /* tp_base */ + &PyCFunction_Type, /* tp_base */ 0, /* tp_dict */ function_descr_get, /* tp_descr_get */ 0, /* tp_descr_set */ and it seemed to fix it. Is this right, or is there a different way that functions should get exposed such that pydoc can understand them? Also, for functions with overloads, only one of the docstrings is printed out. It looks like void function::add_to_namespace( object const& name_space, char const* name_, object const& attribute, char const* doc) just replaces the old doc string instead of appending the new one to the old. -nick From gaiacrtn at free.fr Thu Feb 10 20:17:21 2005 From: gaiacrtn at free.fr (Baptiste Lepilleur) Date: Thu, 10 Feb 2005 20:17:21 +0100 Subject: [C++-sig] Pyste: patch to export all enums automatically Message-ID: <01e301c50fa5$252cf150$0200a8c0@lain> The attached patch adds the command-line option --export-enum-values to automatically call export_values() on all enum declarations. If the command-line option is not specified, the behavior remain unchanged and you still need to specify call export_values(...) on each enum if you want to export it. Baptiste. -------------- next part -------------- A non-text attachment was scrubbed... Name: pyste-export-enum-values.patch Type: application/octet-stream Size: 2951 bytes Desc: not available URL: From nicodemus at esss.com.br Thu Feb 10 22:13:35 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Thu, 10 Feb 2005 19:13:35 -0200 Subject: [C++-sig] Pyste: patch to export all enums automatically In-Reply-To: <01e301c50fa5$252cf150$0200a8c0@lain> References: <01e301c50fa5$252cf150$0200a8c0@lain> Message-ID: <420BCE7F.8020300@esss.com.br> Hi Baptiste, Baptiste Lepilleur wrote: > The attached patch adds the command-line option --export-enum-values to >automatically call export_values() on all enum declarations. > > If the command-line option is not specified, the behavior remain >unchanged and you still need to specify call export_values(...) on each enum >if you want to export it. > > Thanks for the patch! I'm just not so sure if that's the best way to implement a feature like that (perhaps Pyste's command line is too cluttered already?). Opinions, anyone? Regards, Nicodemus. From nicodemus at esss.com.br Thu Feb 10 22:14:13 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Thu, 10 Feb 2005 19:14:13 -0200 Subject: [C++-sig] Pyste bug: implicit constructors In-Reply-To: <4204043F.4841.6A19A9B@localhost> References: <4204043F.4841.6A19A9B@localhost> Message-ID: <420BCEA5.1040205@esss.com.br> Niall Douglas wrote: >Referring to v1.32. If you have a struct like this: > >struct FXProcess >{ > struct Foo > { > int foo; > }; >}; > >... and you feed it to pyste, pyste gives: > >class_< FXProcess::Foo, boost::noncopyable >("Foo", no_init) > >And that's not correct obviously. Looking at the GCC-XML output: > >mangled="_ZN2FX9FXProcess14FooC1ERKS1_ *INTERNAL*" location="f0:154" >file="f0" line="154"> > > > >Now the problem becomes in pyste, GCCXMLParser.py: > > artificial = element.get('artificial', False) > if not artificial: > ctor = Constructor(name, classname, params, visib) > else: > # we don't want artificial constructors > ctor = Unknown('__Unknown_Element_%s' % id) > >Since the artificial flag is 1, Constructor() never gets called and >thus pyste generating the boost::noncopyable. > >I suggest: > > artificial = element.get('artificial', False) > ctor = Constructor(name, classname, params, visib) > if artificial and not ctor.IsCopy(): > # we don't want artificial constructors except copy ones > ctor = Unknown('__Unknown_Element_%s' % id) > >... but this may not be the right thing either. > > Hi Niall, Sorry for taking so long to respond! I'll take a look at this issue in the weekend. Thanks, Nicodemus. From rwgk at yahoo.com Fri Feb 11 03:01:21 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 10 Feb 2005 18:01:21 -0800 (PST) Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050208030017.GJ3873@ewok.lucasdigital.com> Message-ID: <20050211020121.98997.qmail@web20223.mail.yahoo.com> --- Nick Rasmussen wrote: > I'm running into a problem with functions at the module level not > showing up in pydoc. The problem is that the type of the function > object in the module is: > > >>> type(testfoo.foo) > > > Which isn't a sublcass of > > When pydoc walks the module it only documents routines that are > either builtin (according to inspect.isbuiltin) or are objects > whose module can be deduced via inspect.getmodule. > > I modified function.cpp with: > > --- libs/python/src/object/function.cpp.orig 2005-02-07 17:11:52.000066304 > -0800 > +++ libs/python/src/object/function.cpp 2005-02-07 16:55:24.000120507 -0800 > @@ -608,7 +608,7 @@ > 0, /* tp_methods */ > 0, // func_memberlist, /* tp_members */ > function_getsetlist, /* tp_getset */ > - 0, /* tp_base */ > + &PyCFunction_Type, /* tp_base */ > 0, /* tp_dict */ > function_descr_get, /* tp_descr_get */ > 0, /* tp_descr_set */ > > and it seemed to fix it. Is this right, or is there a different > way that functions should get exposed such that pydoc can understand > them? I applied this patch locally and tested it in 14 different configurations. It appears to work OK with Python 2.2, but leads to platform-specific fatal errors with Python 2.3 and 2.4 (Abort, Bus error, C assertions in Python, or plain wrong results). Here is the full damage: http://cci.lbl.gov/cctbx_build/show_error_summary.cgi?build_tag=2005_02_10_1102 (This page will go away after a few days.) Using the exact same sources, but without the patch above, eliminates all errors. Before I knew about the Python 2.3 and 2.4 failures I asked David Abrahams regarding the patch. For the records: > > With regards to this posting: > > > > http://mail.python.org/pipermail/c++-sig/2005-February/008541.html > > > > I've applied the patch locally. All the tests run fine. > > Can you think of any negative side-effects of applying the patch? > > Well, I think it's probably benign. > > It might mean that BPL function objects get bigger. Also, if > something out there checks to see whether it's handling a PyCFunction > and then manipulates the guts of the object on that basis, it might > get unexpected results. I can't think of any other problems, but it's > possible they're lurking. If I wanted to really know I'd have to go > review what happens when you subclass a built-in type that way... and > it's probably not documented, so that would mean reading the Python > source. We need a volunteer to do this research and to figure out what is wrong when using Python 2.3 and 2.4. > Also, for functions with overloads, only one of the docstrings > is printed out. It looks like > > void function::add_to_namespace( > object const& name_space, char const* name_, object const& attribute, > char const* doc) > > just replaces the old doc string instead of appending the new one > to the old. Another case for a volunteer... Sorry that I cannot be more helpful. Cheers, Ralf __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From nick at ilm.com Fri Feb 11 03:39:37 2005 From: nick at ilm.com (Nick Rasmussen) Date: Thu, 10 Feb 2005 18:39:37 -0800 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050211020121.98997.qmail@web20223.mail.yahoo.com> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> Message-ID: <20050211023937.GP14902@ewok.lucasdigital.com> On Thu, 10 Feb 2005, Ralf W. Grosse-Kunstleve wrote: > --- Nick Rasmussen wrote: > > > I'm running into a problem with functions at the module level not > > showing up in pydoc. The problem is that the type of the function > > object in the module is: > > > > >>> type(testfoo.foo) > > > > > > Which isn't a sublcass of > > > > When pydoc walks the module it only documents routines that are > > either builtin (according to inspect.isbuiltin) or are objects > > whose module can be deduced via inspect.getmodule. > > > > I modified function.cpp with: > > > > --- libs/python/src/object/function.cpp.orig 2005-02-07 17:11:52.000066304 > > -0800 > > +++ libs/python/src/object/function.cpp 2005-02-07 16:55:24.000120507 -0800 > > @@ -608,7 +608,7 @@ > > 0, /* tp_methods */ > > 0, // func_memberlist, /* tp_members */ > > function_getsetlist, /* tp_getset */ > > - 0, /* tp_base */ > > + &PyCFunction_Type, /* tp_base */ > > 0, /* tp_dict */ > > function_descr_get, /* tp_descr_get */ > > 0, /* tp_descr_set */ > > > > and it seemed to fix it. Is this right, or is there a different > > way that functions should get exposed such that pydoc can understand > > them? > > I applied this patch locally and tested it in 14 different configurations. It > appears to work OK with Python 2.2, but leads to platform-specific fatal errors > with Python 2.3 and 2.4 (Abort, Bus error, C assertions in Python, or plain > wrong results). Here is the full damage: > > http://cci.lbl.gov/cctbx_build/show_error_summary.cgi?build_tag=2005_02_10_1102 > > (This page will go away after a few days.) > > Using the exact same sources, but without the patch above, eliminates all > errors. Thanks for testing it out. It's been working fine for me here (suse9.1 amd64 with python2.3), but I'll see if I can figure out what the right fix is. I took a quick look at PyCFunction_Type, and it's tp_flags are set to: Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,/* tp_flags */ Two things make me suspicious: absent is Py_TPFLAGS_BASETYPE, and I'm not sure if subclasses of gc-aware classes need to support garbage collection as well. I'll run it by our local python expert and see what he has to say. -nick From jbrandmeyer at earthlink.net Fri Feb 11 05:13:03 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 10 Feb 2005 23:13:03 -0500 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050211020121.98997.qmail@web20223.mail.yahoo.com> References: <20050211020121.98997.qmail@web20223.mail.yahoo.com> Message-ID: <1108095184.30150.12.camel@illuvatar> On Thu, 2005-02-10 at 18:01 -0800, Ralf W. Grosse-Kunstleve wrote: > > Also, for functions with overloads, only one of the docstrings > > is printed out. It looks like > > > > void function::add_to_namespace( > > object const& name_space, char const* name_, object const& attribute, > > char const* doc) > > > > just replaces the old doc string instead of appending the new one > > to the old. > > Another case for a volunteer... > > Sorry that I cannot be more helpful. I have a patch that implements this feature, with the effect that sequential docstrings will have a single blank line separating them. Here is the documentation change that describes its behavior: (from doc/v2/class.html, Effects of the "docstring" argument to class::def) Value will be bound to the __doc__ attribute of the resulting method overload. If an earlier overload supplied a docstring, two newline characters and the new docstring are appended to it. I have attached the patch for comment. If there are no objections I can commit it tomorrow afternoon. -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: docstring.patch Type: text/x-patch Size: 2577 bytes Desc: not available URL: From nick at ilm.com Fri Feb 11 20:26:02 2005 From: nick at ilm.com (Nick Rasmussen) Date: Fri, 11 Feb 2005 11:26:02 -0800 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <1108095184.30150.12.camel@illuvatar> References: <20050211020121.98997.qmail@web20223.mail.yahoo.com> <1108095184.30150.12.camel@illuvatar> Message-ID: <20050211192602.GR14902@ewok.lucasdigital.com> On Thu, 10 Feb 2005, Jonathan Brandmeyer wrote: > On Thu, 2005-02-10 at 18:01 -0800, Ralf W. Grosse-Kunstleve wrote: > > > > Also, for functions with overloads, only one of the docstrings > > > is printed out. It looks like > > > > > > void function::add_to_namespace( > > > object const& name_space, char const* name_, object const& attribute, > > > char const* doc) > > > > > > just replaces the old doc string instead of appending the new one > > > to the old. > > > > Another case for a volunteer... > > > > Sorry that I cannot be more helpful. > > I have a patch that implements this feature, with the effect that > sequential docstrings will have a single blank line separating them. > Here is the documentation change that describes its behavior: > > (from doc/v2/class.html, Effects of the "docstring" argument to > class::def) > Value will be bound to the __doc__ attribute of the resulting method > overload. If an earlier overload supplied a docstring, two newline > characters and the new docstring are appended to it. > > I have attached the patch for comment. If there are no objections I can > commit it tomorrow afternoon. Exactly what I was looking for. Thanks. -nick From prez at neuromancy.net Sat Feb 12 00:12:56 2005 From: prez at neuromancy.net (Preston A. Elder) Date: Fri, 11 Feb 2005 18:12:56 -0500 Subject: [C++-sig] Re: Wrapping C++ class with unnamed union References: Message-ID: On Wed, 15 Dec 2004 20:14:10 -0500, David Abrahams wrote: >> union { >> struct { >> Real r,g,b,a; >> }; >> Real val[4]; >> }; > Real get_r(Ogre::ColourValue& c) {return c.r;} > void set_r(Ogre::ColourValue& c, Real x) { c.r = x;} > > class_(....) > .add_property("r", get_r, set_r) I know this is an old topic, but how would you do this when some of the union arguments are arrays, like, for example, the in6_addr structure: struct in6_addr { union { uint8_t u6_addr8[16]; uint16_t u6_addr16[8]; uint32_t u6_addr32[4]; } in6_u; #define s6_addr in6_u.u6_addr8 #define s6_addr16 in6_u.u6_addr16 #define s6_addr32 in6_u.u6_addr32 }; Thanks, -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net) From prez at neuromancy.net Sat Feb 12 00:27:41 2005 From: prez at neuromancy.net (Preston A. Elder) Date: Fri, 11 Feb 2005 18:27:41 -0500 Subject: [C++-sig] boost::* standard python conversions Message-ID: I wonder, is there any concentrated task to convert parts of boost that make sense to have appropriate python wrappers? So far, I've converted boost::format, boost::date_time and boost:logic::tribool, however I have not seen a standard place where people who have had to do such conversions could submit them, or where previous user's attempts/efforts could be found. My attempts so far for the aforementioned libraries are at: http://www.neuromancy.net/viewcvs/Mantra-I/python/boost/?root=mantra Obviously some parts of boost are woefully unsuited to conversion attempts, but there are many parts that conversion is quite suitable. Even some template classes can be converted if you take the defaults, for example boost::basic_format has a standard typedef 'format' and 'wformat', which is what I converted, since obviously I could not translate the templated class itself. Hope the above helps others, and I hope to hear about other's efforts in converting boost::* (or other standard stuff such as std::*, or libc components). Second, I noticed that there is a std::map<> and std::vector<> indexing suite, are there any plans for, say, std::list<> or std::set<>? Or has anyone done these in the same style as the vector/map ones? Finally, I saw mention of someone requesting (quite some time ago) something like implicitly_convertible that allows you to specify a conversion function. I would like to voice my opinion that this is an excellent idea. After all, the current implicitly_convertible eventually just does: Result v(Source); Why not add a standard boost::python way to do instead: Result v(ConversionFunc(Source)); I don't immagine it would be all that difficult to implement, and it would save a lot of people a LOT of time trying to mess with the somewhat ungainly syntax of rvalue conversions, etc. I tried to make this myself once, but ran into problems, mainly because I did not quite understand what I was doing (this was very early in my boost::python days :P). Thanks, -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net) From nicodemus at esss.com.br Sat Feb 12 00:55:16 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Fri, 11 Feb 2005 21:55:16 -0200 Subject: [C++-sig] boost::* standard python conversions In-Reply-To: References: Message-ID: <420D45E4.6050504@esss.com.br> Preston A. Elder wrote: >Hope the above helps others, and I hope to hear about other's efforts in >converting boost::* (or other standard stuff such as std::*, or libc >components). > > Hmm, I find this very interesting! At work I have exposed std::vector, std::map, std::pair (instantiated with various types, obviously). The beauty about exporting template classes is that you can make a function that exports any instantiation: template void export_std_vector(const char* name) { // export std::vector } Then boost::python could automatically export vectors of builtin types, plus provide the user with this "export" functions to allow them to export vector of custom types. I think that if this kind of thing was avaiable in boost::python out-of-box it would be very handy (like boost::python::numeric). I would of course be willing to contribute to some code. :) What others think? Regards, Nicodemus. From prez at neuromancy.net Sat Feb 12 01:05:27 2005 From: prez at neuromancy.net (Preston A. Elder) Date: Fri, 11 Feb 2005 19:05:27 -0500 Subject: [C++-sig] Re: boost::* standard python conversions References: <420D45E4.6050504@esss.com.br> Message-ID: On Fri, 11 Feb 2005 21:55:16 -0200, Nicodemus wrote: > template > void export_std_vector(const char* name) > { > // export std::vector > } My pair conversion code is in my own 'python.h', here: http://www.neuromancy.net/viewcvs/Mantra-I/python/python.h?root=mantra&rev=1.3&view=auto Look for PairConversion, it uses the to_python_converter/rvalue stuff. As I said, map and vector are supported (pretty much) by boost::python already through their boost::python::vector_indexing_suite and boost::python::map_indexing_suite, however 'set' and 'list' are notably missing. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net) From nicodemus at esss.com.br Sat Feb 12 01:15:05 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Fri, 11 Feb 2005 22:15:05 -0200 Subject: [C++-sig] Re: boost::* standard python conversions In-Reply-To: References: <420D45E4.6050504@esss.com.br> Message-ID: <420D4A89.7040304@esss.com.br> Preston A. Elder wrote: >On Fri, 11 Feb 2005 21:55:16 -0200, Nicodemus wrote: > > >My pair conversion code is in my own 'python.h', here: >http://www.neuromancy.net/viewcvs/Mantra-I/python/python.h?root=mantra&rev=1.3&view=auto > >Look for PairConversion, it uses the to_python_converter/rvalue >stuff. > > Oh, I misunderstood your email... I meant actually *exporting* the types to Python, ie, having a std_vector_double being used in Python, and being passed/returned from functions just as builtin types and std::strings are, for example. We use this to pass great amounts of data from Python to C++ (also with numeric, of course). >As I said, map and vector are supported (pretty much) by boost::python >already through their boost::python::vector_indexing_suite and >boost::python::map_indexing_suite, however 'set' and 'list' are notably >missing. > > Sure. I just thought it would be nice to have some builtin types exported automatically, like numarray/numeric. Regards, Nicodemus. From rwgk at yahoo.com Sat Feb 12 08:41:13 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 11 Feb 2005 23:41:13 -0800 (PST) Subject: [C++-sig] boost::* standard python conversions In-Reply-To: Message-ID: <20050212074114.84968.qmail@web20227.mail.yahoo.com> --- "Preston A. Elder" wrote: > I wonder, is there any concentrated task to convert parts of boost that > make sense to have appropriate python wrappers? I am not aware of a concerted effort to wrap parts of boost. I've done a few more or less general wrappers myself: boost::rational: http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/rational_ext.cpp?view=markup I think this is fairly complete, but the hash support could need more attention. Wrappers for std::vector, std::set, std::map: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/ I made an attempt to keep these as simple as possible to minimize compile times and extension module (i.e. .so or .dll) sizes. Simple application of the Mersenne twister (random number generator) in boost: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/array_family/boost_python/flex_random.cpp?view=markup There is also some general support for mapping C++ containers to Python tuples, and Python tuples, list, ranges and iterators to C++ containers: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.13&view=auto The end-user interfaces are at the bottom of the file and very easy to use, i.e. tuple_mapping_variable_capacity >(); The compile-time required for tuple mappings is signficiantly less than that required for a fully-blown boost::python::class_<> based wrapper (because the standard Python tuple facilities are reused). It is not suitable for large arrays though because of the copy overhead (from a native C++ container into a tuple or from a Python sequence into a C++ container). In my experience as a scientific application developer, when it comes to wrapping C++ containers there is not a general one-size-fits-all solution. Compile times and extension module sizes for fully loaded boost::python::class_<> based container wrappers are significant. I am actively using four or five different approaches, depending on the usage patterns. Hopefully in ten year, when computers are again 10 times faster and everybody as 32GB of RAM or more this will be a non-issue and we can simply throw in a general solution for everything, even if the conversions are not used very much. However given current technology I find it necessary to decide case-by-case what is the best balance of compile-time/extension module size vs. run-time performance. Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From nicodemus at esss.com.br Sat Feb 12 17:41:49 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Sat, 12 Feb 2005 14:41:49 -0200 Subject: [C++-sig] boost::* standard python conversions In-Reply-To: <20050212074114.84968.qmail@web20227.mail.yahoo.com> References: <20050212074114.84968.qmail@web20227.mail.yahoo.com> Message-ID: <420E31CD.50005@esss.com.br> Ralf W. Grosse-Kunstleve wrote: >I am actively >using four or five different approaches, depending on the usage patterns. >Hopefully in ten year, when computers are again 10 times faster and everybody >as 32GB of RAM or more this will be a non-issue and we can simply throw in a >general solution for everything, even if the conversions are not used very >much. However given current technology I find it necessary to decide >case-by-case what is the best balance of compile-time/extension module size vs. >run-time performance. > > Hi Ralph, I would be interested in hear the approaches you take to deal with this problems. Regards, Nicodemus. From mike at thewilsonfamily.freeserve.co.uk Sat Feb 12 19:12:04 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Sat, 12 Feb 2005 18:12:04 -0000 Subject: [C++-sig] Exporting __stdcall functions in Boost.Python Message-ID: <000c01c5112e$6f592c50$5b6a4e51@MIKESPC01> Hi, I am trying to use Boost.Python (via pyste) to export the __stdcall f() below, but get a compile time error (using MSVC 7.1, boost 1.32). #include void __stdcall f() { } void Export_Test() { boost::python::def("f", &f); } The compilation error is: C:\Boost\include\boost-1_32\boost\python\make_function.hpp(104): error C2664: 'boost::mpl::vector1 boost::python::detail::get_signature(RT (__cdecl *)(void),void *)' : cannot convert parameter 1 from 'void (__stdcall *)(void)' to 'void (__cdecl *)(void)' with [ T0=void, RT=void ] It appears that the problem is with the __stdcall modifier. A better description of the problem is also given in: http://mail.python.org/pipermail/c++-sig/2003-April/003811.html I was wondering the best way of wrapping f() (and many more like it) so that the above program compiles (The only way I could do it (due to my lack of skill) is via macros). Any help gratefully received. Regards, Mike From roman.yakovenko at gmail.com Sun Feb 13 08:14:18 2005 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Sun, 13 Feb 2005 09:14:18 +0200 Subject: [C++-sig] Pyste: patch to export all enums automatically In-Reply-To: <420BCE7F.8020300@esss.com.br> References: <01e301c50fa5$252cf150$0200a8c0@lain> <420BCE7F.8020300@esss.com.br> Message-ID: <7465b617050212231465663582@mail.gmail.com> On Thu, 10 Feb 2005 19:13:35 -0200, Nicodemus wrote: > Hi Baptiste, > > Baptiste Lepilleur wrote: > > > The attached patch adds the command-line option --export-enum-values to > >automatically call export_values() on all enum declarations. > > > > If the command-line option is not specified, the behavior remain > >unchanged and you still need to specify call export_values(...) on each enum > >if you want to export it. > > > > > > Thanks for the patch! I'm just not so sure if that's the best way to > implement a feature like that (perhaps Pyste's command line is too > cluttered already?). Opinions, anyone? I think we have those choices: 1. to leave as is + we are stay consisten with current code - command line sometimes is realy big 2. to setup global configuration class. + only one place to configure pyste 3. in every exporter we can define class variables that will control exporting + it is easy to see what configurations actualy do - difficult to use for user 4. combining 2 + 3: to define configuration variables in evry exporter and linking to this variables from single configuration class Roman > > Regards, > Nicodemus. > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From liwei_peng at yahoo.com Mon Feb 14 00:14:40 2005 From: liwei_peng at yahoo.com (Liwei Peng) Date: Sun, 13 Feb 2005 15:14:40 -0800 (PST) Subject: [C++-sig] boost python: How to convert a class X object to class Y object automatically Message-ID: <20050213231440.75480.qmail@web53005.mail.yahoo.com> Hi, Can someone give me some suggestion on how I can convert a class X object to a class Y object automatically through boost python? class Y { ... }; class X { public: Y get_y(); ... }; While in C++, I can do this: X x; Y y = x.get_y(); In python, I'd like to convert X object automatically, transparently to Y object without having to call "get_y()". Any comments are welcome, Thanks, Liwei __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From psbolanos at hotmail.com Mon Feb 14 16:41:25 2005 From: psbolanos at hotmail.com (Pedro Bolaños) Date: Mon, 14 Feb 2005 15:41:25 +0000 Subject: [C++-sig] Building Message-ID: Hi, I've been trying to build Boost.Python, without success, both, using bjam(3.1.10), and the visual studio project. When I use bjam, I set the following environment variables: VC7_ROOT = C:\Archivos de programa\Microsoft Visual Studio .NET\Vc7 PYTHON_ROOT = c:\desarrollo\python23 PYTHON_VERSION = 2.3 and invoke the command in "C:\Desarrollo\boost_1_32_0\libs\python\build" as follows: bjam "-sTOOLS=vc7" When using the visual studio project I get the following output: ------ Build started: Project: boost_python, Configuration: Release Win32 ------ Compiling... type_id.cpp tuple.cpp str.cpp registry.cpp pickle_support.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled object_protocol.cpp object_operators.cpp numeric.cpp module.cpp long.cpp list.cpp life_support.cpp iterator.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled inheritance.cpp ../../../../boost\pending\detail\property.hpp(80) : error C2039: 'result<`template-parameter258'>' : is not a member of 'boost::detail::property_value_end' ../../../../boost\pending\detail\property.hpp(80) : fatal error C1507: previous user errors and subsequent error recovery halt further compilation function.cpp ../../../../boost\python\args_fwd.hpp(45) : error C2118: negative subscript or subscript is too large ../../../../boost\python\args_fwd.hpp(46) : see reference to class template instantiation 'boost::python::detail::error::more_keywords_than_function_arguments<,>' being compiled from_python.cpp errors.cpp enum.cpp dict.cpp class.cpp Generating Code... Compiling... builtin_converters.cpp \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(77) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(70) : while compiling class-template member function 'void boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python::construct(PyObject *,boost::python::converter::rvalue_from_python_stage1_data *)' with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_from_python ] \Desarrollo\boost_1_32_0\libs\python\src\converter\builtin_converters.cpp(396) : see reference to class template instantiation 'boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python' being compiled with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_from_python ] arg_to_python_base.cpp aix_init_module.cpp Generating Code... Build log was saved at "file://c:\Desarrollo\boost_1_32_0\libs\python\build\VisualStudio\release-obj\BuildLog.htm" boost_python - 5 error(s), 1 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped What can I do about it? Am I missing any step? Thank you very much. Sebastian Bola?os. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From grig at gheorghiu.net Mon Feb 14 23:33:41 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 14 Feb 2005 14:33:41 -0800 (PST) Subject: [C++-sig] Looking for Brian Luft Message-ID: <20050214223341.5238.qmail@web54506.mail.yahoo.com> Brian, If this message reaches you, please reply. You left a comment on my blog about the LA PIG thing, but you didn't leave your email. I found this email on Google. Grig From nicodemus at esss.com.br Tue Feb 15 00:44:02 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Mon, 14 Feb 2005 21:44:02 -0200 Subject: [C++-sig] Pyste: patch to export all enums automatically In-Reply-To: <7465b617050212231465663582@mail.gmail.com> References: <01e301c50fa5$252cf150$0200a8c0@lain> <420BCE7F.8020300@esss.com.br> <7465b617050212231465663582@mail.gmail.com> Message-ID: <421137C2.2070808@esss.com.br> Roman Yakovenko wrote: >On Thu, 10 Feb 2005 19:13:35 -0200, Nicodemus wrote: > > >>Hi Baptiste, >> >>Baptiste Lepilleur wrote: >> >> >> >>> The attached patch adds the command-line option --export-enum-values to >>>automatically call export_values() on all enum declarations. >>> >>> If the command-line option is not specified, the behavior remain >>>unchanged and you still need to specify call export_values(...) on each enum >>>if you want to export it. >>> >>> >>> >>> >>Thanks for the patch! I'm just not so sure if that's the best way to >>implement a feature like that (perhaps Pyste's command line is too >>cluttered already?). Opinions, anyone? >> >> > >I think we have those choices: >1. to leave as is > + we are stay consisten with current code > - command line sometimes is realy big >2. to setup global configuration class. > + only one place to configure pyste >3. in every exporter we can define class variables that will control exporting > + it is easy to see what configurations actualy do > - difficult to use for user >4. combining 2 + 3: to define configuration variables in evry exporter > and linking to this variables from single configuration class > > Right; I will apply your patch then. It will just have to wait a little until I get my Visual C++ CD to properly test it up. Thanks again, Nicodemus. From nicodemus at esss.com.br Tue Feb 15 00:45:32 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Mon, 14 Feb 2005 21:45:32 -0200 Subject: [C++-sig] Pyste bug: implicit constructors In-Reply-To: <420BCEA5.1040205@esss.com.br> References: <4204043F.4841.6A19A9B@localhost> <420BCEA5.1040205@esss.com.br> Message-ID: <4211381C.2050205@esss.com.br> Nicodemus wrote: > Niall Douglas wrote: > >> I suggest: >> >> artificial = element.get('artificial', False) >> ctor = Constructor(name, classname, params, visib) >> if artificial and not ctor.IsCopy(): >> # we don't want artificial constructors except copy ones >> ctor = Unknown('__Unknown_Element_%s' % id) >> >> ... but this may not be the right thing either. >> >> I guess the correct thing would be to instantiate the Constructors anyway, but only export those that are non-artificial. This way, we get the usual Boost.Python behaviour. What you think? Regards, Nicodemus. From ghost at cs.msu.su Tue Feb 15 10:21:41 2005 From: ghost at cs.msu.su (Vladimir Prus) Date: Tue, 15 Feb 2005 12:21:41 +0300 Subject: [C++-sig] Boost.Python compilation warning Message-ID: Hello, I'm getting this when compiling the getting_started1 example: gcc-C++-action bin/example/getting_started1.so/gcc/debug/shared-linkable-true/getting_started1.o In file included from /home/ghost/Work/boost/boost/python/detail/wrap_python.hpp:30, from /home/ghost/Work/boost/boost/python/detail/prefix.hpp:13, from /home/ghost/Work/boost/boost/python/module.hpp:8, from /home/ghost/Work/boost/libs/python/example/getting_started1.cpp:14: /usr/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39, from /usr/include/c++/3.3/i486-linux/bits/c++config.h:35, from /usr/include/c++/3.3/string:45, from /home/ghost/Work/boost/libs/python/example/getting_started1.cpp:5: /usr/include/features.h:131:1: warning: this is the location of the previous definition I have up-to-date CVS tree, Python 2.3.4 and gcc version 3.3.5. Any ideas? - Volodya From rwgk at yahoo.com Tue Feb 15 11:43:51 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 15 Feb 2005 02:43:51 -0800 (PST) Subject: [C++-sig] Boost.Python compilation warning In-Reply-To: Message-ID: <20050215104351.88345.qmail@web20223.mail.yahoo.com> --- Vladimir Prus wrote: > > Hello, > I'm getting this when compiling the getting_started1 example: > > gcc-C++-action > bin/example/getting_started1.so/gcc/debug/shared-linkable-true/getting_started1.o > In file included > from /home/ghost/Work/boost/boost/python/detail/wrap_python.hpp:30, > from > /home/ghost/Work/boost/boost/python/detail/prefix.hpp:13, > from /home/ghost/Work/boost/boost/python/module.hpp:8, > from > /home/ghost/Work/boost/libs/python/example/getting_started1.cpp:14: > /usr/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE" > redefined > In file included from /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39, > from /usr/include/c++/3.3/i486-linux/bits/c++config.h:35, > from /usr/include/c++/3.3/string:45, > from > /home/ghost/Work/boost/libs/python/example/getting_started1.cpp:5: > /usr/include/features.h:131:1: warning: this is the location of the previous > definition > > I have up-to-date CVS tree, Python 2.3.4 and gcc version 3.3.5. Any ideas? Yes. Unfortunately the include order is important. As of Python 2.3 not only in theory, but also in practice (some platforms). Please try again with the latest boost CVS. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From ghost at cs.msu.su Tue Feb 15 12:30:19 2005 From: ghost at cs.msu.su (Vladimir Prus) Date: Tue, 15 Feb 2005 14:30:19 +0300 Subject: [C++-sig] Re: Boost.Python compilation warning References: <20050215104351.88345.qmail@web20223.mail.yahoo.com> Message-ID: Ralf W. Grosse-Kunstleve wrote: >> In file included from >> /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39, >> from >> /usr/include/c++/3.3/i486-linux/bits/c++config.h:35, >> from /usr/include/c++/3.3/string:45, from >> /home/ghost/Work/boost/libs/python/example/getting_started1.cpp:5: >> /usr/include/features.h:131:1: warning: this is the location of the >> previous definition >> >> I have up-to-date CVS tree, Python 2.3.4 and gcc version 3.3.5. Any >> ideas? > > Yes. Unfortunately the include order is important. As of Python 2.3 not > only in theory, but also in practice (some platforms). Please try again > with the latest boost CVS. Thank you! Works fine now. - Volodya From rwgk at yahoo.com Tue Feb 15 12:38:49 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 15 Feb 2005 03:38:49 -0800 (PST) Subject: [C++-sig] boost::* standard python conversions In-Reply-To: <420E31CD.50005@esss.com.br> Message-ID: <20050215113849.47188.qmail@web20228.mail.yahoo.com> --- Nicodemus wrote: > Ralf W. Grosse-Kunstleve wrote: > > >I am actively > >using four or five different approaches, depending on the usage patterns. > >Hopefully in ten year, when computers are again 10 times faster and > everybody > >as 32GB of RAM or more this will be a non-issue and we can simply throw in a > >general solution for everything, even if the conversions are not used very > >much. However given current technology I find it necessary to decide > >case-by-case what is the best balance of compile-time/extension module size > vs. > >run-time performance. > > > > > > Hi Ralph, > > I would be interested in hear the approaches you take to deal with this > problems. I'll try a very brief summary of my array wrappers: - The simplest approach: mapping from C++ containers to Python tuples and vice versa. Main support header: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?view=markup - The most comprehensive approach: fully loaded boost::python::class_<> based N-dimensional arrays including all arithmetic (+-*/%) and boolean (<>=<=>==!=) operators, math functions (sin, cos, floor, etc.), selection facilities (generalized slicing) and full+fast+portable pickle support. The same Python type can be converted to 20+ different but related C++ types; e.g. if the multi-dimensional Python array is in fact just a 1-dim array it can be converted to a 1-dim C++ type. -- This system is quite a beast. Compiling the complete wrappers for the element type double takes about 45 seconds under Redhat WS 3, 3GHz Xeon. Now consider that I also have wrappers for bool, complex_double, float, int, long, size_t, std::string and a "vec3" type (triple of three doubles), plus a few domain-specific types. http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/ - A simplified array wrapper for a reference-counted 1-dim array type, similar to the vector indexing suite, but with a few extras to cooperate with the "comprehensive wrappers" above, and a few omissions to keep compile times down. http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/shared_wrapper.h?view=markup - Simple wrappers for std::vector, std::set, std::map. Designed as thin as possible to keep compile times down. http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/ I am not sure how much any of this generalizes. I guess container_conversions.h could be useful in many contexts, but the compromises I made in implementing the other approaches may not work well in other environments. I am posting the links here only as potential sources of ideas, for people who are not afraid of looking at raw code. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From ghost at cs.msu.su Tue Feb 15 13:21:13 2005 From: ghost at cs.msu.su (Vladimir Prus) Date: Tue, 15 Feb 2005 15:21:13 +0300 Subject: [C++-sig] 'numpy' test broken? Message-ID: Hello, using fresh CVS state, I get failure of the 'numpy' test. I run: bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.3 numpy and get error. The interesting part of the test output is: dlopen("/home/ghost/Work/boost/bin/boost/libs/python/test/numpy_ext.so/gcc/debug/shared-linkable-true/ numpy_ext.so", 2); testing default extension module Running __main__.__doc__ ........ Trying: exercise_numarray(x, p) Expecting: nothing ***************************************************************** Failure in example: exercise_numarray(x, p) from line #6 of __main__._numarray_tests Exception raised: Traceback (most recent call last) File "/usr/lib/python2.3/doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "", line 1, in ? ValueError: type must be either a 1-length string, or a python type object Trying: check(y.astype()); Expecting: nothing Any ideas? - Volodya From Marc.Lazareff at onera.fr Tue Feb 15 19:30:59 2005 From: Marc.Lazareff at onera.fr (Marc Lazareff) Date: Tue, 15 Feb 2005 19:30:59 +0100 Subject: [C++-sig] Python scopes in C++ Message-ID: <42123FE3.3010009@onera.fr> Hello, Our software uses Python bindings (through SWIG) for C++ "description" classes, implementing a data-oriented user interaction model. These classes are data containers, managing attribute/value pairs through C++ maps, images of the corresponding Python dictionaries for Python "description" objects. C++ description objects themselves are "registered" with a global manager. All goes well as long as we treat all entities in a unique, global, scope. But this mechanism does not respect Python scopes, because all objects are registered on the same level, so that : import spam and : from spam import * have equivalent results for the C++ data structure, which does not respect the Python scoping logic. Thus we need to replicate in our C++ code the Python scopes mechanism. I wondered if any of you had experience with a solution for this problem, maybe re-using the Python C code. Thank you for any advice, Marc Lazareff From nicodemus at esss.com.br Tue Feb 15 20:48:48 2005 From: nicodemus at esss.com.br (Nicodemus) Date: Tue, 15 Feb 2005 16:48:48 -0300 Subject: [C++-sig] boost::* standard python conversions In-Reply-To: <20050215113849.47188.qmail@web20228.mail.yahoo.com> References: <20050215113849.47188.qmail@web20228.mail.yahoo.com> Message-ID: <42125220.2050109@esss.com.br> Ralf W. Grosse-Kunstleve wrote: >I'll try a very brief summary of my array wrappers: > >- The simplest approach: mapping from C++ containers to Python tuples and vice >versa. Main support header: >http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?view=markup > >- The most comprehensive approach: fully loaded boost::python::class_<> based >N-dimensional arrays including all arithmetic (+-*/%) and boolean (<>=<=>==!=) >operators, math functions (sin, cos, floor, etc.), selection facilities >(generalized slicing) and full+fast+portable pickle support. The same Python >type can be converted to 20+ different but related C++ types; e.g. if the >multi-dimensional Python array is in fact just a 1-dim array it can be >converted to a 1-dim C++ type. -- This system is quite a beast. Compiling the >complete wrappers for the element type double takes about 45 seconds under >Redhat WS 3, 3GHz Xeon. Now consider that I also have wrappers for bool, >complex_double, float, int, long, size_t, std::string and a "vec3" type >(triple of three doubles), plus a few domain-specific types. >http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/ > >- A simplified array wrapper for a reference-counted 1-dim array type, similar >to the vector indexing suite, but with a few extras to cooperate with the >"comprehensive wrappers" above, and a few omissions to keep compile times down. >http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/shared_wrapper.h?view=markup > >- Simple wrappers for std::vector, std::set, std::map. Designed as thin as >possible to keep compile times down. >http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/ > >I am not sure how much any of this generalizes. I guess container_conversions.h >could be useful in many contexts, but the compromises I made in implementing >the other approaches may not work well in other environments. I am posting the >links here only as potential sources of ideas, for people who are not afraid of >looking at raw code. > > Ralf, Thanks for the summary. I have looked at the code and it looks good; I might use some of those ideas on my own code. But what I meant earlier were which approaches you usually take to keep the compile time down; I expressed myself poorly, sorry. Best Regards, Nicodemus. From mike at thewilsonfamily.freeserve.co.uk Tue Feb 15 22:24:39 2005 From: mike at thewilsonfamily.freeserve.co.uk (Mike) Date: Tue, 15 Feb 2005 21:24:39 -0000 Subject: [C++-sig] Problem in 'boost::python::range' in 1.32 (works in 1.31) Message-ID: <000001c513a5$886e0390$9a3386d9@MIKESPC01> Hi, I've produced a simplified version of a compile error I am now getting in 1.32 which was ok in 1.31. I am using MSVC 7.1. Is this a bug, or an error in my original code? Regards, Mike -----Start of Code ------ #include #include #include struct S { virtual void f()=0; // remove '=0' to compile (or use 1.31) }; typedef std::vector Container; typedef Container::iterator iterator; boost::indirect_iterator begin(Container& v) { return boost::make_indirect_iterator(v.begin()); }; boost::indirect_iterator end (Container& v) { return boost::make_indirect_iterator(v.end()); }; using namespace boost::python; object show_compiler_error_in_1_32( ) { // Fails here return range< return_internal_reference<> > ( begin, end ); } Error message follows: -----End of Code ------ C:\Boost\include\boost-1_32\boost\type_traits\is_convertible.hpp(195) : error C2259: 'S' : cannot instantiate abstract class due to following members: 'void S::f(void)' : pure virtual function was not defined FailsIn1_32.cpp(6) : see declaration of 'S::f' C:\Boost\include\boost-1_32\boost\type_traits\is_convertible.hpp(224) : see reference to class template instantiation 'boost::detail::is_convertible_basic_impl' being compiled with [ From=boost::detail::is_convertible_impl::dereferenceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>::ref_type, To=boost::mpl::identity::dereferenceable >::type>::type ] C:\Boost\include\boost-1_32\boost\type_traits\is_convertible.hpp(279) : see reference to class template instantiation 'boost::detail::is_convertible_impl' being compiled with [ From=boost::mpl::identity::dereferenceable >::type >::type , To=boost::mpl::identity::dereferenceable >::type>::type ] C:\Boost\include\boost-1_32\boost\mpl\aux_\preprocessed\plain\and.hpp(51) : see reference to class template instantiation 'boost::is_convertible' being compiled with [ From=boost::mpl::identity::dereferenceable >::type >::type , To=boost::mpl::identity::dereferenceable >::type>::type ] C:\Boost\include\boost-1_32\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::mpl::and_' being compiled with [ T1=boost::is_convertible::dereferenceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>, T2=boost::mpl::not_::type,boost::forward_traversal_tag>> ] C:\Boost\include\boost-1_32\boost\mpl\eval_if.hpp(40) : see reference to class template instantiation 'boost::mpl::if_' being compiled with [ T1=boost::mpl::and_::dereferenceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>,boost::mpl::not_::type,boost::forward_traversal_tag>>>, T2=boost::mpl::if_::derefere nceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>,boost::detail::postfix_increment_proxy>,boost::detail::writable_postfix_increment_proxy>>, T3=boost::mpl::identity> ] C:\Boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(291) : see reference to class template instantiation 'boost::mpl::eval_if' being compiled with [ C=boost::mpl::and_::dereferenceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>,boost::mpl::not_::type,boost::forward_traversal_tag>>>, F1=boost::mpl::if_::derefere nceable >::type >::type ,boost::mpl::identity::dereferenceable >::type>::type>,boost::detail::postfix_increment_proxy>,boost::detail::writable_postfix_increment_proxy>>, F2=boost::mpl::identity> ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(65) : see reference to class template instantiation 'boost::detail::postfix_increment_result' being compiled with [ Iterator=boost::indirect_iterator, Value=boost::mpl::identity::dereferenceable >::type>::type, Reference=boost::mpl::identity::dereferenceable >::type >::type, CategoryOrTraversal=boost::mpl::identity ::type ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(62) : while compiling class-template member function 'boost::python::objects::iterator_range::next::result _type boost::python::objects::iterator_range::next::operato r ()(boost::python::objects::iterator_range &)' with [ NextPolicies=boost::python::return_internal_reference<>, Iterator=iterator_const ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(127) : see reference to class template instantiation 'boost::python::objects::iterator_range::next' being compiled with [ NextPolicies=boost::python::return_internal_reference<>, Iterator=iterator_const ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(163) : see reference to function template instantiation 'boost::python::api::object boost::python::objects::detail::demand_iterator_class>(const char *,Iterator *,const NextPolicies &)' being compiled with [ Iterator=const iterator_const, NextPolicies=boost::python::return_internal_reference<> ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(161) : while compiling class-template member function 'boost::python::objects::iterator_range boost::python::objects::detail::py_iter_::operator ()(boost::python::back_reference) const' with [ NextPolicies=boost::python::return_internal_reference<>, Iterator=iterator_const, Target=Container, Accessor1=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, Accessor2=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, T=Container & ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(187) : see reference to class template instantiation 'boost::python::objects::detail::py_iter_' being compiled with [ Target=Container, Iterator=iterator_const, Accessor1=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, Accessor2=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, NextPolicies=boost::python::return_internal_reference<> ] C:\Boost\include\boost-1_32\boost\python\object\iterator.hpp(239) : see reference to function template instantiation 'boost::python::api::object boost::python::objects::detail::make_iterator_function(const Accessor1 &,const Accessor2 &,const NextPolicies &,Iterator &(__cdecl *)(void),boost::type *,int)' being compiled with [ Target=Container, T=const iterator_const, NextPolicies=boost::python::return_internal_reference<>, Accessor1=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, Accessor2=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, Iterator=const iterator_const ] C:\Boost\include\boost-1_32\boost\python\iterator.hpp(39) : see reference to function template instantiation 'boost::python::api::object boost::python::objects::make_iterator_function,boost::_bi::protected_bind_t>(const Accessor1 &,const Accessor2 &,const NextPolicies &,boost::type *)' being compiled with [ Target=Container, NextPolicies=boost::python::return_internal_reference<>, F=boost::_bi::bind_t,boost::indirect_iter ator (__cdecl *)(Container &),boost::_bi::list1>::B1>>, Accessor1=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, Accessor2=boost::_bi::protected_bind_t,boost::indirect_iterator (__cdecl *)(Container &),boost::_bi::list1>::B1>>>, T=Container ] C:\Boost\include\boost-1_32\boost\python\iterator.hpp(96) : see reference to function template instantiation 'boost::python::api::object boost::python::detail::make_iterator(__cdecl *)(Container &),boost::indirect_iterator(__cdecl *)(Container &),boost::python::return_internal_reference<>>(Accessor1,Accessor2,NextPolic ies,Target &(__cdecl *)(void))' being compiled with [ Iterator=iterator, Accessor1=boost::indirect_iterator (__cdecl *)(Container &), Accessor2=boost::indirect_iterator (__cdecl *)(Container &), NextPolicies=boost::python::return_internal_reference<>, Target=Container ] FailsIn1_32.cpp(28) : see reference to function template instantiation 'boost::python::api::object boost::python::range,boost::indir ect_iterator(__cdecl *)(Container &),boost::indirect_iterator(__cdecl *)(Container &)>(Accessor1,Accessor2,NextPolicies *)' being compiled with [ Iterator=iterator, Accessor1=boost::indirect_iterator (__cdecl *)(Container &), Accessor2=boost::indirect_iterator (__cdecl *)(Container &), NextPolicies=boost::python::return_internal_reference<> ] --- End of message From rwgk at yahoo.com Tue Feb 15 23:56:03 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 15 Feb 2005 14:56:03 -0800 (PST) Subject: [C++-sig] boost::* standard python conversions In-Reply-To: <42125220.2050109@esss.com.br> Message-ID: <20050215225603.11568.qmail@web20221.mail.yahoo.com> --- Nicodemus wrote: > Thanks for the summary. I have looked at the code and it looks good; I > might use some of those ideas on my own code. But what I meant earlier > were which approaches you usually take to keep the compile time down; Apart from being very conscious about the array wrappers I don't do anything special. I guess it may help that I do all my wrapping manually (because I don't want to be dependent on gcc-xml) and I only wrap what I need. Ralf __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From jlh at yvn.com Wed Feb 16 09:20:56 2005 From: jlh at yvn.com (jim) Date: Wed, 16 Feb 2005 00:20:56 -0800 Subject: [C++-sig] wrapping xbase library Message-ID: <200502160020.56378.jlh@yvn.com> Sirs: I maintain a production data system written in Clipper. Clipper having been abandoned by Computer associates, I would like to be able to do things in python -- which will require using the existing xbase data structure for the time being. Suggestions that I move the data system to postgresql or mysql... are not useful at this time. I must work with the xbase files for the time being because so much of the system must use them. And I require a real time two way dialog between the new and the old. I need to be able to manipulate xbase dbf, dbt and ntx files -- data files, memo files and index files -- in much the same fashion that clipper does it. Shared files, record locking, update index files if key fields change ... If I can get the above, most else is negotiable. The xbase c++ library appears to be such an interface and I have been trying to create a python module from that library. I only need a small subset of the actual library functions although having access to them all would be a good thing. I am soliciting assistance in this project -- paid or otherwise. I will be more than willing to do the grunt work, but it seems as if I need some coaching to get some of the hooks from the xbase library into python. I would expect that the results would be offered to the community under the gpl or python license -- altho again, if I get the modules built I need to do the job, most else is negotiable. If I am suggesting things that are outside the accepted procedurs in this group and community, coaching on means and methods would be quite welcome. Again, methods and language are not important to me. A useable pyxbase module is the goal. Thanks in advance, Jim Hurlburt Yakima, WA From sakesun at boonthavorn.com Wed Feb 16 09:26:51 2005 From: sakesun at boonthavorn.com (Sakesun Roykiattisak) Date: Wed, 16 Feb 2005 15:26:51 +0700 Subject: [C++-sig] wrapping xbase library In-Reply-To: <200502160020.56378.jlh@yvn.com> References: <200502160020.56378.jlh@yvn.com> Message-ID: <421303CB.9000600@boonthavorn.com> http://sourceforge.net/projects/xdb/ Found via google From clay at idleengineer.net Wed Feb 16 10:28:59 2005 From: clay at idleengineer.net (Clay Culver) Date: Wed, 16 Feb 2005 04:28:59 -0500 Subject: [C++-sig] Converting C++ Class into Python Binding Message-ID: <4213125B.1060900@idleengineer.net> Lets say I have a library written in C++ called Foo. This library has been exposed with boost.python so I can use it in python. I'm writing a program that embeds python into a C++ program, and both the C++ program and the embedded python scripts will use the Foo library and share objects. Here's my problem: I want to take an object of type Bar (from the Foo library) that has been created in C++ and return it based on a function call in python (I need a reference, not a copy of the object). To do this, I need to convert from the C++ class into a PyObject. I'm up to this point: static PyObject * get_foo_object( PyObject *self, PyObject *args ) { // parse params // get the Bar object "bar" return ???; } Basically I have the object bar, but I need to return a reference to bar as a PyObject. Since the Bar class exists in both the C++ code and in the python bindings I think this should be simple, but I can't seem to figure out how to convert from the C++ object to the Python object. Any suggestions on how this is done? (Or just link me to documentation where this is explained. I'm still new to boost.python, and my searches didn't give me what I was looking for.) Thanks, Clay From rwgk at yahoo.com Wed Feb 16 18:24:24 2005 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 16 Feb 2005 09:24:24 -0800 (PST) Subject: [C++-sig] Converting C++ Class into Python Binding In-Reply-To: <4213125B.1060900@idleengineer.net> Message-ID: <20050216172424.57612.qmail@web20224.mail.yahoo.com> --- Clay Culver wrote: > static PyObject * > get_foo_object( PyObject *self, PyObject *args ) > { > // parse params > // get the Bar object "bar" > > return ???; > } I am not competent enough to give you a definitive answer, but I believe this should get you close: boost::python::object get_foo_object(...) { ... return boost::python::object(bar); } I don't know how to control pass-by-reference vs. pass-by-value. I'd look for "boost::ref" in the tutorial since this is the best clue I have off the top of my head. Also, this is unusual in a Boost.Python wrapper: > get_foo_object( PyObject *self, PyObject *args ) Why don't you use the "native" signature instead? HTH, Ralf __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From clay at idleengineer.net Wed Feb 16 19:00:07 2005 From: clay at idleengineer.net (Clay Culver) Date: Wed, 16 Feb 2005 13:00:07 -0500 Subject: [C++-sig] Converting C++ Class into Python Binding In-Reply-To: <20050216172424.57612.qmail@web20224.mail.yahoo.com> References: <20050216172424.57612.qmail@web20224.mail.yahoo.com> Message-ID: <42138A27.2090506@idleengineer.net> Ralf W. Grosse-Kunstleve wrote: > > >I am not competent enough to give you a definitive answer, but I believe this >should get you close: > >boost::python::object >get_foo_object(...) >{ > ... > return boost::python::object(bar); >} > >I don't know how to control pass-by-reference vs. pass-by-value. I'd look for >"boost::ref" in the tutorial since this is the best clue I have off the top of >my head. > > This is what I've seen before, but I just need to be sure that a copy of the object is not made (which is usually the case in python). If I get this working I can just test it. >Also, this is unusual in a Boost.Python wrapper: > > > >>get_foo_object( PyObject *self, PyObject *args ) >> >> > >Why don't you use the "native" signature instead? > > This is how you would do it with the Python/C api. I seem to be having difficulty making the transition to boost. I have a decent grasp of how to wrap C++ objects objects into a python object, but what's more fuzzy is working with the interpreter using boost. I'm trying to embed Python into my application, but I get all the way to the point where I need to start returning references to C++ objects and I get stuck. My main flow is: 0) I already have library Foo bound in both Python and C++ (import Foo works in python, in C++ I include Foo headers). 1) Build a new module for this application to expose the data I'm trying to share. (get_foo_object would be one of the bound methods so that python could call "import new_module", "f = new_module.get_foo_object()" and from there start manipulating f) 2) Startup the interpreter. 3) Load the module I created in 1 with Py_InitModule. 4) Use python scripts to call methods in this new module to interact with the data. The only problem I seem to be having is during #1, trying to convert from a C++ object to its wrapper. I'll try return boost::python::object(bar). Am I going about this the wrong way? Should I be using pure boost instead of trying to do this with the Python/C API? Thanks, Clay -------------- next part -------------- An HTML attachment was scrubbed... URL: From clay at idleengineer.net Wed Feb 16 22:40:20 2005 From: clay at idleengineer.net (Clay Culver) Date: Wed, 16 Feb 2005 16:40:20 -0500 Subject: [C++-sig] Converting C++ Class into Python Binding In-Reply-To: <42138A27.2090506@idleengineer.net> References: <20050216172424.57612.qmail@web20224.mail.yahoo.com> <42138A27.2090506@idleengineer.net> Message-ID: <4213BDC4.1090906@idleengineer.net> Ok scratch all of that. I'm going to rewrite everything using Boost's wrapper functions. I might be back with a similar question in a week. =) Clay From nick at ilm.com Thu Feb 17 00:26:06 2005 From: nick at ilm.com (Nick Rasmussen) Date: Wed, 16 Feb 2005 15:26:06 -0800 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050211023937.GP14902@ewok.lucasdigital.com> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> <20050211023937.GP14902@ewok.lucasdigital.com> Message-ID: <20050216232606.GM17806@ewok.lucasdigital.com> On Thu, 10 Feb 2005, Nick Rasmussen wrote: > > Thanks for testing it out. It's been working fine for me here > (suse9.1 amd64 with python2.3), but I'll see if I can figure > out what the right fix is. > > I took a quick look at PyCFunction_Type, and it's tp_flags are > set to: > > Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,/* tp_flags */ > > Two things make me suspicious: absent is Py_TPFLAGS_BASETYPE, > and I'm not sure if subclasses of gc-aware classes need to > support garbage collection as well. > > I'll run it by our local python expert and see what he has > to say. I ran this question past python-dev, and they said that one way to do this is to have PyCFunction_Type as the __class__ attribute: http://thread.gmane.org/gmane.comp.python.devel/66557 I'm now running boost::python with the following patch applied (docstring concatenation and the __class__ attribute), and this seems to be working for me. -nick --- libs/python/src/object/function.cpp.orig Mon Feb 7 17:11:52 2005 +++ libs/python/src/object/function.cpp Wed Feb 16 12:13:38 2005 @@ -472,7 +472,12 @@ if (doc != 0) { object attr_copy(attribute); - attr_copy.attr("__doc__") = doc; + if (PyObject_HasAttrString(attr_copy.ptr(), "__doc__") && attr_copy.attr("__doc__")) { + attr_copy.attr("__doc__") += "\n\n"; + attr_copy.attr("__doc__") += doc; + } + else + attr_copy.attr("__doc__") = doc; } } @@ -566,11 +571,17 @@ else return python::incref(f->name().ptr()); } + + static PyObject* function_get_class(PyObject* op, void*) + { + return python::incref(reinterpret_cast(&PyCFunction_Type)); + } } static PyGetSetDef function_getsetlist[] = { {"__name__", (getter)function_get_name, 0 }, {"func_name", (getter)function_get_name, 0 }, + {"__class__", (getter)function_get_class, 0 }, {"__doc__", (getter)function_get_doc, (setter)function_set_doc}, {"func_doc", (getter)function_get_doc, (setter)function_set_doc}, {NULL} /* Sentinel */ From jbrandmeyer at earthlink.net Thu Feb 17 04:59:44 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Wed, 16 Feb 2005 22:59:44 -0500 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050216232606.GM17806@ewok.lucasdigital.com> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> <20050211023937.GP14902@ewok.lucasdigital.com> <20050216232606.GM17806@ewok.lucasdigital.com> Message-ID: <1108612785.8079.12.camel@illuvatar> On Wed, 2005-02-16 at 15:26 -0800, Nick Rasmussen wrote: > On Thu, 10 Feb 2005, Nick Rasmussen wrote: > > > > Thanks for testing it out. It's been working fine for me here > > (suse9.1 amd64 with python2.3), but I'll see if I can figure > > out what the right fix is. > > > > I took a quick look at PyCFunction_Type, and it's tp_flags are > > set to: > > > > Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,/* tp_flags */ > > > > Two things make me suspicious: absent is Py_TPFLAGS_BASETYPE, > > and I'm not sure if subclasses of gc-aware classes need to > > support garbage collection as well. > > > > I'll run it by our local python expert and see what he has > > to say. > > > I ran this question past python-dev, and they said that > one way to do this is to have PyCFunction_Type as the > __class__ attribute: > > http://thread.gmane.org/gmane.comp.python.devel/66557 > > I'm now running boost::python with the following patch applied > (docstring concatenation and the __class__ attribute), and > this seems to be working for me. I'm more than a little leery of changing the __class__ attribute, since all instances of Boost.Python.function would be lying about what they are. If x and f.x are Boost.Python.function objects with docstrings, than inspect.getdoc(x) and inspect.getdoc(f.x) work. inspect.ismethoddescriptor(x) and inspect.ismethod(f.x) also return True. Where does pydoc test whether or not to document something as a function? -Jonathan From jlh at yvn.com Thu Feb 17 07:10:05 2005 From: jlh at yvn.com (jim) Date: Wed, 16 Feb 2005 22:10:05 -0800 Subject: [C++-sig] wrapping xbase library In-Reply-To: <421303CB.9000600@boonthavorn.com> References: <200502160020.56378.jlh@yvn.com> <421303CB.9000600@boonthavorn.com> Message-ID: <200502162210.05295.jlh@yvn.com> Unfortunatly, is a pointer to the same library -- older version. Thanks though. Jim On Wednesday 16 February 2005 12:26 am, Sakesun Roykiattisak wrote: > http://sourceforge.net/projects/xdb/ > Found via google > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From nick at ilm.com Thu Feb 17 19:06:46 2005 From: nick at ilm.com (Nick Rasmussen) Date: Thu, 17 Feb 2005 10:06:46 -0800 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <1108612785.8079.12.camel@illuvatar> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> <20050211023937.GP14902@ewok.lucasdigital.com> <20050216232606.GM17806@ewok.lucasdigital.com> <1108612785.8079.12.camel@illuvatar> Message-ID: <20050217180646.GT17806@ewok.lucasdigital.com> On Wed, 16 Feb 2005, Jonathan Brandmeyer wrote: > I'm more than a little leery of changing the __class__ attribute, since > all instances of Boost.Python.function would be lying about what they > are. > > If x and f.x are Boost.Python.function objects with docstrings, than > inspect.getdoc(x) and inspect.getdoc(f.x) work. > inspect.ismethoddescriptor(x) and inspect.ismethod(f.x) also return > True. > > Where does pydoc test whether or not to document something as a > function? > > -Jonathan > for python2.3 it's at pydoc.py:559 for key, value in inspect.getmembers(object, inspect.isroutine): if inspect.isbuiltin(value) or inspect.getmodule(value) is object: if visiblename(key): funcs.append((key, value)) fdict[key] = '#-' + key if inspect.isfunction(value): fdict[value] = fdict[key] since inspect.isbuiltin(value) returns false and getmodule(value) returns None for non-python functions. My original solution was changing: if inspect.isbuiltin(value) or inspect.getmodule(value) is object: to: tmp = inspect.getmodule(value) if inspect.isbuiltin(value) or not tmp or tmp is object: in order to just document all entries in the module that have unknown provenance, but I still worry about what else may depend on isbuiltin. The other mechaism that I thought of was to do something like: import inspect inspect.isbuiltin = (some boost-aware version) When a boost module is imported. -nick From jbrandmeyer at earthlink.net Thu Feb 17 23:47:27 2005 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 17 Feb 2005 17:47:27 -0500 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <20050217180646.GT17806@ewok.lucasdigital.com> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> <20050211023937.GP14902@ewok.lucasdigital.com> <20050216232606.GM17806@ewok.lucasdigital.com> <1108612785.8079.12.camel@illuvatar> <20050217180646.GT17806@ewok.lucasdigital.com> Message-ID: <1108680447.20294.19.camel@illuvatar> On Thu, 2005-02-17 at 10:06 -0800, Nick Rasmussen wrote: > On Wed, 16 Feb 2005, Jonathan Brandmeyer wrote: > > Where does pydoc test whether or not to document something as a > > function? > > > > -Jonathan > > > > for python2.3 it's at pydoc.py:559 > > for key, value in inspect.getmembers(object, inspect.isroutine): > if inspect.isbuiltin(value) or inspect.getmodule(value) is object: > if visiblename(key): > funcs.append((key, value)) > fdict[key] = '#-' + key > if inspect.isfunction(value): fdict[value] = fdict[key] All of the routines have been filtered off already, so do you know why they are then filtering for only builtin types? If I comment out the "if inspect.isbuiltin(value)..." line, it appears to work just fine. -Jonathan From nick at ilm.com Fri Feb 18 02:10:09 2005 From: nick at ilm.com (Nick Rasmussen) Date: Thu, 17 Feb 2005 17:10:09 -0800 Subject: [C++-sig] functions not showing up in pydoc In-Reply-To: <1108680447.20294.19.camel@illuvatar> References: <20050208030017.GJ3873@ewok.lucasdigital.com> <20050211020121.98997.qmail@web20223.mail.yahoo.com> <20050211023937.GP14902@ewok.lucasdigital.com> <20050216232606.GM17806@ewok.lucasdigital.com> <1108612785.8079.12.camel@illuvatar> <20050217180646.GT17806@ewok.lucasdigital.com> <1108680447.20294.19.camel@illuvatar> Message-ID: <20050218011008.GZ17806@ewok.lucasdigital.com> On Thu, 17 Feb 2005, Jonathan Brandmeyer wrote: > On Thu, 2005-02-17 at 10:06 -0800, Nick Rasmussen wrote: > > On Wed, 16 Feb 2005, Jonathan Brandmeyer wrote: > > > > Where does pydoc test whether or not to document something as a > > > function? > > > > > > -Jonathan > > > > > > > for python2.3 it's at pydoc.py:559 > > > > for key, value in inspect.getmembers(object, inspect.isroutine): > > if inspect.isbuiltin(value) or inspect.getmodule(value) is object: > > if visiblename(key): > > funcs.append((key, value)) > > fdict[key] = '#-' + key > > if inspect.isfunction(value): fdict[value] = fdict[key] > > All of the routines have been filtered off already, so do you know why > they are then filtering for only builtin types? If I comment out the > "if inspect.isbuiltin(value)..." line, it appears to work just fine. > > -Jonathan They have it there so pydoc doesn't document functions pulled in from other modules, there's just special handling for builtins as there's no way to recover source modules from builtin functions, so it documents all builtin functions. -nick From simon at arrowtheory.com Sun Feb 20 22:08:17 2005 From: simon at arrowtheory.com (Simon Burton) Date: Sun, 20 Feb 2005 21:08:17 +0000 Subject: [C++-sig] .def(str(self)) compile problems Message-ID: <20050220210817.34430160.simon@arrowtheory.com> Hi ! I'm having trouble getting the __str__ wrapper for my C++ class to compile. Everything else i've tried works fine (methods/functions/operators), but when I include the .def( str(self) ) line the compilation fails. Any help much appreciated. I am new to python/C++, but have done a lot of python/C interfacing. details follow. Simon. blue:~/home/cpp/break$ bjam -sTOOLS=gcc lift ...found 1537 targets... ...updating 2 targets... gcc-C++-action bin/break/lift.so/gcc/debug/shared-linkable-true/lift.o /home/simon/local/boost_1_32_0/boost/python/def_visitor.hpp: In static member function `static void boost::python::def_visitor_access::visit(const V&, classT&) [with V = boost::python::def_visitor, classT = boost::python::class_]': /home/simon/local/boost_1_32_0/boost/python/def_visitor.hpp:67: instantiated from `void boost::python::def_visitor::visit(classT&) const [with classT = boost::python::class_, DerivedVisitor = boost::python::api::object]' /home/simon/local/boost_1_32_0/boost/python/class.hpp:225: instantiated from `boost::python::class_& boost::python::class_::def(const boost::python::def_visitor&) [with Derived = boost::python::api::object, W = interval, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' lift.cpp:12: instantiated from here /home/simon/local/boost_1_32_0/boost/python/def_visitor.hpp:31: error: no matching function for call to `boost::python::api::object::visit(boost::python::class_&) const' set -e "g++" -c -Wall -ftemplate-depth-255 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0 -fno-inline -fPIC -I"bin/break" -I "/usr/local//include/python2.3" -I "/home/simon/local/boost_1_32_0" -o "bin/break/lift.so/gcc/debug/shared-linkable-true/lift.o" "lift.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "bin/break/lift.so/gcc/debug/shared-linkable-true/lift.o" ...failed gcc-C++-action bin/break/lift.so/gcc/debug/shared-linkable-true/lift.o... ...removing bin/break/lift.so/gcc/debug/shared-linkable-true/lift.o ...skipped <@break/lift.so/gcc/debug/shared-linkable-true>lift.so for lack of <@break/lift.so/gcc/debug/shared-linkable-true>lift.o... ...failed updating 1 target... ...skipped 1 target... blue:~/home/cpp/break$ blue:~/home/cpp/break$ g++ --version g++ (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) blue:~/home/cpp/break$ cat interval.hpp class interval { public: class division : public std::exception {}; class disorder : public std::exception {}; interval() : _lower(), _upper() {} private: double _lower; double _upper; friend double lower(const interval&); friend double upper(const interval&); }; inline double lower(const interval& x) { return x._lower; } inline double upper(const interval& x) { return x._upper; } std::ostream& operator<<(std::ostream& x, interval y) { return x << '[' << lower(y) << ',' << upper(y) << ']'; } blue:~/home/cpp/break$ cat lift.cpp #include #include "interval.hpp" using namespace boost::python; BOOST_PYTHON_MODULE(lift) { class_< interval >("interval", init< >()) .def( str(self) ) ; def( "lower", lower ); def( "upper", upper ); } blue:~/home/cpp/break$ cat Jamfile project-root ; import python ; extension lift : lift.cpp