, argc=1, ubp_av=0xbfffe0e4, init=0x8052c88 <_init>, fini=0x80e54b0 <_fini>, rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbfffe0dc) at ../sysdeps/generic/libc-start.c:129 Does anyone have any idea where to go, or what might be the cause of the problem? The codebase is fairly massive, and small changes in input or the execution of the program can cause the behavior to change (and not break). If some information not included would be helpful, I would be happy to post it. Thanks for any help / feedback you can provide. -- Matt C. Anderson -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- No thank you Delmar. A third of a gopher would only arouse my appetite without bedding her back down... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From s_sourceforge at nedprod.com Thu Nov 20 23:36:51 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 20 Nov 2003 22:36:51 -0000 Subject: [C++-sig] threading problem In-Reply-To: <16317.13136.459334.144952@gohan.cs.wisc.edu> Message-ID: <3FBD4203.25103.1FBBD72F@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Nov 2003 at 15:34, manderso at cs.wisc.edu wrote: > I've been using Boost.Python in my research work for about 6 months > now, and I've just recently bumped into a problem with threading > during PyFinalize. It has me confused, and I'm not entirely sure what > path to pursue in trying to debug it. I don't expect anyone to be > able to solve the problem from the information herein, but I'm hoping > that someone will have an intuition on what *might* be the problem; > candidates that I should try to track down. Do you have that buggy version of glibc with the faulty NPTL threads implementation? It hangs randomly with mutexes. There's a fix available (new RPM for RH9 etc). Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP71CA8EcvDLFGKbPEQK3NwCfbKjxcBr9uekS7POZvram6mMx+UEAniqG rnsUm2o4pjp7WfjrHSEHsLqS =YZEA -----END PGP SIGNATURE----- From hupp at cs.wisc.edu Fri Nov 21 00:13:54 2003 From: hupp at cs.wisc.edu (Adam Hupp) Date: Thu, 20 Nov 2003 17:13:54 -0600 Subject: [C++-sig] threading problem In-Reply-To: <16317.13136.459334.144952@gohan.cs.wisc.edu> References: <16317.13136.459334.144952@gohan.cs.wisc.edu> Message-ID: <20031120231354.GA1854@upl.cs.wisc.edu> On Thu, Nov 20, 2003 at 03:34:08PM -0600, manderso at cs.wisc.edu wrote: > > I've been using Boost.Python in my research work for about 6 months > now, and I've just recently bumped into a problem with threading > during PyFinalize. It has me confused, and I'm not entirely sure what > path to pursue in trying to debug it. I don't expect anyone to be > able to solve the problem from the information herein, but I'm hoping > that someone will have an intuition on what *might* be the problem; > candidates that I should try to track down. Long time no see :) I have admittedly not read your whole mail, but I believe there is a known problem with calling PyFinalize when using boost::python. I'm sure there's something in the archives about it. -Adam From Benjamin.Golinvaux at euresys.com Fri Nov 21 12:22:26 2003 From: Benjamin.Golinvaux at euresys.com (Benjamin Golinvaux) Date: Fri, 21 Nov 2003 12:22:26 +0100 Subject: [C++-sig] Newbie : build & return a new list Message-ID: Hello I am creating a function like this : PyObject* testCreateList() { ... PyObject* newList = PyList_New(...); ... return newList; } can I assume that if I wrap it that way : def("testCreateList", testCreateList) Then will it behave correctly wrt references, i.e. is doing this : myList = myTestModule.testCreateList() the same as myList = [ .... ] ? or do I need to use the manage_new_object call policy ? I must say I don't understand when manage_new_object needs to be used. Also, and this is unrelated, is there a nicer way to create a list using boost ? I hope I'm not bothering you with my ultrabasic questions. If there is some example code I can read to help me going from the very simple tutorial to something more complex, I'd be glad to read it ! Thank you very much Benjamin -----Message d'origine----- De : c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] De la part de Adam Hupp Envoy? : vendredi 21 novembre 2003 0:14 ? : Development of Python/C++ integration Objet : Re: [C++-sig] threading problem On Thu, Nov 20, 2003 at 03:34:08PM -0600, manderso at cs.wisc.edu wrote: > > I've been using Boost.Python in my research work for about 6 months > now, and I've just recently bumped into a problem with threading > during PyFinalize. It has me confused, and I'm not entirely sure what > path to pursue in trying to debug it. I don't expect anyone to be > able to solve the problem from the information herein, but I'm hoping > that someone will have an intuition on what *might* be the problem; > candidates that I should try to track down. Long time no see :) I have admittedly not read your whole mail, but I believe there is a known problem with calling PyFinalize when using boost::python. I'm sure there's something in the archives about it. -Adam _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig **************** The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the addressee. If you are not the addressee any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this transmission by error please notify the sender immediately and then delete this email. EURESYS shall not be liable for any loss of or damage to revenues, profits, goodwill, data, information systems or other special, incidental, indirect, consequential or punitive damages of any kind arising in connection with the use of information contained in this mail or its attachments. Email transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore is in no way liable for any errors or omissions in the content of this message, which may arise as a result of email transmission. If verification is required, please request a hard copy. Please note that neither EURESYS, nor the sender accepts any responsibility for viruses and it is your responsibility to scan attachments (if any). **************** From dave at boost-consulting.com Fri Nov 21 13:33:31 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 21 Nov 2003 07:33:31 -0500 Subject: [C++-sig] Re: Newbie : build & return a new list References: Message-ID: "Benjamin Golinvaux" writes: > Hello > > I am creating a function like this : > > PyObject* testCreateList() > { > ... > PyObject* newList = PyList_New(...); > ... > return newList; > } Don't do that; use boost::python::list instead: #include using namespace boost::python; list testCreateList() { list newList; ... return newList; }; > can I assume that if I wrap it that way : > > def("testCreateList", testCreateList) > > Then will it behave correctly wrt references, > i.e. is doing this : > > myList = myTestModule.testCreateList() > > the same as > > myList = [ .... ] > > ? > > or do I need to use the manage_new_object call policy ? > I must say I don't understand when manage_new_object needs > to be used. It's used when you are returning some object you've allocated with operator new and which would otherwise be leaked. > Also, and this is unrelated, is there a nicer way to create > a list using boost ? See above ;-) > I hope I'm not bothering you with my ultrabasic questions. > If there is some example code I can read to help me going > from the very simple tutorial to something more complex, > I'd be glad to read it ! http://www.boost.org/libs/python/test/list.cpp http://www.boost.org/libs/python/test/list.py might help a bit. -- Dave Abrahams Boost Consulting www.boost-consulting.com From jonw at mindless.com Sat Nov 22 00:48:04 2003 From: jonw at mindless.com (Jonathan Warrington) Date: Fri, 21 Nov 2003 16:48:04 -0700 Subject: [C++-sig] Exposing C++ objects to Python at runtime Message-ID: I'm working on writing a generic interface for scripting, so far I have a simple javascript implementation, and a very simple python implementation. What I'm looking for, is there any way to register c++ classes / objects at runtime? What I'd like to be able to do, is pass a string, and pointers (object, and function) into my interface which would then register them at runtime (dynamically)? It looks quite possible for just straight functions, but was wondering if anyone had done something similar, or had any suggestions on how to do it? Thanks Jon From dave at boost-consulting.com Sat Nov 22 13:57:35 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 22 Nov 2003 07:57:35 -0500 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: Message-ID: Jonathan Warrington writes: > I'm working on writing a generic interface for scripting, so far I > have a simple javascript implementation, and a very simple python > implementation. > > What I'm looking for, is there any way to register c++ classes / > objects at runtime? What I'd like to be able to do, is pass a string, > and pointers (object, and function) into my interface which would then > register them at runtime (dynamically)? It looks quite possible for > just straight functions, but was wondering if anyone had done > something similar, or had any suggestions on how to do it? Boost.Python already does that. Your module initialization function executes at runtime. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Sun Nov 23 12:01:38 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Sun, 23 Nov 2003 11:01:38 +0000 Subject: [C++-sig] Re: Newbie : fastest way of sending floats References: <16316.64229.451337.394451@gull.eos.ubc.ca> Message-ID: Philip Austin writes: > Benjamin Golinvaux writes: > > > > I am not looking for the cleanest code, but for the FASTEST way > > to pass the array of floats. I am willing to use the raw C api if > > needed. > > The fastest way to pass an array of floats is to use Numerical > Python (http://www.pfdubois.com/numpy). Boost supports conversions > between numpy (and its eventual successor, numarray) and python. > Here's an example of a wrapper for a spline interpolator, which also > makes use of a boost/numpy support library available at > http://www.eos.ubc.ca/research/clouds/num_util.html > > py::numeric::array splinewrap(py::numeric::array x, py::numeric::array y, > double yp1, double ypn) > { > nbpl::check_rank(x,1); > nbpl::check_type(x,PyArray_DOUBLE); > int xsize=nbpl::size(x); > nbpl::check_rank(y,1); > nbpl::check_type(y,PyArray_DOUBLE); > int ysize=nbpl::size(y); > assert(xsize==ysize); > double* xptr=(double*) nbpl::data(x); > double* yptr=(double*) nbpl::data(y); > py::numeric::array y2=nbpl::makeNum(ysize, PyArray_DOUBLE); > double* y2ptr=(double*) nbpl::data(y2); > spline(xptr,yptr,ysize,yp1,ypn,y2ptr); > return y2; > } Another alternative would be to store the data in a C++ vector and access it from Python via the indexing suite (available in the CVS). From the looks of the above code, this would give you a more convenient interface, but there is an important performance trade-off to consider: every time you access the vector from Python, you go through the Boost.Python function dispatch code, which adds a significant overhead if the operation itself is very simple. It's not a problem when processing the entire vector in C++ via a single call from Python, but probably *is* a problem if you spend a lot of time handling or inserting single values from Python code. Here are some comparative performance results from my testing of the (indexing_v2) indexing suite: Operation on vector (sec) *Python list time (inverted) ========================= Fill: 1.95659923258 5.1706970443 Search: 0.0113099569917 0.0755311358728 (13.23957317) Reorder: 27.9347512044 7.83041287513 Sort: 0.153025035305 0.0575254278229 (17.3836169125) The test fills a vector, does some searches on it, scrambles the contents and then sorts the contents. The column at right shows the runtime relative to the same operations in pure Python using a Python list. As you can see, filling and reordering the vector (which handles values one at a time) from Python are 5 or 8 times slower, whereas the search and sort functions (which handle the whole vector in C++ via a single Python call) are 13 or 17 times faster. -- Raoul Gough. export LESS='-X' From nicodemus at esss.com.br Sun Nov 23 23:26:21 2003 From: nicodemus at esss.com.br (Nicodemus) Date: Sun, 23 Nov 2003 19:26:21 -0300 Subject: [C++-sig] tutorial html files out of date? In-Reply-To: <00da01c3a3f3$469d24f0$64646464@godzilla> References: <20031105193157.165.qmail@web20201.mail.yahoo.com> <3FA96C97.9010001@esss.com.br> <00da01c3a3f3$469d24f0$64646464@godzilla> Message-ID: <3FC1340D.3090001@esss.com.br> Joel de Guzman wrote: >Nicodemus wrote: > > >>Ralf W. Grosse-Kunstleve wrote: >> >> >> >>>Hi Joel and Bruno, >>> >>>The quickstart.txt file (in boost/libs/python/doc/tutorial/doc) seems to >>>contain much more material than is reflected in the html files in the same >>>directory. Is this something that we could fix before the 1.31 release? >>> >>> >>> >>Joel has the correctly configured quickdoc to generate the tutorial >>documentation... if Joel can't do it, I guess I can configure mine to >>handle the tutorial too (I think only the copyright needs to be changed). >> >> > >Thanks, I'd appreciate that a lot. Perhaps it's more Python savvy to >switch to ReST? I'm not sure. > > Ok, just commited the updated html files. Sorry everyone about the delay! Regards, Nicodemus. From joel at boost-consulting.com Mon Nov 24 16:30:57 2003 From: joel at boost-consulting.com (Joel de Guzman) Date: Mon, 24 Nov 2003 23:30:57 +0800 Subject: [C++-sig] tutorial html files out of date? References: <20031105193157.165.qmail@web20201.mail.yahoo.com> <3FA96C97.9010001@esss.com.br><00da01c3a3f3$469d24f0$64646464@godzilla> <3FC1340D.3090001@esss.com.br> Message-ID: <003601c3b29f$f9f82800$64646464@godzilla> Nicodemus wrote: > Joel de Guzman wrote: > Ok, just commited the updated html files. Sorry everyone about the delay! Man, you beat me to the punch! Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From jonw at mindless.com Mon Nov 24 18:03:01 2003 From: jonw at mindless.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 10:03:01 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References:

