From ak at ixion.net Wed Sep 1 11:22:50 2004 From: ak at ixion.net (Andreas Kloeckner) Date: Wed, 01 Sep 2004 11:22:50 +0200 Subject: [C++-sig] ublas vector based arithmetic In-Reply-To: References: Message-ID: <1094030569.13791.15.camel@aramis> Hi Neal, all, Am Di, den 31.08.2004 schrieb Neal D. Becker um 16:57: > Recently I proposed using std::vector for arithmetic. Since then it was > suggested to look at ublas. I think > this is a good idea for my > requirements. > [snip] > I have gotten an implementation working, based mostly on Pylinear-0.9 from > Andreas Kloeckner,ak at ixion.net, http://pylinear.sf.net. My version is much > smaller, simpler and without all the dependencies, but only handles vectors > (not matrices). It adds some convenience features, like constructing > vectors from tuples/lists. pylinear.sf.net is not active currently, but I hope I'll have time to upload an initial set of stuff soon. I never got an activation email from Sourceforge, but I suppose they quietly approved the project... strange. :) As of right now, Pylinear is a bit slower than Numeric, but I believe that a bunch of this can be ironed out by taking a closer look at the BPL. (I haven't checked what performance will be like using the BPL from 1.32) The first thing that I'm planning on doing is to make Pylinear usable without the extra linear algebra libraries. Neal: I'd also like your construction patches if you'd like to supply them. Andreas From ndbecker2 at verizon.net Wed Sep 1 13:27:30 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 01 Sep 2004 07:27:30 -0400 Subject: [C++-sig] Re: ublas vector based arithmetic References: <1094030569.13791.15.camel@aramis> Message-ID: Andreas Kloeckner wrote: > Hi Neal, all, > > Am Di, den 31.08.2004 schrieb Neal D. Becker um 16:57: >> Recently I proposed using std::vector for arithmetic. Since then it was >> suggested to look at ublas. I think >> this is a good idea for my >> requirements. >> [snip] >> I have gotten an implementation working, based mostly on Pylinear-0.9 >> from >> Andreas Kloeckner,ak at ixion.net, http://pylinear.sf.net. My version is >> much smaller, simpler and without all the dependencies, but only handles >> vectors >> (not matrices). It adds some convenience features, like constructing >> vectors from tuples/lists. > > pylinear.sf.net is not active currently, but I hope I'll have time to > upload an initial set of stuff soon. I never got an activation email > from Sourceforge, but I suppose they quietly approved the project... > strange. :) > > As of right now, Pylinear is a bit slower than Numeric, but I believe > that a bunch of this can be ironed out by taking a closer look at the > BPL. (I haven't checked what performance will be like using the BPL from > 1.32) > > The first thing that I'm planning on doing is to make Pylinear usable > without the extra linear algebra libraries. Neal: I'd also like your > construction patches if you'd like to supply them. > I did get pylinear-0.9 to build, but right now I'm using boost-cvs. pylinear-0.9 doesn't compile against current boost-cvs (gcc3.3 linux fc2), and I didn't try to debug it. I'll email you directly the source I'm using. From roman.yakovenko at gmail.com Wed Sep 1 14:59:13 2004 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 1 Sep 2004 15:59:13 +0300 Subject: [C++-sig] boost license Message-ID: <7465b6170409010559214768ab@mail.gmail.com> Hi. Is it possible to use boost license in projects that doesn't belong to boost libraries ? P.S. A few month ago I saw this question on boost list, but I can't find answer. Google returns to many answers and FAQ says nothing about this. Thanks for help. Roman From MKhesin at liquidnet.com Wed Sep 1 15:54:38 2004 From: MKhesin at liquidnet.com (Max Khesin) Date: Wed, 1 Sep 2004 09:54:38 -0400 Subject: [C++-sig] boost license Message-ID: <4B6FB7F60D37D41188C300B0D022E0C003050B68@exchange.lnholdings.com> I believe Dave answered 'yes', but I cannot find the thread either. Some threads are more searchable then others. m > -----Original Message----- > From: Roman Yakovenko [mailto:roman.yakovenko at gmail.com] > Sent: Wednesday, September 01, 2004 8:59 AM > To: c++-sig at python.org > Subject: [C++-sig] boost license > > > Hi. Is it possible to use boost license in projects that doesn't > belong to boost libraries ? > > P.S. > A few month ago I saw this question on boost list, but I > can't find answer. > Google returns to many answers and FAQ says nothing about this. > > Thanks for help. > > Roman > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From dave at boost-consulting.com Wed Sep 1 16:44:41 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 10:44:41 -0400 Subject: [C++-sig] Re: boost license References: <7465b6170409010559214768ab@mail.gmail.com> Message-ID: Roman Yakovenko writes: > Hi. Is it possible to use boost license in projects that doesn't > belong to boost libraries ? Yes. > P.S. > A few month ago I saw this question on boost list, but I can't find answer. > Google returns to many answers and FAQ says nothing about this. Fixing... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ostiguy at fnal.gov Wed Sep 1 19:47:14 2004 From: ostiguy at fnal.gov (Francois Ostiguy) Date: Wed, 1 Sep 2004 12:47:14 -0500 (CDT) Subject: [C++-sig] numarray 1.0 and BPL - s small fix ? Message-ID: Hi - I recently have been playing with numarray 1.0 and the associated support for the array type in BPL. One of the first thing I noticed is that a.nelements(); where a is a numeric::array, fails with the message TypeError: No registered converter was able to produce a C++ rvalue of type long from this Python object of type builtin_function_or_method I found the following thread in the archive, but apparently there was no resolution: http://aspn.activestate.com/ASPN/Mail/Message/2033918 Looking at the source, (BPL 1_31 and current CVS ) I see the following code in the file libs/python/src/numeric.cpp: ... long array_base::nelements() const { return extractattr("nelements"); } I think this code should be replaced (at least for numarray 1.0 ) with long array_base::nelements() const { return attr("nelements")(); } At least, this works for me. Perhaps nelements was a simple scalar attribute in the old numeric extension ? -Francois ---------------------------------------------------------------------------- Dr. Jean-Francois OSTIGUY voice: (630) 840-2231 Beam Physics Dept MS220 FAX: (630) 840-6039 Fermi National Accelerator Laboratory email: ostiguy at fnal.gov Batavia IL 60510-0500 WWW:www-ap.fnal.gov/~ostiguy From dave at boost-consulting.com Wed Sep 1 20:10:20 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 14:10:20 -0400 Subject: [C++-sig] Re: numarray 1.0 and BPL - s small fix ? References: Message-ID: Francois Ostiguy writes: > Hi - > > I recently have been playing with numarray 1.0 and the associated > support for the array type in BPL. One of the first thing I noticed > is that > > a.nelements(); > > where a is a numeric::array, fails with the message > > TypeError: No registered converter was able to produce a C++ rvalue > of type long from this Python object of type > builtin_function_or_method > > I found the following thread in the archive, but apparently there was no > resolution: > > http://aspn.activestate.com/ASPN/Mail/Message/2033918 > > > Looking at the source, (BPL 1_31 and current CVS ) I see > the following code in the file libs/python/src/numeric.cpp: > > ... > > long array_base::nelements() const > { > return extractattr("nelements"); > } Not even possible. That wouldn't compile. > > I think this code should be replaced (at least for numarray 1.0 ) with > > long array_base::nelements() const > { > return attr("nelements")(); > } > > At least, this works for me. I'm shocked. this->attr("nelements")() is of type boost::python::object, which has no implicit conversion to long. Are you sure you compiled the code? > Perhaps nelements was a simple scalar > attribute in the old numeric extension ? ?? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ostiguy at fnal.gov Wed Sep 1 20:48:00 2004 From: ostiguy at fnal.gov (Francois Ostiguy) Date: Wed, 1 Sep 2004 13:48:00 -0500 (CDT) Subject: [C++-sig] Re: numarray 1.0 and BPL - oops In-Reply-To: References: Message-ID: > I'm shocked. this->attr("nelements")() is of type > boost::python::object, which has no implicit conversion to long. Are > you sure you compiled the code? Oops, rightfully so. I did this earlier this morning. I should have pasted the code directly instead of operating from memory The code should have read ... return extract( this->attr("nelements")() ); ... -Francois ---------------------------------------------------------------------------- Dr. Jean-Francois OSTIGUY voice: (630) 840-2231 Beam Physics Dept MS220 FAX: (630) 840-6039 Fermi National Accelerator Laboratory email: ostiguy at fnal.gov Batavia IL 60510-0500 WWW:www-ap.fnal.gov/~ostiguy From ben.everett at ilc.com Wed Sep 1 20:53:53 2004 From: ben.everett at ilc.com (Ben Everett) Date: Wed, 1 Sep 2004 14:53:53 -0400 Subject: [C++-sig] Embedding Boost.Python and Exposing Classes to Python Message-ID: <001c01c49055$07f5ddb0$4632a8c0@ilcnet.local> Hello, I am working on a project that requires heavy C++ and Python interraction. I need to have a C++ class extended into Python and any changes that take place on that class in Python be reflected in the instance that I have in the C++ application. The problem is that I can't get Boost.Python to work at all (even the examples) and the nature of the project makes it hard to use Boost.Jam. The documentation doesn't really have enough information provided in it by itself, and I find myself digging through source files and other projects source (which I don't have the time to do) for supplemental information. Is there a site, FAQ, or HowTo somewhere that goes into embedding Boost.Python and utilizing it more thoroughly than the current documentation has? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boost-consulting.com Wed Sep 1 21:11:58 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 15:11:58 -0400 Subject: [C++-sig] Re: numarray 1.0 and BPL - oops In-Reply-To: (Francois Ostiguy's message of "Wed, 1 Sep 2004 13:48:00 -0500 (CDT)") References: Message-ID: Francois Ostiguy writes: >> I'm shocked. this->attr("nelements")() is of type >> boost::python::object, which has no implicit conversion to long. Are >> you sure you compiled the code? > > > Oops, rightfully so. > > I did this earlier this morning. > > I should have pasted the code directly instead of operating from memory > > The code should have read > > ... > return extract( this->attr("nelements")() ); > ... Which of the two snippets you posted is that? Neither one was right. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Wed Sep 1 21:22:09 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 15:22:09 -0400 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python References: <001c01c49055$07f5ddb0$4632a8c0@ilcnet.local> Message-ID: "Ben Everett" writes: > Hello, > I am working on a project that requires heavy C++ and Python > interraction. I need to have a C++ class extended into Python and any > changes that take place on that class in Python be reflected in the > instance that I have in the C++ application. The problem is that I > can't get Boost.Python to work at all (even the examples) and the > nature of the project makes it hard to use Boost.Jam. Start by going through the documented steps to make it work using Boost.Build. For embedding, go to libs/python/test bjam -sTOOLS=your-toolset embedding Then once you have it working you can invoke bjam -n -a -sTOOLS=your-toolset embedding to see the build commands issued by bjam to successfully build/test the embedding example. > The documentation doesn't really have enough information provided > in it by itself, and I find myself digging through source files and > other projects source (which I don't have the time to do) for > supplemental information. Is there a site, FAQ, or HowTo somewhere > that goes into embedding Boost.Python and utilizing it more thoroughly > than the current documentation has? If the above isn't enough to get you started, you can always contract with Boost Consulting for help ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ostiguy at fnal.gov Wed Sep 1 21:48:24 2004 From: ostiguy at fnal.gov (Francois Ostiguy) Date: Wed, 1 Sep 2004 14:48:24 -0500 (CDT) Subject: [C++-sig] Re: numarray 1.0 and BPL - oops In-Reply-To: References: Message-ID: the code that works for me is exactly as follows: long array_base::nelements() const { return extract( attr("nelements")() ); } I make no claim about correctness ... I am not familiar enough with the low level details of BPL. What is certain is that the current code long array_base::nelements() const { return extract( attr("nelements") ); } ^^^^ i.e. without operator() does not work (numarray 1.0/bpl 1_31/gcc-3.3.3). The error message: TypeError: No registered converter was able to produce a C++ rvalue of type long from this Python object of type builtin_function_or_method. seems to be generated because attr("nelements") returns a callable PyObject* that cannot be converted to a long. The relevant function from the numarray code (1.0) seems to be static PyObject * _ndarray_nelements(PyArrayObject *self, PyObject *args) { if (!PyArg_ParseTuple(args, ":nelements")) return NULL; return PyInt_FromLong(NA_elements(self)); } -Francois ---------------------------------------------------------------------------- Dr. Jean-Francois OSTIGUY voice: (630) 840-2231 Beam Physics Dept MS220 FAX: (630) 840-6039 Fermi National Accelerator Laboratory email: ostiguy at fnal.gov Batavia IL 60510-0500 WWW:www-ap.fnal.gov/~ostiguy From dave at boost-consulting.com Wed Sep 1 22:25:12 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 16:25:12 -0400 Subject: [C++-sig] Re: numarray 1.0 and BPL - oops References: Message-ID: Francois Ostiguy writes: > the code that works for me is exactly as follows: > > > long array_base::nelements() const > { > return extract( attr("nelements")() ); > } > > > I make no claim about correctness ... I am not familiar enough with the > low level details of BPL. It's correct. > What is certain is that the current code > > long array_base::nelements() const > { > return extract( attr("nelements") ); > } > ^^^^ > i.e. without operator() > > does not work (numarray 1.0/bpl 1_31/gcc-3.3.3). I can find no evidence that numeric ever used a different interface. > The error message: > > TypeError: No registered converter was able to produce a C++ rvalue of > type long from this Python object of type builtin_function_or_method. > > seems to be generated because attr("nelements") returns a callable > PyObject* that cannot be converted to a long. > > > The relevant function from the numarray code (1.0) seems to be > > static PyObject * > _ndarray_nelements(PyArrayObject *self, PyObject *args) > { > if (!PyArg_ParseTuple(args, ":nelements")) > return NULL; > return PyInt_FromLong(NA_elements(self)); > } I'll check in the fix. Thanks! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From s_sourceforge at nedprod.com Thu Sep 2 00:16:11 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 01 Sep 2004 23:16:11 +0100 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python In-Reply-To: Message-ID: <4136583B.11801.6F66AB4@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1 Sep 2004 at 15:22, David Abrahams wrote: > > The documentation doesn't really have enough information > > provided > > in it by itself, and I find myself digging through source files and > > other projects source (which I don't have the time to do) for > > supplemental information. Is there a site, FAQ, or HowTo somewhere > > that goes into embedding Boost.Python and utilizing it more > > thoroughly than the current documentation has? > > If the above isn't enough to get you started, you can always contract > with Boost Consulting for help ;-) Also, search this mailing list and download a library which has already embedded BPL for study. You should expect it to take you far longer than your anticipate, but perserverence will win you through. I took four months myself. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQTZKLMEcvDLFGKbPEQLAtwCgvwnwsySrScVf9iV+SGT4aV6Q2j4Anj9I fBL9zU1DoGUqNnG4HvzKYOds =pVmn -----END PGP SIGNATURE----- From dave at boost-consulting.com Thu Sep 2 03:01:38 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 01 Sep 2004 21:01:38 -0400 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python References: <4136583B.11801.6F66AB4@localhost> Message-ID: "Niall Douglas" writes: > On 1 Sep 2004 at 15:22, David Abrahams wrote: > >> > The documentation doesn't really have enough information >> > provided >> > in it by itself, and I find myself digging through source files and >> > other projects source (which I don't have the time to do) for >> > supplemental information. Is there a site, FAQ, or HowTo somewhere >> > that goes into embedding Boost.Python and utilizing it more >> > thoroughly than the current documentation has? >> >> If the above isn't enough to get you started, you can always contract >> with Boost Consulting for help ;-) > > Also, search this mailing list and download a library which has > already embedded BPL for study. > > You should expect it to take you far longer than your anticipate, but > perserverence will win you through. I took four months myself. To be fair, Niall, lots of people get going in a few days. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From python at cityofdreams.com Thu Sep 2 05:46:16 2004 From: python at cityofdreams.com (Peter) Date: Wed, 01 Sep 2004 23:46:16 -0400 Subject: [C++-sig] PyImport_Import problems with a BOOST_PYTHON_MODULE defined module Message-ID: I solved the initial import problem by defining a global object variable and constructing an instance from that, i.e., object g_Catcher; BOOST_PYTHON_MODULE(RuntimeSupport) { g_Catcher = class_("StdoutCatcher") .def( "write", &StdoutCatcher::write ) ; } Then imported the module and created the class instance: boost::python::str supportModuleName("RuntimeSupport"); handle<> supportModule( PyImport_Import(supportModuleName.ptr()) ); object catcherObj = g_Catcher(); PySys_SetObject("stdout",catcherObj.ptr()); PySys_SetObject("stderr",catcherObj.ptr()); I'm still having problems with the visibility of modules imported PyImport_Import. Python code still does not see these modules, so I have to reimport them in Python. Regards Peter > Thanks to some previous answers plus some intense googling, I've been > able to use a C++ class to capture stdout and stderr. However, I have > encountered a problem with PyImport_Import and a module defined with > BOOST_PYTHON_MODULE. > > I created a StdoutCatcher C++ class (in a module named RuntimeSupport) > and have got to the point where I can use it from within Python ok: > > >>> import sys, RuntimeSupport > >>> sys.stdout = RuntimeSupport.StdoutCatcher() > >>> sys.stderr = RuntimeSupport.StdoutCatcher() > > But my goal is to redirect stdout purely using the C APIs, but I still > have much to learn and have hit a bit of a wall after experimenting all > day. I found that PyImport_Import should accomplish what I want, but > for all my experimenting I just can't get it to work. Below is the code > and it would be great if anyone could critique my use of boost.python > and the Python C API, and point out where I have gone wrong. All > criticism would be very much appreciated. > > Building with MS VC++ 6 on w2k, using Python embedded in the app. > > //********************************************************* > class StdoutCatcher > { > public: > StdoutCatcher() { clear(); } > void write( const std::string& str ) { text_ += str; } > > static const std::string& text(void) { return text_; } > static void clear(void) { text_.erase(); } > > private: > static std::string text_; > }; > std::string StdoutCatcher::text_; > > //********************************************************* > // Python module > BOOST_PYTHON_MODULE(RuntimeSupport) > { > class_("StdoutCatcher") > .def( "write", &StdoutCatcher::write ) > ; > } > > ... initialize everything ... > > PyImport_AppendInittab("RuntimeSupport", initRuntimeSupport); > Py_Initialize(); > mainModule_ = new object(handle<>(borrowed( > PyImport_AddModule("__main__") ) ) ); > mainNamespace_ = new dict(mainModule_->attr("__dict__") ); > > ... everything now works ok if just using Python > ... but I can't get it to work using just API calls, > ... see below > > // import the RuntimeSupport module > // --> I tried all import ways; > // PyImport_ImportModuleEx, PyImport_Import, > // PyImport_ImportModule > boost::python::str supportModuleName("RuntimeSupport"); > handle<> supportModule( > PyImport_Import(supportModuleName.ptr()) ); > > // create an instance of StdoutCatcher > // --> this bit doesn't work and returns NoneType > // --> maybe because PyImport failed? > object catcher = mainNamespace_->get("StdoutCatcher"); > > // --> is there a better way to check for NoneType > // than a strcmp? > PyObject* pObj = catcher.ptr(); > if ( strcmp(pObj->ob_type->tp_name, "NoneType") == 0) > { > // ... why isn't StdoutCatcher being found? > } > else > { > // --> never get to this bit > > // create an instance of StdoutCatcher > object catcherObj = catcher(); > > // set sys.stdout and sys.stderr to the > // StdoutCatcher instance > PySys_SetObject("stdout",catcherObj.ptr()); > PySys_SetObject("stderr",catcherObj.ptr()); > } > > ... so the main question is, why can't I import StdoutCatcher using the > APIs? > > Thanks, > Peter > > > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From python at cityofdreams.com Thu Sep 2 05:59:16 2004 From: python at cityofdreams.com (Peter) Date: Wed, 01 Sep 2004 23:59:16 -0400 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python Message-ID: > Also, search this mailing list and download a library which has > already embedded BPL for study. > > You should expect it to take you far longer than your anticipate, but > perserverence will win you through. I took four months myself. > > Cheers, > Niall I agree. I'm going through the same process of learning how to use the BPL to embed Python and, as soon as you move beyond the basics, be prepared for lots of googling and searching of the email list. I've found you still need to learn the Python C API for many things (or maybe I'm still too much of a beginner to know how to do things the BPL way). I would love it if someone would post links to the source of a number of different projects built using Boost.Python to a significant extent. Cheers, Peter From dave at boost-consulting.com Thu Sep 2 12:24:11 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 02 Sep 2004 06:24:11 -0400 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python References: Message-ID: "Peter" writes: >> Also, search this mailing list and download a library which has >> already embedded BPL for study. >> >> You should expect it to take you far longer than your anticipate, but >> perserverence will win you through. I took four months myself. >> >> Cheers, >> Niall > > I agree. I'm going through the same process of learning how to use the > BPL to embed Python and, as soon as you move beyond the basics, be > prepared for lots of googling and searching of the email list. I've > found you still need to learn the Python C API for many things (or maybe > I'm still too much of a beginner to know how to do things the BPL way). > > I would love it if someone would post links to the source of a number of > different projects built using Boost.Python to a significant extent. The contents of libs/python/test in your Boost distribution shows just about everything the library knows how to do. Did you look at those files? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From python at cityofdreams.com Thu Sep 2 12:45:13 2004 From: python at cityofdreams.com (Peter) Date: Thu, 02 Sep 2004 06:45:13 -0400 Subject: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Python Message-ID: > The contents of libs/python/test in your Boost distribution shows just > about everything the library knows how to do. Did you look at those > files? I... uh... I have now. From ostiguy at fnal.gov Thu Sep 2 16:50:11 2004 From: ostiguy at fnal.gov (Francois Ostiguy) Date: Thu, 2 Sep 2004 09:50:11 -0500 (CDT) Subject: [C++-sig] numarray 1.0 and BPL - resolution Message-ID: For the benefit of those who might encounter the same problem I did, I am re-posting the last message I received from Dave. For some reason this final reply was not automatically archived yesterday (at least not on the ActiveState hosted archive). Francois Ostiguy writes: > the code that works for me is exactly as follows: > > > long array_base::nelements() const > { > return extract( attr("nelements")() ); > } > > > I make no claim about correctness ... I am not familiar enough with the > low level details of BPL. It's correct. > What is certain is that the current code > > long array_base::nelements() const > { > return extract( attr("nelements") ); > } > ^^^^ > i.e. without operator() > > does not work (numarray 1.0/bpl 1_31/gcc-3.3.3). I can find no evidence that numeric ever used a different interface. > The error message: > > TypeError: No registered converter was able to produce a C++ rvalue of > type long from this Python object of type builtin_function_or_method. > > seems to be generated because attr("nelements") returns a callable > PyObject* that cannot be converted to a long. > > > The relevant function from the numarray code (1.0) seems to be > > static PyObject * > _ndarray_nelements(PyArrayObject *self, PyObject *args) > { > if (!PyArg_ParseTuple(args, ":nelements")) > return NULL; > return PyInt_FromLong(NA_elements(self)); > } I'll check in the fix. Thanks! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From s_sourceforge at nedprod.com Thu Sep 2 20:32:06 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 02 Sep 2004 19:32:06 +0100 Subject: How long did it take you to integrate BPL into your app? (was: Re: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to In-Reply-To: Message-ID: <41377536.4.B4F9C0F@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1 Sep 2004 at 21:01, David Abrahams wrote: > > You should expect it to take you far longer than your anticipate, > > but perserverence will win you through. I took four months myself. > > To be fair, Niall, lots of people get going in a few days. Oh I got going in a few days too, but once one starts doing things which the docs & examples don't directly explain one runs into a very steep learning curve. Out of interest, has anyone on this list fully integrated BPL into their application in less than 140 hours (one man month)? I mean from start to completion here. If it is an open source application, please give us the application's home page. Any replies will be the basis of a new page listing good examples of real world applications of BPL. I shall personally construct such a page and send it in to be applied against CVS head if there are any answers and I think from inspection of the source it has been correctly done. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQTdnJsEcvDLFGKbPEQI0YgCaA61tNQsVAxGtzZ7HswQyPbkKLTQAoJeb Jr6dXQAOfaSbh02EfTW99Qg1 =a1SM -----END PGP SIGNATURE----- From MKhesin at liquidnet.com Thu Sep 2 21:58:51 2004 From: MKhesin at liquidnet.com (Max Khesin) Date: Thu, 2 Sep 2004 15:58:51 -0400 Subject: How long did it take you to integrate BPL into your app? (was : Re: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to Message-ID: <4B6FB7F60D37D41188C300B0D022E0C003050B74@exchange.lnholdings.com> When I initially wrapped a C++ API for one of my previous jobs in pyhton it took less than an hour. Embedding was harder and took a few days. I agree that the docs could be improved, especially the embedding docs. But it is also true that with a library so internally complicated as BPL docs have limited value, and that's where this list comes in. max. > > > You should expect it to take you far longer than your anticipate, > > > but perserverence will win you through. I took four months myself. > > > > To be fair, Niall, lots of people get going in a few days. > > Oh I got going in a few days too, but once one starts doing things > which the docs & examples don't directly explain one runs into a very > steep learning curve. > > Out of interest, has anyone on this list fully integrated BPL into > their application in less than 140 hours (one man month)? I mean from > start to completion here. If it is an open source application, please > give us the application's home page. > > Any replies will be the basis of a new page listing good examples of > real world applications of BPL. I shall personally construct such a > page and send it in to be applied against CVS head if there are any > answers and I think from inspection of the source it has been > correctly done. > > Cheers, > Niall > > > > > > -----BEGIN PGP SIGNATURE----- > Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 > > iQA/AwUBQTdnJsEcvDLFGKbPEQI0YgCaA61tNQsVAxGtzZ7HswQyPbkKLTQAoJeb > Jr6dXQAOfaSbh02EfTW99Qg1 > =a1SM > -----END PGP SIGNATURE----- > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicodemus at esss.com.br Thu Sep 2 23:27:29 2004 From: nicodemus at esss.com.br (Nicodemus) Date: Thu, 02 Sep 2004 18:27:29 -0300 Subject: [C++-sig] Pyste docstring support ? In-Reply-To: <8da04e6704083009213834fbbd@mail.gmail.com> References: <8da04e6704083009213834fbbd@mail.gmail.com> Message-ID: <41379041.1050401@esss.com.br> Hi, Could you please point me to the relevant thread? Thanks, Nicodemus. Kaben Nanlohy wrote: >Hi; > >On this mailing list I have seen a patch to Boost.Python's Pyste >providing some docstring support, but the patch does not appear to >have been incorporated into cvs. Why is that ? > >Thanks -- K > > > From kaben.nanlohy at gmail.com Fri Sep 3 00:04:45 2004 From: kaben.nanlohy at gmail.com (Kaben Nanlohy) Date: Thu, 2 Sep 2004 18:04:45 -0400 Subject: [C++-sig] Pyste docstring support ? In-Reply-To: <41379041.1050401@esss.com.br> References: <8da04e6704083009213834fbbd@mail.gmail.com> <41379041.1050401@esss.com.br> Message-ID: <8da04e6704090215047b33c338@mail.gmail.com> Certainly : http://mail.python.org/pipermail/c++-sig/2004-January/006691.html The patch there mentioned documents only classes and functions, not member functions. Perhaps that is good reason. On Thu, 02 Sep 2004 18:27:29 -0300, Nicodemus wrote: > Hi, > > Could you please point me to the relevant thread? > > Thanks, > Nicodemus. > > Kaben Nanlohy wrote: > > >On this mailing list I have seen a patch to Boost.Python's Pyste > >providing some docstring support, but the patch does not appear to > >have been incorporated into cvs. Why is that ? -- to contact me, use gmail.00 at kaben.stochastic.net to contact me without your email entering my gmail archive, use no.gmail.00 at kaben.stochastic.net to cause your email to be trashed, unread, use kaben.nanlohy at gmail.com to propose, use I.want.to.have.your.baby.00 at kaben.stochastic.net to tell me I'm weird, use you.complete.freak.00 at kaben.stochastic.net From caustin at gmail.com Fri Sep 3 07:25:05 2004 From: caustin at gmail.com (Chad Austin) Date: Fri, 3 Sep 2004 00:25:05 -0500 Subject: How long did it take you to integrate BPL into your app? (was: Re: [C++-sig] Re: Embedding Boost.Python and Exposing Classes to In-Reply-To: <41377536.4.B4F9C0F@localhost> References: <41377536.4.B4F9C0F@localhost> Message-ID: <2096514e04090222257621e0d3@mail.gmail.com> > Oh I got going in a few days too, but once one starts doing things > which the docs & examples don't directly explain one runs into a very > steep learning curve. Agreed! It's easy to get something to work, but it's somewhat difficult to figure out some of the subtle issues... (Like the fact that Cygwin gcc is trying to allocate over 4 GB of RAM when linking my current app...) The documentation for some of the less commonly-used things like register_ptr_to_python is a little sparse, IMO. > Out of interest, has anyone on this list fully integrated BPL into > their application in less than 140 hours (one man month)? I mean from > start to completion here. If it is an open source application, please > give us the application's home page. It took about a week or two to get the components I planned to export to Python working. Eventually I'll be exporting a lot more. Project is http://empyrean.sourceforge.net/ > Any replies will be the basis of a new page listing good examples of > real world applications of BPL. I shall personally construct such a > page and send it in to be applied against CVS head if there are any > answers and I think from inspection of the source it has been > correctly done. Sounds like a good thing to have. Thanks Niall, Chad From s_sourceforge at nedprod.com Fri Sep 3 20:25:13 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 03 Sep 2004 19:25:13 +0100 Subject: How long did it take you to integrate BPL into your app? (was: Re: [C++-sig] Re: Embedding Boost.Python and Exposing Classe In-Reply-To: <2096514e04090222257621e0d3@mail.gmail.com> References: <41377536.4.B4F9C0F@localhost> Message-ID: <4138C519.15089.106FAD87@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3 Sep 2004 at 0:25, Chad Austin wrote: > It took about a week or two to get the components I planned to export > to Python working. Eventually I'll be exporting a lot more. Project > is http://empyrean.sourceforge.net/ Unfortunately this project comes with no recent source code and it's also not very mature. Any other working example of BPL suggestions? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQTi3CsEcvDLFGKbPEQLrSgCfYwrcmdYhSefKuZXbrtGlJImY/4QAmwWl tcTwfm5OvSaUDRNj1wSky1iN =Wkbc -----END PGP SIGNATURE----- From jmastro at rochester.rr.com Fri Sep 3 21:49:05 2004 From: jmastro at rochester.rr.com (Jim) Date: Fri, 3 Sep 2004 15:49:05 -0400 Subject: [C++-sig] Returning shared_ptr to Python Message-ID: <001601c491ef$122d81c0$2602a8c0@jimswindows> Hi list. Here's my latest problem, that I may actually have solved. My C++ code keeps it's boost::python::object's (BPO's) in shared_ptr's. (My problem isn't wrapping C++ types in shared_ptr's, but just BPO's in shared_ptr's and getting the Python object out for use in Python.) I need to return the Python object to Python, and have the Python scripts call arbitrary methods in them. This works perfectly if I just return a boost::python::object by value, like this: boost::python::object ReturnBPO() { using namespace boost::python; object scriptModule = object( handle<>( PyImport_ImportModule("MyScript") ) ); object theClass = scriptModule.attr("MyScript"); // create a MyScript.MyScript Python object return object( theClass() ); } In Python, I can then do: obj = SomeModule.ReturnBPO() obj.call_something() and everything works fine...but not really useful because my BPO's are in shared_ptr's. This is what I came up with. I would like to know if it's a good solution. It seems to work fine. In my extension module code, I put this: typedef boost::shared_ptr ScriptObjectPtr; struct ScriptObjectPtr_to_PyObject { static PyObject* convert(ScriptObjectPtr const& x) { boost::python::object * bpo = x.get(); // get the BPO* from the shared_ptr PyObject* p = bpo->ptr(); // get PyObject* from BPO Py_INCREF( p ); // If I don't have this here, it crashes return p; } }; void export_Stuff() { to_python_converter(); } This works fine. It appears that without the Py_INCREF call, the Python object gets released soon after I return it (based on print statements). Is this the best way to do what I'm trying to do? I wouldn't be surprised if there's a simpler solution that I'm missing. I guess I also could change my C++ interface to do what convert is doing without doing it in the extension module, too. Any input very much appreciated. -jim From caustin at gmail.com Sat Sep 4 00:53:55 2004 From: caustin at gmail.com (Chad Austin) Date: Fri, 3 Sep 2004 17:53:55 -0500 Subject: How long did it take you to integrate BPL into your app? (was: Re: [C++-sig] Re: Embedding Boost.Python and Exposing Classe In-Reply-To: <4138C519.15089.106FAD87@localhost> References: <41377536.4.B4F9C0F@localhost> <2096514e04090222257621e0d3@mail.gmail.com> <4138C519.15089.106FAD87@localhost> Message-ID: <2096514e040903155323888071@mail.gmail.com> On Fri, 03 Sep 2004 19:25:13 +0100, Niall Douglas wrote: > On 3 Sep 2004 at 0:25, Chad Austin wrote: > > It took about a week or two to get the components I planned to export > > to Python working. Eventually I'll be exporting a lot more. Project > > is http://empyrean.sourceforge.net/ > > Unfortunately this project comes with no recent source code and it's > also not very mature. I'm trying to keep it relatively low-key until after the Independent Games Festival submission in November. No recent source code? The CVS repository is actively updated. What exactly are you looking for? From jmastro at rochester.rr.com Sat Sep 4 09:16:10 2004 From: jmastro at rochester.rr.com (Jim) Date: Sat, 4 Sep 2004 03:16:10 -0400 Subject: [C++-sig] Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> Message-ID: <003c01c4924f$0dee9df0$2602a8c0@jimswindows> > I need to return the Python object to Python, and have the Python scripts call arbitrary methods > in them. I also need to pass the PyObject* I pulled out of the boost::python::object back to the C++ code. I have no clue how to do this. Trying to call a C++ function expecting a shared_ptr and a Point results in this output: Boost.Python.ArgumentError: Python argument types in MyClass.MyMethod(MyClass, instance, Point) did not match C++ signature: MyMethod(class Module::Class {lvalue}, class boost::shared_ptr {lvalue}, class Point) and unfortunately I'm not sure what to do to pass the object back to C++. I _must_ be going about this all wrong. Help? -jim From dave at boost-consulting.com Sat Sep 4 15:52:28 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 04 Sep 2004 09:52:28 -0400 Subject: [C++-sig] Re: Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> Message-ID: "Jim" writes: > Hi list. Here's my latest problem, that I may actually have > solved. My C++ code keeps it's boost::python::object's (BPO's) in > shared_ptr's. > (My problem isn't wrapping C++ types in shared_ptr's, but just BPO's > in shared_ptr's Doesn't surprise me! boost::shared_ptr ? That seems like a terrible idea to me. boost::python::object already maintains the Python object it holds by reference-counting. shared_ptr adds another layer of reference counting. I can't imagine a good reason for it. > and getting the Python object out for use in Python.) I need to > return the Python object to Python, and have the Python scripts call > arbitrary methods in them. Well, if you really must, just give your wrapped C++ functions return types of boost::python::object, and use return *p; where p is a boost::shared_ptr... But as I've said it sounds like a terrible idea to me. > This works perfectly if I just return a boost::python::object by > value, like this: > > boost::python::object > ReturnBPO() > { > using namespace boost::python; > object scriptModule = object( handle<>( > PyImport_ImportModule("MyScript") ) ); > object theClass = scriptModule.attr("MyScript"); // create a > MyScript.MyScript Python object > return object( theClass() ); > } > > In Python, I can then do: > obj = SomeModule.ReturnBPO() > obj.call_something() > > and everything works fine... As it should. > but not really useful because my BPO's are in shared_ptr's. But... why? > This is what I came up with. I would like to know if it's a good > solution. It seems to work fine. In my extension module code, I put > this: > > typedef boost::shared_ptr ScriptObjectPtr; > > struct ScriptObjectPtr_to_PyObject > { > static PyObject* convert(ScriptObjectPtr const& x) > { > boost::python::object * bpo = x.get(); // get the BPO* from the > shared_ptr > PyObject* p = bpo->ptr(); // get PyObject* from > BPO > Py_INCREF( p ); // If I don't have > this here, it crashes > return p; > } > }; > > void export_Stuff() > { > to_python_converter(); > } > > > This works fine. It's not the slickest way to code it, though I guess you can do that. But... why? > It appears that without the Py_INCREF call, the Python object gets > released soon after I return it (based on print statements). Is this > the best way to do what I'm trying to do? Not quite, but I still don't understand why you are trying to do that. > I wouldn't be surprised if there's a simpler solution that I'm > missing. I guess I also could change my C++ interface to do what > convert is doing without doing it in the extension module, too. > > Any input very much appreciated. Drop the use of shared_ptr for this purpose? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Sat Sep 4 15:54:39 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 04 Sep 2004 09:54:39 -0400 Subject: [C++-sig] Re: Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> <003c01c4924f$0dee9df0$2602a8c0@jimswindows> Message-ID: "Jim" writes: >> I need to return the Python object to Python, and have the Python scripts > call arbitrary methods >> in them. > > I also need to pass the PyObject* I pulled out of the boost::python::object > back to the C++ code. I have no clue how to do this. Trying to call a C++ > function expecting a shared_ptr and a Point results > in this output: > > Boost.Python.ArgumentError: Python argument types in > MyClass.MyMethod(MyClass, instance, Point) > did not match C++ signature: > MyMethod(class Module::Class {lvalue}, class boost::shared_ptr boost::python::api::object> {lvalue}, class Point) > > and unfortunately I'm not sure what to do to pass the object back to C++. I > _must_ be going about this all wrong. Help? Well, you could register a from-python conversion for boost::shared_ptr, but my sense is that you're going to drop the use of shared_ptr... or boost::python::object... pretty soon. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From jmastro at rochester.rr.com Sat Sep 4 17:02:02 2004 From: jmastro at rochester.rr.com (Jim) Date: Sat, 4 Sep 2004 11:02:02 -0400 Subject: [C++-sig] Re: Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> Message-ID: <001901c49290$2305dff0$2602a8c0@jimswindows> David Abrahams wrote: > boost::shared_ptr ? > > That seems like a terrible idea to me. boost::python::object already > maintains the Python object it holds by reference-counting. > shared_ptr adds another layer of reference counting. I can't imagine > a good reason for it. My reason was to get some kind of ref counting on it, because before I started with Boost.Python, the objects that are now Python objects were just C++ objects and needed shared_ptr. So I just stupidly changed shared_ptr to shared_ptr without thinking about it when I started with Boost.Python. Now I see that it's unnecessary to ref count since object already does so, but probably didn't when I wrote that. Thanks for straightening me out again. -jim From dave at boost-consulting.com Sun Sep 5 00:44:32 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 04 Sep 2004 18:44:32 -0400 Subject: [C++-sig] Re: Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> <001901c49290$2305dff0$2602a8c0@jimswindows> Message-ID: "Jim" writes: > David Abrahams wrote: >> boost::shared_ptr ? >> >> That seems like a terrible idea to me. boost::python::object already >> maintains the Python object it holds by reference-counting. >> shared_ptr adds another layer of reference counting. I can't imagine >> a good reason for it. > > My reason was to get some kind of ref counting on it, because before I > started with Boost.Python, the objects that are now Python objects were just > C++ objects and needed shared_ptr. So I just stupidly changed > shared_ptr to shared_ptr without > thinking about it when I started with Boost.Python. Now I see that it's > unnecessary to ref count since object already does so, but probably didn't > when I wrote that. Thanks for straightening me out again. Sure. But if you really have MyCPPObject instances (or instances of something derived from MyCPPObject in Python), it might be a good idea to stick with shared_ptr instead... just FWIW. -Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From jmastro at rochester.rr.com Sun Sep 5 04:37:37 2004 From: jmastro at rochester.rr.com (Jim) Date: Sat, 4 Sep 2004 22:37:37 -0400 Subject: [C++-sig] Re: Returning shared_ptr to Python References: <001601c491ef$122d81c0$2602a8c0@jimswindows> <001901c49290$2305dff0$2602a8c0@jimswindows> Message-ID: <001301c492f1$4eaf9540$2602a8c0@jimswindows> David Abrahams wrote: > Sure. But if you really have MyCPPObject instances (or instances of > something derived from MyCPPObject in Python), it might be a good > idea to stick with shared_ptr instead... just FWIW. Right now I don't, but I might eventually have a C++ base class for all my Python objects of this type, so yeah, the shared_ptr may reappear here. BTW, after getting rid of the shared_ptr business and just using lists of object's, everything's up and running great again. I didn't really say what I was doing in my post, but basically I got the bright idea not too long ago that I was going to rewrite some tools of mine in Python (using wxPython), which meant my game engine had to be wrapped up with boost.python so the scripts could use it. It's worked out great so far. -jim From serial at 12-218-67-203.client.mchsi.com Tue Sep 7 08:16:30 2004 From: serial at 12-218-67-203.client.mchsi.com (serial at 12-218-67-203.client.mchsi.com) Date: Tue, 07 Sep 2004 06:16:30 +0000 Subject: [C++-sig] updates In-Reply-To: References: Message-ID: <236J6185FD95G4A9@12-218-67-203.client.mchsi.com> Adobe Illustrator CS - 90 Adobe Illustrator CS - 90 Quark Express 6.0 - 60 Office 2003 Professional - 110 Borland Delphi 7 Professional - 70 Microsoft Windows 2000 Professional - 50 Quark Express 6.0 - 60 Microsoft SQL Server 2000 Enterprise Edition - 200 Borland Delphi 7 Professional - 70 Adobe Illustrator CS - 90 and a lot more http://www.alloembest.info/ From sseefeld at art.ca Tue Sep 7 20:40:07 2004 From: sseefeld at art.ca (Stefan Seefeld) Date: Tue, 7 Sep 2004 14:40:07 -0400 Subject: [C++-sig] using user-defined metaclasses with boost.python Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA974C@MTL-EXCHANGE> hi there, is it possible to provide a user-defined metaclass for python classes generated via boost.python ? As far as I can see boost.python defines its own metaclass, so I would expect to have to derive from that. But where can I inject it to make it accessible to my own types ? Thanks, Stefan From dave at boost-consulting.com Tue Sep 7 21:29:30 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 07 Sep 2004 15:29:30 -0400 Subject: [C++-sig] Re: using user-defined metaclasses with boost.python References: <20DCDD8F0FCED411AC4D001083CF504501AA974C@MTL-EXCHANGE> Message-ID: Stefan Seefeld writes: > hi there, > > is it possible to provide a user-defined metaclass > for python classes generated via boost.python ? > As far as I can see boost.python defines its own > metaclass, so I would expect to have to derive from > that. But where can I inject it to make it accessible > to my own types ? I don't understand what you mean by "inject it." Do you want to control the metaclass of the classes wrapped with Boost.Python, or only some classes derived from wrapped classes in Python? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From sseefeld at art.ca Tue Sep 7 21:57:55 2004 From: sseefeld at art.ca (Stefan Seefeld) Date: Tue, 7 Sep 2004 15:57:55 -0400 Subject: [C++-sig] Re: using user-defined metaclasses with boost.pytho n Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA974D@MTL-EXCHANGE> > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: September 7, 2004 15:30 > I don't understand what you mean by "inject it." Do you want to > control the metaclass of the classes wrapped with Boost.Python, or > only some classes derived from wrapped classes in Python? Sorry for not being clear. I'm wondering whether it is possible to derive from boost.python's metaclass to influence class (instance) generation of wrapper classes themselfs. Is that possible at all ? Thanks, Stefan From dave at boost-consulting.com Tue Sep 7 23:18:24 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 07 Sep 2004 17:18:24 -0400 Subject: [C++-sig] Re: using user-defined metaclasses with boost.pytho n References: <20DCDD8F0FCED411AC4D001083CF504501AA974D@MTL-EXCHANGE> Message-ID: Stefan Seefeld writes: >> From: David Abrahams [mailto:dave at boost-consulting.com] >> Sent: September 7, 2004 15:30 > >> I don't understand what you mean by "inject it." Do you want to >> control the metaclass of the classes wrapped with Boost.Python, or >> only some classes derived from wrapped classes in Python? > > Sorry for not being clear. I'm wondering whether it is possible > to derive from boost.python's metaclass to influence class (instance) > generation of wrapper classes themselfs. Is that possible at all ? Conceivably it's possible, but it would require changes to the C++ code of Boost.Python. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From mark.rowe at gmail.com Tue Sep 7 23:35:20 2004 From: mark.rowe at gmail.com (Mark Rowe) Date: Wed, 8 Sep 2004 09:35:20 +1200 Subject: [C++-sig] Building/testing extensions: boost-python-runtest Message-ID: <7074ab3d04090714356663fe50@mail.gmail.com> Hi, I am using boost::python to wrap a C++ library primarily so that I can write unit tests for it in Python. Inside the python/ directory of my project I have unit tests named similar to test_A.py, test_B.py, that are run by a driver script named test.py. My problem is that when building and testing the code with bjam, the unit tests are not re-run if a change is made to test_*.py. The are re-run correctly if test.py itself is changed. Any information on how to add this type of dependency to the Jamfile would be appreciated. The relevant snippet from my Jamfile is: # Declare a test for the extension module boost-python-runtest testFoo : # Python test driver test.py # extension modules to use Foo ; Regards, Mark Rowe From dave at boost-consulting.com Wed Sep 8 13:38:53 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 08 Sep 2004 07:38:53 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <7074ab3d04090714356663fe50@mail.gmail.com> Message-ID: Mark Rowe writes: > Hi, > > I am using boost::python to wrap a C++ library primarily so that I can > write unit tests for it in Python. Inside the python/ directory of my > project I have unit tests named similar to test_A.py, test_B.py, that > are run by a driver script named test.py. My problem is that when > building and testing the code with bjam, the unit tests are not re-run > if a change is made to test_*.py. The are re-run correctly if test.py > itself is changed. Any information on how to add this type of > dependency to the Jamfile would be appreciated. > > The relevant snippet from my Jamfile is: > > # Declare a test for the extension module > boost-python-runtest testFoo > : # Python test driver > test.py > # extension modules to use > Foo > ; Try using this version of the rule instead, which allows you to list any number of python files in any order. If it works, let me know and I'll check it in. ---- rule boost-python-runtest ( target : sources + : requirements * : local-build * : args * ) { local gRUN_TEST_ARGS = $(args) ; local pyfiles = [ MATCH ^(.*[.]py)$ : $(sources) ] ; sources = [ difference $(sources) : $(pyfiles) ] ; local gRUN_TEST_INPUT_FILES = [ FGristFiles $(pyfiles) ] ; # tell Jam that the python script is relative to this directory SEARCH on $(gRUN_TEST_INPUT_FILES) = $(SEARCH_SOURCE) ; # The user can add additional arguments in PYTHON_TEST_ARGS. local gRUN_TEST_ARGS2 = $(PYTHON_TEST_ARGS) ; gRUN_TEST_ARGS2 ?= -v ; # # Stick the names of the python script and source files used in # testing into $(source-files) on the main target. This is kind # of a hack, because boost-test will be returning the name of the # main target, but unfortunatedly dump-tests runs during the # evaluation of boost-test and not during the build phase :( # local main-target = [ FGristFiles [ expand-target-names $(target) : RUN_PYD ] ] ; source-files on $(main-target) = $(gRUN_TEST_INPUT_FILES) ; local dependencies = [ FGristFiles [ expand-source-names $(sources) ] ] ; source-files on $(main-target) += $(gTARGET_SOURCES($(dependencies))) ; local result = [ boost-test $(sources) : RUN_PYD : $(requirements) boost-python-disable-borland python-intel-use-gcc-stdlib # unless otherwise # specified, assume the GCC standard # library is needed for intel : $(target) : $(local-build) ] ; } -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ndbecker2 at verizon.net Wed Sep 8 14:08:47 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 08 Sep 2004 08:08:47 -0400 Subject: [C++-sig] import from c++? Message-ID: I have 2 modules written with boost::python. I have module A that exposes a class a, and now module B needs a. If a python program then imports A and B, it works fine. My question is, is there some way I can add code to the boost:python module B to cause importing of A? From mark.rowe at gmail.com Wed Sep 8 14:40:25 2004 From: mark.rowe at gmail.com (Mark Rowe) Date: Thu, 9 Sep 2004 00:40:25 +1200 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest In-Reply-To: References: <7074ab3d04090714356663fe50@mail.gmail.com> Message-ID: <7074ab3d040908054039458090@mail.gmail.com> On Wed, 08 Sep 2004 07:38:53 -0400, David Abrahams wrote: > > Try using this version of the rule instead, which allows you to list > any number of python files in any order. If it works, let me know and > I'll check it in. Thanks David, this seems to work fine. Regards, Mark Rowe From ndbecker2 at verizon.net Wed Sep 8 14:45:51 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 08 Sep 2004 08:45:51 -0400 Subject: [C++-sig] Re: Re: Building/testing extensions: boost-python-runtest References: <7074ab3d04090714356663fe50@mail.gmail.com> <7074ab3d040908054039458090@mail.gmail.com> Message-ID: Mark Rowe wrote: > On Wed, 08 Sep 2004 07:38:53 -0400, David Abrahams > wrote: >> >> Try using this version of the rule instead, which allows you to list >> any number of python files in any order. If it works, let me know and >> I'll check it in. > > Thanks David, this seems to work fine. > Anyone who likes python might want to try scons. It's really easy to build python extensions with scons. Here is an example that would build uvector.so: BOOST_VERSION = 'boost.cvs' BOOST = '/usr/local/src/' + BOOST_VERSION BOOSTLIBPATH = BOOST+'/stage/lib' env = Environment (LIBPATH=['./',BOOSTLIBPATH], CPPPATH=[BOOST, '/usr/include/python2.3'], RPATH=['./',BOOSTLIBPATH]) env.SharedLibrary (target='uvector', source='uvector.cc', SHLIBPREFIX='', LIBS=[BOOST_PYTHON_LIB]) From dave at boost-consulting.com Wed Sep 8 15:00:16 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 08 Sep 2004 09:00:16 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <7074ab3d04090714356663fe50@mail.gmail.com> <7074ab3d040908054039458090@mail.gmail.com> Message-ID: "Neal D. Becker" writes: > Mark Rowe wrote: > >> On Wed, 08 Sep 2004 07:38:53 -0400, David Abrahams >> wrote: >>> >>> Try using this version of the rule instead, which allows you to list >>> any number of python files in any order. If it works, let me know and >>> I'll check it in. >> >> Thanks David, this seems to work fine. >> > > Anyone who likes python might want to try scons. > > It's really easy to build python extensions with scons. Here is an example > that would build uvector.so: > > BOOST_VERSION = 'boost.cvs' > BOOST = '/usr/local/src/' + BOOST_VERSION > BOOSTLIBPATH = BOOST+'/stage/lib' > env = Environment (LIBPATH=['./',BOOSTLIBPATH], CPPPATH=[BOOST, > '/usr/include/python2.3'], RPATH=['./',BOOSTLIBPATH]) > env.SharedLibrary (target='uvector', source='uvector.cc', SHLIBPREFIX='', > LIBS=[BOOST_PYTHON_LIB]) For which compilers/platforms does that combination of environment variables work? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ndbecker2 at verizon.net Wed Sep 8 14:55:45 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 08 Sep 2004 08:55:45 -0400 Subject: [C++-sig] serialization Message-ID: Now serialization will hopefully be part of boost soon. It would be good to share a single serialization implementation, so that a class could be serialized in c++ using boost or by python. Here is one way to achieve this. Assume template void serialize(Archive & ar, const unsigned int version); is added to your class. Then an easy way to use this from boost::python is to serialize to a stringstream, and pickle the resulting string. Here is an example: struct mt_pickle_suite : python::pickle_suite { static python::object getstate (rng_t& rng) { std::ostringstream os; boost::archive::binary_oarchive oa(os); oa << rng; return python::str (os.str()); } static void setstate(rng_t& rng, python::object entries) { python::str s = python::extract (entries)(); std::string st = python::extract (s)(); std::istringstream is (st); boost::archive::binary_iarchive ia (is); ia >> rng; } }; From dave at boost-consulting.com Wed Sep 8 15:01:02 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 08 Sep 2004 09:01:02 -0400 Subject: [C++-sig] Re: import from c++? References: Message-ID: "Neal D. Becker" writes: > I have 2 modules written with boost::python. > > I have module A that exposes a class a, and now module B needs a. If a > python program then imports A and B, it works fine. My question is, is > there some way I can add code to the boost:python module B to cause > importing of A? PyRun_String("import a") or whatever? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From ndbecker2 at verizon.net Wed Sep 8 15:24:29 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 08 Sep 2004 09:24:29 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <7074ab3d04090714356663fe50@mail.gmail.com> <7074ab3d040908054039458090@mail.gmail.com> Message-ID: David Abrahams wrote: > "Neal D. Becker" writes: > >> Mark Rowe wrote: >> >>> On Wed, 08 Sep 2004 07:38:53 -0400, David Abrahams >>> wrote: >>>> >>>> Try using this version of the rule instead, which allows you to list >>>> any number of python files in any order. If it works, let me know and >>>> I'll check it in. >>> >>> Thanks David, this seems to work fine. >>> >> >> Anyone who likes python might want to try scons. >> >> It's really easy to build python extensions with scons. Here is an >> example that would build uvector.so: >> >> BOOST_VERSION = 'boost.cvs' >> BOOST = '/usr/local/src/' + BOOST_VERSION >> BOOSTLIBPATH = BOOST+'/stage/lib' >> env = Environment (LIBPATH=['./',BOOSTLIBPATH], CPPPATH=[BOOST, >> '/usr/include/python2.3'], RPATH=['./',BOOSTLIBPATH]) >> env.SharedLibrary (target='uvector', source='uvector.cc', SHLIBPREFIX='', >> LIBS=[BOOST_PYTHON_LIB]) > > For which compilers/platforms does that combination of environment > variables work? > I'm using this on Linux Fedora core2, gcc is gcc-3.3.3 (don't think that matters much). For anyone not familiar with scons, scons is written in python. The "makefile" equivalents are actually python scripts, so you can do anything in them that you could do with python. (The env variables referred to above are scons env variables, not os env variables) From ndbecker2 at verizon.net Wed Sep 8 16:09:43 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 08 Sep 2004 10:09:43 -0400 Subject: [C++-sig] Re: import from c++? References: Message-ID: David Abrahams wrote: > "Neal D. Becker" writes: > >> I have 2 modules written with boost::python. >> >> I have module A that exposes a class a, and now module B needs a. If a >> python program then imports A and B, it works fine. My question is, is >> there some way I can add code to the boost:python module B to cause >> importing of A? > > PyRun_String("import a") > > or whatever? > BOOST_PYTHON_MODULE(whatever) { // PyRun_SimpleString("import a"); << this works PyImport_Import (str ("a").ptr()); << even better I think From dave at boost-consulting.com Wed Sep 8 19:43:29 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 08 Sep 2004 13:43:29 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <7074ab3d04090714356663fe50@mail.gmail.com> <7074ab3d040908054039458090@mail.gmail.com> Message-ID: "Neal D. Becker" writes: > David Abrahams wrote: > >> "Neal D. Becker" writes: >> >>> Mark Rowe wrote: >>> >>>> On Wed, 08 Sep 2004 07:38:53 -0400, David Abrahams >>>> wrote: >>>>> >>>>> Try using this version of the rule instead, which allows you to list >>>>> any number of python files in any order. If it works, let me know and >>>>> I'll check it in. >>>> >>>> Thanks David, this seems to work fine. >>>> >>> >>> Anyone who likes python might want to try scons. >>> >>> It's really easy to build python extensions with scons. Here is an >>> example that would build uvector.so: >>> >>> BOOST_VERSION = 'boost.cvs' >>> BOOST = '/usr/local/src/' + BOOST_VERSION >>> BOOSTLIBPATH = BOOST+'/stage/lib' >>> env = Environment (LIBPATH=['./',BOOSTLIBPATH], CPPPATH=[BOOST, >>> '/usr/include/python2.3'], RPATH=['./',BOOSTLIBPATH]) >>> env.SharedLibrary (target='uvector', source='uvector.cc', SHLIBPREFIX='', >>> LIBS=[BOOST_PYTHON_LIB]) >> >> For which compilers/platforms does that combination of environment >> variables work? >> > > I'm using this on Linux Fedora core2, gcc is gcc-3.3.3 (don't think that > matters much). The same Scons file will work with vc6, vc7, vc7.1, metrowerks, intel, ...? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From s_sourceforge at nedprod.com Wed Sep 8 23:26:28 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 08 Sep 2004 22:26:28 +0100 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest In-Reply-To: Message-ID: <413F8714.14844.FD358D6@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8 Sep 2004 at 13:43, David Abrahams wrote: > >> For which compilers/platforms does that combination of environment > >> variables work? For simple programs, all of them. Actually Neal's scons file is far too long, scons can read most of that stuff from environment variables. And since it's python, you'd just write an "includeBoost()" function. > > I'm using this on Linux Fedora core2, gcc is gcc-3.3.3 (don't think > > that matters much). > > The same Scons file will work with vc6, vc7, vc7.1, metrowerks, > intel, ...? All the MSVC's though v8 may be a little shaky. I've hacked together an ICC support file which is still pending merging to CVS. It's very easy to add support for a new system/toolkit or indeed new builders. scons knows what compilers you have on your system and automatically chooses one, configuring everything for you. You just tell it what files go into what libraries/executables and scons does the rest. In the scons files for TnFOX, they are identical on Linux and Win32 except for the really nasty hacks I've inserted to make it work inside VMWare off the same source tree. I do have a per-compiler directory with per-compiler .py files which sets per-compiler command line options but other than that it's literally that easy. I've been recommending scons to replace MSVC's own build system and everyone who has agrees it's superior (even those who don't need a cross-platform build system). You get to stay inside MSVC just the build button now invokes scons. BTW anyone who is getting annoyed by scons taking more than five seconds to compute, I hacked in an invocation of psyco and it's now instantaneous! Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQT95BMEcvDLFGKbPEQKXIwCfVIyRVuDAIjb/LK9Ku4ri/KjlmKYAn2LE 2HaHho7QwvaPF/WZMoGO5Opq =XE2O -----END PGP SIGNATURE----- From dave at boost-consulting.com Thu Sep 9 19:01:51 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 09 Sep 2004 13:01:51 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <413F8714.14844.FD358D6@localhost> Message-ID: "Niall Douglas" writes: > On 8 Sep 2004 at 13:43, David Abrahams wrote: > >> >> For which compilers/platforms does that combination of environment >> >> variables work? > > For simple programs, all of them. Boost.Python isn't simple, though. > Actually Neal's scons file is far > too long, scons can read most of that stuff from environment > variables. And since it's python, you'd just write an > "includeBoost()" function. So you have to set up a bunch of environment variables that describe the specifics of how to use those compilers? >> > I'm using this on Linux Fedora core2, gcc is gcc-3.3.3 (don't think >> > that matters much). >> >> The same Scons file will work with vc6, vc7, vc7.1, metrowerks, >> intel, ...? > > All the MSVC's though v8 may be a little shaky. I've hacked together > an ICC support file which is still pending merging to CVS. It's very > easy to add support for a new system/toolkit or indeed new builders. > > scons knows what compilers you have on your system and automatically > chooses one, configuring everything for you. You just tell it what > files go into what libraries/executables and scons does the rest. > > In the scons files for TnFOX, they are identical on Linux and Win32 > except for the really nasty hacks I've inserted to make it work > inside VMWare off the same source tree. I do have a per-compiler > directory with per-compiler .py files which sets per-compiler command > line options Aha. That's a part that Boost.Build is eliminating. > but other than that it's literally that easy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From s_sourceforge at nedprod.com Thu Sep 9 19:58:26 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 09 Sep 2004 18:58:26 +0100 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest In-Reply-To: Message-ID: <4140A7D2.10461.143B40EA@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9 Sep 2004 at 13:01, David Abrahams wrote: > >> >> For which compilers/platforms does that combination of > >> >> environment variables work? > > > > For simple programs, all of them. > > Boost.Python isn't simple, though. It's simple enough. You're not running any special preprocessors and you don't need any special command line options. You're not building it into multiple libraries. > > Actually Neal's scons file is far > > too long, scons can read most of that stuff from environment > > variables. And since it's python, you'd just write an > > "includeBoost()" function. > > So you have to set up a bunch of environment variables that describe > the specifics of how to use those compilers? No not at all, but then neither did Neal's example. You do need to supply where Boost lives though scons would usually include /usr/local/include etc. automatically. > > In the scons files for TnFOX, they are identical on Linux and Win32 > > except for the really nasty hacks I've inserted to make it work > > inside VMWare off the same source tree. I do have a per-compiler > > directory with per-compiler .py files which sets per-compiler > > command line options > > Aha. That's a part that Boost.Build is eliminating. I'd very much doubt if Boost.Build could automatically disable specific warnings and such :) My per-compiler files are simply for per-compiler settings. If you weren't exerting as fine control as I am, you could just pass -O2 and that would would on almost every compiler. > > but other than that it's literally that easy. I've not used Boost.Build much but I have found it much less intuitive to alter than scons. scons is a python file, it's far easier than XML-like obscurely named commands. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQUCZw8EcvDLFGKbPEQJw8wCgxZjDdBmcJfK8KDpSO9OkZLkgp98AoKLX BfedaP2uDgcUdYNe8ZMhBgLH =kAaw -----END PGP SIGNATURE----- From itamar at itamarst.org Thu Sep 9 23:17:18 2004 From: itamar at itamarst.org (Itamar Shtull-Trauring) Date: Thu, 09 Sep 2004 17:17:18 -0400 Subject: [C++-sig] Shared pointers and python subclasses Message-ID: <1094764638.1014.45.camel@sheriffpony> I have a structure somewhat like this (I simplified to explain): typedef boost::shared_ptr RecordHandlerPtr; class_("RecordHandler"); class_("CacheRecordRetriever",init()); Now, if I subclass RecordHandler in python, I can't pass an instance of the subclass to CacheRecordRetriever's constructor in my Python code, it raises a RuntimeErorr claiming it's the wrong type. How do I solve this? Thanks! -- Itamar Shtull-Trauring http://itamarst.org From eli at water.ca.gov Fri Sep 10 00:04:10 2004 From: eli at water.ca.gov (esatel) Date: Thu, 9 Sep 2004 15:04:10 -0700 Subject: [C++-sig] to_python_converters with internal-ref-like management Message-ID: Hi. I have a question about how/whether it is possible to use a to_python_converter and still take advantage of lifetime management using weak references. It is a special case, but kind of an interesting one. I have a an class called array_holder containing a large member of class boost::multi_array. Member functions of my array_holder class return sliced subarrays of the parent array. Because of the way multi_array works (to manage large objects), in C++ subarrays contain pointers to, rather than copies of, the underlying data from the parent array. When I wrap the array_holder class for python, I want to return subarrays from these methods as PyArrays. I can do this without copying any of the underlying data as follows (some pseudo code is included below): 1. The array_holder method returns by value a (new) subarray object containing a pointer to the (original) multi_array data. 2. The converter converts the subarray to a PyArray without copying the data -- it creates a new PyArray and points it to the same base address as the subarray. However, to be safe, the array_holder (which contains the multi_array managing the data) to last as long as the subarray. Is there a slick way to do this? I realize that I can eliminate the need for this dependence through copies, but the size of the arrays involved (slices >10000 doubles) motivates me to avoid the wasted motion. Thanks, Eli The following pseudo-code mimics how I do it unsafely: /* multi_array and sub_array are in Boost -- both contain a raw char* pointer to data */ typedef multi_array::array_view<2>::type subarray_type; class array_holder { public: subarray_type get_slice(); // creates the new subarray object, // sets the *data pointer of the subarray to // that of the multi_array } private: array_type m_multi_array(); } struct marray_to_pyarray { static PyObject* convert(subarray_type const& a) { PyObject* po = PyArray_FromDimsAndData(2, (int*) a.shape(), PyArray_DOUBLE, (char*) a.origin() // point to the subarray data ); return po; } }; void export_array_holder(){ import_array(); class_("array_holder") .def("slice", &array_holder::get_slice); to_python_converter(); } BOOST_PYTHON_MODULE(demo_array){ export_array_holder(); } From rwgk at yahoo.com Fri Sep 10 03:28:48 2004 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 9 Sep 2004 18:28:48 -0700 (PDT) Subject: [C++-sig] to_python_converters with internal-ref-like management In-Reply-To: Message-ID: <20040910012848.63071.qmail@web20225.mail.yahoo.com> --- esatel wrote: > I realize that I can eliminate the need for this dependence through > copies, but the size of the arrays involved (slices >10000 doubles) > motivates me to avoid the wasted motion. Welcome to hell! Ralf P.S.: Sorry. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From jbrandmeyer at earthlink.net Fri Sep 10 04:42:58 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 09 Sep 2004 22:42:58 -0400 Subject: [C++-sig] to_python_converters with internal-ref-like management In-Reply-To: References: Message-ID: <1094784178.9863.24.camel@illuvatar> On Thu, 2004-09-09 at 18:04, esatel wrote: > However, to be safe, the array_holder (which contains the multi_array > managing the data) to last as long as the subarray. Is there a slick way to > do this? I realize that I can eliminate the need for this dependence through > copies, but the size of the arrays involved (slices >10000 doubles) > motivates me to avoid the wasted motion. > > Thanks, > Eli Try this: -Manage the array_holder's memory with shared_ptr, or some other refcounting system. -Create a dummy class for Python which does nothing other than own a reference to the underlying array_holder. -Convert the subarray to a _numarray_-based Python array (because this trick won't work with with Numeric). -Make a boost::python::object from the PyObject* you just initialized (I'll call it 'ret' for later reference). Make sure you do it in a way that doesn't delete the underlying PyObject too early, or add an extra reference to it. -Call ret.attr( "some_unique_name") = object(dummy(array_holder)); -Return ret to Python. Here's how I think it should work. Because numarray uses the new class system, you can add arbitrary attributes to numarray objects. So, you add an attribute that holds a reference to the underlying data. When the refcount on the PyArray goes to zero, so will the extra attribute's refcount (assuming that someone else didn't reference it again somehow - that is why you use the hard-to-guess name*). When Python destroys the dummy attribute, the refcount on the data to which that slice object pointed gets its refcount decremented. I haven't tried this before, so if you try it, and it works, please let folks know. HTH, -Jonathan *I would even go as far as salting the name with a wee bit of random data, but that might be overkill. From jbrandmeyer at earthlink.net Fri Sep 10 04:51:35 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 09 Sep 2004 22:51:35 -0400 Subject: [C++-sig] to_python_converters with internal-ref-like management In-Reply-To: <1094784178.9863.24.camel@illuvatar> References: <1094784178.9863.24.camel@illuvatar> Message-ID: <1094784694.9863.29.camel@illuvatar> On Thu, 2004-09-09 at 22:42, Jonathan Brandmeyer wrote: > On Thu, 2004-09-09 at 18:04, esatel wrote: > > > However, to be safe, the array_holder (which contains the multi_array > > managing the data) to last as long as the subarray. Is there a slick way to > > do this? I realize that I can eliminate the need for this dependence through > > copies, but the size of the arrays involved (slices >10000 doubles) > > motivates me to avoid the wasted motion. > > > > Thanks, > > Eli > > Try this: > > -Manage the array_holder's memory with shared_ptr, or some other > refcounting system. > -Create a dummy class for Python which does nothing other than own a > reference to the underlying array_holder. Even simpler than the above - in the module initialization function, make a class_ >("whatever"). > -Convert the subarray to a _numarray_-based Python array (because this > trick won't work with with Numeric). > -Make a boost::python::object from the PyObject* you just initialized > (I'll call it 'ret' for later reference). Make sure you do it in a way > that doesn't delete the underlying PyObject too early, or add an extra > reference to it. > -Call ret.attr( "some_unique_name") = object(dummy(array_holder)); And then, call ret.attr( "some_unique_name") = object( shared_ptr); > -Return ret to Python. > > Here's how I think it should work. Because numarray uses the new class > system, you can add arbitrary attributes to numarray objects. So, you > add an attribute that holds a reference to the underlying data. When > the refcount on the PyArray goes to zero, so will the extra attribute's > refcount (assuming that someone else didn't reference it again somehow - > that is why you use the hard-to-guess name*). When Python destroys the > dummy attribute, the refcount on the data to which that slice object > pointed gets its refcount decremented. > > I haven't tried this before, so if you try it, and it works, please let > folks know. > > HTH, > -Jonathan > > *I would even go as far as salting the name with a wee bit of random > data, but that might be overkill. > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From Rainer.Kluger at LBBW.de Fri Sep 10 06:39:27 2004 From: Rainer.Kluger at LBBW.de (Rainer Kluger) Date: Fri, 10 Sep 2004 06:39:27 +0200 Subject: [C++-sig] Rainer Kluger/INTERN/LBBW ist =?iso-8859-1?q?au=DFer_Haus=2E_=5B?= =?iso-8859-1?q?=27LBBW=27=3A_checked=5D?= Message-ID: Ich werde ab Freitag, den 10. September 2004, nicht anwesend sein und kehre voraussichtlich am Donnerstag, den 30. September 2004, zur?ck. In dringenden F?llen wenden Sie sich bitte an Herrn Holger Joukl (1651) oder Frau Manuela Kaelberer (1651). Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empf?nger sind oder falls diese E-Mail irrt?mlich an Sie adressiert wurde, verst?ndigen Sie bitte den Absender sofort und l?schen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte ?bermittlung sind nicht gestattet. Die Sicherheit von ?bermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Best?tigung w?nschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. From caustin at gmail.com Fri Sep 10 08:56:33 2004 From: caustin at gmail.com (Chad Austin) Date: Fri, 10 Sep 2004 01:56:33 -0500 Subject: [C++-sig] Shared pointers and python subclasses In-Reply-To: <1094764638.1014.45.camel@sheriffpony> References: <1094764638.1014.45.camel@sheriffpony> Message-ID: <2096514e040909235639192152@mail.gmail.com> When binding the RecordHandler subclass, you could try: implicitly_convertable(); Boost.Python can't automatically figure out which HeldTypes are implicitly convertible (atm), so you have to tell it. Cheers, Chad On Thu, 09 Sep 2004 17:17:18 -0400, Itamar Shtull-Trauring wrote: > I have a structure somewhat like this (I simplified to explain): > > typedef boost::shared_ptr RecordHandlerPtr; > class_("RecordHandler"); > class_("CacheRecordRetriever",init()); > > Now, if I subclass RecordHandler in python, I can't pass an instance of > the subclass to CacheRecordRetriever's constructor in my Python code, it > raises a RuntimeErorr claiming it's the wrong type. How do I solve this? > > Thanks! > > -- > Itamar Shtull-Trauring http://itamarst.org From ndbecker2 at verizon.net Fri Sep 10 14:57:09 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 10 Sep 2004 08:57:09 -0400 Subject: [C++-sig] Re: Re: Building/testing extensions: boost-python-runtest References: <4140A7D2.10461.143B40EA@localhost> Message-ID: Scons scripts are python, and scons itself is also python. Imagine how easy life is if you have make, but written in python, so you can easily access it's internals or change any aspect from the makefile (not that you would typically need to). scons src itself is actually quite small, as well. From ndbecker2 at verizon.net Fri Sep 10 16:25:04 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 10 Sep 2004 10:25:04 -0400 Subject: [C++-sig] boost::optional from python Message-ID: I have C++ functions that take boost::optional arguments. How best to call them from python? Consider: int F (boost::optional& o); It would be most natural to be able to (from python) i = F(None) j = F(2) I'm guessing I could register a converter from T -> boost::optional? Still, how does this handle None? From itamar at itamarst.org Fri Sep 10 17:07:47 2004 From: itamar at itamarst.org (Itamar Shtull-Trauring) Date: Fri, 10 Sep 2004 11:07:47 -0400 Subject: [C++-sig] Shared pointers and python subclasses In-Reply-To: <2096514e040909235639192152@mail.gmail.com> References: <1094764638.1014.45.camel@sheriffpony> <2096514e040909235639192152@mail.gmail.com> Message-ID: <1094828867.8944.0.camel@sheriffpony> On Fri, 2004-09-10 at 02:56, Chad Austin wrote: > When binding the RecordHandler subclass, you could try: > > implicitly_convertable(); > > Boost.Python can't automatically figure out which HeldTypes are > implicitly convertible (atm), so you have to tell it. I'm creating the subclass in Python - e.g. class TestHandler(mymodule.RecordHandler): # .... So I can't do that. From dave at boost-consulting.com Fri Sep 10 18:11:09 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 10 Sep 2004 12:11:09 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <4140A7D2.10461.143B40EA@localhost> Message-ID: "Niall Douglas" writes: > On 9 Sep 2004 at 13:01, David Abrahams wrote: > >> >> >> For which compilers/platforms does that combination of >> >> >> environment variables work? >> > >> > For simple programs, all of them. >> >> Boost.Python isn't simple, though. > > It's simple enough. You're not running any special preprocessors and > you don't need any special command line options. On many platforms, I certainly do. > You're not building > it into multiple libraries. > >> > Actually Neal's scons file is far >> > too long, scons can read most of that stuff from environment >> > variables. And since it's python, you'd just write an >> > "includeBoost()" function. >> >> So you have to set up a bunch of environment variables that describe >> the specifics of how to use those compilers? > > No not at all, but then neither did Neal's example. You do need to > supply where Boost lives though scons would usually include > /usr/local/include etc. automatically. Okay. >> > In the scons files for TnFOX, they are identical on Linux and Win32 >> > except for the really nasty hacks I've inserted to make it work >> > inside VMWare off the same source tree. I do have a per-compiler >> > directory with per-compiler .py files which sets per-compiler >> > command line options >> >> Aha. That's a part that Boost.Build is eliminating. > > I'd very much doubt if Boost.Build could automatically disable > specific warnings and such :) > > My per-compiler files are simply for per-compiler settings. If you > weren't exerting as fine control as I am, you could just pass -O2 and > that would would on almost every compiler. ?? Lots of compilers don't respond to -O2. The point is that Boost.Build abstracts away the meaning of particular compiler options, so that Jamfiles are written in terms of features and values, many of which are applicable across compilers. >> > but other than that it's literally that easy. > > I've not used Boost.Build much but I have found it much less > intuitive to alter than scons. scons is a python file, it's far > easier than XML-like obscurely named commands. There are no "XML-like commands" in Boost.Build. The syntax for specifying feature,value pairs in Jamfiles uses angle brackets (value), but I am trying to change things so the command-line syntax of feature=value will work in Jamfiles also. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Fri Sep 10 18:16:30 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 10 Sep 2004 12:16:30 -0400 Subject: [C++-sig] Re: Shared pointers and python subclasses References: <1094764638.1014.45.camel@sheriffpony> Message-ID: Itamar Shtull-Trauring writes: > I have a structure somewhat like this (I simplified to explain): > > typedef boost::shared_ptr RecordHandlerPtr; > class_("RecordHandler"); > class_("CacheRecordRetriever",init()); > > Now, if I subclass RecordHandler in python, I can't pass an instance of > the subclass to CacheRecordRetriever's constructor in my Python code, it > raises a RuntimeErorr claiming it's the wrong type. How do I solve this? The one explanation I can think of is that you've defined an __init__ function in your subclass that doesn't call RecordHandler.__init__. That is what would create the contained C++ RecordHandler object, and without that you can't convert it to a RecordHandlerPtr. If that's not the case please post a small, reproducible example. One C++ file and one Python file. This is supposed to work. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Fri Sep 10 18:13:05 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 10 Sep 2004 12:13:05 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <4140A7D2.10461.143B40EA@localhost> Message-ID: "Neal D. Becker" writes: G> Scons scripts are python, and scons itself is also python. > > Imagine how easy life is if you have make, but written in python, so you can > easily access it's internals or change any aspect from the makefile (not > that you would typically need to). > > scons src itself is actually quite small, as well. I like the idea of Scons and have been following its development since before it started ;-). I am also interested in the idea of replacing the Boost.Build core with Scons. I'm asking these questions because I want to be sure that Boost.Build itself is still providing important advantages. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Fri Sep 10 18:22:26 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 10 Sep 2004 12:22:26 -0400 Subject: [C++-sig] Re: boost::optional from python References: Message-ID: "Neal D. Becker" writes: > I have C++ functions that take boost::optional arguments. How best to call > them from python? > > Consider: > > int F (boost::optional& o); > > It would be most natural to be able to (from python) > > i = F(None) > j = F(2) > > I'm guessing I could register a converter from T -> boost::optional? > Still, how does this handle None? This is a bit odd. You want to get a mutable lvalue from Python when you pass None? What should happens when F writes into o? Same goes for 2, for that matter. ints are immutable in Python. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From Rainer.Kluger at LBBW.de Fri Sep 10 18:43:03 2004 From: Rainer.Kluger at LBBW.de (Rainer Kluger) Date: Fri, 10 Sep 2004 18:43:03 +0200 Subject: [C++-sig] Rainer Kluger/INTERN/LBBW ist =?iso-8859-1?q?au=DFer_Haus=2E_=5B?= =?iso-8859-1?q?=27LBBW=27=3A_checked=5D?= Message-ID: Ich werde ab Freitag, den 10. September 2004, nicht anwesend sein und kehre voraussichtlich am Donnerstag, den 30. September 2004, zur?ck. In dringenden F?llen wenden Sie sich bitte an Herrn Holger Joukl (1651) oder Frau Manuela Kaelberer (1651). Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empf?nger sind oder falls diese E-Mail irrt?mlich an Sie adressiert wurde, verst?ndigen Sie bitte den Absender sofort und l?schen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte ?bermittlung sind nicht gestattet. Die Sicherheit von ?bermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Best?tigung w?nschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. From rwgk at yahoo.com Fri Sep 10 19:28:25 2004 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 10 Sep 2004 10:28:25 -0700 (PDT) Subject: [C++-sig] Re: boost::optional from python In-Reply-To: Message-ID: <20040910172825.47913.qmail@web20224.mail.yahoo.com> --- David Abrahams wrote: > "Neal D. Becker" writes: > > > I have C++ functions that take boost::optional arguments. How best to call > > them from python? > > > > Consider: > > > > int F (boost::optional& o); > > > > It would be most natural to be able to (from python) > > > > i = F(None) > > j = F(2) > > > > I'm guessing I could register a converter from T -> boost::optional? > > Still, how does this handle None? > > This is a bit odd. You want to get a mutable lvalue from Python when > you pass None? What should happens when F writes into o? Same goes > for 2, for that matter. ints are immutable in Python. This case is interesting, though: int F (boost::optional const& o); David, what's involved in enabling this for: - all builtin types - user-defined types (maybe class_) Ralf __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From ndbecker2 at verizon.net Fri Sep 10 19:38:23 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 10 Sep 2004 13:38:23 -0400 Subject: [C++-sig] Re: boost::optional from python References: Message-ID: David Abrahams wrote: > "Neal D. Becker" writes: > >> I have C++ functions that take boost::optional arguments. How best to >> call them from python? >> >> Consider: >> >> int F (boost::optional& o); >> >> It would be most natural to be able to (from python) >> >> i = F(None) >> j = F(2) >> >> I'm guessing I could register a converter from T -> boost::optional? >> Still, how does this handle None? > > This is a bit odd. You want to get a mutable lvalue from Python when > you pass None? What should happens when F writes into o? Same goes > for 2, for that matter. ints are immutable in Python. > No, not mutable, let's say: int F (boost::optionalconst &o) It almost works to do: ---optional_wrap.cc template inline void set (boost::optional& o, T x) { o = x; } template inline object get (boost::optional& o) { return o ? object (o.get()) : object() ; } template inline boost::optional* optional_from_object (object& o) { return new boost::optional; } template static void exposeOptional (const char* name) { class_ >(name, init()) .def ("__init__", make_constructor (optional_from_object)) .def ("set", &set) .def ("get", &get) .def (!(self)) ; } BOOST_PYTHON_MODULE(optional_wrap) { exposeOptional ("optional_int"); exposeOptional ("optional_double"); } -------------------another module int F (boost::optionalconst& o) { return 2; } BOOST_PYTHON_MODULE(something) { PyImport_Import (str ("optional_wrap").ptr()); def ("F", &F, (arg ("i")=boost::optional())); } ---------------------- >>> F >>> F() 2 >>> F(2) Traceback (most recent call last): File "", line 1, in ? Boost.Python.ArgumentError: Python argument types in _burstodemod_wrap.F(int) did not match C++ signature: F(boost::optional i=) From ndbecker2 at verizon.net Fri Sep 10 19:56:04 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 10 Sep 2004 13:56:04 -0400 Subject: [C++-sig] Re: boost::optional from python References: Message-ID: I guess this works: template inline boost::optional to_opt (object const& o) { if (o == object()) return boost::optional(); else return boost::optional (extract (o)()); } // This is the client function that wants optional arg int G (boost::optionalconst& o) { return (o ? o.get() : -1); } // Need this wrapper int F (object const& o) { return G (to_opt (o)); } BOOST_PYTHON_MODULE(Testo) { def ("F", &F, (arg ("i")=object())); } From dave at boost-consulting.com Fri Sep 10 21:41:13 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 10 Sep 2004 15:41:13 -0400 Subject: [C++-sig] Re: boost::optional from python References: <20040910172825.47913.qmail@web20224.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: > >> "Neal D. Becker" writes: >> >> > I have C++ functions that take boost::optional arguments. How best to call >> > them from python? >> > >> > Consider: >> > >> > int F (boost::optional& o); >> > >> > It would be most natural to be able to (from python) >> > >> > i = F(None) >> > j = F(2) >> > >> > I'm guessing I could register a converter from T -> boost::optional? >> > Still, how does this handle None? >> >> This is a bit odd. You want to get a mutable lvalue from Python when >> you pass None? What should happens when F writes into o? Same goes >> for 2, for that matter. ints are immutable in Python. > > This case is interesting, though: > > int F (boost::optional const& o); > > David, what's involved in enabling this for: > > - all builtin types > - user-defined types (maybe class_) We can either have it "just work" automatically or we can have it with explicit registration for particular types: register_optional_from_python() The latter is fairly trivial -- you already know the techniques for making custom from_python converters, Ralf. The former requires a bit more work in the Boost.Python core. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From Rainer.Kluger at LBBW.de Sat Sep 11 00:44:35 2004 From: Rainer.Kluger at LBBW.de (Rainer Kluger) Date: Sat, 11 Sep 2004 00:44:35 +0200 Subject: [C++-sig] Rainer Kluger/INTERN/LBBW ist =?iso-8859-1?q?au=DFer_Haus=2E_=5B?= =?iso-8859-1?q?=27LBBW=27=3A_checked=5D?= Message-ID: Ich werde ab Freitag, den 10. September 2004, nicht anwesend sein und kehre voraussichtlich am Donnerstag, den 30. September 2004, zur?ck. In dringenden F?llen wenden Sie sich bitte an Herrn Holger Joukl (1651) oder Frau Manuela Kaelberer (1651). Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empf?nger sind oder falls diese E-Mail irrt?mlich an Sie adressiert wurde, verst?ndigen Sie bitte den Absender sofort und l?schen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte ?bermittlung sind nicht gestattet. Die Sicherheit von ?bermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Best?tigung w?nschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version. From s_sourceforge at nedprod.com Sat Sep 11 14:49:54 2004 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 11 Sep 2004 13:49:54 +0100 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest In-Reply-To: Message-ID: <41430282.11556.1D6D7DF9@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10 Sep 2004 at 12:13, David Abrahams wrote: > G> Scons scripts are python, and scons itself is also python. > > > > Imagine how easy life is if you have make, but written in python, so > > you can easily access it's internals or change any aspect from the > > makefile (not that you would typically need to). > > > > scons src itself is actually quite small, as well. > > I like the idea of Scons and have been following its development > since before it started ;-). I am also interested in the idea of > replacing the Boost.Build core with Scons. I'm asking these questions > because I want to be sure that Boost.Build itself is still providing > important advantages. Have you considered writing a parser in python which translates jam files into scons operations? This way you get the best of both worlds. scons can also be used as a library rather than just standalone - just import it and go. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQUL0dsEcvDLFGKbPEQIHIwCfQozrFV3NOjFs5KSDqtdQKBz69FQAn0JN Hm0iX5oMiOVBOeTKxmyCKrEj =h/Z6 -----END PGP SIGNATURE----- From dave at boost-consulting.com Sat Sep 11 16:45:43 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 11 Sep 2004 10:45:43 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <41430282.11556.1D6D7DF9@localhost> Message-ID: "Niall Douglas" writes: > On 10 Sep 2004 at 12:13, David Abrahams wrote: > >> G> Scons scripts are python, and scons itself is also python. >> > >> > Imagine how easy life is if you have make, but written in python, so >> > you can easily access it's internals or change any aspect from the >> > makefile (not that you would typically need to). >> > >> > scons src itself is actually quite small, as well. >> >> I like the idea of Scons and have been following its development >> since before it started ;-). I am also interested in the idea of >> replacing the Boost.Build core with Scons. I'm asking these questions >> because I want to be sure that Boost.Build itself is still providing >> important advantages. > > Have you considered writing a parser in python which translates jam > files into scons operations? This way you get the best of both > worlds. scons can also be used as a library rather than just > standalone - just import it and go. I have considered that. Dealing with the existing Jamfile syntax is probably the least of my concerns. First there would be a major project to reimplement most of the Boost.Build logic in Python. Building a system where Jamfiles can be expressed in pure Python is the first (big) step. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From seefeld at sympatico.ca Sat Sep 11 17:39:00 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sat, 11 Sep 2004 11:39:00 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest In-Reply-To: References: <41430282.11556.1D6D7DF9@localhost> Message-ID: <41431C14.3080000@sympatico.ca> David Abrahams wrote: > "Niall Douglas" writes: >>Have you considered writing a parser in python which translates jam >>files into scons operations? This way you get the best of both >>worlds. scons can also be used as a library rather than just >>standalone - just import it and go. > > > I have considered that. Dealing with the existing Jamfile syntax is > probably the least of my concerns. First there would be a major > project to reimplement most of the Boost.Build logic in Python. > Building a system where Jamfiles can be expressed in pure Python is > the first (big) step. did you talk to the scons developers about such a project ? I'm sure such an abstraction layer that lets you query tools based on features would be tremendously useful. I'v myself considered to look into a 'port' of the distutils logic to be another higher level layer on top of scons that provides users with some default structure for installation and packaging in a portable way. Regards, Stefan From dave at boost-consulting.com Sat Sep 11 20:38:04 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 11 Sep 2004 14:38:04 -0400 Subject: [C++-sig] Re: Building/testing extensions: boost-python-runtest References: <41430282.11556.1D6D7DF9@localhost> <41431C14.3080000@sympatico.ca> Message-ID: Stefan Seefeld writes: > David Abrahams wrote: >> "Niall Douglas" writes: > >>> Have you considered writing a parser in python which translates jam >>> files into scons operations? This way you get the best of both >>> worlds. scons can also be used as a library rather than just >>> standalone - just import it and go. >> I have considered that. Dealing with the existing Jamfile syntax is >> probably the least of my concerns. First there would be a major >> project to reimplement most of the Boost.Build logic in Python. >> Building a system where Jamfiles can be expressed in pure Python is >> the first (big) step. > > did you talk to the scons developers about such a project ? I've been talking with Steven Knight since before he started on Scons. So, yes, he's aware of the idea. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From bhall at gamers-fix.com Sun Sep 12 03:08:54 2004 From: bhall at gamers-fix.com (Brian Hall) Date: Sat, 11 Sep 2004 20:08:54 -0500 Subject: [C++-sig] Derived C++ types in Python Message-ID: <20040912010842.238D61E4003@bag.python.org> Hello all, Do C++ types in python automatically get cast to the most specific type as they cross the python barrier? I know this code below isn't quite right, but I'm just trying to illustrate the concept. class A { int doSomething(); }; class B : public A { int doSomethingElse(); } class C { int doSomethingElseEntirely(); void fillPtr() { myptr = new B; } A* myptr; } // python class class D(C): def __init__(self): self.fillPtr() def anotherfunc(self): self.myptr.doSomethingElse() Assuming I have something like the classes above, and assuming they've all been properly exposed. If my python class D had its myptr member initialized on the C++ side with a class B instance, would the python side know about it? Would the exposed myptr member have access to all of the exposed methods on the derived type? Thanks! Brian Hall From ansgar.philippsen at unibas.ch Sun Sep 12 23:07:51 2004 From: ansgar.philippsen at unibas.ch (Ansgar Philippsen) Date: Sun, 12 Sep 2004 23:07:51 +0200 Subject: [C++-sig] thanks and app announcement Message-ID: <9C2AC0ABAD4FA6C99B2F68E8@angel7.pz.unibas.ch> Hi everybody This is my first post to this list, so let me first thank all of you for providing such a superb and powerful tool. I don't have a question per se, since I have managed to extract all information I needed so far from the docs and this list. I would like to ask you, however, to add IPLT, found under http://www.iplt.org, to the list of projects that utilize boost.python (and other libs from boost as well). IPLT is an image processing library and toolbox for the structural biology electron microscopy community. I would call it a budding/evolving project, since it is currently not in production stage, but rather under heavy development. Python is used as the main scripting/interaction level, but also for rapid prototyping, since the underlying C++ class library is pretty much fully exposed via boost.python (at least the high-level interface). The combined power of C++ and Python for this project turned out to be just awesome. Cheers from Switzerland - Ansgar ====================================== Ansgar Philippsen, PhD MIH - Biozentrum - Basel - Switzerland http://www.mih.unibas.ch From dave at boost-consulting.com Mon Sep 13 03:17:45 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 12 Sep 2004 21:17:45 -0400 Subject: [C++-sig] Re: Derived C++ types in Python References: <20040912010842.238D61E4003@bag.python.org> Message-ID: "Brian Hall" writes: > Hello all, > > Do C++ types in python automatically get cast to the most specific type as > they cross the python barrier? I know this code below isn't quite right, > but I'm just trying to illustrate the concept. > > > class A > { > int doSomething(); > }; > > class B : public A > { > int doSomethingElse(); > } > > class C > { > int doSomethingElseEntirely(); > void fillPtr() { myptr = new B; } > A* myptr; > } > > // python class > class D(C): > def __init__(self): > self.fillPtr() > > def anotherfunc(self): > self.myptr.doSomethingElse() > > Assuming I have something like the classes above, and assuming they've all > been properly exposed. If my python class D had its myptr member > initialized on the C++ side with a class B instance, would the python side > know about it? Would the exposed myptr member have access to all of the > exposed methods on the derived type? If A is a polymorphic class (has a virtual function -- your example doesn't) *and* the most-derived type is one that's wrapped (like B) then yes. Boost.Python will check the type of the result of self.myptr and make sure it's wrapped in the appropriate Python class. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Mon Sep 13 03:26:13 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 12 Sep 2004 21:26:13 -0400 Subject: [C++-sig] Re: thanks and app announcement References: <9C2AC0ABAD4FA6C99B2F68E8@angel7.pz.unibas.ch> Message-ID: Ansgar Philippsen writes: > Hi everybody > > This is my first post to this list, so let me first thank all of you > for providing such a superb and powerful tool. You're welcome! > I don't have a question per se, since I have managed to extract all > information I needed so far from the docs and this list. How refreshing! Most people struggle with the docs a bit. Hoping to do better one day. > I would like to ask you, however, to add IPLT, found under > http://www.iplt.org, to the list of projects that utilize boost.python > (and other libs from boost as well). IPLT is an image processing > library and toolbox for the structural biology electron microscopy > community. I would call it a budding/evolving project, since it is > currently not in production stage, but rather under heavy > development. Python is used as the main scripting/interaction level, > but also for rapid prototyping, since the underlying C++ class library > is pretty much fully exposed via boost.python (at least the high-level > interface). The combined power of C++ and Python for this project > turned out to be just awesome. done, thanks. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From jbrandmeyer at earthlink.net Mon Sep 13 05:03:53 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Sun, 12 Sep 2004 23:03:53 -0400 Subject: [C++-sig] Inheritance interoperability with other class systems Message-ID: <1095044632.9191.34.camel@illuvatar> I want to make a new class in Python that inherits from both a Boost.Python class and a class from the PyGTK library. Unfortunately, I get an exception: TypeError: multiple bases have instance lay-out conflict when the interpreter executes my Python class statement. Every instance of this exception that I have found via Google was caused due to one base class in each inheritance hierarchy having a __slots__ member defined, but that isn't the case here. What could be the cause of this error? I have a attached C++ and Python code for my trivial example, but you will need PyGTK on your system to run it. Thanks for the help, -Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: dummy.cpp Type: text/x-c++src Size: 142 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inheritor.py Type: application/x-python Size: 86 bytes Desc: not available URL: From dave at boost-consulting.com Mon Sep 13 17:31:03 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 13 Sep 2004 11:31:03 -0400 Subject: [C++-sig] Re: Inheritance interoperability with other class systems References: <1095044632.9191.34.camel@illuvatar> Message-ID: Jonathan Brandmeyer writes: > I want to make a new class in Python that inherits from both a > Boost.Python class and a class from the PyGTK library. Unfortunately, I > get an exception: > > TypeError: multiple bases have instance lay-out conflict > > when the interpreter executes my Python class statement. Every instance > of this exception that I have found via Google was caused due to one > base class in each inheritance hierarchy having a __slots__ member > defined, but that isn't the case here. What could be the cause of this > error? It's just what the message says: instances of C++ classes wrapped by Boost.Python have a layout that's defined in boost/python/object/instance.hpp. PyGTK probably has some other instance layout. I suggest using aggregation and delegation to simulate inheritance of one of the classes. This is not fundamentally a Boost.Python problem; it's kinda built in to the nature of Python. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From igor at pcigeomatics.com Mon Sep 13 20:54:15 2004 From: igor at pcigeomatics.com (Igor Lapshin) Date: Mon, 13 Sep 2004 14:54:15 -0400 Subject: [C++-sig] Is there a 15-parameter limit for function definitions in Python.Boost? Message-ID: Hi all, I'm trying to expose several functions with quite impressive number of arguments: 20-35(!) :-( I found that after 15 arguments compiler starts produce errors: C:\Boost\include\boost-1_31\boost\python\make_function.hpp(77) : error C2780: 'boost::mpl::vector17::type&,T0,T1,T2,T3, T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14> boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14) volatile const,Target *)' : expects 2 arguments - 1 provided C:\Boost\include\boost-1_31\boost\python\signature.hpp(165) : see declaration of 'boost::python::detail::get_signature' C:\Boost\include\boost-1_31\boost\python\make_function.hpp(130) : see reference to function template instantiation 'boost::python::api::object boost::python::detail::make_function_dispatch(F,const CallPolicies &,const Keywords &,boost::mpl::true_)' being compiled with [ CallPolicies=boost::python::detail::tuple_extract_impl::apply::all_t,boost::mpl::lambda_impl>,boost::python::detail::is_reference_to_class,boost::mpl::not_>>,boost::mpl::void_,boost::mpl::true_>::type>::result_t ype, KeywordsOrSignature=boost::python::detail::tuple_extract_impl::ap ply::all_t,boost::mpl::lambda_impl,boost::mpl::void_,boost::mpl::true_>::type> ::result_type, F=int (__cdecl *)(const std::string &,const std::string &,boost::python::list,boost::python::list,const std::string &,const std::string &,const std::string &,const std::string &,const std::string &,boost::python::list,boost::python::list,const std::string &,boost::python::list,const std::string &,boost::python::list,boost::python::list), Keywords=boost::python::detail::tuple_extract_impl::apply::all_t,boost::mpl::lambda_impl,boost::mpl::void_,boost::mpl::true_>::type> ::result_type ] Is it some limit? Is there any way to increase it? Thanks, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From sseefeld at art.ca Mon Sep 13 20:55:59 2004 From: sseefeld at art.ca (Stefan Seefeld) Date: Mon, 13 Sep 2004 14:55:59 -0400 Subject: [C++-sig] Is there a 15-parameter limit for function definiti ons in Python.Boost? Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA9761@MTL-EXCHANGE> From: Igor Lapshin [mailto:igor at pcigeomatics.com] Sent: September 13, 2004 14:54 >Hi all, > >I'm trying to expose several functions with quite impressive number of arguments: 20-35(!) L bear with the poor soul who has to read and understand this code ! Did you consider grouping these arguments into structs ? I believe the answer to your question is yes, and this limit is specified with a configurable compile-time parameter (a macro). To increase it you have to recompile bpl. Regards, Stefan From dave at boost-consulting.com Mon Sep 13 21:43:46 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 13 Sep 2004 15:43:46 -0400 Subject: [C++-sig] Re: Is there a 15-parameter limit for function definiti ons in Python.Boost? References: <20DCDD8F0FCED411AC4D001083CF504501AA9761@MTL-EXCHANGE> Message-ID: Stefan Seefeld writes: > From: Igor Lapshin [mailto:igor at pcigeomatics.com] > Sent: September 13, 2004 14:54 > >>Hi all, >> >>I'm trying to expose several functions with quite impressive number of > arguments: 20-35(!) L > > bear with the poor soul who has to read and understand this code ! > Did you consider grouping these arguments into structs ? > > I believe the answer to your question is yes, and this limit is specified > with a configurable > compile-time parameter (a macro). To increase it you have to recompile bpl. I don't think you do, actually, but it would probably be wise. See http://www.boost.org/libs/python/doc/v2/configuration.html#app-defined -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From igor at pcigeomatics.com Mon Sep 13 21:57:37 2004 From: igor at pcigeomatics.com (Igor Lapshin) Date: Mon, 13 Sep 2004 15:57:37 -0400 Subject: [C++-sig] Re: Is there a 15-parameter limit for function definitions in Python.Boost? Message-ID: BOOST_PYTHON_MAX_ARITY=35 works! Thanks a lot, David! Stefan: I know that 35 arguments are over any imaginable limit... but I cannot change that design (I have already tried and was told that "users want it"). I'm simply a humble programmer who has the task to make those functions work :-( Thanks and cheers, Igor $-> From: David Abrahams [mailto:dave at boost-consulting.com] $-> Sent: Monday, September 13, 2004 3:44 PM $-> $-> I don't think you do, actually, but it would probably be wise. $-> $-> See http://www.boost.org/libs/python/doc/v2/configuration.html#app- $-> defined $-> $-> -- $-> Dave Abrahams From achim.domma at syynx.de Tue Sep 14 01:10:17 2004 From: achim.domma at syynx.de (Achim Domma) Date: Tue, 14 Sep 2004 01:10:17 +0200 Subject: [C++-sig] boost.python with cygwin Message-ID: <20040913231116.C56D91E4007@bag.python.org> Hi, I try to compile boost.python using cygwin without success. I have an up-to-date cygwin installation and a python 2.3.4 which I have compiled and installed under cygwin. I set PYTHON_VERSION to 2.3 and PYTHON_ROOT=/usr/local, which seems to be ok. If I set PYTHON_ROOT to another value, bjam complains as usual. Excecuting bjam I get errors like this: /home/..../detail/wrap_python.hpp:41:24: patchlevel.h : No such file or directory /home/..../detail/wrap_python.hpp:121:21: Python.h : No such file or directory Looks like the include pathes are wrong, but why? Any idea? Regards, Achim From ndbecker2 at verizon.net Tue Sep 14 14:45:26 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 14 Sep 2004 08:45:26 -0400 Subject: [C++-sig] Howto debug boost::python under redhat/fedora linux Message-ID: This information might be good to add to the docs. Under Redhat/Fedora Linux, binaries are normally stripped of debugging symbols. This means that running 'gdb /usr/bin/python' will not be very useful. The debugging symbols are shipped as a seperate package. You need to install: (e.g.) python-debuginfo. If you are using yum, you can add this to your yum.conf: [debug] name=debug baseurl=http://mirror.linux.duke.edu/pub/fedora/linux/core/$releasever/$basearch/debug/ Now to use it do the following: 1. gdb /usr/bin/python 2. sym /usr/lib/debug/usr/bin/python.debug 3. cd , start your program. 4. After the desired shared library is loaded by python send an interrupt to the process and gdb will wake up, allowing you to set a breakpoint in your shared module. From dave at boost-consulting.com Tue Sep 14 16:29:17 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 14 Sep 2004 10:29:17 -0400 Subject: [C++-sig] Re: Howto debug boost::python under redhat/fedora linux References: Message-ID: "Neal D. Becker" writes: > This information might be good to add to the docs. > > Under Redhat/Fedora Linux, binaries are normally stripped of debugging > symbols. This means that running 'gdb /usr/bin/python' will not be very > useful. > > The debugging symbols are shipped as a seperate package. You need to > install: (e.g.) python-debuginfo. > > If you are using yum, you can add this to your yum.conf: > [debug] > name=debug > baseurl=http://mirror.linux.duke.edu/pub/fedora/linux/core/$releasever/$basearch/debug/ > > Now to use it do the following: > > 1. gdb /usr/bin/python > 2. sym /usr/lib/debug/usr/bin/python.debug > 3. cd , start your program. > 4. After the desired shared library is loaded by python send an interrupt to > the process and gdb will wake up, allowing you to set a breakpoint in your > shared module. Great, where would you suggest it be added? Could I convince you to prepare a patch for the appropriate HTML file (and maybe check it in?) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Tue Sep 14 16:31:55 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 14 Sep 2004 10:31:55 -0400 Subject: [C++-sig] Re: boost.python with cygwin References: <20040913231116.C56D91E4007@bag.python.org> Message-ID: "Achim Domma" writes: > Hi, > > I try to compile boost.python using cygwin without success. I have an > up-to-date cygwin installation and a python 2.3.4 which I have compiled and > installed under cygwin. I set PYTHON_VERSION to 2.3 and > PYTHON_ROOT=/usr/local, which seems to be ok. If I set PYTHON_ROOT to > another value, bjam complains as usual. > > Excecuting bjam I get errors like this: > > /home/..../detail/wrap_python.hpp:41:24: patchlevel.h : No such file or > directory > /home/..../detail/wrap_python.hpp:121:21: Python.h : No such file or > directory > > Looks like the include pathes are wrong, but why? Any idea? I don't know; it's working perfectly for me. Do you have a non-standard Python installation? What do you see in /usr/local/include/python2.3/ ?? You might have to set PYTHON_INCLUDES. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From eli at water.ca.gov Tue Sep 14 23:22:49 2004 From: eli at water.ca.gov (esatel) Date: Tue, 14 Sep 2004 14:22:49 -0700 Subject: [C++-sig] Re: to_python_converters with internal-ref-like management References: Message-ID: I am still working on Jonothan Brandmeyer's solution. I'm a beginner to the object API, so it may take a bit. In the meantime, is the following a bad solution to this problem? It uses a free function in C++ as a member accessor in python, and it uses call policies to set up the dependency that I want. Minus a few lines of conversion details, the whole thing looks like: // A free function PyObject* slice_getter( multi_array_holder& holder){ subarray=holder.get_slice() return(convert_to_numarrayptr(subarray)); //details omitted } // The salient part of the python wrapper .def("get_slice", &get_the_slice, with_custodian_and_ward_postcall<0,1>()) I have only tested this for object lifetime management. It appears to work -- the multi_array_holder won't get destroyed while a subarray points to it. This solution seem to circumvent the whole to_python_converter apparatus, which scares me a bit -- is the only downside that the code isn't reusable, or is there other voodoo performed by to_python_converter I am going to wish I had? Thanks, Eli "esatel" wrote in message news:chqk0r$3lq$1 at sea.gmane.org... > Hi. I have a question about how/whether it is possible to use a > to_python_converter and still take advantage of lifetime management using > weak references. It is a special case, but kind of an interesting one. > > I have a an class called array_holder containing a large member of class > boost::multi_array. Member functions of my array_holder class return > sliced > subarrays of the parent array. Because of the way multi_array works (to > manage large objects), in C++ subarrays contain pointers to, rather than > copies of, the underlying data from the parent array. > > When I wrap the array_holder class for python, I want to return subarrays > from these methods as PyArrays. I can do this without copying any of the > underlying data as follows (some pseudo code is included below): > 1. The array_holder method returns by value a (new) subarray object > containing a pointer to the (original) multi_array data. > 2. The converter converts the subarray to a PyArray without copying the > data -- it creates a new PyArray and points it to the same base address as > the subarray. > > However, to be safe, the array_holder (which contains the multi_array > managing the data) to last as long as the subarray. Is there a slick way > to > do this? I realize that I can eliminate the need for this dependence > through > copies, but the size of the arrays involved (slices >10000 doubles) > motivates me to avoid the wasted motion. > > Thanks, > Eli > > > The following pseudo-code mimics how I do it unsafely: > > /* multi_array and sub_array are in Boost -- > both contain a raw char* pointer to data */ > typedef multi_array::array_view<2>::type subarray_type; > > class array_holder > { > public: > subarray_type get_slice(); // creates the new subarray object, > // sets the *data pointer of the subarray > to > // that of the multi_array > } > private: > array_type m_multi_array(); > } > > struct marray_to_pyarray > { > static PyObject* convert(subarray_type const& a) > { > PyObject* po = PyArray_FromDimsAndData(2, > (int*) a.shape(), > PyArray_DOUBLE, > (char*) a.origin() // point to the subarray data > ); > return po; > } > }; > > void export_array_holder(){ > import_array(); > class_("array_holder") > .def("slice", &array_holder::get_slice); > to_python_converter(); > } > > BOOST_PYTHON_MODULE(demo_array){ > export_array_holder(); > } From jbrandmeyer at earthlink.net Wed Sep 15 00:12:40 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Tue, 14 Sep 2004 18:12:40 -0400 Subject: [C++-sig] Re: to_python_converters with internal-ref-like management In-Reply-To: References: Message-ID: <1095199960.23728.17.camel@illuvatar> On Tue, 2004-09-14 at 17:22, esatel wrote: > I am still working on Jonothan Brandmeyer's solution. I'm a beginner to the > object API, so it may take a bit. > > In the meantime, is the following a bad solution to this problem? I think you've found a much, much better solution. This call policy performs a more sophisticated version of what I had thought up. I had assumed that this feature would only work with a Boost.Python-wrapped class, but after looking at its implementation, I see that it works for any PyObject. -Jonathan From rigmania at naver.com Wed Sep 15 15:35:20 2004 From: rigmania at naver.com (=?ks_c_5601-1987?B?IrnawM8i?=) Date: Wed, 15 Sep 2004 22:35:20 +0900 (KST) Subject: [C++-sig] how can i send python class object as parameter of python method...? Message-ID: <41484518.000002.15683@nhn431> HI, I wander whether it has a method to pass python object(especially class object) into python method from c++ which integrate python. should i pass tuple or list and convert it into class in python? or can i make class already in c++ and pass this object to python? thanks in advance... -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrish at debian.org Wed Sep 15 17:27:53 2004 From: chrish at debian.org (Christian Hudon) Date: Wed, 15 Sep 2004 11:27:53 -0400 Subject: [C++-sig] [PATCH] Pyste: fix for include path problem Message-ID: <41485F79.9060707@debian.org> Hi, the following patch fixes a problem with Pyste and #includes that happens when tail is not None. The way the project I'm trying to wrap is structured, all the .h and .cc files are in subdirectories of the project root directory. We do a single -I for the project root directory, and all the includes are done using #include (for files in other directories) or #include "file_in_same_dir.h" (for files in the same directory). The way Pyste does things when there is a tail that needs to be appended to the .h file breaks this. Suppose I'm wrapping something in foo.h, and that foo.h contains a line that #include "bar.h" (a file in the same directory). But when Pyste needs to append something to a .h file, it copies the file over to /tmp and then appends whatever is needed to it. It then passes that file over to gccxml. But in this case it won't work because the copy of foo.h is in /tmp, so it won't find bar.h anymore. My fix is, instead of copying the file, #include "/full/path/to/foo.h", and then add the tail to it. That way gccxml will find the file bar.h, because it's still in the same directory as foo.h. I also use the more secure mkstemp if it's available for creating the temporary file. Patch attached. Please consider applying for the next version of Pyste. If you have questions, don't hesitate to ask... Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: pyste.tail.patch Type: text/x-patch Size: 1092 bytes Desc: not available URL: From ndbecker2 at verizon.net Thu Sep 16 13:50:35 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 16 Sep 2004 07:50:35 -0400 Subject: [C++-sig] profiling code Message-ID: I realize this isn't exactly specific to boost-python. I want to profile my boost-python code. I'm using Linux. AFAICT, I would need to use a version of python build with -pg. Hopefully this would allow profiling dynamically loaded modules? (I haven't tried it recently). Is there any way to profile my modules without building a special python? From ghost at cs.msu.su Thu Sep 16 13:55:31 2004 From: ghost at cs.msu.su (Vladimir Prus) Date: Thu, 16 Sep 2004 15:55:31 +0400 Subject: [C++-sig] Re: profiling code References: Message-ID: Hi Neal, > I realize this isn't exactly specific to boost-python. I want to profile > my > boost-python code. I'm using Linux. > > AFAICT, I would need to use a version of python build with -pg. Hopefully > this would allow profiling dynamically loaded modules? (I haven't tried > it recently). > > Is there any way to profile my modules without building a special python? Sure, you can you the valgrind "skin" called "calltree". It produces a profile file which can be then visualied using the "kcachegrind" tool. Advantages: no need to recompile anything. You also get better precision because the binary is not alterted by the profiling code. Disadvantages: since valgrind essentially emulates processor, the program will run 10 times slower. - Volodya From jbrandmeyer at earthlink.net Thu Sep 16 14:21:52 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 16 Sep 2004 08:21:52 -0400 Subject: [C++-sig] profiling code In-Reply-To: References: Message-ID: <1095337311.4803.38.camel@illuvatar> On Thu, 2004-09-16 at 07:50, Neal D. Becker wrote: > I realize this isn't exactly specific to boost-python. I want to profile my > boost-python code. I'm using Linux. > > AFAICT, I would need to use a version of python build with -pg. Hopefully > this would allow profiling dynamically loaded modules? (I haven't tried it > recently). You also need to link the interpreter statically against all of the code that you want to profile, since gprof doesn't work across .so boundaries. HTH, -Jonathan From ndbecker2 at verizon.net Thu Sep 16 18:53:48 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 16 Sep 2004 12:53:48 -0400 Subject: [C++-sig] Re: profiling code References: Message-ID: Vladimir Prus wrote: > Hi Neal, > >> I realize this isn't exactly specific to boost-python. I want to profile >> my >> boost-python code. I'm using Linux. >> >> AFAICT, I would need to use a version of python build with -pg. >> Hopefully >> this would allow profiling dynamically loaded modules? (I haven't tried >> it recently). >> >> Is there any way to profile my modules without building a special python? > > Sure, you can you the valgrind "skin" called "calltree". It produces a > profile file which can be then visualied using the "kcachegrind" tool. > Advantages: no need to recompile anything. You also get better precision > because the binary is not alterted by the profiling code. > Disadvantages: since valgrind essentially emulates processor, the program > will run 10 times slower. > 2 points: 1) Thanks! callgrind + kcachegrind are fantastic tools. 2) I was able to speed up my code by 4X. Turns out, problem was my use of index operator [] on iterators instead of ++, etc. David Abrahams told me this more than once. Moral: Listen to Master Abrahams! From bhartsho at yahoo.com Fri Sep 17 06:55:43 2004 From: bhartsho at yahoo.com (brett hartshorn) Date: Thu, 16 Sep 2004 21:55:43 -0700 (PDT) Subject: [C++-sig] how to wrap a typedef std::list in boostPython? Message-ID: <20040917045543.4456.qmail@web13421.mail.yahoo.com> Hi, I am having some problems wrapping a typedef std::list in boostpython. Here is my code: typedef std::list< osg::ref_ptr > EventHandlerList; and the wrapper: class_("EventHandlerList") .def("push_back", &osgProducer::Viewer::EventHandlerList::push_back) .def("push_front", &osgProducer::Viewer::EventHandlerList::push_front) .def("__iter__", iterator()) ; the error that python reports when trying to use the push_front function. Traceback (most recent call last): File "./osgkeyboard.py", line 385, in ? main(sys.argv) File "./osgkeyboard.py", line 358, in main viewer.getEventHandlerList().push_front(osgGA.GUIEventHandler()) Boost.Python.ArgumentError: Python argument types in EventHandlerList.push_front(EventHandlerList, GUIEventHandler) did not match C++ signature: push_front(std::list, std::allocator > > {lvalue}, osg::ref_ptr) -brett __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From rwgk at yahoo.com Fri Sep 17 13:09:58 2004 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 17 Sep 2004 04:09:58 -0700 (PDT) Subject: [C++-sig] how to wrap a typedef std::list in boostPython? In-Reply-To: <20040917045543.4456.qmail@web13421.mail.yahoo.com> Message-ID: <20040917110958.9059.qmail@web20228.mail.yahoo.com> --- brett hartshorn wrote: > Hi, > > I am having some problems wrapping a typedef std::list in boostpython. Here > is my code: > > typedef std::list< osg::ref_ptr > EventHandlerList; > > and the wrapper: > > class_("EventHandlerList") > .def("push_back", &osgProducer::Viewer::EventHandlerList::push_back) > .def("push_front", &osgProducer::Viewer::EventHandlerList::push_front) > .def("__iter__", iterator()) > ; > > the error that python reports when trying to use the push_front function. > > Traceback (most recent call last): > File "./osgkeyboard.py", line 385, in ? > main(sys.argv) > File "./osgkeyboard.py", line 358, in main > viewer.getEventHandlerList().push_front(osgGA.GUIEventHandler()) > Boost.Python.ArgumentError: Python argument types in > EventHandlerList.push_front(EventHandlerList, GUIEventHandler) > did not match C++ signature: > push_front(std::list, > std::allocator > > {lvalue}, > osg::ref_ptr) The element type of your std::list<> template instantiation is: osg::ref_ptr What is osg::ref_ptr<>? How did you wrap osgGA::GUIEventHandler? Somehow you have to tell Boost.Python how to extract a osgGA::GUIEventHandler from a osg::ref_ptr. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From nick.gildea at gmail.com Sat Sep 18 01:25:08 2004 From: nick.gildea at gmail.com (Nicholas Gildea) Date: Sat, 18 Sep 2004 00:25:08 +0100 Subject: [C++-sig] "unidentifiable C++ exception" Message-ID: First, sorry if this is a little off-topic, but I wasn't sure where else to ask. I've started (trying) to use Boost.Python to embed Python in a C++ application. After managing to successfully get the "Hello World" style example working, I've run into a problem. When I started to use PyRun_File instead of PyRun_String, I first got an access violation and then after some Googling saw a suggestion to use the Boost.Python exception handling wrappers to try and solve the problem, which generates the "unidentifiable C++ exception" error. My code looks like the following: #include #include #include #pragma comment( lib, "python23.lib" ) #pragma comment( lib, "boost_python.lib" ) using namespace boost::python; void test() { handle<> mainModule( borrowed( PyImport_AddModule( "__main__" ) ) ); handle<> mainNamespace( borrowed( PyModule_GetDict( mainModule.get() ) ) ); const char* const path = "test.py"; FILE* f = fopen( path, "r" ); if( f == NULL ) { std::cout << "[c++] Couldn't open file!\n"; return; } handle<>( PyRun_File( f, path, Py_file_input, mainNamespace.get(), mainNamespace.get() ) ); fclose( f ); } int main( int argc, char** argv ) { Py_Initialize(); if( handle_exception( test ) ) { if( PyErr_Occurred() ) { PyErr_Print(); } return 1; } return 0; } with test.py consisting of just a print statement. I'm compiling this using VC7.1, and using the library supplied with Python 2.3.3 and have built boost_python.lib from boost version 1.31 (also in VC7.1). If anyone could point me in the possible direction of my problem, or give me tips on how to track it down, it would be very much appreciated. Thanks, Nick. From nicodemus at esss.com.br Sat Sep 18 02:20:37 2004 From: nicodemus at esss.com.br (Nicodemus) Date: Fri, 17 Sep 2004 21:20:37 -0300 Subject: [C++-sig] [PATCH] Pyste: fix for include path problem In-Reply-To: <41485F79.9060707@debian.org> References: <41485F79.9060707@debian.org> Message-ID: <414B7F55.5000506@esss.com.br> Hi Christian Christian Hudon wrote: > Hi, > > the following patch fixes a problem with Pyste and #includes that > happens when tail is not None. > I will gladly apply this patch sometime next week. Thanks for the effort! Regards, Nicodemus. From dave at boost-consulting.com Sat Sep 18 13:09:23 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 18 Sep 2004 07:09:23 -0400 Subject: [C++-sig] Re: "unidentifiable C++ exception" References: Message-ID: Nicholas Gildea writes: > First, sorry if this is a little off-topic, but I wasn't sure where else to ask. > > I've started (trying) to use Boost.Python to embed Python in a C++ > application. After managing to successfully get the "Hello World" > style example working, I've run into a problem. When I started to use > PyRun_File instead of PyRun_String, I first got an access violation > and then after some Googling saw a suggestion to use the Boost.Python > exception handling wrappers to try and solve the problem, which > generates the "unidentifiable C++ exception" error. The access violation is the real problem. Stick the following in your file and the EH stuff will stop interfering with it. # include # pragma warning(push) # pragma warning(disable:4297) extern "C" void straight_to_debugger(unsigned int, EXCEPTION_POINTERS*) { throw; } extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*) = _set_se_translator(straight_to_debugger); # pragma warning(pop) > My code looks like the following: > > #include > #include > #include > > #pragma comment( lib, "python23.lib" ) > #pragma comment( lib, "boost_python.lib" ) > > using namespace boost::python; > > void test() > { > handle<> mainModule( borrowed( PyImport_AddModule( "__main__" ) ) ); > handle<> mainNamespace( borrowed( PyModule_GetDict( mainModule.get() ) ) ); > > const char* const path = "test.py"; > > FILE* f = fopen( path, "r" ); > if( f == NULL ) > { > std::cout << "[c++] Couldn't open file!\n"; > return; > } > > handle<>( PyRun_File( f, path, Py_file_input, mainNamespace.get(), > mainNamespace.get() ) ); > > fclose( f ); > } > > int main( int argc, char** argv ) > { > Py_Initialize(); > > if( handle_exception( test ) ) > { > if( PyErr_Occurred() ) > { > PyErr_Print(); > } > > return 1; > } > > return 0; > } > > with test.py consisting of just a print statement. I'm compiling this > using VC7.1, and using the library supplied with Python 2.3.3 and have > built boost_python.lib from boost version 1.31 (also in VC7.1). The problem is almost certainly that the Python23.lib you're using was built with a different version of VC, which had a different layout for the FILE structure. The solution is to rebuild it from source. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From nick.gildea at gmail.com Sat Sep 18 15:26:12 2004 From: nick.gildea at gmail.com (Nicholas Gildea) Date: Sat, 18 Sep 2004 14:26:12 +0100 Subject: [C++-sig] Re: "unidentifiable C++ exception" In-Reply-To: References: Message-ID: Thanks for the quick responce David. You were right about the python library, I've now get the code working. After trying (and failing) to build python 2.3.3 myself I discovered the 2.4 release is built with VC7.1 and so updating to that version has solved the problem. Thanks again, Nick. On Sat, 18 Sep 2004 07:09:23 -0400, David Abrahams wrote: > Nicholas Gildea writes: > > > First, sorry if this is a little off-topic, but I wasn't sure where else to ask. > > > > I've started (trying) to use Boost.Python to embed Python in a C++ > > application. After managing to successfully get the "Hello World" > > style example working, I've run into a problem. When I started to use > > PyRun_File instead of PyRun_String, I first got an access violation > > and then after some Googling saw a suggestion to use the Boost.Python > > exception handling wrappers to try and solve the problem, which > > generates the "unidentifiable C++ exception" error. > > The access violation is the real problem. Stick the following in > your file and the EH stuff will stop interfering with it. > > # include > # pragma warning(push) > # pragma warning(disable:4297) > extern "C" void straight_to_debugger(unsigned int, EXCEPTION_POINTERS*) > { > throw; > } > extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*) > = _set_se_translator(straight_to_debugger); > # pragma warning(pop) > > > My code looks like the following: > > > > #include > > #include > > #include > > > > #pragma comment( lib, "python23.lib" ) > > #pragma comment( lib, "boost_python.lib" ) > > > > using namespace boost::python; > > > > void test() > > { > > handle<> mainModule( borrowed( PyImport_AddModule( "__main__" ) ) ); > > handle<> mainNamespace( borrowed( PyModule_GetDict( mainModule.get() ) ) ); > > > > const char* const path = "test.py"; > > > > FILE* f = fopen( path, "r" ); > > if( f == NULL ) > > { > > std::cout << "[c++] Couldn't open file!\n"; > > return; > > } > > > > handle<>( PyRun_File( f, path, Py_file_input, mainNamespace.get(), > > mainNamespace.get() ) ); > > > > fclose( f ); > > } > > > > int main( int argc, char** argv ) > > { > > Py_Initialize(); > > > > if( handle_exception( test ) ) > > { > > if( PyErr_Occurred() ) > > { > > PyErr_Print(); > > } > > > > return 1; > > } > > > > return 0; > > } > > > > with test.py consisting of just a print statement. I'm compiling this > > using VC7.1, and using the library supplied with Python 2.3.3 and have > > built boost_python.lib from boost version 1.31 (also in VC7.1). > > The problem is almost certainly that the Python23.lib you're using was > built with a different version of VC, which had a different layout for > the FILE structure. The solution is to rebuild it from source. > > HTH, > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From gmccaughan at synaptics-uk.com Tue Sep 21 16:44:01 2004 From: gmccaughan at synaptics-uk.com (Gareth McCaughan) Date: Tue, 21 Sep 2004 15:44:01 +0100 Subject: [C++-sig] Arrays Message-ID: <200409211544.01826.gmccaughan@synaptics-uk.com> I have some C++ software that I'm wrapping using Boost.Python . Some bits of it make use of plain ol' C-style arrays. Typical (but lightly fictionalized) situation: I have a method that talks to some hardware and fills a buffer with measurements. unsigned short buffer[N_SAMPLES]; instrument.measure(&buffer[0], N_SAMPLES); And another that sends data to another piece of hardware. long waveform[N_SAMPLES]; for (int i=0; i((1<<24)*sin(0.01*i)); instrument.drive(&waveform[0], N_SAMPLES); I would like to be able to provide access to all this from Python. One approach would be to change everything to use vectors rather than arrays; after all, they are guaranteed to store their data contiguously. Then I could use the indexing_suite. That would probably be manageable, but I'd rather not have to change all the code. Is there anything easier I can do? The ideal would be to be able to say buffer = [0]*N_SAMPLES instrument.measure(buffer, N_SAMPLES) and waveform = [(1<<24)*math.sin(0.01*i) for i in range(N_SAMPLES)] instrument.drive(waveform, N_SAMPLES) and have it Just Work (tm). I'd settle for something nearer to buffer = c_array_short(N_SAMPLES) instrument.measure(buffer, N_SAMPLES) and waveform = c_array_long(N_SAMPLES) for i in range(N_SAMPLES): waveform[i] = (1<<24)*math.sin(0.01*i) instrument.drive(waveform, N_SAMPLES) if that's more realistic. (I don't need to be able to change the sizes of these arrays; I'm content if I can create them, destroy them, store data in them, and get it out again.) Is any of this possible with Boost.Python as it currently stands, and if so how? I understand that someone has worked on a new version of the indexing_suite that somehow makes it easier to work with arrays, but (unless I'm confused) this is not in any released version of Boost.Python, and the webpage that describes it[1] shows some signs of abandonment: last update in February, talking about what the author is proposing to do "this week". What's the actual state of this work? [1] http://home.clara.net/raoulgough/boost/ Thanks in advance, -- Gareth McCaughan From dave at boost-consulting.com Tue Sep 21 18:09:29 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 21 Sep 2004 12:09:29 -0400 Subject: [C++-sig] Re: Arrays References: <200409211544.01826.gmccaughan@synaptics-uk.com> Message-ID: Gareth McCaughan writes: > I have some C++ software that I'm wrapping using Boost.Python . > Some bits of it make use of plain ol' C-style arrays. Typical > (but lightly fictionalized) situation: I have a method that > talks to some hardware and fills a buffer with measurements. > > unsigned short buffer[N_SAMPLES]; > instrument.measure(&buffer[0], N_SAMPLES); > > And another that sends data to another piece of hardware. If your functions accepted array references, like this: void measure(unsigned short (&buffer)[N_SAMPLES]); it would be easier to give you a convenient solution. As it stands, the best thing I can suggest is to write thin wrappers: void measure(Instrument& i, boost::python::list b) { std::size_t len = extract(b.attr("__len__")()); boost::scoped_array b2 = new unsigned[len]; for (unsigned i = 0; i < len; ++i) b2[i] = extract(b[i]); i.measure(b, len); } Then wrap the measure function above. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From gmccaughan at synaptics-uk.com Tue Sep 21 18:38:32 2004 From: gmccaughan at synaptics-uk.com (Gareth McCaughan) Date: Tue, 21 Sep 2004 17:38:32 +0100 Subject: [C++-sig] Re: Arrays In-Reply-To: References: <200409211544.01826.gmccaughan@synaptics-uk.com> Message-ID: <200409211738.32203.gmccaughan@synaptics-uk.com> On Tuesday 2004-09-21 17:09, David Abrahams wrote: [I said:] > > I have some C++ software that I'm wrapping using Boost.Python . > > Some bits of it make use of plain ol' C-style arrays. Typical > > (but lightly fictionalized) situation: I have a method that > > talks to some hardware and fills a buffer with measurements. > > > > unsigned short buffer[N_SAMPLES]; > > instrument.measure(&buffer[0], N_SAMPLES); > > > > And another that sends data to another piece of hardware. [David:] > If your functions accepted array references, like this: > > void measure(unsigned short (&buffer)[N_SAMPLES]); > > it would be easier to give you a convenient solution. Alas... :-) > As it stands, > the best thing I can suggest is to write thin wrappers: > > void measure(Instrument& i, boost::python::list b) > { > std::size_t len = extract(b.attr("__len__")()); > boost::scoped_array b2 = new unsigned[len]; > for (unsigned i = 0; i < len; ++i) > b2[i] = extract(b[i]); > i.measure(b, len); > } > > Then wrap the measure function above. That sounds like an effective solution. (I assume that last line should refer to b2 rather than b.) ... But, in fact, I changed my mind about how much pain was involved in moving to vectors everywhere, and made the change. It turned out not to be too bad. So now the indexing_suite works fine for my needs. Sorry to have wasted your time. -- g From beyer at imb-jena.de Wed Sep 22 15:42:30 2004 From: beyer at imb-jena.de (Andreas Beyer) Date: Wed, 22 Sep 2004 15:42:30 +0200 Subject: [C++-sig] type comparison in indexing_suite_detail.hpp Message-ID: <41518146.7060807@imb-jena.de> Hi, I am using boost_python from the CVS-server (today, Sep. 22, 2004) with MinGW on WindowsXP. When compiling the example for the vector_indexing_suite I get the following two warnings: [...] ..\..\..\libs\python\test\vector_indexing_suite.cpp:54: instantiated from here C:\boost-cvs-22092004/boost/python/suite/indexing/detail/indexing_suite_detail.hpp:591: warning: comparison between signed and unsigned integer expressions [...] ..\..\..\libs\python\test\vector_indexing_suite.cpp:54: instantiated from here C:\boost-cvs-22092004/boost/python/suite/indexing/detail/indexing_suite_detail.hpp:605: warning: comparison between signed and unsigned integer expressions The follwoing code piece from indexing_suite_detail.hpp causes the trouble (from function base_get_slice_data()): [...] if (Py_None == slice->start) { // this is line 582 from_ = min_index; } else { long from = extract( slice->start); if (from < 0) // Negative slice index from += max_index; if (from < 0) // Clip lower bounds to zero from = 0; if (from > max_index) // <<< PROBLEM, line 591 from = max_index; from_ = boost::numeric_cast(from); } if (Py_None == slice->stop) { to_ = max_index; } else { long to = extract( slice->stop); if (to < 0) to += max_index; if (to < 0) to = 0; if (to > max_index) // <<< PROBLEM, line 605 to = max_index; to_ = boost::numeric_cast(to); } [...] In the two indicated lines values of type 'Index' (which is unsigned) are compared to long. We know at that point, that 'from' and 'to' are not negative. So I suggest to change the order of the cast and of the comparison to 'max_index' as follows: [...] if (from < 0) // Clip lower bounds to zero from = 0; from_ = boost::numeric_cast(from); if (from_ > max_index) // Clip upper bounds to max_index. from_ = max_index; [...] if (to < 0) to = 0; to_ = boost::numeric_cast(to); if (to_ > max_index) to_ = max_index; [...] This seems to work fine. Andreas Attached is my version of indexing_suite_detail.hpp. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: indexing_suite_detail.hpp URL: From dennis at fsmath.zbt.uni-heidelberg.de Wed Sep 22 21:04:06 2004 From: dennis at fsmath.zbt.uni-heidelberg.de (Dennis Brakhane) Date: Wed, 22 Sep 2004 21:04:06 +0200 Subject: [C++-sig] How to turn a C++-Class-instance into a boost::python::object? Message-ID: <4151CCA6.5090408@mathphys.fsk.uni-heidelberg.de> Hi. What I want to do is the following: I have a class "Foo", already wrapped and exposed to Python. Now I have a instance "foo" in C++, and want to add this instance into Python's namespace. I could define a function get_foo: Foo& get_foo() { return foo; } and expose this to Python and write python code like "foo = get_foo", but I want to do it directly in C++. I tried the following: { Foo foo; using namespace boost::python; // get main_namespace of Python interpreter etc. main_namespace["A"] = object(0); main_namespace["B"] = object(foo); } the first assignment to A works as expected, the "object(foo)" parts throws a already_set exception (which mean that it cannot convert it, AFAIK) So, my question is: what is the correct way to do this? Or isn't it possible at all. From ndbecker2 at verizon.net Wed Sep 22 22:07:13 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 22 Sep 2004 16:07:13 -0400 Subject: [C++-sig] return_internal_ref trouble (gcc341) Message-ID: This is the first time I tried return_internal_reference. I noticed that in gcc-3.4.1, complex has been changed so that real() and imag() return a ref (or const ref). Hurray! But then what's wrong here: #include #include #include #include #include #include #include using namespace boost::python; BOOST_PYTHON_MODULE(c) { typedef std::complex Complex; class_("whatever") .def ("real", (double&(Complex::*)())(&Complex::real), return_internal_reference<>()) ; } g++ -c -I /usr/local/src/boost.cvs c.cc -I /usr/include/python2.3 /usr/local/src/boost.cvs/boost/python/object/make_instance.hpp: In static member function `static PyObject* boost::python::objects::make_instance_impl::execute(Arg&) [with Arg = double*, T = double, Holder = boost::python::objects::pointer_holder, Derived = boost::python::objects::make_ptr_instance >]': /usr/local/src/boost.cvs/boost/python/to_python_indirect.hpp:96: instantiated from `static PyObject* boost::python::detail::make_reference_holder::execute(T*) [with T = double]' /usr/local/src/boost.cvs/boost/python/to_python_indirect.hpp:60: instantiated from `PyObject* boost::python::to_python_indirect::execute(const U&, mpl_::false_) const [with U = double, T = double&, MakeHolder = boost::python::detail::make_reference_holder]' /usr/local/src/boost.cvs/boost/python/to_python_indirect.hpp:37: instantiated from `PyObject* boost::python::to_python_indirect::operator()(const U&) const [with U = double, T = double&, MakeHolder = boost::python::detail::make_reference_holder]' /usr/local/src/boost.cvs/boost/python/detail/invoke.hpp:88: instantiated from `PyObject* boost::python::detail::invoke(boost::python::detail::invoke_tag_< false, true>, const RC&, F&, TC&) [with RC = boost::python::to_python_indirect, F = double&(std::complex::*)(), TC = boost::python::arg_from_python]' /usr/local/src/boost.cvs/boost/python/detail/caller.hpp:199: instantiated from `PyObject* boost::python::detail::caller_arity<1u>::impl::operator()(PyObject*, PyObject*) [with F = double&(std::complex::*)(), Policies = boost::python::return_internal_reference<1u, boost::python::default_call_policies>, Sig = boost::mpl::vector2]' /usr/local/src/boost.cvs/boost/python/object/py_function.hpp:38: instantiated from `PyObject* boost::python::objects::caller_py_function_impl::operator( (PyObject*, PyObject*) [with Caller = boost::python::detail::caller::*)(), boost::python::return_internal_reference<1u, boost::python::default_call_policies>, boost::mpl::vector2 >]' c.cc:937: instantiated from here /usr/local/src/boost.cvs/boost/python/object/make_instance.hpp:24: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>' From dave at boost-consulting.com Wed Sep 22 22:51:19 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 22 Sep 2004 16:51:19 -0400 Subject: [C++-sig] Re: return_internal_ref trouble (gcc341) References: Message-ID: "Neal D. Becker" writes: > This is the first time I tried return_internal_reference. I noticed that in > gcc-3.4.1, complex has been changed so that real() and imag() return a ref > (or const ref). Hurray! But then what's wrong here: Basically return_internal_reference only works when the referenced type is a wrapped class. Why not just return them by value? x.real() = 3 can't work in Python anyhow. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Wed Sep 22 23:12:45 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 22 Sep 2004 17:12:45 -0400 Subject: [C++-sig] Re: How to turn a C++-Class-instance into a boost::python::object? References: <4151CCA6.5090408@mathphys.fsk.uni-heidelberg.de> Message-ID: Dennis Brakhane writes: > Hi. > > What I want to do is the following: > I have a class "Foo", already wrapped and exposed to Python. > Now I have a instance "foo" in C++, and want to add this instance into > Python's namespace. I could define a function get_foo: > > Foo& get_foo() { return foo; } > > and expose this to Python and write python code like "foo = get_foo", > but I want to do it directly in C++. > > I tried the following: > > { Foo foo; > using namespace boost::python; > // get main_namespace of Python interpreter etc. > main_namespace["A"] = object(0); > main_namespace["B"] = object(foo); > } > the first assignment to A works as expected, the "object(foo)" parts > throws a already_set exception (which mean that it cannot convert it, > AFAIK) > > So, my question is: what is the correct way to do this? Or isn't it > possible at all. There are lots of ways. http://tinyurl.com/5p266 should answer your questions, I hope. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From jbrandmeyer at earthlink.net Thu Sep 23 00:22:51 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Wed, 22 Sep 2004 18:22:51 -0400 Subject: [C++-sig] Explicit failure markup Message-ID: <1095891770.14035.37.camel@illuvatar> How are the expected failures communicated to the regression testing system? I need to mark the slice test as failing on gcc-2.95.3-linux for the same reason that the other tests fail on this platform (exception translation). Thanks, -Jonathan From ndbecker2 at verizon.net Wed Sep 22 23:45:22 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Wed, 22 Sep 2004 17:45:22 -0400 Subject: [C++-sig] Re: return_internal_ref trouble (gcc341) References: Message-ID: David Abrahams wrote: > "Neal D. Becker" writes: > >> This is the first time I tried return_internal_reference. I noticed that >> in gcc-3.4.1, complex has been changed so that real() and imag() return a >> ref >> (or const ref). Hurray! But then what's wrong here: > > Basically return_internal_reference only works when the referenced > type is a wrapped class. Why not just return them by value? > > x.real() = 3 > > can't work in Python anyhow. > Oh, I thought it would. What is the purpose of return_internal_reference then? From dave at boost-consulting.com Thu Sep 23 01:45:13 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 22 Sep 2004 19:45:13 -0400 Subject: [C++-sig] Re: return_internal_ref trouble (gcc341) References: Message-ID: Neal Becker writes: > David Abrahams wrote: > >> "Neal D. Becker" writes: >> >>> This is the first time I tried return_internal_reference. I noticed that >>> in gcc-3.4.1, complex has been changed so that real() and imag() return a >>> ref >>> (or const ref). Hurray! But then what's wrong here: >> >> Basically return_internal_reference only works when the referenced >> type is a wrapped class. Why not just return them by value? >> >> x.real() = 3 >> >> can't work in Python anyhow. >> > > Oh, I thought it would. If you can't write it in pure Python, nothing Boost.Python does is going to help you. > What is the purpose of return_internal_reference > then? To return python objects that wrap _existing_ C++ class instances (without copying them) whose lifetime is controlled by "self" or one of the other arguments. Calling mutating C++ member functions on those objects from Python modifies them in place. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Thu Sep 23 01:45:54 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 22 Sep 2004 19:45:54 -0400 Subject: [C++-sig] Re: Explicit failure markup References: <1095891770.14035.37.camel@illuvatar> Message-ID: Jonathan Brandmeyer writes: > How are the expected failures communicated to the regression testing > system? I need to mark the slice test as failing on gcc-2.95.3-linux > for the same reason that the other tests fail on this platform > (exception translation). See $BOOST_ROOT/status/explicit-failures-markup.xml -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From jbrandmeyer at earthlink.net Thu Sep 23 02:32:51 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Wed, 22 Sep 2004 20:32:51 -0400 Subject: [C++-sig] Re: Explicit failure markup In-Reply-To: References: <1095891770.14035.37.camel@illuvatar> Message-ID: <1095899571.14035.51.camel@illuvatar> On Wed, 2004-09-22 at 19:45, David Abrahams wrote: > Jonathan Brandmeyer writes: > > > How are the expected failures communicated to the regression testing > > system? I need to mark the slice test as failing on gcc-2.95.3-linux > > for the same reason that the other tests fail on this platform > > (exception translation). > > See $BOOST_ROOT/status/explicit-failures-markup.xml I had seen this file, but the only reference that I can see for the python lib is (on CVS HEAD): Where is the code that causes (for example) the args test to show up as an expected failure on gcc-2.95.3-linux? Thanks, -Jonathan From joel at boost-consulting.com Thu Sep 23 03:27:20 2004 From: joel at boost-consulting.com (Joel) Date: Thu, 23 Sep 2004 09:27:20 +0800 Subject: [C++-sig] type comparison in indexing_suite_detail.hpp In-Reply-To: <41518146.7060807@imb-jena.de> References: <41518146.7060807@imb-jena.de> Message-ID: <41522678.2080600@boost-consulting.com> Andreas Beyer wrote: > Hi, > > I am using boost_python from the CVS-server (today, Sep. 22, 2004) with > MinGW on WindowsXP. > > When compiling the example for the vector_indexing_suite I get the > following two warnings: > [...] > > The follwoing code piece from indexing_suite_detail.hpp causes the > trouble (from function base_get_slice_data()): [...] > > In the two indicated lines values of type 'Index' (which is unsigned) > are compared to long. We know at that point, that 'from' and 'to' are > not negative. So I suggest to change the order of the cast and of the > comparison to 'max_index' as follows: > [...] > > This seems to work fine. Hi Andreas, I think the patch looks good. However, I suggest we apply the patch after boost 1.32 is released to avoid unwanted disruptions (there's no such thing as an "innocuous" fix ;-). Please remind me again, ok? Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Thu Sep 23 14:11:48 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 23 Sep 2004 08:11:48 -0400 Subject: [C++-sig] Re: Explicit failure markup References: <1095891770.14035.37.camel@illuvatar> <1095899571.14035.51.camel@illuvatar> Message-ID: Jonathan Brandmeyer writes: > On Wed, 2004-09-22 at 19:45, David Abrahams wrote: >> Jonathan Brandmeyer writes: >> >> > How are the expected failures communicated to the regression testing >> > system? I need to mark the slice test as failing on gcc-2.95.3-linux >> > for the same reason that the other tests fail on this platform >> > (exception translation). >> >> See $BOOST_ROOT/status/explicit-failures-markup.xml > > I had seen this file, but the only reference that I can see for the > python lib is (on CVS HEAD): > > > > > > > > > > > > > Where is the code that causes (for example) the args test to show up as > an expected failure on gcc-2.95.3-linux? I don't know. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dimour at mail.ru Thu Sep 23 15:06:31 2004 From: dimour at mail.ru (Dmitri Mouromtsev) Date: Thu, 23 Sep 2004 17:06:31 +0400 Subject: [C++-sig] Memory leaks in Python embedded in wxWindows Message-ID: <966768988.20040923170631@mail.ru> Hello all, I am using Python embedded in wxWindows application. And I've found memory leaks even in empty applications. There is an example of such application below. Without wxWindows there are no memory leaks. Sample wx program: wxWindows v. 2.5.1 BOOST v. 1.31 Python v. 2.3.3 Compiled iv VC 7.1 #include "wx/wx.h" #include "boost\python.hpp" using namespace boost::python; class MyFrame: public wxFrame { public: MyFrame::MyFrame() : wxFrame(NULL, -1, "Test") { Py_Initialize(); } MyFrame::~MyFrame() { Destroy(); Py_Finalize(); } }; class MyApp: public wxApp { public: bool OnInit() { MyFrame *frame = new MyFrame(); frame->Show(TRUE); SetTopWindow(frame); return TRUE; } }; IMPLEMENT_APP(MyApp) Any suggestion would be appreciated. Thanks. -- Best regards, Dmitri mailto:dimour at mail.ru From nick at rockstarvancouver.com Thu Sep 23 22:27:55 2004 From: nick at rockstarvancouver.com (Nick Trout) Date: Thu, 23 Sep 2004 13:27:55 -0700 Subject: [C++-sig] Memory leaks in Python embedded in wxWindows Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F8F0D259@iggy.rockstarvancouver.com> > I am using Python embedded in wxWindows application. And I've found > memory leaks even in empty applications. There is an example of such > application below. Without wxWindows there are no memory leaks. Why not use wxPython? Nick From agurtovoy at meta-comm.com Fri Sep 24 12:27:44 2004 From: agurtovoy at meta-comm.com (Aleksey Gurtovoy) Date: Fri, 24 Sep 2004 05:27:44 -0500 Subject: [C++-sig] Re: Explicit failure markup In-Reply-To: <1095899571.14035.51.camel@illuvatar> (Jonathan Brandmeyer's message of "Wed, 22 Sep 2004 20:32:51 -0400") References: <1095891770.14035.37.camel@illuvatar> <1095899571.14035.51.camel@illuvatar> Message-ID: Jonathan Brandmeyer writes: > On Wed, 2004-09-22 at 19:45, David Abrahams wrote: >> Jonathan Brandmeyer writes: >> >> > How are the expected failures communicated to the regression testing >> > system? I need to mark the slice test as failing on gcc-2.95.3-linux >> > for the same reason that the other tests fail on this platform >> > (exception translation). >> >> See $BOOST_ROOT/status/explicit-failures-markup.xml > > I had seen this file, but the only reference that I can see for the > python lib is (on CVS HEAD): > > > > > > > > > > > > > Where is the code that causes (for example) the args test to show up as > an expected failure on gcc-2.95.3-linux? Jonathan, There are two sources for expected failures: 1) Explicit markup in "status/explicit-failures-markup.xml". 2) Failures from so-called reference or last-known-good release, checked into the Boost CVS under "libs/expected_results.xml". Please see http://article.gmane.org/gmane.comp.lib.boost.devel/104708 for the rationale. The particular failures you are reffering to are coming from the second source. HTH, -- Aleksey Gurtovoy MetaCommunications Engineering From MAKCblM at mail.ru Fri Sep 24 13:01:49 2004 From: MAKCblM at mail.ru (Babitski Maxim) Date: Fri, 24 Sep 2004 15:01:49 +0400 Subject: [C++-sig] Memory leaks in Python embedded in wxWindows Message-ID: <16911071468.20040924150149@mail.ru> >> I am using Python embedded in wxWindows application. And I've found >> memory leaks even in empty applications. There is an example of such >> application below. Without wxWindows there are no memory leaks. > >Why not use wxPython? Because I have C++ program From ndbecker2 at verizon.net Fri Sep 24 15:40:55 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 24 Sep 2004 09:40:55 -0400 Subject: [C++-sig] make_constructor doc buglet Message-ID: The arguments to make_constructor() are not shown in the doc: template object make_constructor(); template object make_constructor(Policies const& policies) From dave at boost-consulting.com Sun Sep 26 17:28:48 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 26 Sep 2004 11:28:48 -0400 Subject: [C++-sig] Re: make_constructor doc buglet References: Message-ID: "Neal D. Becker" writes: > The arguments to make_constructor() are not shown in the doc: > > template > object make_constructor(); > > template > object make_constructor(Policies const& policies) This is a known issue (http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/2126948). I'm afraid it's a bit more than a buglet though, and right now nothing is being done about it. I'd still love to have a patch for this problem. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From wl at flexis.de Wed Sep 29 13:45:16 2004 From: wl at flexis.de (Wolfgang Langner) Date: Wed, 29 Sep 2004 13:45:16 +0200 Subject: [C++-sig] overloaded constructor, problem with int and bool Message-ID: Hello, I have a C++ class that can be initialized with (double, int and bool). With the following constructor it's not possible to init with a bool value: class_("Value") .def(init<>()) .def(init()) .def(init()) .def(init()); Because int is the last entry and it wins. Bool constructor is never called. example: v = Value(False) -> v = Value(0) and int constructor is called Is there a way to get this working ? I tried to change the order and got other strange results. With order .def(init()) .def(init()) .def(init()); all initializations with int are converted to use the double constructor. v = Value(10) results in a call to the double constructor and Value has the wrong type. Search trough documentation and Mailing list returned no results. Environment: Boost Version 1.31.0, VisualStudio .Net 2003 (VC7.1), Windows XP SP1. (STLPort 4.5.3) bye by Wolfgang From ndbecker2 at verizon.net Wed Sep 29 15:51:39 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 29 Sep 2004 09:51:39 -0400 Subject: [C++-sig] epydoc with boost::python Message-ID: I'm trying to use epydoc to doc my boost::python code. I ran into a problem. Here's an example: class_ (name, "IIR filter", no_init) .def ("__init__", make_constructor (from_range,ublas::vector >, default_call_policies(), (arg ("numerator"), arg ("denominator") )), "construct on IIR filter\n" "@param numerator: numerator coeffs\n" "@type numerator: vector\n" "@type denominator: vector" ) .def ("Compute", &compute_wrap,ublas::vector >, (arg ("x")), "@param x: input\n" "@type x: vector\n" "@return: vector" ) ; Running epydoc on this I get errors like this: In iir_wrap.IIR_double.__init__ docstring (line 1): --------------------------------------------------------------------------- - Warning: @param for unknown parameter numerator - Warning: @type for unknown parameter denominator - Warning: @type for unknown parameter numerator epydoc expects python code like this: def ponder(person, time): <<< notice the func args """ @param person: Who should think. @type person: L{Person} or L{Animal} @param time: How long they should think. @type time: C{int} or C{float} """ [...] while I got this: help (iir_wrap.IIR_double) Help on class IIR_double in module iir_wrap: class IIR_double(Boost.Python.instance) | IIR filter | | Method resolution order: | IIR_double | Boost.Python.instance | __builtin__.object | | Methods defined here: | | Compute(...) <<<<< here's the problem | @param x: input | @type x: vector | @return: vector | | __init__(...) | construct on IIR filter | @param numerator: numerator coeffs | @type numerator: vector | @type denominator: vector Any ideas how to fix this? From qhf at oce.nl Wed Sep 29 15:59:24 2004 From: qhf at oce.nl (Fred Houben) Date: Wed, 29 Sep 2004 15:59:24 +0200 Subject: [C++-sig] how to wrap a template function without casting Message-ID: <000a01c4a62c$86c6bdc0$6bf6bc86@oce.nl> Hello, I'm using a class resource that has a template member function called hasResource. I want to wrap this function with boost.python. I know I can cast hasResource to a function of the desired signature. The following code is an example. #include using namespace boost::python; using namespace std; class Resource { public: template void hasResource( T& value) { } }; BOOST_PYTHON_MODULE(res) { class_("Resource") .def ("hasResource", (void (Resource::*)(std::string&)) &Resource::hasResource) ; } The problem is that hasResource has to be able to take about 50 different formal parameters. I don't want to cast all of them. Is it possible to wrap hasResource without having to cast every signature? I hope someone can help me, Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.hartling at gmail.com Wed Sep 29 17:16:21 2004 From: patrick.hartling at gmail.com (Patrick Hartling) Date: Wed, 29 Sep 2004 10:16:21 -0500 Subject: [C++-sig] Boost.Python and GCC 3.4.2 Message-ID: <944f7d8e04092908161bd8ecf2@mail.gmail.com> I am running into a problem compiling Boost.Python using GCC 3.4.2. I get the following error using Boost.Python from CVS as of today: gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o In file included from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_instance.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_ptr_instance.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/to_python_indirect.hpp:11, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/arg_to_python.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/call.hpp:15, from /home/patrick/src/Boost/boost-cvs/boost/python/object_core.hpp:12, from /home/patrick/src/Boost/boost-cvs/boost/python/object.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/tuple.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/numeric.hpp:10, from /home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp:6: /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: a casts to a type other than an integral or enumeration type cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: '->' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: `&' cannot appear in a constant-expression In file included from /home/patrick/src/Boost/boost-cvs/boost/python/converter/registry.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/registered.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_instance.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_ptr_instance.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/to_python_indirect.hpp:11, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/arg_to_python.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/call.hpp:15, from /home/patrick/src/Boost/boost-cvs/boost/python/object_core.hpp:12, from /home/patrick/src/Boost/boost-cvs/boost/python/object.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/tuple.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/numeric.hpp:10, from /home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp:6: /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: '->' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: `&' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: template argument 1 is invalid /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: `value' is not a member of `' set -e "g++" -c -Wall -ftemplate-depth-255 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fno-inline -fPIC -I"bin/boost/libs/python/build" -I "/usr/local/include/python2.3" -I "/home/patrick/src/Boost/boost-cvs" -o "bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o" "/home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp" The code that GCC is complaining about is the type cast in the last term of the last statement in the following: template struct additional_instance_size { typedef instance instance_data; typedef instance instance_char; static const std::size_t value = sizeof(instance_data) - ((size_t)(&((instance_char *)0)->storage)); }; I haven't run into this problem before, and I am not sure how to go about fixing it (and submitting a patch if appropriate). I did find a semi-related discussion on another mailing list with a reference to the relevant part of the C++ Standard: http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html I have seen reports from other people on this list saying that they are using GCC 3.4 to compile Boost.Python without problems, so I may be doing something wrong. I have attached some simple test code that reproduces the compiler error. Is there a way to work around this, or is it a GCC bug? In case it makes a difference, here are the OS and compiler details: > uname -mrs FreeBSD 5.3-BETA5 i386 > g++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 -Patrick -- Patrick L. Hartling Research Assistant, VRAC http://www.137.org/patrick/ -------------- next part -------------- A non-text attachment was scrubbed... Name: const-exp.cpp Type: application/octet-stream Size: 229 bytes Desc: not available URL: From dave at boost-consulting.com Wed Sep 29 18:50:20 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 29 Sep 2004 12:50:20 -0400 Subject: [C++-sig] Re: overloaded constructor, problem with int and bool References: Message-ID: Wolfgang Langner writes: > Hello, > > I have a C++ class that can be initialized with (double, int and bool). > With the following constructor it's not possible to init with a bool value: > > class_("Value") > .def(init<>()) > .def(init()) > .def(init()) > .def(init()); > > Because int is the last entry and it wins. > Bool constructor is never called. > example: > v = Value(False) > -> v = Value(0) and int constructor is called > > Is there a way to get this working ? > > I tried to change the order and got other strange results. > With order > > .def(init()) > .def(init()) > .def(init()); > > all initializations with int are converted to use the double constructor. > v = Value(10) results in a call to the double constructor and Value > has the wrong type. > > Search trough documentation and Mailing list returned no results. Someday this will be better. In the meantime, one approach you can take is to use an injected constructor that takes a back_reference parameter, and then inspect the original PyObject* to see if its type was Bool. // untested Value* make_value(back_reference x) { if (x.source().ptr()->ob_type == PyBool_Type) return new Value(x != 0); else return new Value(x); } ... .def(init) .def(make_constructor(make_value)) HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From liwei_peng at yahoo.com Wed Sep 29 18:52:15 2004 From: liwei_peng at yahoo.com (Liwei Peng) Date: Wed, 29 Sep 2004 09:52:15 -0700 (PDT) Subject: [C++-sig] HELP: implicit converter on pointer type failed Message-ID: <20040929165215.66760.qmail@web53007.mail.yahoo.com> Hi, I am using boost python to wrap a C++ class. What I'd like to have is implict type conversion. The following is my code: // C++ part class Circle { public: Circle(float r); float get_area() const; private: float radius; }; class CircleWrapper { CircleWrapper(Circle * c); operator Circle*() const; private: Circle* circle; }; void test_circle(CircleWrapper c); // boost python part implicitly_convertible(); // python: c = Cirlce(12.1) test_circle(c) // error message Boost.Python.ArgumentError: Python argument types in test_circle(Circle) did not match C++ signature: test_circle(CircleWrapper) Can someone tell me why 'test_circle()' failed in this case? And how can I make it work? Thanks in advance, Liwei __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dave at boost-consulting.com Wed Sep 29 19:01:21 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 29 Sep 2004 13:01:21 -0400 Subject: [C++-sig] Re: how to wrap a template function without casting References: <000a01c4a62c$86c6bdc0$6bf6bc86@oce.nl> Message-ID: "Fred Houben" writes: > BOOST_PYTHON_MODULE(res) > > { > > class_("Resource") > > .def ("hasResource", (void (Resource::*)(std::string&)) &Resource::hasResource) > > ; > > } > > > > The problem is that hasResource has to be able to take about 50 different formal parameters. I don't want to cast all of them. Is it possible to wrap hasResource without having to cast every signature? Fred, your mailer is very impolite, with the extra line breaks in code, and none in regular text. All I can suggest is a metaprogramming solution, something like: // untested #include #include #include using namespace mpl::placeholders; // A function object that does the def you want for any given type struct def_hasResource { def_hasResource(class& c) : c(c) {} template void operator()(boost::type) const { void (Resource::* pmf)(T) = &Resource::hasResource; c.def("hasResource", pmf); } class& c; }; ... typedef boost::mpl::vector48< // if you have 48 types std::string&, int, double, ... > param_types; class_ c("Resource"); boost::mpl::for_each >(hasResource(c)); HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Wed Sep 29 19:05:57 2004 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 29 Sep 2004 13:05:57 -0400 Subject: [C++-sig] Re: Boost.Python and GCC 3.4.2 References: <944f7d8e04092908161bd8ecf2@mail.gmail.com> Message-ID: Patrick Hartling writes: > The code that GCC is complaining about is the type cast in the last > term of the last statement in the following: > > template > struct additional_instance_size > { > typedef instance instance_data; > typedef instance instance_char; > static const std::size_t value = sizeof(instance_data) - > ((size_t)(&((instance_char *)0)->storage)); > > > }; > > I haven't run into this problem before, and I am not sure how to go > about fixing it (and submitting a patch if appropriate). I did find a > semi-related discussion on another mailing list with a reference to > the relevant part of the C++ Standard: > > http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html > > I have seen reports from other people on this list saying that they > are using GCC 3.4 to compile Boost.Python without problems, so I may > be doing something wrong. I have attached some simple test code that > reproduces the compiler error. Is there a way to work around this, or > is it a GCC bug? It is a GCC bug, but not where you think. This expression: (&((instance_char *)0)->storage) is generated by GCC's C library sizeof() macro. sizeof is required to return an integral constant, by whatever means. So the GCC people need to stick in some special compiler magic to make it happy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From wl at flexis.de Thu Sep 30 12:50:13 2004 From: wl at flexis.de (Wolfgang Langner) Date: Thu, 30 Sep 2004 12:50:13 +0200 Subject: [C++-sig] Solution: overloaded constructor, problem with int and bool In-Reply-To: References: Message-ID: Hello, >>I have a C++ class that can be initialized with (double, int and bool). >>With the following constructor it's not possible to init with a bool value: >> >>class_("Value") >> .def(init<>()) >> .def(init()) >> .def(init()) >> .def(init()); >> >>Because int is the last entry and it wins. >>Bool constructor is never called. >>example: >>v = Value(False) >>-> v = Value(0) and int constructor is called >> >>Is there a way to get this working ? > Someday this will be better. In the meantime, one approach you can > take is to use an injected constructor that takes a > back_reference parameter, and then inspect the original PyObject* > to see if its type was Bool. > Thanks, this was the right hint for me. Tested Version: // injected constructor Value* make_Value(back_reference x) { if (x.source().ptr()->ob_type == &PyBool_Type) { return new Value(x.get() != 0); } else { return new Value(x.get()); } } ... .def(init()) .def("__init__", make_constructor(make_Value)) I hope this helps other people too. bye by Wolfgang From ndbecker2 at verizon.net Thu Sep 30 13:10:20 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 30 Sep 2004 07:10:20 -0400 Subject: [C++-sig] More on documenting boost::python Message-ID: I am trying to use epydoc with boost::python. It is almost working now, but I have one problem. Free function docs don't show up. It seems to be related to the fact that they also don't show up in python "help". For example, notice that the function "interleave" shows up in dir(), and if I explicitly ask for help on the function, but not in help(). Anyone ideas? >>> import block_interleaver_wrap >>> dir (block_interleaver_wrap) ['__doc__', '__file__', '__name__', 'block_interleaver', 'deinterleave', 'deinterleave_c', 'interleave', 'interleave_c'] >>> help (block_interleaver_wrap) Help on module block_interleaver_wrap: NAME block_interleaver_wrap - Module for Block Interleavers FILE /disk1/nbecker/shannon2/wrap/block_interleaver_wrap.so CLASSES Boost.Python.instance(__builtin__.object) block_interleaver class block_interleaver(Boost.Python.instance) | Block Interleaver | | Method resolution order: | block_interleaver | Boost.Python.instance | __builtin__.object | | Methods defined here: | | __init__(...) | __init__(size,rows,cols) | Construct a Block Interleaver. | Only full arrays are supported. | @param size: array size | @type size: int | @param rows: rows | @type rows: int | @param cols: cols | @type cols: int | | v(...) | | vinv(...) | | ---------------------------------------------------------------------- | Data and other attributes defined here: | | __instance_size__ = 44 | | ---------------------------------------------------------------------- | Data and other attributes inherited from Boost.Python.instance: | | __dict__ = | | __new__ = | T.__new__(S, ...) -> a new object with type S, a subtype of T | | __weakref__ = >> help (block_interleaver_wrap.interleave) Help on function: interleave(...) interleave(inter,x) Interleave input I{x} using interleaver I{inter}@param inter: stuff From dave at boost-consulting.com Thu Sep 30 14:02:17 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 30 Sep 2004 08:02:17 -0400 Subject: [C++-sig] Re: More on documenting boost::python References: Message-ID: "Neal D. Becker" writes: > I am trying to use epydoc with boost::python. It is almost working now, but > I have one problem. Free function docs don't show up. It seems to be > related to the fact that they also don't show up in python "help". For > example, notice that the function "interleave" shows up in dir(), > and if I explicitly ask for help on the function, but not in > help(). Anyone ideas? If you search the archives you might find some messages about this. The problem, IIRC, is that there's a complicated system of attributes on built-in Python function objects that's used by the documentation systems, and Boost.Python's functions don't supply those attributes. Patches, as always, are welcome. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From patrick.hartling at gmail.com Thu Sep 30 14:26:11 2004 From: patrick.hartling at gmail.com (Patrick Hartling) Date: Thu, 30 Sep 2004 07:26:11 -0500 Subject: [C++-sig] Re: Boost.Python and GCC 3.4.2 In-Reply-To: References: <944f7d8e04092908161bd8ecf2@mail.gmail.com> Message-ID: <944f7d8e0409300526350709e2@mail.gmail.com> On Wed, 29 Sep 2004 13:05:57 -0400, David Abrahams wrote: > Patrick Hartling writes: > > > The code that GCC is complaining about is the type cast in the last > > term of the last statement in the following: > > > > template > > struct additional_instance_size > > { > > typedef instance instance_data; > > typedef instance instance_char; > > static const std::size_t value = sizeof(instance_data) - > > ((size_t)(&((instance_char *)0)->storage)); > > > > > > }; > > > > I haven't run into this problem before, and I am not sure how to go > > about fixing it (and submitting a patch if appropriate). I did find a > > semi-related discussion on another mailing list with a reference to > > the relevant part of the C++ Standard: > > > > http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html > > > > I have seen reports from other people on this list saying that they > > are using GCC 3.4 to compile Boost.Python without problems, so I may > > be doing something wrong. I have attached some simple test code that > > reproduces the compiler error. Is there a way to work around this, or > > is it a GCC bug? > > It is a GCC bug, but not where you think. This expression: > > (&((instance_char *)0)->storage) > > is generated by GCC's C library sizeof() macro. Do you mean offsetof() here? I should have looked at the expansion of BOOST_PYTHON_OFFSETOF before going straight to the full output from the preprocessor. > sizeof is required to > return an integral constant, by whatever means. So the GCC people > need to stick in some special compiler magic to make it happy. After digging into this some more, I think that this is a FreeBSD bug. GCC 3.4.2 works just fine on Fedora Core 2 (though I haven't tried other Linux distributions). On FreeBSD, stddef.h expands offsetof() to __offsetof() (from sys/cdefs.h). __offsetof() is what generates the above code that GCC 3.4.2 does not like. I'll let the FreeBSD folks know about this in hopes of seeing it fixed before FreeBSD 5.3 gets released. Thanks for pointing me in the right direction on this. -Patrick -- Patrick L. Hartling Research Assistant, VRAC http://www.137.org/patrick/ From ndbecker2 at verizon.net Thu Sep 30 14:27:44 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 30 Sep 2004 08:27:44 -0400 Subject: [C++-sig] Re: More on documenting boost::python References: Message-ID: David Abrahams wrote: > "Neal D. Becker" writes: > >> I am trying to use epydoc with boost::python. It is almost working now, >> but >> I have one problem. Free function docs don't show up. It seems to be >> related to the fact that they also don't show up in python "help". For >> example, notice that the function "interleave" shows up in dir(), >> and if I explicitly ask for help on the function, but not in >> help(). Anyone ideas? > > If you search the archives you might find some messages about this. > The problem, IIRC, is that there's a complicated system of attributes > on built-in Python function objects that's used by the documentation > systems, and Boost.Python's functions don't supply those attributes. > Patches, as always, are welcome. > Is there a searchable archive somewhere? From jbrandmeyer at earthlink.net Thu Sep 30 14:59:38 2004 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 30 Sep 2004 08:59:38 -0400 Subject: [C++-sig] Re: Boost.Python and GCC 3.4.2 In-Reply-To: <944f7d8e0409300526350709e2@mail.gmail.com> References: <944f7d8e04092908161bd8ecf2@mail.gmail.com> <944f7d8e0409300526350709e2@mail.gmail.com> Message-ID: <1096549178.16391.11.camel@illuvatar> On Thu, 2004-09-30 at 08:26, Patrick Hartling wrote: > On Wed, 29 Sep 2004 13:05:57 -0400, David Abrahams > wrote: > > Patrick Hartling writes: > > > > > The code that GCC is complaining about is the type cast in the last > > > term of the last statement in the following: > > > > > > template > > > struct additional_instance_size > > > { > > > typedef instance instance_data; > > > typedef instance instance_char; > > > static const std::size_t value = sizeof(instance_data) - > > > ((size_t)(&((instance_char *)0)->storage)); > > > > > > > > > }; > > > > > > I haven't run into this problem before, and I am not sure how to go > > > about fixing it (and submitting a patch if appropriate). I did find a > > > semi-related discussion on another mailing list with a reference to > > > the relevant part of the C++ Standard: > > > > > > http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html > > > > > > I have seen reports from other people on this list saying that they > > > are using GCC 3.4 to compile Boost.Python without problems, so I may > > > be doing something wrong. I have attached some simple test code that > > > reproduces the compiler error. Is there a way to work around this, or > > > is it a GCC bug? > > > > It is a GCC bug, but not where you think. This expression: > > > > (&((instance_char *)0)->storage) > > > > is generated by GCC's C library sizeof() macro. > > Do you mean offsetof() here? I should have looked at the expansion of > BOOST_PYTHON_OFFSETOF before going straight to the full output from > the preprocessor. > > > sizeof is required to > > return an integral constant, by whatever means. So the GCC people > > need to stick in some special compiler magic to make it happy. > > After digging into this some more, I think that this is a FreeBSD bug. > GCC 3.4.2 works just fine on Fedora Core 2 (though I haven't tried > other Linux distributions). On FreeBSD, stddef.h expands offsetof() > to __offsetof() (from sys/cdefs.h). __offsetof() is what generates > the above code that GCC 3.4.2 does not like. I'll let the FreeBSD > folks know about this in hopes of seeing it fixed before FreeBSD 5.3 > gets released. > > Thanks for pointing me in the right direction on this. > > -Patrick I ran into a similar bug with a prerelease of GCC 3.4. The bug was ultimately corrected by the GCC team using a new __offsetof__() built-in function and a macro that calls it in the GCC-supplied stddef.h. HTH, -Jonathan From dave at boost-consulting.com Thu Sep 30 15:31:30 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 30 Sep 2004 09:31:30 -0400 Subject: [C++-sig] Re: More on documenting boost::python References: Message-ID: "Neal D. Becker" writes: > David Abrahams wrote: > >> "Neal D. Becker" writes: >> >>> I am trying to use epydoc with boost::python. It is almost working now, >>> but >>> I have one problem. Free function docs don't show up. It seems to be >>> related to the fact that they also don't show up in python "help". For >>> example, notice that the function "interleave" shows up in dir(), >>> and if I explicitly ask for help on the function, but not in >>> help(). Anyone ideas? >> >> If you search the archives you might find some messages about this. >> The problem, IIRC, is that there's a complicated system of attributes >> on built-in Python function objects that's used by the documentation >> systems, and Boost.Python's functions don't supply those attributes. >> Patches, as always, are welcome. >> > > Is there a searchable archive somewhere? http://www.boost.org/more/mailing_lists.htm#cplussig details several. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Thu Sep 30 15:32:13 2004 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 30 Sep 2004 09:32:13 -0400 Subject: [C++-sig] Re: Boost.Python and GCC 3.4.2 References: <944f7d8e04092908161bd8ecf2@mail.gmail.com> <944f7d8e0409300526350709e2@mail.gmail.com> Message-ID: Patrick Hartling writes: > On Wed, 29 Sep 2004 13:05:57 -0400, David Abrahams > wrote: >> Patrick Hartling writes: >> >> > The code that GCC is complaining about is the type cast in the last >> > term of the last statement in the following: >> > >> > template >> > struct additional_instance_size >> > { >> > typedef instance instance_data; >> > typedef instance instance_char; >> > static const std::size_t value = sizeof(instance_data) - >> > ((size_t)(&((instance_char *)0)->storage)); >> > >> > >> > }; >> > >> > I haven't run into this problem before, and I am not sure how to go >> > about fixing it (and submitting a patch if appropriate). I did find a >> > semi-related discussion on another mailing list with a reference to >> > the relevant part of the C++ Standard: >> > >> > http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html >> > >> > I have seen reports from other people on this list saying that they >> > are using GCC 3.4 to compile Boost.Python without problems, so I may >> > be doing something wrong. I have attached some simple test code that >> > reproduces the compiler error. Is there a way to work around this, or >> > is it a GCC bug? >> >> It is a GCC bug, but not where you think. This expression: >> >> (&((instance_char *)0)->storage) >> >> is generated by GCC's C library sizeof() macro. > > Do you mean offsetof() here? Uh, yeah, sorry. > I should have looked at the expansion of > BOOST_PYTHON_OFFSETOF before going straight to the full output from > the preprocessor. > >> sizeof is required to >> return an integral constant, by whatever means. So the GCC people >> need to stick in some special compiler magic to make it happy. > > After digging into this some more, I think that this is a FreeBSD bug. > GCC 3.4.2 works just fine on Fedora Core 2 (though I haven't tried > other Linux distributions). On FreeBSD, stddef.h expands offsetof() > to __offsetof() (from sys/cdefs.h). __offsetof() is what generates > the above code that GCC 3.4.2 does not like. I'll let the FreeBSD > folks know about this in hopes of seeing it fixed before FreeBSD 5.3 > gets released. > > Thanks for pointing me in the right direction on this. sure thing. Sorry for the sizeof misdirection. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From itamar at itamarst.org Thu Sep 30 23:36:16 2004 From: itamar at itamarst.org (Itamar Shtull-Trauring) Date: Thu, 30 Sep 2004 17:36:16 -0400 Subject: [C++-sig] SIGSEGV on extract_pointer Message-ID: <1096580176.25489.20.camel@sheriffpony> Platform: Redhat 7.3 on x86, gcc 2.96 (yes, it's horrible and ancient), boost 1.31. I have some code that looks like this: extract pchecker(self.attr("protocol")); if (pchecker.check()) { this->protocol = pchecker(); When running this it gets a SIGSEGV: 0x401eccb5 in boost::python::converter::get_lvalue_from_python () from /usr/local/lib/libboost_python-gcc-mt-1_31.so.1.31.0 (gdb) up #1 0x4027bcf2 in boost::python::converter::extract_pointer::extract_pointer (this=0xbfffda68, obj=0x87666ac) at /usr/local/include/boost-1_31/boost/python/extract.hpp:203 The code in question being: template inline extract_pointer::extract_pointer(PyObject* obj) : m_source(obj) , m_result( obj == Py_None ? 0 : (get_lvalue_from_python)(obj, registered_pointee::converters) ) { } Here's the fun part - it does NOT crash when I compile with -fno-inline. My code is perfectly valid, AFAICT - there is a protocol attribute there and it is of the right type. This is part of my C++/Twisted integration project. -- Itamar Shtull-Trauring http://itamarst.org