Message-ID: <3FC239C5.2050103@mindless.com> David Abrahams wrote: > Jonathan Warrington writes: > > >>I'm working on writing a generic interface for scripting, so far I >>have a simple javascript implementation, and a very simple python >>implementation. >> >>What I'm looking for, is there any way to register c++ classes / >>objects at runtime? What I'd like to be able to do, is pass a string, >>and pointers (object, and function) into my interface which would then >>register them at runtime (dynamically)? It looks quite possible for >>just straight functions, but was wondering if anyone had done >>something similar, or had any suggestions on how to do it? > > > Boost.Python already does that. Your module initialization function > executes at runtime. > Hmm, I don't think I made what I was looking for quite clear enough, sorry. What I'd like to do, is register classes, and functions without using the Boost.Python macros, as I don't want to have Boost.Python dependencies in my other code. I want to keep those dependencies in an wrapper, and not expose Python or anything to the other developers. Hopefully this makes it a little more clear. I'm having trouble expressing what I want as I'm not sure of the correct terminology for what I'm trying to do. :( thanks Jon From jon at shirwin.com Mon Nov 24 18:03:37 2003 From: jon at shirwin.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 10:03:37 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References:

Message-ID: <3FC239DA.4030401@mindless.com> David Abrahams wrote: > Jonathan Warrington writes: > > >>I'm working on writing a generic interface for scripting, so far I >>have a simple javascript implementation, and a very simple python >>implementation. >> >>What I'm looking for, is there any way to register c++ classes / >>objects at runtime? What I'd like to be able to do, is pass a string, >>and pointers (object, and function) into my interface which would then >>register them at runtime (dynamically)? It looks quite possible for >>just straight functions, but was wondering if anyone had done >>something similar, or had any suggestions on how to do it? > > > Boost.Python already does that. Your module initialization function > executes at runtime. > Hmm, I don't think I made what I was looking for quite clear enough, sorry. What I'd like to do, is register classes, and functions without using the Boost.Python macros, as I don't want to have Boost.Python dependencies in my other code. I want to keep those dependencies in an wrapper, and not expose Python or anything to the other developers. Hopefully this makes it a little more clear. I'm having trouble expressing what I want as I'm not sure of the correct terminology for what I'm trying to do. :( thanks Jon From jon at shirwin.com Mon Nov 24 18:03:37 2003 From: jon at shirwin.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 10:03:37 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References:

Message-ID: <3FC239E9.90506@shirwin.com> David Abrahams wrote: > Jonathan Warrington writes: > > >>I'm working on writing a generic interface for scripting, so far I >>have a simple javascript implementation, and a very simple python >>implementation. >> >>What I'm looking for, is there any way to register c++ classes / >>objects at runtime? What I'd like to be able to do, is pass a string, >>and pointers (object, and function) into my interface which would then >>register them at runtime (dynamically)? It looks quite possible for >>just straight functions, but was wondering if anyone had done >>something similar, or had any suggestions on how to do it? > > > Boost.Python already does that. Your module initialization function > executes at runtime. > Hmm, I don't think I made what I was looking for quite clear enough, sorry. What I'd like to do, is register classes, and functions without using the Boost.Python macros, as I don't want to have Boost.Python dependencies in my other code. I want to keep those dependencies in an wrapper, and not expose Python or anything to the other developers. Hopefully this makes it a little more clear. I'm having trouble expressing what I want as I'm not sure of the correct terminology for what I'm trying to do. :( thanks Jon From olivier.ravard at novagrid.com Mon Nov 24 19:33:34 2003 From: olivier.ravard at novagrid.com (Olivier Ravard) Date: 24 Nov 2003 19:33:34 +0100 Subject: [C++-sig] numeric::array howto Message-ID: <1069698814.2044.23.camel@trantor.univ-rennes1.fr> Hi , I want to write an interface of a given library for python and my problem is to convert internal vectors (like standards C vectors) to numeric::array. After hundred of tests, nothing works. Is there examples which show how to use numeric::array ? My problems are : - to create a numeric::array of a given size (which is known at the runtime) - to acces the number of elements of a numeric::array (v.nelements() doesn't work) - to acces to the data pointer for a memcpy. Sorry if it is an FAQ. Thanks. Olivier Ravard [image] [image] [image] NovaGrid S.A. olivier.ravard at novagrid.com WEB : http://www.novagrid.com TEL/FAX : 02 23 23 62 32 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: petitlogo.gif Type: image/gif Size: 2078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rule-blue-right.png Type: image/png Size: 207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent.png Type: image/png Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rule-blue-center.png Type: image/png Size: 160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rule-blue-left.png Type: image/png Size: 207 bytes Desc: not available URL: From s_sourceforge at nedprod.com Mon Nov 24 18:46:55 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 24 Nov 2003 17:46:55 -0000 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: <3FC239DA.4030401@mindless.com> References: Message-ID: <3FC2440F.5268.334BD5E0@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Nov 2003 at 10:03, Jonathan Warrington wrote: > > Boost.Python already does that. Your module initialization function > > executes at runtime. > > Hmm, I don't think I made what I was looking for quite clear enough, > sorry. What I'd like to do, is register classes, and functions > without using the Boost.Python macros, as I don't want to have > Boost.Python dependencies in my other code. I want to keep those > dependencies in an wrapper, and not expose Python or anything to the > other developers. > > Hopefully this makes it a little more clear. I'm having trouble > expressing what I want as I'm not sure of the correct terminology for > what I'm trying to do. :( That's easy - you hatch out all the boost.python and python stuff into its own DLL. If you want an example, http://tnfox.sourceforge.net/ provides a TnFOX C++ library with no python knowledge and a wrapper DLL called TnFOX.pyd which provides python bindings for the C++ library. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP8JED8EcvDLFGKbPEQKiDgCgnkb3XoIvY8odBloMYJ4TWnzVGdkAmweF otYkPUzvAnTdI39h6zTr2JO1 =tzoL -----END PGP SIGNATURE----- From rwgk at yahoo.com Mon Nov 24 22:13:12 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Mon, 24 Nov 2003 13:13:12 -0800 (PST) Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: <3FC239E9.90506@shirwin.com> Message-ID: <20031124211312.89915.qmail@web20211.mail.yahoo.com> --- Jonathan Warrington wrote: > Hmm, I don't think I made what I was looking for quite clear enough, > sorry. What I'd like to do, is register classes, and functions without > using the Boost.Python macros, as I don't want to have Boost.Python > dependencies in my other code. I want to keep those dependencies in an > wrapper, and not expose Python or anything to the other developers. That's what Boost.Python is designed for: non-intrusive wrapping. Macros are not used very much. Most of the work is done with templates. I am afraid I still don't know what your actual question is. Did you already work through some simple examples? The tutorial is a very good starting point. Ralf __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From jon at shirwin.com Mon Nov 24 23:17:28 2003 From: jon at shirwin.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 15:17:28 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: <20031124211312.89915.qmail@web20211.mail.yahoo.com> References: <3FC239E9.90506@shirwin.com> <20031124211312.89915.qmail@web20211.mail.yahoo.com> Message-ID: Ralf W. Grosse-Kunstleve wrote: > > That's what Boost.Python is designed for: non-intrusive wrapping. Macros are > not used very much. Most of the work is done with templates. > > I am afraid I still don't know what your actual question is. Did you already > work through some simple examples? The tutorial is a very good starting point. > > Ralf Yes I've looked at the tutorial, and all the examples use the macro BOOST_PYTHON_MODULE() which means the classes that will be scriptable will have to import the Boost.Python headers, and be compiled against Python. I want to have all my scriptable classes not need to know anything about any scripting languages, just import my scripting header (which also doesn't include Boost.Python) which has generic looking interface functions for execution, and registering functions and classes as being scriptable, and a dll which contains that actual implementations. For example (I know this isn't a javascript forum but it's an example) I also have a javascript dll implementing the same interface which for the "register function" function will take a name string (what it'll called in the script) and a function pointer (the function to be called.) So there is nothing language specific in the interface but the dll does parameter conversions between the javascript types, and c++ types. I've been sidetracked with other work today, but just looking through the straight Python C API I think I can get functions working like I have them working in javascript, but I would like to be able to register classes as well. The vague start of the interface is below, the idea is to be able to create dlls that implement the interface, so that if we want to change scripting languages for another project all we need to do, is throw a different dll in there, and then write the scripts in a new language. All the rest of the pieces of the system that register scriptable pieces don't even need to know anythings changed, as they still call the same functions to register scriptable components. //Script function takes an arg count, an arg array, and returns a value typedef void (*SCRIPT_FUNCTION)( int, ScriptVal**, ScriptVal* ); struct SW_ScriptEngine{ virtual void initialize() = 0; virtual void release() = 0; virtual ScriptVal* executeScript(String script) = 0; virtual bool registerFunction(String name, SCRIPT_FUNCTION func, String moduleName) = 0; }; From rwgk at yahoo.com Mon Nov 24 23:37:02 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Mon, 24 Nov 2003 14:37:02 -0800 (PST) Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: Message-ID: <20031124223702.24216.qmail@web20202.mail.yahoo.com> --- Jonathan Warrington wrote: > Yes I've looked at the tutorial, and all the examples use the macro > BOOST_PYTHON_MODULE() which means the classes that will be scriptable > will have to import the Boost.Python headers, and be compiled against > Python. Why would that be? You only have to compile the wrapper code using the Boost.Python headers (and with that the Python headers). your_wrapper.cpp: #include // first to meet a Python requirement #include BOOST_PYTHON_MODULE(foo) { boost::python::class_("your_class_bar"); } Compile and link against your_library.a or your_library.so. Look at the bjam toolsets to see how exactly it is done on each of the of platforms that Boost.Python was tested under (many). Ralf __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From RaoulGough at yahoo.co.uk Mon Nov 24 23:54:00 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 24 Nov 2003 22:54:00 +0000 Subject: [C++-sig] indexing_v2 status update Message-ID: Here's a status report on the indexing_v2 work I've been doing: o I've improved the handling for containers of shared_ptr's, so that sorting and searching automatically do the right indirection. o Fixed various layout and naming convention issues o container_proxy is now strongly exception safe (commit or rollback) o The container_proxy Generator parameter now works even on MSVC6 o I've added a Flags parameter to allow expensive features (in terms of object code size) to be selectively disabled. o I've added convenience templates for use without partial template specialization support (vector_suite, map_suite, etc.) These last two points bring the interface a little closer to what Joel de Guzman had originally, although the flags that he used were passed separately as individual bool parameters instead of as flag bits. He certainly wasn't kidding about the extra effort in supporting MSVC6. So as far as I know, there is no outstanding coding work remaining for the current level of functionality. I'm now updating the documentation to reflect the recent changes, and then the suite, in my opinion, will be ready for release. One possible extension I've been thinking about, as suggested by Ralf W. Grosse-Kunstleve, is the idea of allowing construction of a container from a Python iterable object: e.g. v = Vector ([1,2,3]) The ideal way to do it would be to massage the single input parameter into two C++ iterators that could be passed to the templated vector constructor, but I haven't looked far enough into the constructor dispatching internals to know how to do this, or even if it is possible. The problem, AFAICS, would be knowing when to select that overload of the constructor and when not to, and how/where to insert the necessary code to create the two iterators from the single Python object. Any advice would be appreciated. This might also be significant for another of Ralf's suggestions - pickling support. So I have two loosely related questions - what do people thing about including the current indexing_v2 suite in release 1.31, and should I try adding the iterator-based constructor support? -- Raoul Gough. export LESS='-X' From jon at shirwin.com Tue Nov 25 00:01:20 2003 From: jon at shirwin.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 16:01:20 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: <20031124223702.24216.qmail@web20202.mail.yahoo.com> References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> Message-ID: Ah, ok I think I see where the communication problem was now. What I was wanting to do, was have it so that my other components would only know of that scripting engine interface, and use that to register themselves at runtime when they are created, and therefore if my XYZ class changes all I have to do is recompile that. Not have to generate new Boost.Python registration code, and recompile that wrapper. So, App Starts App creates an instance of Scripting Engine App creates an instance of class XYZ App passes scripting engine to XYZ->Init() XYZ registers what it wants to be scriptable as scriptable So, if I want to use javascript instead, I tell App to create a javascript engine instead, and then nothing else would need to change except the scripts being called. No need to create new wrapper code. Does that make more sense as to what I'm wanting to be able to do? I'm assuming that it'd require certain restrictions on what can be registered, like the way I was doing the functions, where you can only register a specific function prototype, as long as it's not too restrictive, that's fine. Jon Ralf W. Grosse-Kunstleve wrote: > --- Jonathan Warrington wrote: > >>Yes I've looked at the tutorial, and all the examples use the macro >>BOOST_PYTHON_MODULE() which means the classes that will be scriptable >>will have to import the Boost.Python headers, and be compiled against >>Python. > > > Why would that be? You only have to compile the wrapper code using the > Boost.Python headers (and with that the Python headers). > > your_wrapper.cpp: > > #include // first to meet a Python requirement > #include > > BOOST_PYTHON_MODULE(foo) > { > boost::python::class_("your_class_bar"); > } > > Compile and link against your_library.a or your_library.so. Look at the bjam > toolsets to see how exactly it is done on each of the of platforms that > Boost.Python was tested under (many). > > Ralf > From dave at boost-consulting.com Tue Nov 25 01:31:25 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 24 Nov 2003 19:31:25 -0500 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <3FC239E9.90506@shirwin.com> <20031124211312.89915.qmail@web20211.mail.yahoo.com> Message-ID: Jonathan Warrington writes: > Ralf W. Grosse-Kunstleve wrote: >> That's what Boost.Python is designed for: non-intrusive >> wrapping. Macros are >> not used very much. Most of the work is done with templates. >> I am afraid I still don't know what your actual question is. Did you >> already >> work through some simple examples? The tutorial is a very good starting point. >> Ralf > > Yes I've looked at the tutorial, and all the examples use the macro > BOOST_PYTHON_MODULE() which means the classes that will be scriptable > will have to import the Boost.Python headers, and be compiled against > Python. Absolutely not. The wrapping code which uses the Boost.Python headers and is "compiled against" Python only needs the *declarations* of the classes being wrapped, not their definitions. Of course, you'll need to have an object file or library containing the definitions of the functions you're wrapping somewhere. > I want to have all my scriptable classes not need to know > anything about any scripting languages, Done. > just import my scripting > header (which also doesn't include Boost.Python) which has generic > looking interface functions for execution, and registering functions > and classes as being scriptable, and a dll which contains that actual > implementations. Not done. With Boost.Python you register your classes in a separate compilation unit from the rest of your code. You can even link your classes into a separate dynamic library so that they're not even in the same "link unit" with any Boost.Python code. > For example (I know this isn't a javascript forum but it's an example) > I also have a javascript dll implementing the same interface which for > the "register function" function will take a name string (what it'll > called in the script) and a function pointer (the function to be > called.) So there is nothing language specific in the interface but > the dll does parameter conversions between the javascript types, and > c++ types. > > I've been sidetracked with other work today, but just looking through > the straight Python C API I think I can get functions working like I > have them working in javascript, but I would like to be able to > register classes as well. > > The vague start of the interface is below, the idea is to be able to > create dlls that implement the interface, so that if we want to change > scripting languages for another project all we need to do, is throw a > different dll in there, and then write the scripts in a new > language. All the rest of the pieces of the system that register > scriptable pieces don't even need to know anythings changed, as they > still call the same functions to register scriptable components. > > //Script function takes an arg count, an arg array, and returns a value > typedef void (*SCRIPT_FUNCTION)( int, ScriptVal**, ScriptVal* ); > struct SW_ScriptEngine{ > virtual void initialize() = 0; > virtual void release() = 0; > virtual ScriptVal* executeScript(String script) = 0; > virtual bool registerFunction(String name, SCRIPT_FUNCTION func, > String moduleName) = 0; > }; Boost.Python doesn't work that way (and thank goodness!), so if you really are wedded to an interface like that one, I wish you good luck in your travels. I get the vague feeling that you're so used to working in a particular way that you're unable to see that Boost.Python would actually serve your needs, though I could be wrong. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Nov 25 01:35:53 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 24 Nov 2003 19:35:53 -0500 Subject: [C++-sig] Re: indexing_v2 status update References: Message-ID: Raoul Gough writes: > So I have two loosely related questions - what do people thing about > including the current indexing_v2 suite in release 1.31, 2 questions: a. Where can I browse the documentation? b. Where can I review the test code? > and should I try adding the iterator-based constructor support? IMO yes, but my opinion isn't strongly-held. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Tue Nov 25 01:12:01 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 25 Nov 2003 00:12:01 +0000 Subject: [C++-sig] Re: indexing_v2 status update References:

Message-ID: David Abrahams writes: > Raoul Gough writes: > >> So I have two loosely related questions - what do people thing about >> including the current indexing_v2 suite in release 1.31, > > 2 questions: > > a. Where can I browse the documentation? > > b. Where can I review the test code? Both are available on the indexing_v2 branch in libs/python, so you could just do an update -r indexing_v2 in that directory. The docco is then in libs/python/doc/v2/containers.html and the test code is in files like test__*.cpp and .py in libs/python/test/ Alternatively, the html-only portion of the documentation is available at: http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/python/doc/v2/Attic/containers.html?rev=1.1.2 I'm still working on some updates to this. > >> and should I try adding the iterator-based constructor support? > > IMO yes, but my opinion isn't strongly-held. I guess the real question is how to do it. I'll start looking into it a bit deeper, but I suspect I'll need some advice. Converting the Python iterable object to two C++ iterators isn't hard, but I don't know how to create the forwarding function and a sensible __iter__ overload that gets called (only) when appropriate. The problem is that there will be other container constructors that really do take just a single parameter, so how can the code decide whether to try one of them or whether to try making two C++ iterators out of the parameter. For one thing, it would be good if the code could use the normal copy constructor if passed a wrapped C++ object of the same type, or at least use C++ iterators directly rather than going through a C++ wrapper of a Python iterator that is actually a C++ iterator (C++ -> Python -> C++ dispatching). I don't know how realistic that idea is. -- Raoul Gough. export LESS='-X' From jonw at mindless.com Tue Nov 25 01:12:15 2003 From: jonw at mindless.com (Jonathan Warrington) Date: Mon, 24 Nov 2003 17:12:15 -0700 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References: <3FC239E9.90506@shirwin.com> <20031124211312.89915.qmail@web20211.mail.yahoo.com>

Message-ID: David Abrahams wrote: > > Boost.Python doesn't work that way (and thank goodness!), so if you > really are wedded to an interface like that one, I wish you good luck > in your travels. > > I get the vague feeling that you're so used to working in a particular way > that you're unable to see that Boost.Python would actually serve your > needs, though I could be wrong. > I'm not sure if it's that I'm used to working a particular way, or not (been awhile since I've coded in c++). I guess I'd come up with what I thought was a good idea for a plugable system where all that was required to change scripting languages was to change the call to CreateScriptEngine. Also not needing the developers to know anything about the scripting language, and the scripting system didn't need to know anything about the other components being written. Maybe I haven't given Boost.Python a fair enough look, I'll try to look at it without my preconceived notions of what I want, tommorrow. Thanks for all your help. Jon From RaoulGough at yahoo.co.uk Tue Nov 25 01:28:48 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 25 Nov 2003 00:28:48 +0000 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> Message-ID: Jonathan Warrington writes: > Ah, ok I think I see where the communication problem was now. > > What I was wanting to do, was have it so that my other components > would only know of that scripting engine interface, and use that to > register themselves at runtime when they are created, and therefore if > my XYZ class changes all I have to do is recompile that. Not have to > generate new Boost.Python registration code, and recompile that > wrapper. > > So, > App Starts > App creates an instance of Scripting Engine > App creates an instance of class XYZ > App passes scripting engine to XYZ->Init() > XYZ registers what it wants to be scriptable as scriptable Well, I don't know how realistic this is. IIUC, you want some kind of an abstract interface that allows you to add new functions, object types and methods to various scripting engines. In this way, your classes can expose themselves to any of the engines, while having compile-time dependencies only on the abstract interface. So consider the following: >>> //Script function takes an arg count, an arg array, and returns a >>> //value >>> typedef void (*SCRIPT_FUNCTION)( int, ScriptVal**, ScriptVal* ); >>> struct SW_ScriptEngine{ >>> virtual void initialize() = 0; >>> virtual void release() = 0; >>> virtual ScriptVal* executeScript(String script) = 0; >>> virtual bool registerFunction(String name, SCRIPT_FUNCTION >>> func, String moduleName) = 0; >>>}; class my_class { void function1(int); int function2() const; void register_self (SW_ScriptEngine *eng_ptr) { eng_ptr->registerFunction (&function1); eng_ptr->registerFunction (&function2); } }; Now the type of function1 is "void (my_class::*)(int)" and the type of function2 is "int (my_class::*)() const". How is registerFunction going to be able to deal with those member functions (and all possible others)? That's before you look at registering constructors, virtual functions and so on - in fact, all of the issues that Boost.Python already deals with in its own way. > > So, if I want to use javascript instead, I tell App to create a > javascript engine instead, and then nothing else would need to change > except the scripts being called. No need to create new wrapper code. > > Does that make more sense as to what I'm wanting to be able to do? > I'm assuming that it'd require certain restrictions on what can be > registered, like the way I was doing the functions, where you can only > register a specific function prototype, as long as it's not too > restrictive, that's fine. Separation of model, view and controller is all I can suggest (as others have already implicity done). Your XYZ classes are your model of the world, you create a script-enabled "view" on them in separate code, and control it from the scripts. Naturally, the view must be updated to reflect changes in the model. -- Raoul Gough. export LESS='-X' From dave at boost-consulting.com Tue Nov 25 02:36:22 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 24 Nov 2003 20:36:22 -0500 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <3FC239E9.90506@shirwin.com> <20031124211312.89915.qmail@web20211.mail.yahoo.com>

Message-ID: Jonathan Warrington writes: > David Abrahams wrote: >> Boost.Python doesn't work that way (and thank goodness!), so if you >> really are wedded to an interface like that one, I wish you good luck >> in your travels. >> I get the vague feeling that you're so used to working in a >> particular way >> that you're unable to see that Boost.Python would actually serve your >> needs, though I could be wrong. >> > > I'm not sure if it's that I'm used to working a particular way, or not > (been awhile since I've coded in c++). I guess I'd come up with what > I thought was a good idea for a plugable system where all that was > required to change scripting languages was to change the call to > CreateScriptEngine. Also not needing the developers to know anything > about the scripting language, and the scripting system didn't need to > know anything about the other components being written. > > Maybe I haven't given Boost.Python a fair enough look, I'll try to > look at it without my preconceived notions of what I want, > tommorrow. Thanks for all your help. I think, now that I understand what you're doing, that Boost.Python won't do what you want. Your idea is a good one, but interestingly, it appears to still be intrusive. Your classes may not need to know about Python or Boost.Python, but they do (according to you) need to know about your scripting system interface. Boost.Python lets you wrap classes that know nothing of scripting or Python. The Boost.Python C++ wrapping interface doesn't, in principle, *need* to know about Python - more could be done through runtime polymorphism, to isolate the compilation of wrappers from specific target languages, but it would be costly in the size and speed of extension modules. I think the only way this makes sense is if you need to link support for multiple languages into the same library or application. Even then, I might be inclined to use a templated (compile-time polymorphic) interface to generate relatively fast-and-small wrappers. It doesn't seem as though there's a lot to be gained by having a single copy of the wrapping logic for a class, since it will end up doing many, many dynamic dispatches. The boost-langbinding project is trying to address the question of how to unify the implementations and syntax of Boost.Python and Luabind. It would be very interesting to think about how a "write the wrapping code once" system might come out of it. -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Tue Nov 25 02:39:02 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Mon, 24 Nov 2003 17:39:02 -0800 (PST) Subject: [C++-sig] Re: indexing_v2 status update In-Reply-To: Message-ID: <20031125013902.27858.qmail@web20205.mail.yahoo.com> --- Raoul Gough wrote: > >> and should I try adding the iterator-based constructor support? > > > > IMO yes, but my opinion isn't strongly-held. I think it is really important. > I guess the real question is how to do it. I'll start looking into it > a bit deeper, but I suspect I'll need some advice. Converting the > Python iterable object to two C++ iterators isn't hard, but I don't > know how to create the forwarding function and a sensible __iter__ > overload that gets called (only) when appropriate. The problem is that > there will be other container constructors that really do take just a > single parameter, so how can the code decide whether to try one of > them or whether to try making two C++ iterators out of the parameter. > > For one thing, it would be good if the code could use the normal copy > constructor if passed a wrapped C++ object of the same type, or at > least use C++ iterators directly rather than going through a C++ > wrapper of a Python iterator that is actually a C++ iterator (C++ -> > Python -> C++ dispatching). I don't know how realistic that idea is. This sounds overly complicated to me. I believe you could get the job done in relatively little time if you started with the container conversions header from the scitbx: http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.10&view=auto Put the code in another namespace, remove to_tuple and the tuple_mapping* convenience templates. Instantiate from_python_sequence<> when a vector-style container is wrapped. Also automatically wrap the copy constructor of that vector-style container. My meta-programming is not very advanced. Therefore I dare suggesting that the from_python_sequence<> template and the copy consturctor should only be instantiated if the user supplies one of the policies (call them FromPythonSequencePolicies). Don't get side-tracked by performance considerations. If someone constructs a container from Python slow performance is expected. What counts for the Python programmer is convenience and flexibility. If you make it easy to wrap C++ containers users can quickly implement time-critical functions in C++. Ralf __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From dave at boost-consulting.com Tue Nov 25 04:38:45 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 24 Nov 2003 22:38:45 -0500 Subject: [C++-sig] Re: indexing_v2 status update References:

&) In python b= B() f(b) I think it is a Visual C++ bug, but i don't know how to bypass it. Thanks again for your help. Raoul Gough a ?crit: >Christophe Pradal writes: > > > >>Raoul Gough a ?crit: >> >> >> >>>David Abrahams writes: >>> >>> >>> >>> >>>>Raoul Gough writes: >>>> >>>> >>>> >>>> >>>>>When I build the Python tests with MSVC (7.1 beta, version 13.10.2292) >>>>>I get non-functioning DLLs. With a debug build, importing an extension >>>>>module into Python aborts silently, and with the release builds it >>>>>reports "ImportError: DLL load failed: Invalid access to memory >>>>>location." I'm reasonably sure this was working a couple of weeks ago. >>>>> >>>>> >>>>> >>>[snip] >>> >>> >>> >>>>It's working for me with vc7.1 release and a debug-python build: >>>> >>>> >>>> >>>[snip] >>> >>>Niall Douglas also reports that it works for him. I guess I must have >>>trashed something in my environment, so I'll have to track it down >>>locally. Thanks to you both for confirming this. >>> >>> >>Hello, >>I have the same problem with MSVC 6 SP5 and STLport and a recent >>boost on cvs. >>When i try to import my module, >>i have the following message >> >>File "", line 1, in ? >>ImportError: DLL load failed: Invalid access to memory location. >> >>Is Raoul solve is problem? >> >> > >No, I haven't ever figured out why this occurs, because I usually use >g++ anyway. I did determine that the generated DLLs are broken >internally in some way, for instance the dependency walker sometimes >just reports that the DLL is corrupt. I've tried different versions of >the Microsoft linker with identical results, so I was guessing that >the problem is introduced during the compilation phase. > >On the other hand, your environment is quite different to mine - I >have the beta version of the .NET compiler (MSVC 7.1 beta) and the >Microsoft-supplied (Dinkumware?) standard library. This is all very >weird, but I'll try to investigate it further. Any more details about >your experiences with this could be helpful. > > > From RaoulGough at yahoo.co.uk Wed Nov 26 19:50:30 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Wed, 26 Nov 2003 18:50:30 +0000 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> Message-ID: Daniel Wallin writes: > Raoul Gough wrote: >> David Abrahams writes: >> >>>Raoul Gough writes: >>> [snip] >> The only difficulty I've thought of would be handling return values. >> For instance, somewhere you have to have a conversion from the C++ >> return type to a PyObject * (for the Python engine) or the >> corresponding type for different engines. Maybe a double-dispatch >> would handle this, meaning a certain amount of scripting language >> dependant code in the function descriptor base class? > > I thought it would just work like: > > PyObject* python_function_wrapper() > { > function& fn = /* something */; > > const type_info* args = fn.arg_types(); > > void** storage_table = /* something */; > > for (int i = 0; i < fn.arity(); ++i) > { > void* storage = allocate_storage_for_converter(args[i]); > perform_conversion(args[i], i, storage, py_args); So perform_conversion knows (a) what the scripting engine argument type is and (b) what the required C++ argument type is. For example, you have a C++ function: void do_something (some_udt); and we need code somewhere to create a some_udt object from a PyObject *, from a lua_State * or whatever. I guess that means the function descriptor can't be truly universal, since it is supposed to be the only place that has compile-time knowledge of the C++ types involved. e.g. function<...>::convert_argument0 (PyObject *src, void *dst) { // create an arg_vector<0> type from PyObject at dst } function<...>::convert_argument0 (lua_State *src, void *dst) { // create an arg_vector<0> object from lua_State at dst } etc. > storage_table[i] = storage; > } > > void* result_storage = allocate_storage_for_converter( > fn.result_type() > ); > > fn.invoke(storage_table, result_storage); > > return perform_result_conversion( > fn.result_type() > , result_storage > ); If I'm right about the parameter conversions, then the same would apply here for the return value conversion. > } > > and function::invoke, simplified, would just do.. > > void function::invoke(void* const* args_storage, void* result_storage) > { > new (result_storage) ResultType( > m_fn( > static_cast(args_storage[0]) > , static_cast(args_storage[1]) > , etc.. > ) > ); > } > > I guess you'd also need a virtual tail call that can destroy the > result.. > > Of course, the converter lookup would be done at init time and stored. But where does the C++ code for the converter (with compile-time knowledge of the C++ types) come from? -- Raoul Gough. export LESS='-X' From RaoulGough at yahoo.co.uk Wed Nov 26 19:55:45 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Wed, 26 Nov 2003 18:55:45 +0000 Subject: [C++-sig] Re: indexing_v2 status update References: Message-ID: David Abrahams writes: > Raoul Gough writes: [snip] >> every GNU-based system I've ever worked on clears the screen by >> default on exit from less. Annoys the hell out of me, when I've just >> scanned a man page to the information that I want, hit "q" and then >> the information disappears! What morons! :-) > > YES!! you are the MAN!! Why, thank you. I knew I wasn't the only one who hated this. Glad to think it's helping someone - it took me ages to realize that it was configurable behaviour. -- Raoul Gough. export LESS='-X' From bob at redivi.com Wed Nov 26 20:10:08 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed, 26 Nov 2003 14:10:08 -0500 Subject: [C++-sig] Re: indexing_v2 status update In-Reply-To: References: Message-ID: <26AA05DE-2044-11D8-9342-000A95686CD8@redivi.com> On Nov 26, 2003, at 1:55 PM, Raoul Gough wrote: > David Abrahams writes: > >> Raoul Gough writes: > [snip] >>> every GNU-based system I've ever worked on clears the screen by >>> default on exit from less. Annoys the hell out of me, when I've just >>> scanned a man page to the information that I want, hit "q" and then >>> the information disappears! What morons! :-) >> >> YES!! you are the MAN!! > > Why, thank you. I knew I wasn't the only one who hated this. Glad to > think it's helping someone - it took me ages to realize that it was > configurable behaviour. You definitely are the man! It's always bothered me too, never looked into fixing it. Thanks! -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From dalwan01 at student.umu.se Wed Nov 26 20:40:54 2003 From: dalwan01 at student.umu.se (Daniel Wallin) Date: Wed, 26 Nov 2003 20:40:54 +0100 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> Message-ID: <3FC501C6.9080809@student.umu.se> Raoul Gough wrote: > Daniel Wallin writes: > > >>Raoul Gough wrote: >> >>>David Abrahams writes: >>> >>> >>>>Raoul Gough writes: >>>> > > [snip] > >>>The only difficulty I've thought of would be handling return values. >>>For instance, somewhere you have to have a conversion from the C++ >>>return type to a PyObject * (for the Python engine) or the >>>corresponding type for different engines. Maybe a double-dispatch >>>would handle this, meaning a certain amount of scripting language >>>dependant code in the function descriptor base class? >> >>I thought it would just work like: >> >> PyObject* python_function_wrapper() >> { >> function& fn = /* something */; >> >> const type_info* args = fn.arg_types(); >> >> void** storage_table = /* something */; >> >> for (int i = 0; i < fn.arity(); ++i) >> { >> void* storage = allocate_storage_for_converter(args[i]); >> perform_conversion(args[i], i, storage, py_args); > > > So perform_conversion knows (a) what the scripting engine argument > type is and (b) what the required C++ argument type is. For example, > you have a C++ function: > > void do_something (some_udt); > > and we need code somewhere to create a some_udt object from a PyObject > *, from a lua_State * or whatever. I guess that means the function > descriptor can't be truly universal, since it is supposed to be the > only place that has compile-time knowledge of the C++ types > involved. e.g. The code which does the actual conversion is separated from the function descriptor. perform_conversion() is completetly language dependent and just an implementation detail in this case. > function<...>::convert_argument0 (PyObject *src, void *dst) { > // create an arg_vector<0> type from PyObject at dst > } > > function<...>::convert_argument0 (lua_State *src, void *dst) { > // create an arg_vector<0> object from lua_State at dst > } That isn't necessary. function doesn't need to care about what the source type is, it just supplies the argument type_info's and invokes a function on a list of argument objects. > etc. > > >> storage_table[i] = storage; >> } >> >> void* result_storage = allocate_storage_for_converter( >> fn.result_type() >> ); >> >> fn.invoke(storage_table, result_storage); >> >> return perform_result_conversion( >> fn.result_type() >> , result_storage >> ); > > > If I'm right about the parameter conversions, then the same would > apply here for the return value conversion. > > >> } >> >>and function::invoke, simplified, would just do.. >> >> void function::invoke(void* const* args_storage, void* result_storage) >> { >> new (result_storage) ResultType( >> m_fn( >> static_cast(args_storage[0]) >> , static_cast(args_storage[1]) >> , etc.. >> ) >> ); >> } >> >>I guess you'd also need a virtual tail call that can destroy the >>result.. >> >>Of course, the converter lookup would be done at init time and stored. > > > But where does the C++ code for the converter (with compile-time > knowledge of the C++ types) come from? From anywhere the language backend wants. It doesn't matter, the only thing that matters is that the scripting backend is capable of generating instances of some types, given by const type_info*'s. We don't really need that much compile time knowledge to perform most conversions. For instance, all UDT conversions for types registered by class_<> goes through the same converter. -- Daniel Wallin From RaoulGough at yahoo.co.uk Wed Nov 26 22:53:35 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Wed, 26 Nov 2003 21:53:35 +0000 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> <3FC501C6.9080809@student.umu.se> Message-ID: Daniel Wallin writes: > Raoul Gough wrote: >> Daniel Wallin writes: [snip] >>>I thought it would just work like: >>> >>> PyObject* python_function_wrapper() >>> { >>> function& fn = /* something */; >>> >>> const type_info* args = fn.arg_types(); >>> >>> void** storage_table = /* something */; >>> >>> for (int i = 0; i < fn.arity(); ++i) >>> { >>> void* storage = allocate_storage_for_converter(args[i]); >>> perform_conversion(args[i], i, storage, py_args); >> So perform_conversion knows (a) what the scripting engine argument >> type is and (b) what the required C++ argument type is. For example, >> you have a C++ function: >> void do_something (some_udt); >> and we need code somewhere to create a some_udt object from a >> PyObject >> *, from a lua_State * or whatever. I guess that means the function >> descriptor can't be truly universal, since it is supposed to be the >> only place that has compile-time knowledge of the C++ types >> involved. e.g. > > The code which does the actual conversion is separated from the function > descriptor. perform_conversion() is completetly language dependent and > just an implementation detail in this case. The point I'm trying to make is that I believe the code in perform_conversion (at some point down the call chain) has to have compile-time knowledge of the C++ type. This means that a simple abstract base class interface will not suffice (at least, not one that is independent of the scripting language in question). > >> function<...>::convert_argument0 (PyObject *src, void *dst) { >> // create an arg_vector<0> type from PyObject at dst >> } >> function<...>::convert_argument0 (lua_State *src, void *dst) { >> // create an arg_vector<0> object from lua_State at dst >> } > > That isn't necessary. function doesn't need to care about what the > source type is, it just supplies the argument type_info's and invokes a > function on a list of argument objects. On a list of C++ arguments? I can agree with that, but I don't understand how those C++ arguments are generated without somebody who understands the scripting langauge objects also knowing what C++ types are involved. [snip] >> But where does the C++ code for the converter (with compile-time >> knowledge of the C++ types) come from? > > From anywhere the language backend wants. It doesn't matter, the only > thing that matters is that the scripting backend is capable of > generating instances of some types, given by const type_info*'s. I don't see how a type_info object will allow you to create an instance of the class it represents. All it gives you is the following: class type_info { public: virtual ~type_info(); bool operator==(const type_info& rhs) const; bool operator!=(const type_info& rhs) const; bool before(const type_info& rhs) const; const char* name() const; private: type_info(const type_info& rhs); type_info& operator=(const type_info& rhs); }; So the scripting language dependant backend receives the type_info, looks it up in its own data structures and then calls some code that knows how to convert a PyObject * (or whatever) into the UDT. My question is, where does that called code come from? > > We don't really need that much compile time knowledge to perform most > conversions. For instance, all UDT conversions for types registered by > class_<> goes through the same converter. ... which dispatches via its own lookup tables to code generated from scripting language dependant templates. For instance, take a look at boost/python/object/make_instance.hpp I'm not trying to say that there is no scope for some compile-time decoupling between the scripting engine and the registration code, just that it will never be complete. -- Raoul Gough. export LESS='-X' From RaoulGough at yahoo.co.uk Wed Nov 26 23:16:58 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Wed, 26 Nov 2003 22:16:58 +0000 Subject: [C++-sig] Re: Extension DLLs nonfunctioning with MSVC 7.1 (beta) References: <3FC385D1.7090902@cirad.fr> <3FC4B63B.2080304@cirad.fr> Message-ID: Christophe Pradal writes: > i work with Python2.3, Visual C++ SP5, STLPort . > > i have my own shared_pointer ( RefCountPtr )and want to use it with boost. > If i add an assignement operator with implicit cast: > template RefCountPtr( const RefCountPtr&ptr ) {...} > i have the following message > > ImportError: DLL load failed: Invalid access to memory location. > > But when i comment this line, all is OK. Weird. I've tracked down my problem, but I'm not sure it would explain what you've described here. In my case, it looks like I generated at some stage a different version of python22.lib for use with g++. I have to admit that I don't recall why I did this, except that the standard one probably didn't work with GNU ld for some reason. Anyway, the link command for MSVC was also picking up this .lib file (after I'd long since forgotten replacing it) and generating an invalid boost_python.dll which was crashing during __DllMainCRTStartup or __CRT_INIT. Kind of embarrasing, really. -- Raoul Gough. export LESS='-X' From s_sourceforge at nedprod.com Wed Nov 26 23:35:13 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 26 Nov 2003 22:35:13 -0000 Subject: [C++-sig] Re: Extension DLLs nonfunctioning with MSVC 7.1 (beta) In-Reply-To: Message-ID: <3FC52AA1.27130.3EA082B1@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Nov 2003 at 10:34, Raoul Gough wrote: > > Is Raoul solve is problem? > > No, I haven't ever figured out why this occurs, because I usually use > g++ anyway. I did determine that the generated DLLs are broken > internally in some way, for instance the dependency walker sometimes > just reports that the DLL is corrupt. I've tried different versions of > the Microsoft linker with identical results, so I was guessing that > the problem is introduced during the compilation phase. Have either of you guys enabled incremental linking? If so then don't, it's a bit flaky even still. Just pass /INCREMENTAL:NO to the linker. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP8UqosEcvDLFGKbPEQLIfACfWotrwGjccF0St7zr1VytXHD46dcAnAz9 Cuj2s0AAPGowQuPgZZCAI65g =fbu9 -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Wed Nov 26 23:39:40 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 26 Nov 2003 22:39:40 -0000 Subject: [C++-sig] Re: indexing_v2 status update In-Reply-To: Message-ID: <3FC52BAC.8927.3EA4955B@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Nov 2003 at 11:17, Raoul Gough wrote: > every GNU-based system I've ever worked on clears the screen by > default on exit from less. Annoys the hell out of me, when I've just > scanned a man page to the information that I want, hit "q" and then > the information disappears! What morons! :-) I guess I'm too used to GUI-based programming - been doing it since 1990 - I use that Help application with KDE to view man pages. I just really, really wish it'd let you open more than one at once :( Other trick is to have many open terminals just for viewing man pages. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP8UrrcEcvDLFGKbPEQLD2ACfasRvCvKYRopbjJzoVZiZ3rK12lEAn2uP iieCwvEGg4DXEKguCP3aZZIK =xwg/ -----END PGP SIGNATURE----- From dalwan01 at student.umu.se Thu Nov 27 10:34:59 2003 From: dalwan01 at student.umu.se (Daniel Wallin) Date: Thu, 27 Nov 2003 10:34:59 +0100 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> <3FC501C6.9080809@student.umu.se> Message-ID: <3FC5C543.5050902@student.umu.se> Raoul Gough wrote: > Daniel Wallin writes: > > >>Raoul Gough wrote: >> >>>Daniel Wallin writes: > > [snip] > >> >>The code which does the actual conversion is separated from the function >>descriptor. perform_conversion() is completetly language dependent and >>just an implementation detail in this case. > > > The point I'm trying to make is that I believe the code in > perform_conversion (at some point down the call chain) has to have > compile-time knowledge of the C++ type. This means that a simple > abstract base class interface will not suffice (at least, not one that > is independent of the scripting language in question). Custom converters aside, there are really very few conversion left that depend on the wrapped language; conversions to/from primitive types, and conversions to/from UDT's wrapped with class_<>. The UDT conversion is only dependent on the wrapped language in that it needs to be able to extract a void* to the UDT object from the argument, it doesn't require any compile time knowledge to generate code that depends on the language. >>>function<...>::convert_argument0 (PyObject *src, void *dst) { >>> // create an arg_vector<0> type from PyObject at dst >>>} >>>function<...>::convert_argument0 (lua_State *src, void *dst) { >>> // create an arg_vector<0> object from lua_State at dst >>>} >> >>That isn't necessary. function doesn't need to care about what the >>source type is, it just supplies the argument type_info's and invokes a >>function on a list of argument objects. > > > On a list of C++ arguments? I can agree with that, but I don't > understand how those C++ arguments are generated without somebody who > understands the scripting langauge objects also knowing what C++ types > are involved. The scripting language obviously has to have converters written to convert primitive types. > [snip] > >>>But where does the C++ code for the converter (with compile-time >>>knowledge of the C++ types) come from? >> >> From anywhere the language backend wants. It doesn't matter, the only >>thing that matters is that the scripting backend is capable of >>generating instances of some types, given by const type_info*'s. > > > I don't see how a type_info object will allow you to create an > instance of the class it represents. All it gives you is the > following: > > class type_info { > public: > virtual ~type_info(); > bool operator==(const type_info& rhs) const; > bool operator!=(const type_info& rhs) const; > bool before(const type_info& rhs) const; > const char* name() const; > private: > type_info(const type_info& rhs); > type_info& operator=(const type_info& rhs); > }; > > So the scripting language dependant backend receives the type_info, > looks it up in its own data structures and then calls some code that > knows how to convert a PyObject * (or whatever) into the UDT. My > question is, where does that called code come from? Like I said, in the case of a primitive type; from the language backend. In the case of a UDT (non-custom converter), extract void* and use language independent code to do the casts or instantiate the object. >>We don't really need that much compile time knowledge to perform most >>conversions. For instance, all UDT conversions for types registered by >>class_<> goes through the same converter. > > > ... which dispatches via its own lookup tables to code generated from > scripting language dependant templates. For instance, take a look at > boost/python/object/make_instance.hpp I know how the conversion process works. Just because the code you referred to couples Python-calls with the code to instantiate the C++ type in a holder doesn't mean it has to be that way. > I'm not trying to say that there is no scope for some compile-time > decoupling between the scripting engine and the registration code, > just that it will never be complete. If we ignore custom converters (which would need to be written separatly for every language backend) and policies, I think it could be. -- Daniel Wallin From christophe.pradal at cirad.fr Thu Nov 27 10:52:23 2003 From: christophe.pradal at cirad.fr (Christophe Pradal) Date: Thu, 27 Nov 2003 10:52:23 +0100 Subject: [C++-sig] smart pointer and polymorphism problem Message-ID: <3FC5C957.6040209@cirad.fr> I use an intrusive refcount pointer as described by Scott Meyers in "More effective C++" and improved by adding template casting operator (Scott Meyers again, but later). Considering RefCountObject as the base class for pointed objects and RefCountPtr the smart pointer template, I built a small example reproducing the error: class O: public virtual RefCountObject { public: O(): RefCountObject() {} virtual ~O() {} virtual int get() = 0; }; class A: public O { public: int _a; A(): O(), _a(1) {} virtual ~A( ) {} int get() {return _a;} }; typedef RCPtr OPtr; typedef RCPtr APtr; int foo(const OPtr& p) { return p->get(); } BOOST_PYTHON_MODULE(test) { class_< O, OPtr, boost::noncopyable >("O", no_init); class_< A, APtr, bases,boost::noncopyable >("A", init<>()); def( "foo",foo ); }; In python, the following test fail: >>> import test >>> a= test.A() >>> test.foo(a) Traceback (most recent call last): File "", line 1, in ? Boost.Python.ArgumentError: Python argument types in test.foo(A) did not match C++ signature: foo(class TOOLS::RefCountPtr) Any idea? -- Christophe PRADAL From RaoulGough at yahoo.co.uk Thu Nov 27 11:15:39 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Thu, 27 Nov 2003 10:15:39 +0000 Subject: [C++-sig] Re: smart pointer and polymorphism problem References: <3FC5C957.6040209@cirad.fr> Message-ID: Christophe Pradal writes: > I use an intrusive refcount pointer as described by Scott Meyers in > "More effective C++" and improved by adding template casting operator > (Scott Meyers again, but later). > Considering RefCountObject as the base class for pointed objects and > RefCountPtr the smart pointer template, I built a small example > reproducing the error: > > class O: public virtual RefCountObject > { > public: > O(): RefCountObject() {} > virtual ~O() {} > virtual int get() = 0; > }; > > class A: public O > { > public: > int _a; > A(): O(), _a(1) {} > virtual ~A( ) {} > int get() {return _a;} > }; > > typedef RCPtr OPtr; > typedef RCPtr APtr; > > int foo(const OPtr& p) { return p->get(); } > > BOOST_PYTHON_MODULE(test) > { > class_< O, OPtr, boost::noncopyable >("O", no_init); > class_< A, APtr, bases,boost::noncopyable >("A", init<>()); > def( "foo",foo ); > }; > > In python, the following test fail: > > >>> import test > >>> a= test.A() > >>> test.foo(a) > Traceback (most recent call last): > File "", line 1, in ? > Boost.Python.ArgumentError: Python argument types in > test.foo(A) > did not match C++ signature: > foo(class TOOLS::RefCountPtr) > > > Any idea? When there is an implicit conversion between types (other than derived to base conversions, I mean), you can register it with something like: boost::python::implicitly_convertible(); Of course, in this case you already have this conversion since you registered O as a base class of A. I notice that foo takes a smart pointer rather than a reference to O, so maybe you would need this: boost::python::implicitly_convertible, RefCountPtr >(); On the other hand, I'm not sure if that will work because Ptr and Ptr are only held types and not the actual class_<> types. It's worth a go I suppose, but you wouldn't have any problem if foo took an O &. -- Raoul Gough. export LESS='-X' From christophe.pradal at cirad.fr Thu Nov 27 11:33:48 2003 From: christophe.pradal at cirad.fr (Christophe Pradal) Date: Thu, 27 Nov 2003 11:33:48 +0100 Subject: [C++-sig] Re: smart pointer and polymorphism problem In-Reply-To: References: <3FC5C957.6040209@cirad.fr> Message-ID: <3FC5D30C.2030806@cirad.fr> Thank you very much. All is OK. Raoul Gough a ?crit: >Christophe Pradal writes: > > > >>I use an intrusive refcount pointer as described by Scott Meyers in >>"More effective C++" and improved by adding template casting operator >>(Scott Meyers again, but later). >>Considering RefCountObject as the base class for pointed objects and >>RefCountPtr the smart pointer template, I built a small example >>reproducing the error: >> >>class O: public virtual RefCountObject >>{ >>public: >> O(): RefCountObject() {} >> virtual ~O() {} >> virtual int get() = 0; >>}; >> >>class A: public O >>{ >>public: >> int _a; >> A(): O(), _a(1) {} >> virtual ~A( ) {} >> int get() {return _a;} >>}; >> >>typedef RCPtr OPtr; >>typedef RCPtr APtr; >> >>int foo(const OPtr& p) { return p->get(); } >> >>BOOST_PYTHON_MODULE(test) >>{ >> class_< O, OPtr, boost::noncopyable >("O", no_init); >> class_< A, APtr, bases,boost::noncopyable >("A", init<>()); >> def( "foo",foo ); >>}; >> >>In python, the following test fail: >> >> >>> import test >> >>> a= test.A() >> >>> test.foo(a) >>Traceback (most recent call last): >> File "", line 1, in ? >>Boost.Python.ArgumentError: Python argument types in >> test.foo(A) >>did not match C++ signature: >> foo(class TOOLS::RefCountPtr) >> >> >>Any idea? >> >> > >When there is an implicit conversion between types (other than derived >to base conversions, I mean), you can register it with something like: > >boost::python::implicitly_convertible(); > >Of course, in this case you already have this conversion since you >registered O as a base class of A. I notice that foo takes a smart >pointer rather than a reference to O, so maybe you would need this: > >boost::python::implicitly_convertible, RefCountPtr >(); > >On the other hand, I'm not sure if that will work because Ptr and >Ptr are only held types and not the actual class_<> types. It's >worth a go I suppose, but you wouldn't have any problem if foo took an >O &. > > > From RaoulGough at yahoo.co.uk Thu Nov 27 12:53:59 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Thu, 27 Nov 2003 11:53:59 +0000 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> <3FC501C6.9080809@student.umu.se> <3FC5C543.5050902@student.umu.se> Message-ID: Daniel Wallin writes: > Raoul Gough wrote: >> Daniel Wallin writes: >> >>>Raoul Gough wrote: >>> >>>>Daniel Wallin writes: >> [snip] >> >>> >>>The code which does the actual conversion is separated from the function >>>descriptor. perform_conversion() is completetly language dependent and >>>just an implementation detail in this case. >> The point I'm trying to make is that I believe the code in >> perform_conversion (at some point down the call chain) has to have >> compile-time knowledge of the C++ type. This means that a simple >> abstract base class interface will not suffice (at least, not one that >> is independent of the scripting language in question). > > Custom converters aside, there are really very few conversion left that > depend on the wrapped language; conversions to/from primitive types, and > conversions to/from UDT's wrapped with class_<>. The UDT conversion is > only dependent on the wrapped language in that it needs to be able to > extract a void* to the UDT object from the argument, it doesn't require > any compile time knowledge to generate code that depends on the > language. [snip] OK, I see what you mean. Once you've got a void * to the real C++ object, you can pass this through a simple abstract interface to handle value extraction, allocation, copying, destruction and so on. The templated code would then only have to provide implementations based on void * instead of per-scripting-language. Sounds very interesting for multi-language support. Implementation, anyone? -- Raoul Gough. export LESS='-X' From paul at paulgrenyer.co.uk Thu Nov 27 13:07:11 2003 From: paul at paulgrenyer.co.uk (Paul Grenyer) Date: Thu, 27 Nov 2003 12:07:11 GMT Subject: [C++-sig] Displaying PyErr_Print() error Message-ID: <200311271207.hARC7BY21012@ns.cricketthosting.co.uk> Hi I originally asked this question some weeks ago, but didn't receive a reply. I've seen from googling that other people have had this problem, but I haven't seen a solution yet. I've intergrated boost.python into a COM object and therefore there is no std::cerr console to display the error message generated by PyErr_Print() after an exception is thrown. I've tried redirecting std::cerr to a stream: catch( const error_already_set& ) { std::stringstream str; std::streambuf* streamBuffer = std::cerr.rdbuf( str.rdbuf() ); PyErr_Print(); std::cerr << python << std::endl; std::cerr.rdbuf( streamBuffer ); throw BadPython( str.str(), __FILE__, __LINE__ ); } The contents of "python", a string holding the python code that generated the exception, is correctly send to "str", but the exception message isn't. Am I doing something wrong? Is there another way to get the error generated by PyErr_Print() in a string? Regards Paul Please note the change of email address! Paul Grenyer Email: paul at paulgrenyer.co.uk Web: www.paulgrenyer.co.uk From paul at paulgrenyer.co.uk Thu Nov 27 13:14:11 2003 From: paul at paulgrenyer.co.uk (Paul Grenyer) Date: Thu, 27 Nov 2003 12:14:11 GMT Subject: [C++-sig] Boost.Python Deployment Dependencies Message-ID: <200311271214.hARCEBq21406@ns.cricketthosting.co.uk> Hi I?m in the process of trying to deploy an application that uses boost.python. I started off by just including the python23.dll (as well as the boost.python dll), but when our python code is executed via boost.python, we get an error suggesting that site.py cannot be found. I then tried installing the python interpreter and libraries as well as our new application, this worked. I then renamed the python23 directory, expecting our application to now fail. It didn?t. I am now somewhat confused about what boost.python actually depends on???? I don?t want to have to install python on every machine where we want to install our application, I want to be able to include the necessary boost.python dependencies in our install script. Any ideas? Regards Paul Please note the change of email address! Paul Grenyer Email: paul at paulgrenyer.co.uk Web: www.paulgrenyer.co.uk From dalwan01 at student.umu.se Thu Nov 27 13:19:11 2003 From: dalwan01 at student.umu.se (Daniel Wallin) Date: Thu, 27 Nov 2003 13:19:11 +0100 Subject: [C++-sig] Re: Exposing C++ objects to Python at runtime In-Reply-To: References: <20031124223702.24216.qmail@web20202.mail.yahoo.com> <3FC48415.9020200@student.umu.se> <3FC501C6.9080809@student.umu.se> <3FC5C543.5050902@student.umu.se> Message-ID: <3FC5EBBF.2070703@student.umu.se> Raoul Gough wrote: > [snip] > > OK, I see what you mean. Once you've got a void * to the real C++ > object, you can pass this through a simple abstract interface to > handle value extraction, allocation, copying, destruction and so > on. The templated code would then only have to provide implementations > based on void * instead of per-scripting-language. Sounds very > interesting for multi-language support. Implementation, anyone? Yes, we are discussing this for boost-langbinding. -- Daniel Wallin From collar at gamic.com Thu Nov 27 15:39:07 2003 From: collar at gamic.com (Benjamin Collar) Date: Thu, 27 Nov 2003 15:39:07 +0100 Subject: [C++-sig] Displaying PyErr_Print() error In-Reply-To: <200311271207.hARC7BY21012@ns.cricketthosting.co.uk> References: <200311271207.hARC7BY21012@ns.cricketthosting.co.uk> Message-ID: <200311271539.07505.collar@gamic.com> Greetings The solution I found suggests making an object in python that has a function, 'write(self, stuff)' . Anything written is kept in an instance string. Instantiate that class in the interpreter and replace sys.stderr with it. In your catch, query that object for its string. I'm not sure if this example is correct / valid / safe / anything else. However, it works for me. If anyone has any suggestions, fire away! (I'm guessing the first suggestion will be, 'why not make the OutputCatcher an exposed c++ class' Good suggestion, that; the python version was simply faster for me to implement.) try { .... python::handle<> rxa( PyRun_String("class OutputCatcher:\n" "\tdef __init__(self):\n" "\t\tself.data=''\n" "\tdef write(self, stuff):\n" "\t\tself.data = self.data + stuff\n\n" "import sys\n" "_catcher = OutputCatcher()\n" "sys.stderr = _catcher\n", Py_file_input, m_main_namespace.ptr(), m_main_namespace.ptr())); .... } catch { // this prints the exception to the catcher object. PyErr_Print(); // get the string data out of this object. QString extractedError="cannot print exception"; python::object catcher(m_main_namespace["_catcher"]); python::object cstr(catcher.attr("data")); if (char *sstr = PyString_AsString(cstr.ptr())) extractedError=sstr; } Ben On Thursday 27 November 2003 13:07, Paul Grenyer wrote: > Hi > > I originally asked this question some weeks ago, but didn't receive a > reply. I've seen from googling that other people have had this problem, > but I haven't seen a solution yet. > > I've intergrated boost.python into a COM object and therefore there is > no std::cerr console to display the error message generated by > PyErr_Print() after an exception is thrown. > > I've tried redirecting std::cerr to a stream: > > catch( const error_already_set& ) > { > std::stringstream str; > std::streambuf* streamBuffer = std::cerr.rdbuf( str.rdbuf() ); > > PyErr_Print(); > std::cerr << python << std::endl; > > std::cerr.rdbuf( streamBuffer ); > throw BadPython( str.str(), __FILE__, __LINE__ ); > } > > The contents of "python", a string holding the python code that > generated the exception, is correctly send to "str", but the exception > message isn't. > > Am I doing something wrong? Is there another way to get the error > generated by PyErr_Print() in a string? > > Regards > Paul > > Please note the change of email address! > > Paul Grenyer > Email: paul at paulgrenyer.co.uk > Web: www.paulgrenyer.co.uk > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- ---------------------------------------- (o__ Benjamin Collar //\ GAMIC mbH ++49 (0)241 889 110 V_/_ Developer/System Administrator To know recursion, you must first know recursion From rwgk at yahoo.com Thu Nov 27 18:18:54 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 27 Nov 2003 09:18:54 -0800 (PST) Subject: [C++-sig] Boost.Python Deployment Dependencies In-Reply-To: <200311271214.hARCEBq21406@ns.cricketthosting.co.uk> Message-ID: <20031127171854.17293.qmail@web20204.mail.yahoo.com> --- Paul Grenyer wrote: > I then tried installing the python interpreter and libraries as well as > our new application, this worked. I then renamed the python23 > directory, expecting our application to now fail. It didn?t. I am now > somewhat confused about what boost.python actually depends on???? I don't have an answer, but here are some related thoughts: Relocating Python under Unix works without problems, but I've not tried to do this under Windows. It would be great if it worked, but I am a bit concerned about registry entries which are global to the machine (as opposed to a login session). E.g.: C:\>assoc .py .py=Python.File C:\>ftype Python.File Python.File=C:\Python23\python.exe "%1" %* C:\>assoc .pyc .pyc=Python.CompiledFile C:\>ftype Python.CompiledFile Python.CompiledFile=C:\Python23\python.exe "%1" %* C:\>assoc .pyo .pyo=Python.CompiledFile C:\>ftype Python.CompiledFile Python.CompiledFile=C:\Python23\python.exe "%1" %* I am not sure if there are other associations. Maybe you are lucky and you don't depend on any of these? > I don?t want to have to install python on every machine where we want > to install our application, I want to be able to include the necessary > boost.python dependencies in our install script. If you figure it would be nice if you could post a summary. Ralf __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From rwgk at yahoo.com Thu Nov 27 18:23:26 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 27 Nov 2003 09:23:26 -0800 (PST) Subject: [C++-sig] Displaying PyErr_Print() error In-Reply-To: <200311271539.07505.collar@gamic.com> Message-ID: <20031127172326.85187.qmail@web20211.mail.yahoo.com> --- Benjamin Collar wrote: > 'write(self, stuff)' . Anything written is kept in an instance string. > Instantiate that class in the interpreter and replace sys.stderr with it. In > your catch, query that object for its string. A minor remark: you can use StringIO or cStringIO for this purpose. I.e. you don't have to write a class with a write method yourself. Ralf __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From s_sourceforge at nedprod.com Thu Nov 27 20:05:53 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 27 Nov 2003 19:05:53 -0000 Subject: [C++-sig] Displaying PyErr_Print() error In-Reply-To: <200311271207.hARC7BY21012@ns.cricketthosting.co.uk> Message-ID: <3FC64B11.3794.43073504@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27 Nov 2003 at 12:07, Paul Grenyer wrote: > I originally asked this question some weeks ago, but didn't receive a > reply. I've seen from googling that other people have had this > problem, but I haven't seen a solution yet. I remember us beginning to talk about this, and then going off on the tangent of whether writing to stdout appears in idle or not. > Am I doing something wrong? Is there another way to get the error > generated by PyErr_Print() in a string? I wouldn't take that approach. As it happens, very shortly I'll be doing the same thing as you want to do for my own TnFOX library - I can't see it being later than early next week, maybe even this weekend. I was going to use the Python C API to interrogate the exception object and from that build a custom FXException which is my library's exception base class. That code should solve your problems. Want me to get back to you when I'm done? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP8ZLEcEcvDLFGKbPEQLDPgCfZFvKbG+Oo4i3S63w8Pf4BrKwwvYAn3CU o1Mp9kgBZL5Y7fv8JwEuYOxJ =XTmW -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Thu Nov 27 20:09:36 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 27 Nov 2003 19:09:36 -0000 Subject: [C++-sig] Boost.Python Deployment Dependencies In-Reply-To: <200311271214.hARCEBq21406@ns.cricketthosting.co.uk> Message-ID: <3FC64BF0.4167.430A9F1A@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27 Nov 2003 at 12:14, Paul Grenyer wrote: > I then tried installing the python interpreter and libraries as well > as our new application, this worked. I then renamed the python23 > directory, expecting our application to now fail. It didn?t. I am now > somewhat confused about what boost.python actually depends on???? It probably found the installation via $PYTHON_LIB or something. > I don?t want to have to install python on every machine where we want > to install our application, I want to be able to include the necessary > boost.python dependencies in our install script. You have two choices - python needs some of its core libraries to work properly so these need supplying. Either you work out what's minimally needed and supply them or (much easier) you just install python on each machine. I personally would go for the latter because maintainence is much easier. When it comes to time for upgrades, you just upgrade. If you go for the former, there's a project on sourceforge somewhere which lets you package your python script as a Win32 executable which is totally self-contained. BitTorrent uses this. Find that and it'll give you a good head-start. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP8ZL8cEcvDLFGKbPEQKeUQCfZ5hvHmlrAryXcQGBB45ngrkmj6IAoOQJ SivMfDD2QTOA18+bywT9pQHU =uu20 -----END PGP SIGNATURE----- From paul at paulgrenyer.co.uk Fri Nov 28 09:28:07 2003 From: paul at paulgrenyer.co.uk (Paul Grenyer) Date: Fri, 28 Nov 2003 08:28:07 GMT Subject: [C++-sig] Displaying PyErr_Print() error Message-ID: <200311280828.hAS8S7X14837@ns.cricketthosting.co.uk> Hi > I wouldn't take that approach. As it happens, very shortly I'll be > doing the same thing as you want to do for my own TnFOX library - I > can't see it being later than early next week, maybe even this > weekend. I was going to use the Python C API to interrogate the > exception object and from that build a custom FXException which is my > library's exception base class. That code should solve your problems. Sounds good! > Want me to get back to you when I'm done? Yes, please!!! Regards Paul Please note the change of email address! Paul Grenyer Email: paul at paulgrenyer.co.uk Web: www.paulgrenyer.co.uk From k.dejong at geog.uu.nl Fri Nov 28 11:07:00 2003 From: k.dejong at geog.uu.nl (Kor de Jong) Date: Fri, 28 Nov 2003 11:07:00 +0100 Subject: [C++-sig] Problem using wrapped void* in Python Message-ID: <3FC71E44.7030402@geog.uu.nl> Hi all, I am trying to wrap a C struct with Boost.Python which among other members has an opaque pointer to some data, for example: // A class in C. typedef struct AClass { ENUM1 v1; void *data; } AClass; // Boost.Python code to wrap AClass. BOOST_PYTHON_MODULE(amodule) { enum_("ENUM1") .value("first", first) .value("second", second) ; class_("AClass") .def_readwrite("v1", &A::v1) .def_readwrite("data", &A::data) ; } // Python code which uses AClass. import amodule var = amodule.AClass() print var.v1 print var.data This results in the following error message when run: print var.data TypeError: No to_python (by-value) converter found for C++ type: Pv I don't want to use the value pointed to by the void pointer in Python (which can't be done anyway I suppose), I just want to copy it around and pass it to wrapped C functions again. So, what I am looking for is a way to tell Boost.Python how to convert from void* to Python and back. I have tried various things, like the opaque_pointer_converter and the to_python_converter, but I end up with code which I don't understand anymore and/or which doesn't compile. I would be very grateful if one of you could provide me with a bit of code to get me going again. Thanks in advance! Kor de Jong From jacek.generowicz at cern.ch Fri Nov 28 14:23:15 2003 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: 28 Nov 2003 14:23:15 +0100 Subject: [C++-sig] vector -> list, preserving identity Message-ID: Imagine I have wrapped (using Boost.Python) 1. a C++ class 2. a function (or method) which returns vector of pointers to said class. I would like to receive the vector as a Python list of instances of the class, but would like the identity of the objects to preserved. IOW, I want the original C++ object at the end of the pointer to be referenced by the Python object which holds it, rather than a new C++ object being instantiated. Here's a minimalized sample of source to demonstrate the situation: #include #include #include #include using namespace boost::python; struct foo { foo () { std::cout << "Creating foo at " << this << std::endl; } void pointer() { std::cout << this << std::endl; } }; std::vector makefoos(int n) { std::vector fv; for (int i=0; i("foo", no_init) .def("pointer", &foo::pointer); def ("makefoos", makefoos); } How should I write a converter for the std::vector, in order to preserve the identity of the foos ? (In the library I am wrapping, the return type of makefoos is actually const std::vector&) Thanks, From RaoulGough at yahoo.co.uk Fri Nov 28 16:29:49 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Fri, 28 Nov 2003 15:29:49 +0000 Subject: [C++-sig] Re: vector -> list, preserving identity References: Message-ID: Jacek Generowicz writes: > Imagine I have wrapped (using Boost.Python) > > 1. a C++ class > > 2. a function (or method) which returns vector of pointers to said class. > > I would like to receive the vector as a Python list of instances of > the class, but would like the identity of the objects to > preserved. IOW, I want the original C++ object at the end of the > pointer to be referenced by the Python object which holds it, rather > than a new C++ object being instantiated. > > Here's a minimalized sample of source to demonstrate the situation: > > #include > #include > #include > #include > using namespace boost::python; > > struct foo { > foo () { std::cout << "Creating foo at " << this << std::endl; } > void pointer() { std::cout << this << std::endl; } > }; > > std::vector makefoos(int n) { > std::vector fv; > for (int i=0; i fv.push_back(new foo); > } > return fv; > } > > BOOST_PYTHON_MODULE( nocopy ) { > > class_("foo", no_init) > .def("pointer", &foo::pointer); > > def ("makefoos", makefoos); > } > > > How should I write a converter for the std::vector, in order to > preserve the identity of the foos ? > > (In the library I am wrapping, the return type of makefoos is actually > const std::vector&) I'm not sure how you would handle this, except by switching to boost::shared_ptr instead of plain pointers. You would end up with something like this: std::vector > makefoos(int n) { // ... } BOOST_PYTHON_MODULE( nocopy ) { class_ >("foo", no_init) .def("pointer", &foo::pointer); class_ > > ("foo_vector") .def (SOMETHING >()); def ("makefoos", makefoos); } Where SOMETHING would use either the current indexing suite (available from CVS) or the new indexing_v2 one (available from a CVS branch). Alternatively, if you only need to iterate over the vector in Python (e.g. "for x in makefoos()"), you could use boost::python::range. None of these will work until you've got the vector element type working by itself though, hence the suggestion to switch to shared_ptr. -- Raoul Gough. export LESS='-X' From RaoulGough at yahoo.co.uk Fri Nov 28 16:46:18 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Fri, 28 Nov 2003 15:46:18 +0000 Subject: [C++-sig] Re: vector -> list, preserving identity References: Message-ID: Raoul Gough writes: > Jacek Generowicz writes: > >> Imagine I have wrapped (using Boost.Python) >> >> 1. a C++ class >> >> 2. a function (or method) which returns vector of pointers to said class. [snip] > std::vector > makefoos(int n) { > // ... > } > > BOOST_PYTHON_MODULE( nocopy ) { > class_ >("foo", no_init) > .def("pointer", &foo::pointer); > > class_ > > ("foo_vector") > .def (SOMETHING >()); > > def ("makefoos", makefoos); > } > > Where SOMETHING would use either the current indexing suite [snip] I should have mentioned the other obvious alternative - package the shared pointers directly into a real Python list. e.g. boost::python::list makefoos (int n) { boost::python::list result; for (...) { result.append (boost::shared_ptr (new ...)); } return result; } -- Raoul Gough. export LESS='-X' From RaoulGough at yahoo.co.uk Fri Nov 28 17:09:23 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Fri, 28 Nov 2003 16:09:23 +0000 Subject: [C++-sig] Re: indexing_v2 status update References: Message-ID: David Abrahams writes: > Raoul Gough writes: > >> David Abrahams writes: [snip] >>> The use of static constants in ContainerTraits is unattractive to >>> me, because it's not particularly extensible. What about asking >>> the user to provide an mpl::set of the property type tags: >>> >>> typedef mpl::set capabilities; >>> >>> or something? >> >> Looks like a good idea. I'll give this a go. > > We may need to whip mpl::set into shape. In the meantime you could > use an mpl::vector, and mpl::find which will give slightly longer > compiles but should work. Actually, I'm not so sure about the benefits of making this change now. For instance, the current boolean flag approach is the same one used in std::numeric_limits. What would you think about using bitwise-combinations of flags? I've recently introduced this as a way to disable expensive features that you don't need, and it seems pretty convenient. The only drawback I can think of is a limitation (on many systems anyway) to 32 selectable properties. Is there anything else that using mpl::set or mpl::vector would get us in terms of functionality that bitsets (or seperate bools) don't have? -- Raoul Gough. export LESS='-X' From dave at boost-consulting.com Fri Nov 28 20:40:10 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 28 Nov 2003 14:40:10 -0500 Subject: [C++-sig] Re: indexing_v2 status update References: Message-ID: Raoul Gough writes: > David Abrahams writes: > >> Raoul Gough writes: >> >>> David Abrahams writes: > [snip] >>>> The use of static constants in ContainerTraits is unattractive to >>>> me, because it's not particularly extensible. What about asking >>>> the user to provide an mpl::set of the property type tags: >>>> >>>> typedef mpl::set capabilities; >>>> >>>> or something? >>> >>> Looks like a good idea. I'll give this a go. >> >> We may need to whip mpl::set into shape. In the meantime you could >> use an mpl::vector, and mpl::find which will give slightly longer >> compiles but should work. > > Actually, I'm not so sure about the benefits of making this change > now. For instance, the current boolean flag approach is the same one > used in std::numeric_limits. numeric_limits is hardly a model of good (based on the best information we have today) design. > What would you think about using bitwise-combinations of flags? > I've recently introduced this as a way to disable expensive features > that you don't need, and it seems pretty convenient. The only > drawback I can think of is a limitation (on many systems anyway) to > 32 selectable properties. As you say, it's also limiting, but it's not terrible. > Is there anything else that using mpl::set or mpl::vector would get us > in terms of functionality that bitsets (or seperate bools) don't have? Yes. These symbolic tags can have operations built into them, so that when you process them you don't have to keep the knowledge about each one's meaning in one monolithic place. Instead you can let the tags themselves do the work, leading to better modularity and extensibility... at least, this may be possible. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Fri Nov 28 21:10:54 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Fri, 28 Nov 2003 20:10:54 +0000 Subject: [C++-sig] Re: indexing_v2 status update References: Message-ID: David Abrahams writes: > Raoul Gough writes: > >> David Abrahams writes: >> >>> Raoul Gough writes: >>> >>>> David Abrahams writes: >> [snip] >>>>> The use of static constants in ContainerTraits is unattractive to >>>>> me, because it's not particularly extensible. What about asking >>>>> the user to provide an mpl::set of the property type tags: >>>>> >>>>> typedef mpl::set capabilities; >>>>> >>>>> or something? >>>> >>>> Looks like a good idea. I'll give this a go. >>> >>> We may need to whip mpl::set into shape. In the meantime you could >>> use an mpl::vector, and mpl::find which will give slightly longer >>> compiles but should work. >> >> Actually, I'm not so sure about the benefits of making this change >> now. For instance, the current boolean flag approach is the same one >> used in std::numeric_limits. > > numeric_limits is hardly a model of good (based on the best > information we have today) design. > >> What would you think about using bitwise-combinations of flags? >> I've recently introduced this as a way to disable expensive features >> that you don't need, and it seems pretty convenient. The only >> drawback I can think of is a limitation (on many systems anyway) to >> 32 selectable properties. > > As you say, it's also limiting, but it's not terrible. It's also very cheap in terms of compile time and mangled name lengths. > >> Is there anything else that using mpl::set or mpl::vector would get us >> in terms of functionality that bitsets (or seperate bools) don't have? > > Yes. These symbolic tags can have operations built into them, so that > when you process them you don't have to keep the knowledge about each > one's meaning in one monolithic place. Instead you can let the tags > themselves do the work, leading to better modularity and > extensibility... at least, this may be possible. Interesting. I was wondering about this, because just replacing tests like traits::has_mutable_ref with traits::property_set::includes::value doesn't seem like much of a win by itself. Being able to do something like "apply each property to this class_ instance" would be a different story. This would also provide a neater way of extending the suite with new Python methods, compared to the current visitor_helper hooks. On the other hand, some of the Python methods are provided only when multiple abilities are present, e.g. "sort" requires is_reorderable and value_traits_::less_than_comparable. Such decisions are currently localized in the visitor template, the "monolithic repository" of this knowledge. I'm not sure that it would make sense to have ContainerTraits provide a ready-made set of Python methods to inject instead of just describing the relevant capabilities of the container. i.e. I'm starting to think that the capabilities are better off being just on/off flags in one form or another. -- Raoul Gough. export LESS='-X' From darylew at hotmail.com Sat Nov 29 03:06:28 2003 From: darylew at hotmail.com (Daryle Walker) Date: Fri, 28 Nov 2003 21:06:28 -0500 Subject: [C++-sig] Displaying PyErr_Print() error In-Reply-To: <200311271207.hARC7BY21012@ns.cricketthosting.co.uk> Message-ID: On 11/27/03 7:07 AM, "Paul Grenyer" wrote: > I've intergrated boost.python into a COM object and therefore there is > no std::cerr console to display the error message generated by > PyErr_Print() after an exception is thrown. I'm only on this list because I'm involved with Boost and it suggested that this list is used for Boost.Python discussion. > I've tried redirecting std::cerr to a stream: > > catch( const error_already_set& ) > { > std::stringstream str; > std::streambuf* streamBuffer = std::cerr.rdbuf( str.rdbuf() ); > > PyErr_Print(); > std::cerr << python << std::endl; > > std::cerr.rdbuf( streamBuffer ); > throw BadPython( str.str(), __FILE__, __LINE__ ); > } If you got Boost (for Boost.Python), there's a different file, called "ios_state.hpp" with a class template called "basic_ios_rdbuf_saver" that can encapsulate your stream-buffer switching under RAII. (In your code above, you could use an std::stringbuf object directly instead of a std::stringstream.) > The contents of "python", a string holding the python code that > generated the exception, is correctly send to "str", but the exception > message isn't. > > Am I doing something wrong? Is there another way to get the error > generated by PyErr_Print() in a string? A general programming suggestion: do you even know if "PyErr_Print" actually uses immediate calls to "std::cerr" in its implementation? Your plan won't work if the answer is "no". -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com From rwgk at yahoo.com Sat Nov 29 17:52:52 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Sat, 29 Nov 2003 08:52:52 -0800 (PST) Subject: [C++-sig] Problem using wrapped void* in Python In-Reply-To: <3FC71E44.7030402@geog.uu.nl> Message-ID: <20031129165252.53194.qmail@web20208.mail.yahoo.com> > So, what I am looking for is a way to tell Boost.Python how to convert > from void* to Python and back. I have tried various things, like the > opaque_pointer_converter and the to_python_converter, but I end up with > code which I don't understand anymore and/or which doesn't compile. I > would be very grateful if one of you could provide me with a bit of code > to get me going again. Recently Niall Douglas added this to the Boost.Python FAQ: http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/faq.html#voidptr Does this help in your case? Ralf __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From dave at boost-consulting.com Sat Nov 29 23:26:16 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 29 Nov 2003 17:26:16 -0500 Subject: [C++-sig] Re: Dereferenceable concept proposal References: <1068140778.13378.43.camel@pbarbier> <1068196067.6088.48.camel@pbarbier> Message-ID: Pierre Barbier de Reuille writes: > Ok, I made a patch that work for me. I hope I did not modify to many > files (there were a lot of .get not for pointers) > > The patch was simply made with a > > cvs diff > no_get.patch > > on the boost/python directory. > > Le jeu 06/11/2003 ? 22:22, David Abrahams a ?crit : >> Pierre Barbier de Reuille writes: >> >> > And perhaps this solution has tons of defaults I don't see :-/ >> >> Do you mean "implications", perhaps? > > Not really, I meant "problems" ... defaults was a frenchism :o) > > -- > Pierre Barbier de Reuille > > INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP > Botanique et Bio-informatique de l'Architecture des Plantes > TA40/PSII, Boulevard de la Lironde > 34398 MONTPELLIER CEDEX 5, France > > tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 Thanks for the patch; it's applied, with some platform workarounds to go with it, and docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com