From romany at actimize.com Mon Sep 1 14:06:13 2003 From: romany at actimize.com (Roman Yakovenko) Date: Mon, 1 Sep 2003 15:06:13 +0300 Subject: [C++-sig] module too big. Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B0F@exchange.adrembi.com> Hi Nicodemus. Thanks for your quick and helpfull responce. But it didn't help me in all cases. The reason is simple my compiler ( VC 6.0 SP 5 ) is too limited. I had to devide even single class ( 15 functions ) to 2 files. Thanks a lot for good tool. Roman. > -----Original Message----- > From: Nicodemus [mailto:nicodemus at globalite.com.br] > Sent: Friday, August 29, 2003 1:06 AM > To: Development of Python/C++ integration > Subject: Re: [C++-sig] module too big. > > > Hi Roman, > > Roman Yakovenko wrote: > > >Hi. Using Pyste I succedded to generate wrapper for my library. > >The file I got is 4000 lines. My question is how can I devide > >this file to a few small ones ? > > > > > > The support for big wrappers has improved a lot in the last > few weeks, > thanks to a combinated effort of Prabhu Ramachandran and myself. We > discussed a lot, shared lots of code, and came up with a > solution that > he and I are quite happy with it. 8) > I didn't write the documentation about it, thought, so I will > describe > the procedure here. Let's use this class hierarchy as an example: > > // A.h > struct A { /* ... */ }; > > // B.h > #include "A.h" > struct B: A { /* ... */ }; > > // C.h > #include "B.h" > struct C: B { /* ... */ }; > > First thing, you must divide your classes in multiple Pyste > files. Mind > you, Boost.Python needs base classes to be instantiated > before derived > classes, and Pyste did that automatically for you, but not > anymore, so > you have to do it by hand. Let's write one Pyste file for our > library then: > > > # mylib.pyste > Class("A", "A.h") > Class("B", "B.h") > Class("C", "C.h") > > > Notice that the base class, A, has been declared first. This is the > simplest usage. We use this command line: > > pyste.py --module=mylib mylib.pyste > > This will generate a file named "mylib.cpp" in the current directory > with all the classes exported. > > Now suppose this file is too big (as is your case) and it > takes ages to > compile, plus after any little change you do in both your code or the > Pyste file you will have to re-generate the wrapper code > (which can take > a while) and recompile it (which taks *quite* a while 8) ). > > The first step to solve this problem is to split your classes in > multiple Pyste files. Here, let's put A and B in their own Pyste file > (AB.pyste), and put C in another (C.pyste). But we have to > declare also > that C.pyste depends on AB.pyste, so that Pyste knows that A > and B are > also being exported to generate the correct code. Here are > the contents > of then: > > > # AB.pyste > Class("A", "A.h") > Class("B", "B.h") > > # C.pyste > Import("AB.pyste") # that's how we declare the dependency > Class("C", "C.h") > > > Ok, now we have to generate the code. You use the --multiple flag to > specify that your are sharing your wrapping code across > multiple cpp files: > > pyste.py --multiple --module=mylib AB.pyste > > This will generate the file mylib/_AB.cpp. > > pyste.py --multiple --module=mylib C.pyste > > This will generate the file mylib/_C.cpp. > > Those files contain the definition of the classes, but they don't > declare BOOST_PYTHON_MODULE. This is done in a separate file, > that you > create with this command line: > > pyste.py --multiple --module=mylib --generate-main > AB.pyste C.pyste > > This will generate the file mylib/_main.cpp. To correctly > generate it, > you have to pass in the command line *all* the Pyste files of your > library. Fortunately, the generation of this file is almost > instantly. ;) > > Now, we have in the mylib folder all the files needed by our library: > > _AB.cpp > _C.cpp > _main.cpp > > You now just compile them all normaly to object files, and > link them all > together. You will have an extension module as before, but with a few > advantages: > > * If you change a header file used by a Pyste file, only the > corresponding cpp of that Pyste file will have to be regenerated and > recompiled, the rest stays intact. > * Compile time will normally be reduced, since with very > big files > the memory consumption by the compiler gets out of hand. > > There's a feature that will also speed-up the re-generation of the > wrappers (not compilation), the possibility to create Pyste > caches. You > just have to add a new option to the command lines above: > "--cache-dir=". In the directory specified, Pyste > will cache > the output by GCCXML, which should give a boost of about 3 to 4 times > over the normal usage. Example: > > pyste.py --multiple --module=mylib --cache-dir=cache C.pyste > > This will generate, besides mylib/_C.cpp, a file named > cache/C.pystec. > The next time you run this same command, it should create the > wrappers > much quicker than before. But note that C.pystec depends on all the > headers of the declarations in C.pyste, so if you change C.h, > you should > re-generate the cache. You can either delete C.pystec, or run: > > pyste.py --multiple --module=mylib --cache-dir=cache > --only-create-cache C.pyste > > This will recreate the C.pystec file, but will not generate > any wrapper > code. > > > Whew! Hope that gets you moving! 8) > Feel free to ask any questions you may have! > > Regards, > Nicodemus. > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From arnaud.picard at edfgdf.fr Mon Sep 1 18:58:29 2003 From: arnaud.picard at edfgdf.fr (Arnaud PICARD) Date: Mon, 1 Sep 2003 18:58:29 +0200 Subject: [C++-sig] Cross module definition Message-ID: Hello, As I've already mentionned, I still have problems with cross def. Here you'll find an example I've used to test a method. I'm not sure I've done it right (actually I guess it's false since I can't get it to work properly) So, in these modules, I have define one as ModuleA and the other as ModuleB. They are AFAIK well written. If I import them under python, and define c = ModuleA.Cmplx( 1., 0. ), b = ModuleB.Printer(), and then try b.print1( c ) or b.print2( c ) it won't work. From arnaud.picard at edfgdf.fr Mon Sep 1 19:05:54 2003 From: arnaud.picard at edfgdf.fr (Arnaud PICARD) Date: Mon, 1 Sep 2003 18:05:54 +0100 Subject: [C++-sig] Cross module definition Message-ID: Sorry, my latest mail was sent before I'd had time to complete it... -------------------------- Hello, As I've already mentionned, I still have problems with cross def. Here you'll find an example I've used to test a method. I'm not sure I've done it right (actually I guess it's false since I can't get it to work properly) So, in these modules, I have define one as ModuleA and the other as ModuleB. They are AFAIK well written. If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b = ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't work. If I define a with ModuleB instead of ModuleA it's running. That's still the same problem I had with cross-module definition, with an example... If I remove the line define_Cmplx() from ModuleD definition, I still cannot get it to work even though I've imported first ModuleA then ModuleB. What do I have to do so that I can pull the line "define_Cmplx()" out of my ModuleB definition so that ModuleB's methods recognize my class Cmplx ? I've understood what was reponsded last time, but I have not been able to have it work properly... Thanks in avance and still sorry for the former incomplete message, Arnaud PICARD EDF R&D, Clamart Dept. SINETICS, I23 (See attached file: MyModules.tar.gz) -------------- next part -------------- A non-text attachment was scrubbed... Name: MyModules.tar.gz Type: application/octet-stream Size: 771 bytes Desc: not available URL: From romany at actimize.com Tue Sep 2 06:20:07 2003 From: romany at actimize.com (Roman Yakovenko) Date: Tue, 2 Sep 2003 07:20:07 +0300 Subject: [C++-sig] Pyste code generation. Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com> Hi Nicodemus. Today Pyste does not generate private virtual functions, right? ( in wrapper class of class that has private pure virtual ) May be it should be changed? Why ? I write wrapper for library that uses template method pattern, where customization of method done by virtual private functions. Here is the full artical http://www.gotw.ca/publications/mill18.htm. Roman From dave at boost-consulting.com Tue Sep 2 15:53:11 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 02 Sep 2003 09:53:11 -0400 Subject: [C++-sig] Re: Patch to add thread support to invoke function. References: <001c01c39c31$a36f0b40$0200a8c0@barrack> Message-ID: "Lijun Qin" writes: > Hi, > > I have made some changes to the invoke.hpp file, to add > > Py_UNBLOCK_THREADS > result = f(...); > Py_BLOCK_THREADS > > pair, this is need for too reasons: > First, if the f(...) is a lengthy operation, it'll block all Python code to > execute, this is not good, > second, if f(...) function call some functions that will acquire the python > global lock, it'll deadlock, one example is the COM inproc server using > Pythoncom22.dll, every COM interface method will first call > PyEval_AcquireThread, but the global lock has been held, so deadlock occur. Hi Lijun, I'm not ignoring your patches. Here's my reservation about accepting this one, though: I don't think it represents a complete solution to threading support in Boost.Python, and I'd like to solve the problem all at once. On way in which this doesn't handle the problem is that if f takes any object, str, dict, handle<>, etc. parameters by value, the call may crash the interpreter as reference counts are changed with threading unblocked. My guess is that the right solution is to simply not unblock threads for those functions, since they are hand-written with Boost.Python in mind and the author can unblock threads manually if neccessary (with a "unguard" object). Another way in which your patch is inadequate is that any code in Py_BLOCK_THREADS will get skipped if f throws an exception, so we really need guard objects which use RAII. Another way is that virtual functions which call back into Python with call_method need to re-acquire the GIL somehow -- it's not yet clear to me whether that should happen inside or outside call_method. The following are references to some threads in which these issues have been discussed, should you wish to explore further: http://aspn.activestate.com/ASPN/Mail/Message/1465959 http://aspn.activestate.com/ASPN/Mail/Message/1603259 http://aspn.activestate.com/ASPN/Mail/Message/1607050 http://aspn.activestate.com/ASPN/Mail/Message/1706806 -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Wed Sep 3 02:39:17 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Wed, 3 Sep 2003 08:39:17 +0800 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> Message-ID: <00de01c371b4$51acd8c0$64646464@godzilla> Raoul Gough wrote: > "Joel de Guzman" writes: > Well, I've had a go anyway. I've produced a container_proxy template > that wraps a random-access container and provides access via element > proxies. The element proxies provide an implicit conversion to the raw > value type, and also a constructor from the raw value type, which > means that it works with an unchanged[*1] vector_indexing_suite as > follows: > > vector_indexing_suite, true> This is great! Did the current tests pass with the new code? > i.e. the wrapped vector with no proxy. This is functionally more or > less equivalent to vector_indexing_suite, i.e. the raw > vector *with* the proxy helper. > > [*1] Actually, it does require a minor patch to make > vector_indexing_suite use the container's reference typedef rather > than data_type & > > Note that I say "more or less" equivalent, since there seems to be a > bug in the existing proxy support. Using vector, where > IntWrapper is a simple int holder with optional tracing, the following > snippet doesn't work correctly: > > copy = v[1] > print "copy is %s, v[1] is %s" % (copy, v[1]) > > v[1] = IntWrapper (5) > print "copy is %s, v[1] is %s" % (copy, v[1]) > > Sample output: > > copy is 3, v[1] is 3 > copy is 5, v[1] is 5 # Wrong - copy should remain unchanged > > The container_proxy wrapper fixes that problem (whatever it is, > probably minor) but doesn't fix the following additional problem, that > both versions exhibit: Indeed. It's nice to hear that container_proxy fixed this. > slice = v[1:2] > print "slice[0] is %s, v[1] is %s" % (slice[0], v[1]) > > v[1].increment() > print "slice[0] is %s, v[1] is %s" % (slice[0], v[1]) > > Sample output: > > slice[0] is 5, v[1] is 5 > slice[0] is 5, v[1] is 6 # Should be slice[0] is 6, v[1] is 6 > > This may be a fundamental problem with how slices are returned. > Compiler is gcc 3.3.1 (mingw special 20030804-1). Right. slices are currently returned by value. I guess this is another area to be explored. I think I know how to deal with it. Let's do it when we refactor the slicing stuff. I think this is a good start. There are lots of things to do and I certainly am glad that you can help. I've already been bitten by the wholesale approach of the current indexing suites (more on that later) that I really need to break it up sometime soon! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From qinlj at solidshare.com Wed Sep 3 02:20:43 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Wed, 3 Sep 2003 08:20:43 +0800 Subject: [C++-sig] Re: Patch to add thread support to invoke function. References: <001c01c39c31$a36f0b40$0200a8c0@barrack> Message-ID: <002b01c371b1$3b138170$0200a8c0@barrack> Hi, I think a better solution is to give the user choice, I mean use a flag which can be passed when calling 'def', such as .def('f', f, enableThreadLock) Currently I'm using boost.python to wrap WTL, and it has hundreds of functions which are simple SendMessage wrappers, and many of them (I think half of them, almost all 'write' operation) can cause callback into the python code again, use the notify message such as WM_COMMAND, WM_NOTIFY. So write wrapper for every one of them is not acceptable. The callback will be implemented use call_method<> normally, but the thread acquiring will not be done is call_method, it'll normally be done earlier in the very point the control transferred from the 'outside world' to the python extension module, in the Windows platform, this will normally at the beginning of COM interface method, Window Procedure, or DLL exported function (this is rare I think). If we can implement the 'enableThreadLock' flag, but make it a 'false' default, it'll be harmless to add this thread support into boost.python code, but when needed, it'll be very convenience to have them. I do agree that there should be a try catch block here, like: Py_UNBLOCK_THREADS try { result = f(...); } catch(...) Py_BLOCK_THREADS throw; } Py_BLOCK_THREADS ... In my case, because SendMessage and COM method will never throw an exception, so I ignored them in the last patch, for a complete solution, it'll be better to do this. Lijun Qin http://www.solidshare.com ----- Original Message ----- From: "David Abrahams" To: Cc: "Lijun Qin" Sent: Tuesday, September 02, 2003 9:53 PM Subject: [C++-sig] Re: Patch to add thread support to invoke function. > "Lijun Qin" writes: > > > Hi, > > > > I have made some changes to the invoke.hpp file, to add > > > > Py_UNBLOCK_THREADS > > result = f(...); > > Py_BLOCK_THREADS > > > > pair, this is need for too reasons: > > First, if the f(...) is a lengthy operation, it'll block all Python code to > > execute, this is not good, > > second, if f(...) function call some functions that will acquire the python > > global lock, it'll deadlock, one example is the COM inproc server using > > Pythoncom22.dll, every COM interface method will first call > > PyEval_AcquireThread, but the global lock has been held, so deadlock occur. > > Hi Lijun, > > I'm not ignoring your patches. Here's my reservation about accepting > this one, though: I don't think it represents a complete solution to > threading support in Boost.Python, and I'd like to solve the problem > all at once. On way in which this doesn't handle the problem is that > if f takes any object, str, dict, handle<>, etc. parameters by value, > the call may crash the interpreter as reference counts are changed > with threading unblocked. My guess is that the right solution is to > simply not unblock threads for those functions, since they are > hand-written with Boost.Python in mind and the author can unblock > threads manually if neccessary (with a "unguard" object). Another way > in which your patch is inadequate is that any code in Py_BLOCK_THREADS > will get skipped if f throws an exception, so we really need guard > objects which use RAII. Another way is that virtual functions which > call back into Python with call_method need to re-acquire the GIL > somehow -- it's not yet clear to me whether that should happen inside > or outside call_method. > > The following are references to some threads in which these issues > have been discussed, should you wish to explore further: > > http://aspn.activestate.com/ASPN/Mail/Message/1465959 > http://aspn.activestate.com/ASPN/Mail/Message/1603259 > http://aspn.activestate.com/ASPN/Mail/Message/1607050 > http://aspn.activestate.com/ASPN/Mail/Message/1706806 > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From mike.thompson at day8.com.au Thu Sep 4 13:57:24 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Thu, 4 Sep 2003 21:57:24 +1000 Subject: [C++-sig] Test eom Message-ID: From mike.thompson at day8.com.au Thu Sep 4 07:19:40 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Thu, 4 Sep 2003 15:19:40 +1000 Subject: [C++-sig] "The filename or extension is too long" Message-ID: I'm attempting to set up a Boost.Python project outside the Boost.Python tree. I'm working with a modified version of the jam files provided in boost\libs\python\example\project.zip (see end of post) Everything appears to be working perfectly EXCEPT that bjam is attempting to create a folder whose path is longer than 255 characters long which, on XP, causes the whole process to fall over with the message "The filename or extension is too long. " Other than this one small problem, I believe my configuration works because I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT to something shorter than 255 characters and successfully built a useable '.pyd'. So. What can I do about these enormous paths? Here is an example: bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre ading-single I've googled and found one mention of this problem in 2002, but there was no resolution or workaround mentioned, simply a comment that it needed to be fixed. There's got to be a solution, because I don't run into this problem when I'm working with the example in the Boost.Python source tree. Any suggestions very welcome. Here are the JAM files I'm working with: ------------- Jamrules --------------------------------------------- path-global BOOST_ROOT : C:/libs/boost ; PYTHON_ROOT = C:/Python23 ; PYTHON_VERSION = 2.3 ; STLPORT_PATH = C:/libs ; STLPORT_4.5-0725_PATH = C:/libs/STLport-4.5-0725 ; STLPORT_VERSION = 4.5-0725 ; TOOLS = msvc-stlport ; BUILD = release ; ---------- Boost-Build.jam ----------------------------------------- # Specify path to the boost build system BOOST_ROOT = C:/libs/boost ; boost-build C:/libs/boost/tools/build ; ---------- Jamfile ----------------------------------------- project-root ; # Include definitions needed for Python modules SEARCH on python.jam = $(BOOST_BUILD_PATH) ; include python.jam ; # Declare a Python extension called getting_started1 extension getting_started1 : # sources getting_started1.cpp : # requirements # link to the appropriate library for the build variant. boost_python boost_python_debug boost_python_pydebug # library path required for linking to boost_python shared lib. You # may need to edit this for your installation C:/libs/boost/libs/python/build/bin-stage ; ------------------------------------------------------------------ -- Mike From dave at boost-consulting.com Wed Sep 3 13:23:39 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 03 Sep 2003 07:23:39 -0400 Subject: [C++-sig] Re: Patch to add thread support to invoke function. References: <001c01c39c31$a36f0b40$0200a8c0@barrack> <002b01c371b1$3b138170$0200a8c0@barrack> Message-ID: "Lijun Qin" writes: > Hi, > > I think a better solution is to give the user choice, I mean use a flag > which can be passed when calling 'def', such as > .def('f', f, enableThreadLock) If you read the links in my previous posting you'll see that I think that's appropriate for some wrapping jobs; for others (such as wrapping Qt calls) it seems that calls are so likely to result in a call back into Python which *must* unconditionally acquire the GIL that people just want to unblock everywhere. So far, however, I'm not sure how to do that without incurring ODR problems, so we may have to go with your idea. Of course, that "flag" should be rolled into the available functionality of CallPolicies. > Currently I'm using boost.python to wrap WTL, and it has hundreds of > functions which are simple SendMessage wrappers, and many of them (I > think half of them, almost all 'write' operation) can cause callback > into the python code again, use the notify message such as > WM_COMMAND, WM_NOTIFY. So write wrapper for every one of them is not > acceptable. The callback will be implemented use call_method<> > normally, but the thread acquiring will not be done is call_method, ^^ "in" > it'll normally be done earlier in the very point the control > transferred from the 'outside world' to the python extension module, > in the Windows platform, this will normally at the beginning of COM > interface method, Window Procedure, or DLL exported function (this > is rare I think). When you say "thread acquiring" do you mean the reacquisition of the Python GIL and thread state? Why would you do it any earlier than in, or just prior to, call_method<>? > If we can implement the 'enableThreadLock' flag, but make it a > 'false' default, it'll be harmless to add this thread support into > boost.python code, but when needed, it'll be very convenience to > have them. I think that's a great approach. Maybe you should extend your prior CallPolicies patch to do it. > I do agree that there should be a try catch block here, like: > > Py_UNBLOCK_THREADS > try { > result = f(...); > } catch(...) > Py_BLOCK_THREADS > throw; > } > Py_BLOCK_THREADS > ... I wasn't quite suggesting that. First of all Py_UNBLOCK_THREADS needs a PyThreadState* variable. Secondly, using an object whose destructor unblocks makes it much easier to select thread blocking or not at compile time. Something like: struct thread_enable { thread_enable() : m_thread_state(PyEval_SaveThread()) {} ~thread_enable() { PyEval_RestoreThread(m_thread_state); } private: PyThreadState* m_thread_state; }; We'll just declare one of these on the stack when the thread_enable flag is used, and declare an unused int when it's not. A similar, but inverted thread state acquisition object should be used around call_method<> invocations. My biggest question is: does it need a thread state, or should it just use PyEval_AcquireLock(), and if it *does* need a thread state, where will it come from? > In my case, because SendMessage and COM method will never throw an > exception, so I ignored them in the last patch, for a complete solution, > it'll be better to do this. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Thu Sep 4 01:02:24 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Thu, 04 Sep 2003 00:02:24 +0100 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> Message-ID: "Joel de Guzman" writes: > Raoul Gough wrote: >> "Joel de Guzman" writes: > >> Well, I've had a go anyway. I've produced a container_proxy template >> that wraps a random-access container and provides access via element >> proxies. The element proxies provide an implicit conversion to the raw >> value type, and also a constructor from the raw value type, which >> means that it works with an unchanged[*1] vector_indexing_suite as >> follows: >> >> vector_indexing_suite, true> > > This is great! Did the current tests pass with the new code? [taking a look at libs/python/test] Hey! You've already written some tests :-) I didn't know about these, but I guess I should have looked there automatically. It turns out that the find() functionality needs some additional comparison operators in the element_proxy. I've added these, and the vector indexing tests now run without failure. It still requires some minor tweaks outside of the suite to make it work (i.e. register_ptr_to_python and implicitly_convertible). Getting register_ptr_to_python to work seemed a little more difficult than I would have expected. In particular, the need to specialize boost::get_pointer probably means making the element_proxy a non-nested class, since it has to be a deducible type: template typename container_proxy::element_proxy::value_type ... get_pointer (container_proxy::element_proxy); Which I believe doesn't work. I've just provided a non-template overload for the test cases. I also had to add an "element" typedef to keep something else happy, and also (at some earlier stage) iterator_category and difference_type. This all reinforces my thoughts from a few weeks back, about the need for some kind of centralized handle_traits or proxy_traits. [snip] >> Sample output: >> >> copy is 3, v[1] is 3 >> copy is 5, v[1] is 5 # Wrong - copy should remain unchanged >> >> The container_proxy wrapper fixes that problem (whatever it is, >> probably minor) but doesn't fix the following additional problem, that >> both versions exhibit: > > Indeed. It's nice to hear that container_proxy fixed this. > >> slice = v[1:2] >> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1]) >> >> v[1].increment() >> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1]) >> >> Sample output: >> >> slice[0] is 5, v[1] is 5 >> slice[0] is 5, v[1] is 6 # Should be slice[0] is 6, v[1] is 6 >> >> This may be a fundamental problem with how slices are returned. >> Compiler is gcc 3.3.1 (mingw special 20030804-1). > > Right. slices are currently returned by value. I guess this is another > area to be explored. I think I know how to deal with it. Let's do > it when we refactor the slicing stuff. I think this is a good start. There > are lots of things to do and I certainly am glad that you can help. I've > already been bitten by the wholesale approach of the current indexing > suites (more on that later) that I really need to break it up sometime > soon! I've also been thinking about the slice return value problem, and I believe the best answer is to return a real Python list containing element proxies. My reasoning is that we can't return a container of identical type to the original, since it has value semantics and we need reference semantics to be at all Python-like. Unfortunately, this means that the following won't work: # Given wrapped C++ function foo (std::vector const &) foo (v) # OK - called on std::vector foo (v[1:4]) # !OK - called on Python list Then again, it also wouldn't work if v[1:4] was a wrapped vector, so why not just use a real Python list and save some template instantiation work. Actually, I'm not sure whether creating a working vector wrapper might not mean more programming work for us as well, in which case I'm definitely against it :-) My latest code is available from the boost-sandbox CVS in the boost-sandbox/boost/python/suite/indexing directory. Note: could it be that the anonymous server is out of date with the SSH one? I could only retrieve the stuff I added via the :ext:raoulgough at cvs.boost-sandbox... path. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Wed Sep 3 14:54:21 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 03 Sep 2003 08:54:21 -0400 Subject: [C++-sig] Re: undefined symbol "typeinfo for boost::python::instance_holder " under Linux/RH9 In-Reply-To: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu> (Matthew David Langston's message of "Sat, 30 Aug 2003 17:59:17 -0700") References: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu> Message-ID: "Langston, Matthew David" writes: > Hi Dave, > > Under Linux I simply did a bjam "-sTOOLS=gcc", which created > > boost/libs/python/build/bin-stage/libboost_python.a > > which bjam appears to have copied (based on file sizes) from > > boost/libs/python/build/bin/libboost_python.a/gcc/release/runtime-link-dynamic/libboost_python.a > > So, I assume bjam built everything properly. What else to try? Are you > saying that statically linking to libboost_python.a on linux/gcc > should work? Yes, it should work. > I am using boost 1.30.0, so would upgrading to 1.30.2 > maybe help? Yes, perhaps, though your problem has the flavor of a compiler/linker bug. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Sep 3 15:01:48 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 03 Sep 2003 09:01:48 -0400 Subject: [C++-sig] Re: Cross module definition References: Message-ID: "Arnaud PICARD" writes: > Sorry, my latest mail was sent before I'd had time to complete it... > -------------------------- > > Hello, > > As I've already mentionned, I still have problems with cross def. > Here you'll find an example I've used to test a method. I'm not sure I've > done it right (actually I guess it's false since I can't get it to work > properly) > > So, in these modules, I have define one as ModuleA and the other as > ModuleB. > They are AFAIK well written. > > If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b = > ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't > work. > If I define a with ModuleB instead of ModuleA it's running. That's still > the same problem I had with cross-module definition, with an example... If > I remove the line define_Cmplx() from ModuleD definition, I still cannot > get it to work even though I've imported first ModuleA then ModuleB. > > What do I have to do so that I can pull the line "define_Cmplx()" out of my > ModuleB definition so that ModuleB's methods recognize my class Cmplx ? > I've understood what was reponsded last time, but I have not been able to > have it work properly... Well, a real complete example that actually compiles on a conforming C++ compiler and includes the precise Python code to execute would be a big help in being sure that I was reproducing your case precisely, but after massageing your code so it would compile (changed to , added "using namespace std;", removed define_Cmplx() from ModuleB) I get: 1 + 0 i 1 + 0 i For both b.print1(a) and b.print2(a). On my compilers. Which compiler and platform are you using? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Sep 3 14:54:07 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 03 Sep 2003 08:54:07 -0400 Subject: [C++-sig] Re: undefined symbol "typeinfo for boost::python::instance_holder " under Linux/RH9 References: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu> Message-ID: "Langston, Matthew David" writes: > Hi Dave, > > Under Linux I simply did a bjam "-sTOOLS=gcc", which created > > boost/libs/python/build/bin-stage/libboost_python.a > > which bjam appears to have copied (based on file sizes) from > > boost/libs/python/build/bin/libboost_python.a/gcc/release/runtime-link-dynamic/libboost_python.a > > So, I assume bjam built everything properly. What else to try? Are you > saying that statically linking to libboost_python.a on linux/gcc > should work? Yes, it should work. > I am using boost 1.30.0, so would upgrading to 1.30.2 > maybe help? Yes, perhaps, though your problem has the flavor of a compiler/linker bug. -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Wed Sep 3 20:47:27 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 3 Sep 2003 11:47:27 -0700 (PDT) Subject: [C++-sig] Cross module definition In-Reply-To: Message-ID: <20030903184727.8334.qmail@web20205.mail.yahoo.com> --- Arnaud PICARD wrote: > If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b = > ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't > work. It works here without a problem. The only change I made is to remove define_Cmplx(); from Boost_B.cc. Any problems you have must be related to how you compile and link. Here is how I did it under Redhat 8.0: g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/dist/boost -I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_A.os /net/cci/rwgk/dist/sandbx/cross_module_problem/Boost_A.cc g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/dist/boost -I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_B.os /net/cci/rwgk/dist/sandbx/cross_module_problem/Boost_B.cc g++ -shared -o libtbx/sandbx_boost/ModuleB.so sandbx/cross_module_problem/Boost_B.os -Llibtbx -lboost_python -lm g++ -shared -o libtbx/sandbx_boost/ModuleA.so sandbx/cross_module_problem/Boost_A.os -Llibtbx -lboost_python -lm % cat tst.py from sandbx_boost import ModuleA from sandbx_boost import ModuleB a = ModuleA.Cmplx( 1., 0. ) b = ModuleB.Printer() b.print1( a ) b.print2( a ) % python tst.py 1 + 0 i 1 + 0 i Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From rwgk at yahoo.com Thu Sep 4 19:08:02 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 4 Sep 2003 10:08:02 -0700 (PDT) Subject: [C++-sig] Cross module definition In-Reply-To: Message-ID: <20030904170802.13048.qmail@web20201.mail.yahoo.com> This is my second attempt at replying to your message. Something seems to be wrong with the mailing list... Now trying to remember what I wrote: --- Arnaud PICARD wrote: > What do I have to do so that I can pull the line "define_Cmplx()" out of my > ModuleB definition so that ModuleB's methods recognize my class Cmplx ? > I've understood what was reponsded last time, but I have not been able to > have it work properly... It works perfectly here under Redhat 8.0. The only change I made to your sources is to remove the define_Cmplx(); line from Boost_B.cc. I think your problems must be due to how you compile and link. This is what I did: g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/hot/boost -I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_A.os /net/cci/rwgk/hot/sandbx/cross_module_problem/Boost_A.cc g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/hot/boost -I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_B.os /net/cci/rwgk/hot/sandbx/cross_module_problem/Boost_B.cc g++ -shared -o libtbx/sandbx_boost/ModuleB.so sandbx/cross_module_problem/Boost_B.os -Llibtbx -lboost_python -lm g++ -shared -o libtbx/sandbx_boost/ModuleA.so sandbx/cross_module_problem/Boost_A.os -Llibtbx -lboost_python -lm % cat tst.py from sandbx_boost import ModuleA from sandbx_boost import ModuleB a = ModuleA.Cmplx( 1., 0. ) b = ModuleB.Printer() b.print1( a ) b.print2( a ) % python tst.py 1 + 0 i 1 + 0 i Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From mike.thompson at day8.com.au Thu Sep 4 23:44:52 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Fri, 5 Sep 2003 07:44:52 +1000 Subject: [C++-sig] "The filename or extension is too long" Message-ID: I'm attempting to set up a Boost.Python project outside the Boost.Python tree. I'm working with a modified version of the jam files provided in boost\libs\python\example\project.zip (see end of post) Everything appears to be working perfectly EXCEPT that bjam is attempting to create a folder whose path is longer than 255 characters long which, on XP, causes the whole process to fall over with the message "The filename or extension is too long. " Other than this one small problem, I believe my configuration works because I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT to something shorter than 255 characters and successfully built a useable '.pyd'. So. What can I do about these enormous paths? Here is an example: bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre ading-single I've googled and found one mention of this problem in 2002, but there was no resolution or workaround mentioned, simply a comment that it needed to be fixed. There's got to be a solution, because I don't run into this problem when I'm working with the example in the Boost.Python source tree. Any suggestions very welcome. Here are the bjam files I'm working with: ------------- Jamrules --------------------------------------------- path-global BOOST_ROOT : C:/libs/boost ; PYTHON_ROOT = C:/Python23 ; PYTHON_VERSION = 2.3 ; STLPORT_PATH = C:/libs ; STLPORT_4.5-0725_PATH = C:/libs/STLport-4.5-0725 ; STLPORT_VERSION = 4.5-0725 ; TOOLS = msvc-stlport ; BUILD = release ; ---------- Boost-Build.jam ----------------------------------------- # Specify path to the boost build system BOOST_ROOT = C:/libs/boost ; boost-build C:/libs/boost/tools/build ; ---------- Jamfile ----------------------------------------- project-root ; # Include definitions needed for Python modules SEARCH on python.jam = $(BOOST_BUILD_PATH) ; include python.jam ; # Declare a Python extension called getting_started1 extension getting_started1 : # sources getting_started1.cpp : # requirements # link to the appropriate library for the build variant. boost_python boost_python_debug boost_python_pydebug # library path required for linking to boost_python shared lib. You # may need to edit this for your installation C:/libs/boost/libs/python/build/bin-stage ; ------------------------------------------------------------------ -- Mike From dave at boost-consulting.com Fri Sep 5 02:08:21 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 04 Sep 2003 20:08:21 -0400 Subject: [C++-sig] Re: "The filename or extension is too long" References: Message-ID: "Mike Thompson" writes: > I'm attempting to set up a Boost.Python project outside the Boost.Python tree. > I'm working with a modified version of the jam files provided in > boost\libs\python\example\project.zip (see end of post) > > Everything appears to be working perfectly EXCEPT that bjam is attempting to > create a folder whose path is longer than 255 characters long which, on XP, > causes the whole process to fall over with the message "The filename or > extension is too long. " > > Other than this one small problem, I believe my configuration works because > I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT > to something shorter than 255 characters and successfully built a useable > '.pyd'. > > So. What can I do about these enormous paths? Here is an example: > > bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli > ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy > namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre > ading-single > > I've googled and found one mention of this problem in 2002, but there was no > resolution or workaround mentioned, simply a comment that it needed to be > fixed. I don't know, man. Something's seriously wrong that all of these properties which already match their default values are showing up in the subvariant path. Rene, can I impose upon you to look into this? -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Fri Sep 5 00:47:29 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Thu, 04 Sep 2003 19:47:29 -0300 Subject: [C++-sig] Pyste code generation. In-Reply-To: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com> References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com> Message-ID: <3F57C101.5010806@globalite.com.br> Roman Yakovenko wrote: > Hi Nicodemus. Today Pyste does not generate private virtual functions, right? >( in wrapper class of class that has private pure virtual ) >May be it should be changed? Why ? I write wrapper for library that uses template >method pattern, where customization of method done by virtual private functions. >Here is the full artical http://www.gotw.ca/publications/mill18.htm. > > Hi Roman, I just commited a change that allows you to override protected and private pure virtual functions in Python. Sorry about the delay and thanks for the feedback! Regards, Nicodemus. From qinlj at solidshare.com Fri Sep 5 02:33:20 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Fri, 5 Sep 2003 08:33:20 +0800 Subject: [C++-sig] Re: Patch to add thread support to invoke function. References: <001c01c39c31$a36f0b40$0200a8c0@barrack><002b01c371b1$3b138170$0200a8c0@barrack> Message-ID: <006401c37345$540afdd0$0200a8c0@barrack> > > it'll normally be done earlier in the very point the control > > transferred from the 'outside world' to the python extension module, > > in the Windows platform, this will normally at the beginning of COM > > interface method, Window Procedure, or DLL exported function (this > > is rare I think). > > When you say "thread acquiring" do you mean the reacquisition of the > Python GIL and thread state? Why would you do it any earlier than in, > or just prior to, call_method<>? > This is because before the call_method<>, we'll normally 'touch' some python object, so acquiring the Python GIL is needed. Of couse, this is not always the case, but since this is common, so I think do acquiring ealier is safter. > A similar, but inverted thread state acquisition object should be > used around call_method<> invocations. My biggest question is: does > it need a thread state, or should it just use PyEval_AcquireLock(), > and if it *does* need a thread state, where will it come from? > According to the python document and my experiences, before a thread call Python core, it must allocate a thread state, If this is the main thread where Py_Initialize() is called, it's just: PyThreadState* s_thisThread = PyThreadState_Swap(NULL); After s_thisThread is valid, one must acquire the GIL to use the interceptor _ASSERT(s_thisThread); PyEval_AcquireThread(s_thisThread); ... call other Python API .. PyEval_ReleaseThread(s_thisThread); In the 'invoke' case, PyEval_SaveThread/PyEval_RestoreThread is sufficient, but in the 'call_method<>' case, one must ensure a thread state is valid, currently, I use PyWinThreadState_Ensure() come from pywintypes.dll, which used 'thread local storage' to save the PyThreadState*. I'm not familiar with Unix platform, so I do not known whether it can be used in unix platform. Lijun Qin http://www.solidshare.com From jjanecek at telusplanet.net Fri Sep 5 08:19:52 2003 From: jjanecek at telusplanet.net (John Janecek) Date: Fri, 05 Sep 2003 00:19:52 -0600 Subject: [C++-sig] Creating an arbitrary sized boost string ? In-Reply-To: Message-ID: <5.1.0.14.2.20030905001157.00b63078@pop.telusplanet.net> I can create a string using str(char* data) where data is a null terminated string what about if data is not a null terminated string ? like i need something like str(unsigned char* data, datalen) how can i do this ? Thanx, it is probably in the docs but i can not find it :( so please do not flame me too bad :) From jacek.generowicz at cern.ch Fri Sep 5 17:25:20 2003 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: Fri, 05 Sep 2003 15:25:20 -0000 Subject: [C++-sig] Boost: virtual inheritance Message-ID: Here's the distillation of some classes we are trying to wrap with Boost.Python, and the way we are trying to do the wrapping. =========================================================== #include struct Item { std::string name(); }; std::string Item::name() { return std::string("hello"); } class Class : virtual public Item { int foo(); }; int Class::foo() { return 42; } #include using namespace boost::python; BOOST_PYTHON_MODULE( btry ) { class_("Item", no_init); class_ >("Class") //, no_init) .def("name", &Class::name); =========================================================== It looks as if the virtual inheritance of Item is what is causing the trouble. It appears as if the following is the relevant part of the compilation error messsage: /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer to member conversion via virtual base `Item' of `Class' Making the inheritance non-virtual makes the distilled example, at least, work fine. Any hints would be warmly appreciated. For completeness (and your enjoyment), we include the full error message ... gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/ -I../../../../Dictionary/Reflection -I/afs/cern.ch/sw/lcg/external/Python/2.2.2/rh73_gcc32/include/python2.2 -c boosttry.cpp -o build/temp.linux-i686-2.2/boosttry.o -g /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp: In member function `void boost::python::class_::def_impl(const char*, Fn, const Helper&, ...) [with Fn = std::string (Item::*)(), Helper = boost::python::detail::def_helper, T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]': /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:246: instantiated from `boost::python::class_& boost::python::class_::def(const char*, F) [with F = std::string (Item::*)(), T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' boosttry.cpp:33: instantiated from here /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer to member conversion via virtual base `Item' of `Class' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp: In static member function `static boost::python::objects::dynamic_id_t boost::python::objects::polymorphic_id_generator::execute(void*) [with T = Class]': /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp:78: instantiated from `void boost::python::objects::register_dynamic_id(T*) [with T = Class]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/class_converters.hpp:77: instantiated from `void boost::python::objects::register_class_from_python(Derived*, Bases*) [with Derived = Class, Bases = boost::python::bases]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:476: instantiated from `void boost::python::class_::register_() const [with T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:494: instantiated from `boost::python::class_::class_(const char*, const char*) [with T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' boosttry.cpp:29: instantiated from here /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp:48: cannot dynamic_cast `p' (of type `class Class*') to type `void*' (source type is not polymorphic) error: command 'gcc' failed with exit status 1 From dave at boost-consulting.com Fri Sep 5 22:32:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 05 Sep 2003 16:32:57 -0400 Subject: [C++-sig] Re: Creating an arbitrary sized boost string ? References: <5.1.0.14.2.20030905001157.00b63078@pop.telusplanet.net> Message-ID: John Janecek writes: > I can create a string using > > str(char* data) > where data is a null terminated string > > what about if data is not a null terminated string ? > > like i need something like > str(unsigned char* data, datalen) > > how can i do this ? Probably the easiest way is with: str(std::string(data, data+datalen)) I agree that it would be nice to have the constructor you're asking for, but it would be a departure from the Python interface; is it a good idea? It might be... -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Sep 5 22:56:48 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 05 Sep 2003 16:56:48 -0400 Subject: [C++-sig] Re: "The filename or extension is too long" References: Message-ID: David Abrahams writes: > "Mike Thompson" writes: > >> I'm attempting to set up a Boost.Python project outside the Boost.Python tree. >> I'm working with a modified version of the jam files provided in >> boost\libs\python\example\project.zip (see end of post) >> >> Everything appears to be working perfectly EXCEPT that bjam is attempting to >> create a folder whose path is longer than 255 characters long which, on XP, >> causes the whole process to fall over with the message "The filename or >> extension is too long. " >> >> Other than this one small problem, I believe my configuration works because >> I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT >> to something shorter than 255 characters and successfully built a useable >> '.pyd'. >> >> So. What can I do about these enormous paths? Here is an example: >> >> bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli >> ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy >> namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre >> ading-single >> >> I've googled and found one mention of this problem in 2002, but there was no >> resolution or workaround mentioned, simply a comment that it needed to be >> fixed. > > I don't know, man. Something's seriously wrong that all of these > properties which already match their default values are showing up in > the subvariant path. Rene, can I impose upon you to look into this? Mike, Try the enclosed patch and let me know if it works out -------------- next part -------------- A non-text attachment was scrubbed... Name: boost-base.patch Type: text/x-patch Size: 1924 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Sat Sep 6 03:32:58 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Sat, 6 Sep 2003 09:32:58 +0800 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> Message-ID: <00f101c37416$d520e070$64646464@godzilla> Hi Raoul, I've spent some time and perused your code. Nice! Although our discussion has been rather sketchy at best, I think I like the general direction this is leading to. Please don't let me slow you down. You've done a nice work. Keep it coming :-) ! Raoul Gough wrote: > "Joel de Guzman" writes: > >> Raoul Gough wrote: >>> "Joel de Guzman" writes: >> >>> Well, I've had a go anyway. I've produced a container_proxy template >>> that wraps a random-access container and provides access via element >>> proxies. The element proxies provide an implicit conversion to the raw >>> value type, and also a constructor from the raw value type, which >>> means that it works with an unchanged[*1] vector_indexing_suite as >>> follows: >>> >>> vector_indexing_suite, true> >> >> This is great! Did the current tests pass with the new code? > > [taking a look at libs/python/test] Hey! You've already written some > tests :-) I didn't know about these, but I guess I should have looked > there automatically. > > It turns out that the find() functionality needs some additional > comparison operators in the element_proxy. I've added these, and the > vector indexing tests now run without failure. It still requires some > minor tweaks outside of the suite to make it work (i.e. > register_ptr_to_python and implicitly_convertible). I just had a problem with the find() functionality. The problem is that it assumes that the element type of the container to be wraped has ==. This is not always the case. Yet, I am not sure how to detect that at compile time and disable the feature appropriately. I think a basic problem with an all-in-one suite is that the requirements become too broad. We really should break the thing down in smaller, easy to manage pieces. >> Right. slices are currently returned by value. I guess this is another >> area to be explored. I think I know how to deal with it. Let's do >> it when we refactor the slicing stuff. I think this is a good start. There >> are lots of things to do and I certainly am glad that you can help. I've >> already been bitten by the wholesale approach of the current indexing >> suites (more on that later) that I really need to break it up sometime >> soon! > > I've also been thinking about the slice return value problem, and I > believe the best answer is to return a real Python list containing > element proxies. My reasoning is that we can't return a container of > identical type to the original, since it has value semantics and we > need reference semantics to be at all Python-like. Unfortunately, this > means that the following won't work: > > # Given wrapped C++ function foo (std::vector const &) > > foo (v) # OK - called on std::vector > foo (v[1:4]) # !OK - called on Python list > > Then again, it also wouldn't work if v[1:4] was a wrapped > vector, so why not just use a real Python list and save > some template instantiation work. Actually, I'm not sure whether > creating a working vector wrapper might not mean more > programming work for us as well, in which case I'm definitely against > it :-) I am considering a slice_proxy. I am not sure how complicated the implementation will be, but I think this is the right solution to the problem. Schematically: slice_proxy { Container& c; Index from; Index to; }; As for the foo (v[1:4]) problem, you can have an implicit conversion from a slice_proxy to a Container. Thoughts? -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Sat Sep 6 05:29:51 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 05 Sep 2003 23:29:51 -0400 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: "Joel de Guzman" writes: >> Then again, it also wouldn't work if v[1:4] was a wrapped >> vector, so why not just use a real Python list and save >> some template instantiation work. Actually, I'm not sure whether >> creating a working vector wrapper might not mean more >> programming work for us as well, in which case I'm definitely against >> it :-) > > I am considering a slice_proxy. I am not sure how complicated > the implementation will be, but I think this is the right solution to the problem. > Schematically: > > slice_proxy > { > Container& c; > Index from; > Index to; > }; > > As for the foo (v[1:4]) problem, you can have an implicit conversion from > a slice_proxy to a Container. Consider whether this might be a way to save on template instantiations: slice_proxy { object c; object from; object to; }; Remember, the container is already wrapped into a runtime-polymorphic object ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Sep 6 10:35:21 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 06 Sep 2003 04:35:21 -0400 Subject: [C++-sig] Re: Boost: virtual inheritance References: Message-ID: Jacek Generowicz writes: > Here's the distillation of some classes we are trying to wrap with > Boost.Python, and the way we are trying to do the wrapping. > > =========================================================== > #include > > struct Item { > std::string name(); > }; > > std::string Item::name() { > return std::string("hello"); > } > > > class Class : virtual public Item { > int foo(); > }; > > int Class::foo() { > return 42; > } > > > #include > using namespace boost::python; > > BOOST_PYTHON_MODULE( btry ) { > > class_("Item", no_init); > > class_ >("Class") //, no_init) > .def("name", &Class::name); > =========================================================== > > > It looks as if the virtual inheritance of Item is what is causing the > trouble. It appears as if the following is the relevant part of the > compilation error messsage: > > /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer > to member conversion via virtual base `Item' of `Class' > > Making the inheritance non-virtual makes the distilled example, at > least, work fine. > > Any hints would be warmly appreciated. The quick workaround is: .def("name", object(&Class::name)) HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Sat Sep 6 11:24:09 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Sat, 06 Sep 2003 10:24:09 +0100 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: David Abrahams writes: > "Joel de Guzman" writes: > >>> Then again, it also wouldn't work if v[1:4] was a wrapped >>> vector, so why not just use a real Python list and >>> save some template instantiation work. Actually, I'm not sure >>> whether creating a working vector wrapper might not >>> mean more programming work for us as well, in which case I'm >>> definitely against it :-) >> >> I am considering a slice_proxy. I am not sure how >> complicated the implementation will be, but I think this is the >> right solution to the problem. Schematically: >> >> slice_proxy >> { >> Container& c; >> Index from; >> Index to; >> }; >> >> As for the foo (v[1:4]) problem, you can have an implicit >> conversion from a slice_proxy to a Container. > > Consider whether this might be a way to save on template > instantiations: > > slice_proxy > { > object c; > object from; > object to; > }; > > Remember, the container is already wrapped into a runtime-polymorphic > object ;-) I already considered and had to reject an approach like this. Actually, I was thinking of using an iterator pair, but the problem would be the same. A slice on this basis will be in error as soon as an insertion or deletion occurs within the [from,to) range in the original container, since the value lookup is deferred until elements are accessed in the slice. To function correctly, the slice must contain proxies for each element in the range _at the time the slice was created_, so the proxies can track their values' movements during inserts, erasures and overwrites. I currently like the idea of returning a Python list of element proxies, since it saves code and template instantiations. Possibly a wrapped std::vector with a suite specialization would be better than a Python list, but I'm not sure exactly what the pros and cons would be. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From RaoulGough at yahoo.co.uk Sat Sep 6 11:43:25 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Sat, 06 Sep 2003 10:43:25 +0100 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: "Joel de Guzman" writes: > Hi Raoul, > > I've spent some time and perused your code. Nice! > Although our discussion has been rather sketchy at best, > I think I like the general direction this is leading to. Please > don't let me slow you down. You've done a nice work. > Keep it coming :-) ! Thanks! I should have some more time for this in the next few days, so I'll see what I can do. > > Raoul Gough wrote: [snip] >> It turns out that the find() functionality needs some additional >> comparison operators in the element_proxy. I've added these, and the >> vector indexing tests now run without failure. It still requires some >> minor tweaks outside of the suite to make it work (i.e. >> register_ptr_to_python and implicitly_convertible). > > I just had a problem with the find() functionality. The problem is that it > assumes that the element type of the container to be wraped has ==. > This is not always the case. Yet, I am not sure how to detect > that at compile time and disable the feature appropriately. I think a > basic problem with an all-in-one suite is that the requirements become > too broad. We really should break the thing down in smaller, easy to > manage pieces. I see. Unless there is some kind of template meta-programming magic to detect operator==, we would need a manual switch. Maybe we could break this down by introducing not only a container_traits template, but a value_traits one as well. The container_traits could then make use of value_traits internally to figure out whether things like find() are possible, and the client code could specialize value_traits where necessary. In most cases, of course, the defaults would work, but in special cases only minimal work is required for the client code, since value_traits would probably be very simple. I guess the next thing to do is pull some of the existing work together, maybe adding the new value_traits template and a partial specialization of container_traits for container_proxy. I'll try to make some progress on this before the middle of the week. One thing we haven't yet considered is support for different conversion policies. Hopefully I'm not just being overly optimistic, and we can retro-fit this later. [snip slice discussion - see my reply to Dave's followup] -- Raoul Gough. (setq dabbrev-case-fold-search nil) From djowel at gmx.co.uk Sat Sep 6 15:56:21 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Sat, 6 Sep 2003 21:56:21 +0800 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: <002701c3747e$df934da0$64646464@godzilla> Raoul Gough wrote: > David Abrahams writes: >> Consider whether this might be a way to save on template >> instantiations: >> >> slice_proxy >> { >> object c; >> object from; >> object to; >> }; >> >> Remember, the container is already wrapped into a runtime-polymorphic >> object ;-) > > I already considered and had to reject an approach like this. > Actually, I was thinking of using an iterator pair, but the problem > would be the same. A slice on this basis will be in error as soon as > an insertion or deletion occurs within the [from,to) range in the > original container, since the value lookup is deferred until elements No, of course not. slice_proxy shouldn't be that naive. The slice_proxy can be thought of as: slice_proxy { element_proxy from; element_proxy to; }; The same element_proxy index management should apply to from and to. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Sat Sep 6 15:57:00 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 06 Sep 2003 09:57:00 -0400 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: Raoul Gough writes: > > I see. Unless there is some kind of template meta-programming magic to > detect operator==, we would need a manual switch. Maybe we could break > this down by introducing not only a container_traits template, but a > value_traits one as well. The container_traits could then make use of > value_traits internally to figure out whether > things like find() are possible, and the client code could specialize > value_traits where necessary. In most cases, of course, the defaults > would work, but in special cases only minimal work is required for the > client code, since value_traits would probably be very simple. Yup. This is all starting to sound a lot like Alexander Nasonov's dynamic_any. -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Sat Sep 6 17:06:26 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Sat, 6 Sep 2003 23:06:26 +0800 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla><003d01c36682$5ec55c40$0100a8c0@godzilla><00d101c36adb$0087aea0$64646464@godzilla><004a01c36b0c$cf71b0e0$50a245ca@godzilla><00de01c371b4$51acd8c0$64646464@godzilla><00f101c37416$d520e070$64646464@godzilla> <002701c3747e$df934da0$64646464@godzilla> Message-ID: <002001c37489$06a7aee0$64646464@godzilla> Joel de Guzman wrote: > Raoul Gough wrote: >> I already considered and had to reject an approach like this. >> Actually, I was thinking of using an iterator pair, but the problem >> would be the same. A slice on this basis will be in error as soon as >> an insertion or deletion occurs within the [from,to) range in the >> original container, since the value lookup is deferred until elements > > No, of course not. slice_proxy shouldn't be that naive. > The slice_proxy can be thought of as: > > slice_proxy > { > element_proxy from; > element_proxy to; > }; > > The same element_proxy index management should apply to from and to. Hmmm.... Upon deeper analysis, I think you are right. Let me meditate on this a bit more. I certainly hope there's a better solution. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From romany at actimize.com Sun Sep 7 12:43:39 2003 From: romany at actimize.com (Roman Yakovenko) Date: Sun, 7 Sep 2003 13:43:39 +0300 Subject: [C++-sig] Wrapping multi - lib project strategy Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020643@exchange.adrembi.com> Hi. I'd like to get help with the subject. Description of the problem: I am writing wrapper for python of some project. This project is very complex one. It has a lot of single - tones. Each single tone lies in its own lib. My naive approach for wrapping it is to place each library in it's own python module ( dll file ). Now I have problem: I initialize single tones as I should. But because it happens in different dlls every single tone sees other as uninitialized. The first solution that come to my head is to compile all my dlls together in one dll. But then I use logical partition of modules. The second solution is: - yours I am almost sure that people already meat such problem. Could you share your solutions, ideas ? Thanks Roman. From romany at actimize.com Sun Sep 7 12:44:35 2003 From: romany at actimize.com (Roman Yakovenko) Date: Sun, 7 Sep 2003 13:44:35 +0300 Subject: [C++-sig] Pyste code generation. Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020644@exchange.adrembi.com> Hi Nicodemus. Thanks you very much. Roman > -----Original Message----- > From: Nicodemus [mailto:nicodemus at globalite.com.br] > Sent: Friday, September 05, 2003 12:47 AM > To: Development of Python/C++ integration > Subject: Re: [C++-sig] Pyste code generation. > > > Roman Yakovenko wrote: > > > Hi Nicodemus. Today Pyste does not generate private > virtual functions, right? > >( in wrapper class of class that has private pure virtual ) > >May be it should be changed? Why ? I write wrapper for > library that uses template > >method pattern, where customization of method done by > virtual private functions. > >Here is the full artical http://www.gotw.ca/publications/mill18.htm. > > > > > > Hi Roman, > > I just commited a change that allows you to override protected and > private pure virtual functions in Python. Sorry about the delay and > thanks for the feedback! > > Regards, > Nicodemus. > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From lkunert at mpi-sb.mpg.de Sun Sep 7 15:46:33 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Sun, 7 Sep 2003 15:46:33 +0200 Subject: [C++-sig] (no subject) Message-ID: Hi! I am considering to integrate am existing Qt-application into viewer called chimera. Chimera is a c++/python application with an integrated IDLE. Therefore I try to wrap my application into python by using boost.python. To get some clues how to achive this, I had look into the hippodraw project. As a priliminary test I tried to execute hippodraw within chimera. I got the following error message: >>> from hippo import HDApp Traceback (most recent call last): File "", line 1, in ? from hippo import HDApp ImportError: /usr/local/lib/libqt-mt.so.3: undefined symbol: FT_Seek_Stream I compiled hippodraw using the following packages, it works perfectly within the "native"python-interpreter on my computer. I'm using SuSE 8.1 python 2.2.1-45 chimera1.1700.exe bundeled with python 2.2.1 (build?!) qt-x11-free-3.2.0 (threads enabeled) boost1.30.2 with Boost.Python 2 g++ 3.2 The integrated IDLE uses another python-build than I do, but the problem arises somewhere in the qt-mt library. At the moment I am a bit clueless how to proceed. I would appreciate some comments on the feasibilty of my project and of cause to the actual error message. Thanks in advance Lars Kunert From dave at boost-consulting.com Sun Sep 7 18:14:55 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 07 Sep 2003 12:14:55 -0400 Subject: [C++-sig] Re: (no subject) References: Message-ID: Lars Kunert writes: > Hi! > > I am considering to integrate am existing Qt-application into viewer > called chimera. Chimera is a c++/python application with an integrated > IDLE. > Therefore I try to wrap my application into python by using boost.python. > To get some clues how to achive this, I had look into the hippodraw > project. As a priliminary test I tried to execute hippodraw within > chimera. I got the following error message: > >>>> from hippo import HDApp > Traceback (most recent call last): > File "", line 1, in ? > from hippo import HDApp > ImportError: /usr/local/lib/libqt-mt.so.3: undefined symbol: > FT_Seek_Stream This has nothing at all to do with Boost.Python; you either need to have the right LD_LIBRARY_PATH settings so that the library containing FT_Seek_Stream can be found, or you need a newer version of that library. > I compiled hippodraw using the following packages, it works perfectly > within the "native"python-interpreter on my computer. > > I'm using SuSE 8.1 > python 2.2.1-45 > chimera1.1700.exe bundeled with python 2.2.1 (build?!) > qt-x11-free-3.2.0 (threads enabeled) > boost1.30.2 with Boost.Python 2 > g++ 3.2 > > The integrated IDLE uses another python-build than I do What does that mean? Normally different builds/versions of Python aren't binary-compatible. -- Dave Abrahams Boost Consulting www.boost-consulting.com From Paul_Kunz at SLAC.Stanford.EDU Sun Sep 7 18:18:39 2003 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Sun, 07 Sep 2003 09:18:39 -0700 Subject: [C++-sig] (no subject) In-Reply-To: References: Message-ID: <200309071618.h87GIda10279@libra3.slac.stanford.edu> >>>>> On Sun, 07 Sep 2003 15:46:33 +0200, Lars Kunert said: > Hi! I am considering to integrate am existing Qt-application into > viewer called chimera. Chimera is a c++/python application with an > integrated IDLE. Which Chimera? A Google search finds quite a few different packages. > Therefore I try to wrap my application into python > by using boost.python. To get some clues how to achive this, I had > look into the hippodraw project. As a priliminary test I tried to > execute hippodraw within chimera. I got the following error message: >>>> from hippo import HDApp > Traceback (most recent call last): File "", line 1, in ? > from hippo import HDApp ImportError: /usr/local/lib/libqt-mt.so.3: > undefined symbol: FT_Seek_Stream I'm primary developer of HippoDraw. I've never seen that error. The symbol doesn't appear to be in Qt sources. I'm clueless on what your problem is. From dave at boost-consulting.com Sun Sep 7 18:56:40 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 07 Sep 2003 12:56:40 -0400 Subject: [C++-sig] Re: Boost: virtual inheritance References: Message-ID: David Abrahams writes: >> It looks as if the virtual inheritance of Item is what is causing the >> trouble. It appears as if the following is the relevant part of the >> compilation error messsage: >> >> /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer >> to member conversion via virtual base `Item' of `Class' >> >> Making the inheritance non-virtual makes the distilled example, at >> least, work fine. >> >> Any hints would be warmly appreciated. > > > The quick workaround is: > > .def("name", object(&Class::name)) This problem is now fixed in CVS. -- Dave Abrahams Boost Consulting www.boost-consulting.com From seefeld at sympatico.ca Sun Sep 7 19:28:04 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sun, 07 Sep 2003 13:28:04 -0400 Subject: [C++-sig] (no subject) In-Reply-To: References: Message-ID: <3F5B6AA4.2070403@sympatico.ca> Lars Kunert wrote: > Hi! > > I am considering to integrate am existing Qt-application into viewer > called chimera. Chimera is a c++/python application with an integrated > IDLE. > Therefore I try to wrap my application into python by using boost.python. > To get some clues how to achive this, I had look into the hippodraw > project. As a priliminary test I tried to execute hippodraw within > chimera. I got the following error message: > > >>>>from hippo import HDApp > > Traceback (most recent call last): > File "", line 1, in ? > from hippo import HDApp > ImportError: /usr/local/lib/libqt-mt.so.3: undefined symbol: > FT_Seek_Stream The symbol is defined by the FreeType library, I believe (which Qt seems to use for font rendering). Make sure your loader can find it (i.e. define the LD_LIBRRY_PATH appropriately), and the error should go away. Hope that helps, Stefan From Jason.Sibthorpe at aculab.com Mon Sep 8 17:28:50 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Mon, 8 Sep 2003 16:28:50 +0100 Subject: [C++-sig] pyste -I Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70D3@saturn.aculab.com> Hi, The -I option to pyste doesn't appear to work as I expect. Invoking pyste without the -I option results in the following error " raise RuntimeError, 'Header file "%s" not found!' % name RuntimeError: Header file "rc-engine.hpp" not found!" As I would expect. Invoking pyste with -I../ does not raise an error and source files are generated but the body of the Export_*() is empty and include directives are missing. ////////////////// // rcengine.pyste ////////////////// rcengine = AllFromHeader("rc-engine.hpp") //////////////// // _rcengine.cpp //////////////// // Includes ====================================================== #include // Using ========================================================= using namespace boost::python; // Module ======================================================== void Export_rcengine() { } -- Note that the following _does_ work // rcengine.pyste rcengine = AllFromHeader("../rc-engine.hpp") Has anyone noticed this behaviour before? I am invoking pyste as follows pyste -I../ --out=rcengine --multiple nuance_config.pyste rcengine.pyste and using Pyste version 0.9.22 Thanks Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: From Jason.Sibthorpe at aculab.com Mon Sep 8 18:09:51 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Mon, 8 Sep 2003 17:09:51 +0100 Subject: [C++-sig] pyste - function output parameters Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70D4@saturn.aculab.com> Hi, Given a c++ function of the form out_arg1 foo(in_arg, out_arg2) { ... } I wonder if there is a neat way of provoking pyste to generate a wrapper so that out_arg2 is returned by the corresponding python function. ie in python out1, out2 = module.foo(in) I believe this is possible in SWIG. Thanks -J Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: From RaoulGough at yahoo.co.uk Mon Sep 8 20:32:58 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 08 Sep 2003 19:32:58 +0100 Subject: [C++-sig] Converting std::out_of_range to Python IndexError Message-ID: In working on the indexing suite, I came across a std::out_of_range exception (thrown by std::vector<>::at) and wanted it to arrive in Python as an IndexError - this functions similarly to the StopIteration exception for sequences with __getitem__ rather than __iter__. Anyway, adding it to libs/python/src/errors.cpp is trivial (diff follows this paragraph). I also added an explicit include for , since this header is the one that defines the standard exception hierarchy. OK to commit these changes? Index: errors.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/python/src/errors.cpp,v retrieving revision 1.9 diff -w -d -u -r1.9 errors.cpp --- errors.cpp 23 Jul 2003 03:00:47 -0000 1.9 +++ errors.cpp 8 Sep 2003 18:24:38 -0000 @@ -11,6 +11,7 @@ #include #include #include +#include namespace boost { namespace python { @@ -37,6 +38,10 @@ catch(const bad_numeric_cast& x) { PyErr_SetString(PyExc_OverflowError, x.what()); + } + catch(const std::out_of_range& x) + { + PyErr_SetString(PyExc_IndexError, x.what()); } catch(const std::exception& x) { -- Raoul Gough. (setq dabbrev-case-fold-search nil) From Jason.Sibthorpe at aculab.com Mon Sep 8 21:38:23 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Mon, 8 Sep 2003 20:38:23 +0100 Subject: [C++-sig] wrapping function taking pointer to pointer Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70D7@saturn.aculab.com> Hi all, Could someone point me towards the documentation (if any exists) for wrapping a function taking a pointer to a pointer to some type. void ptrptr(char **in) {} BOOST_PYTHON_MODULE(test) { def("ptrptr", &ptrptr); } When calling the function from python I get the following did not match C++ signature: inptrptr(char**) Thanks Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: From dave at boost-consulting.com Mon Sep 8 21:43:50 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 08 Sep 2003 15:43:50 -0400 Subject: [C++-sig] Re: wrapping function taking pointer to pointer References: <8C9A566C643ED6119E8900A0C9DE297A020B70D7@saturn.aculab.com> Message-ID: Jason.Sibthorpe at aculab.com writes: > Hi all, > > Could someone point me towards the documentation (if any exists) > for wrapping a function taking a pointer to a pointer to some > type. > > void ptrptr(char **in) > {} > > BOOST_PYTHON_MODULE(test) > { > def("ptrptr", &ptrptr); > } There's no one way to do this. > When calling the function from python I get the following > > > did not match C++ signature: > inptrptr(char**) What kind of Python object do you *expect* to be able to pass to inptrptr? -- Dave Abrahams Boost Consulting www.boost-consulting.com From j8sn at yahoo.com Mon Sep 8 23:30:08 2003 From: j8sn at yahoo.com (=?iso-8859-1?q?jason=20sibthorpe?=) Date: Mon, 8 Sep 2003 22:30:08 +0100 (BST) Subject: [C++-sig] Re: wrapping function taking pointer to pointer Message-ID: <20030908213008.32152.qmail@web10503.mail.yahoo.com> >> Hi all, >> >> Could someone point me towards the documentation (if any exists) >> for wrapping a function taking a pointer to a pointer to some >> type. >> >> void ptrptr(char **in) >> {} >> >> BOOST_PYTHON_MODULE(test) >> { >> def("ptrptr", &ptrptr); >> } > >There's no one way to do this. > >> When calling the function from python I get the following >> >> >> did not match C++ signature: >> inptrptr(char**) > >What kind of Python object do you *expect* to be able to pass to >inptrptr? > >-- >Dave Abrahams >Boost Consulting >www.boost-consulting.com Hi Dave, Thanks for responding. I am interested in understanding the process rather than dealing with a single type but, for the purposes of this discussion, the c++ type is char** and I would think that a python list do the trick. A doco* would be greatly appreciated. Many thanks -J ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk From nicodemus at globalite.com.br Mon Sep 8 23:53:47 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Mon, 08 Sep 2003 18:53:47 -0300 Subject: [C++-sig] pyste -I In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A020B70D3@saturn.aculab.com> References: <8C9A566C643ED6119E8900A0C9DE297A020B70D3@saturn.aculab.com> Message-ID: <3F5CFA6B.1020707@globalite.com.br> Hi Jason, Jason.Sibthorpe at aculab.com wrote: >Hi, > >The -I option to pyste doesn't appear to work as I expect. > >Invoking pyste without the -I option results in the following error >" raise RuntimeError, 'Header file "%s" not found!' % name >RuntimeError: Header file "rc-engine.hpp" not found!" > >As I would expect. > >Invoking pyste with -I../ does not raise an error and source files >are generated but the body of the Export_*() is empty and include >directives are missing. > The -I option is intended only to be passed along to gccxml, not for use with Pyste itself. GCCXML, like any compiler, must process all the header files included by your source file. Is there any reason that you can't hardcode the paths into the Pyste files? Regards, Nicodemus. From nicodemus at globalite.com.br Mon Sep 8 23:57:25 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Mon, 08 Sep 2003 18:57:25 -0300 Subject: [C++-sig] pyste - function output parameters In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A020B70D4@saturn.aculab.com> References: <8C9A566C643ED6119E8900A0C9DE297A020B70D4@saturn.aculab.com> Message-ID: <3F5CFB45.7040202@globalite.com.br> Hi Jason! Jason.Sibthorpe at aculab.com wrote: >Hi, > >Given a c++ function of the form > >out_arg1 foo(in_arg, out_arg2) { ... } > >I wonder if there is a neat way of provoking >pyste to generate a wrapper so that out_arg2 >is returned by the corresponding python function. > >ie in python > >out1, out2 = module.foo(in) > > Automatically no, you would have to write a wrapper for that (untested): foo_wrapper = Wrapper('foo_wrapper', ''' tuple foo_wrapper(in_type in) { out_type2 out2; out_type1 out1 = foo(in, out2); return make_tuple(out1, out2); } ''') foo = Function(...) set_wrapper(foo, foo_wrapper) >I believe this is possible in SWIG. > > I think you have to write a sort-of-wrapper too, but I can be wrong about this. HTH, Nicodemus. From dalwan01 at student.umu.se Tue Sep 9 00:55:06 2003 From: dalwan01 at student.umu.se (Daniel Wallin) Date: Tue, 09 Sep 2003 00:55:06 +0200 Subject: [C++-sig] pyste - function output parameters In-Reply-To: <3F5CFB45.7040202@globalite.com.br> References: <8C9A566C643ED6119E8900A0C9DE297A020B70D4@saturn.aculab.com> <8C9A566C643ED6119E8900A0C9DE297A020B70D4@saturn.aculab.com> Message-ID: <5.1.0.14.0.20030909005341.048483a0@student.umu.se> At 23:57 2003-09-08, Nicodemus wrote: >Hi Jason! > >Jason.Sibthorpe at aculab.com wrote: > >>Hi, >> >>Given a c++ function of the form >> >>out_arg1 foo(in_arg, out_arg2) { ... } >> >>I wonder if there is a neat way of provoking >>pyste to generate a wrapper so that out_arg2 >>is returned by the corresponding python function. >> >>ie in python >> >>out1, out2 = module.foo(in) >> > >Automatically no, you would have to write a wrapper for that (untested): > >foo_wrapper = Wrapper('foo_wrapper', >''' >tuple foo_wrapper(in_type in) >{ > out_type2 out2; > out_type1 out1 = foo(in, out2); > return make_tuple(out1, out2); >} >''') >foo = Function(...) >set_wrapper(foo, foo_wrapper) > >>I believe this is possible in SWIG. >> > >I think you have to write a sort-of-wrapper too, but I can be wrong about >this. FWIW, this is possible in luabind with a policy: def(&foo, pure_out_value(_2)) So I guess this feature might come with boost.langbinding, whenever that's in a usable state. ;) --- Daniel Wallin From mike.thompson at day8.com.au Tue Sep 9 08:33:17 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Tue, 9 Sep 2003 16:33:17 +1000 Subject: [C++-sig] Re: Some questions ... Message-ID: "Mike Thompson" wrote: > > 1. add a link to the Boost.Python Wiki in > http://www.boost.org/libs/python/doc/index.html. > I only found the Wiki once I started googling for answers but it would > have been better for me if I'd seen it initially. It's pages answered some > of my questions. Of course, the moment I post I notice that the Wiki is, in fact, mentioned -- indirectly under "Support". In about 10 other passes over the documentation, I hadn't noticed it there. > > Q1. [snip] > is it possible to graft new constructors onto a class? > I now see that the Boost.Python TODO list mentions this need. So that answers my question mostly. I'll just make a derived class and give it the (different) constructors I want to expose through python. > > Q2. The following function works, but I'm left wondering if there's not a > better way. It takes a list of ints and returns the equivalent > vector. This question remains. -- Mike From mike.thompson at day8.com.au Tue Sep 9 06:33:29 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Tue, 9 Sep 2003 14:33:29 +1000 Subject: [C++-sig] Some questions ... Message-ID: First, Boost.Python is a delight. It's wonderfully functional, bug free and has quite reasonable documentation. After a few initall issues with bjam and stlport, it's all working very, very well for me. My C++ library accesses objects in memory mapped databases, so I was quite worried about technical challenges I might face in the python <-> C++ interface, but its been a breeze (so far) with Boost.Python. I now have python based unit tests for my library which, to me, is so much easier than having C++ based test harnesses. That alone is a huge bonus. The main game for me soon though is building a wxPython application using this newly wrapped library. Based on my learning experience so far, I'd make the following simple suggestions: 1. add a link to the Boost.Python Wiki in http://www.boost.org/libs/python/doc/index.html. I only found the Wiki once I started googling for answers but it would have been better for me if I'd seen it initially. It's pages answered some of my questions. 2. On the same page you might also want to mention that 'boost\libs\python\test' contains unittests that newbies might find interesting. I certainly found them a useful set of examples when once or twice I was stuck. 3. At the very bottom of: http://www.boost.org/libs/python/doc/tutorial/doc/class_operators_special_functions.html there's a "notes box" which starts "What is the business of operator<< .def(str(self))?" that's got to be a mistake, I think, because I can find no mention of operator<< .def(str(self)) on that page. The rest of the note, after that first sentence, is fine. So far so good, but now I have a couple of questions. Q1. It's possible to 'graft' member functions onto a class ... like this: class X { // ... }; void myMethod(const X& x) { // ... } BOOST_PYTHON_MODULE(MyModule) { class_("X") // ... .def("meth", &myMethod) ; } BUT is it possible to graft new constructors onto a class? I realise I could create a derived class from the one I'm wrapping and add the extra constructor there (as well as possibily replicating the existing ones), but are there any other suggestions? Q2. The following function works, but I'm left wondering if there's not a better way. It takes a list of ints and returns the equivalent vector. vector makeVectorFromList(list l) { boost::python::object olen = l.attr("__len__")(); int len = extract(olen)(); vector ret(len); for (int i = 0; i < len; ++i) { extract get_int(l[i]); if (!get_int.check()) { PyErr_SetString(PyExc_TypeError, "makeVectorFromList() expects a list of ints"); throw error_already_set(); } ret[i] = get_int(); } return ret; } -- Mike From mike.thompson at day8.com.au Tue Sep 9 02:52:42 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Tue, 9 Sep 2003 10:52:42 +1000 Subject: [C++-sig] Re: "The filename or extension is too long" References: Message-ID: "David Abrahams" wrote: > > Try the enclosed patch and let me know if it works out > Ahh. I've been away playing with Boost.Python and not reading any lists, so I just saw this. I've already solved the problem by using Visual Studio 6 and leaving bjam out of it. Because I don't need to be cross-platform, this solution will do me just fine going forward. On the other hand, if you need someone to test this patch, then just say and I'll give it a go. -- Mike From Jason.Sibthorpe at aculab.com Tue Sep 9 12:23:46 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Tue, 9 Sep 2003 11:23:46 +0100 Subject: [C++-sig] pyste -I Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70D8@saturn.aculab.com> Hi Nicodemus, Thanks for your response. >Is there any reason that you can't hardcode the paths into the Pyste >files? Yes and no. The problem as I see it. Hardcoding relative paths doesn't work if you generate the .cpp in a different location to that in which you compile your sources. The -output option doesn't help you here. Hardcoded absolute paths are the work of the devil. Sharing generated sources between my project members requires changes to the sources and windows paths don't work on Solaris nor Linux etc Surely this is exactly what the -I option if for? If you agree, I can lend a hand with the implementation. I already have code that parses files for include directives, (albeit in c) the port should be easy. -Jason -----Original Message----- From: Nicodemus [mailto:nicodemus at globalite.com.br] Sent: 08 September 2003 22:54 To: Development of Python/C++ integration Subject: Re: [C++-sig] pyste -I Hi Jason, Jason.Sibthorpe at aculab.com wrote: >Hi, > >The -I option to pyste doesn't appear to work as I expect. > >Invoking pyste without the -I option results in the following error >" raise RuntimeError, 'Header file "%s" not found!' % name >RuntimeError: Header file "rc-engine.hpp" not found!" > >As I would expect. > >Invoking pyste with -I../ does not raise an error and source files >are generated but the body of the Export_*() is empty and include >directives are missing. > The -I option is intended only to be passed along to gccxml, not for use with Pyste itself. GCCXML, like any compiler, must process all the header files included by your source file. Is there any reason that you can't hardcode the paths into the Pyste files? Regards, Nicodemus. _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Tue Sep 9 14:55:00 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 09 Sep 2003 08:55:00 -0400 Subject: [C++-sig] Re: Some questions ... References: Message-ID: "Mike Thompson" writes: > Q2. The following function works, but I'm left wondering if there's not a > better way. It takes a list of ints and returns the equivalent > vector. > > vector makeVectorFromList(list l) > { > boost::python::object olen = l.attr("__len__")(); > int len = extract(olen)(); > > vector ret(len); > > for (int i = 0; i < len; ++i) { > extract get_int(l[i]); > if (!get_int.check()) { > PyErr_SetString(PyExc_TypeError, "makeVectorFromList() > expects a list of ints"); > throw error_already_set(); > } > ret[i] = get_int(); > } > return ret; > } What about that approach would you like to see improved? In other words, why are you left wondering if there's a "better way"? -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike.thompson at day8.com.au Tue Sep 9 15:34:26 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Tue, 9 Sep 2003 23:34:26 +1000 Subject: [C++-sig] Re: Some questions ... References: Message-ID: "David Abrahams" wrote: > "Mike Thompson" writes: > > > Q2. The following function works, but I'm left wondering if there's not a > > better way. It takes a list of ints and returns the equivalent > > vector. > > > > vector makeVectorFromList(list l) > > { > > boost::python::object olen = l.attr("__len__")(); > > int len = extract(olen)(); > > > > vector ret(len); > > > > for (int i = 0; i < len; ++i) { > > extract get_int(l[i]); > > if (!get_int.check()) { > > PyErr_SetString(PyExc_TypeError, "makeVectorFromList() > > expects a list of ints"); > > throw error_already_set(); > > } > > ret[i] = get_int(); > > } > > return ret; > > } > > What about that approach would you like to see improved? In other > words, why are you left wondering if there's a "better way"? > I was wondering if I was missing a bit of existing magic like, say, this: vector v = extract > (l)(); Except, of course, I tried that and it didn't work. But I kept wondering if, by writing this function, I was reinventing a wheel already built, probably more elegantly. So I asked. -- Mike From dave at boost-consulting.com Tue Sep 9 16:41:47 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 09 Sep 2003 10:41:47 -0400 Subject: [C++-sig] Re: Some questions ... References: Message-ID: "Mike Thompson" writes: > "David Abrahams" wrote: >> "Mike Thompson" writes: >> >> > Q2. The following function works, but I'm left wondering if there's not a >> > better way. It takes a list of ints and returns the equivalent >> > vector. >> > >> > vector makeVectorFromList(list l) >> > { >> > boost::python::object olen = l.attr("__len__")(); >> > int len = extract(olen)(); >> > >> > vector ret(len); >> > >> > for (int i = 0; i < len; ++i) { >> > extract get_int(l[i]); >> > if (!get_int.check()) { >> > PyErr_SetString(PyExc_TypeError, "makeVectorFromList() >> > expects a list of ints"); >> > throw error_already_set(); >> > } >> > ret[i] = get_int(); >> > } >> > return ret; >> > } >> >> What about that approach would you like to see improved? In other >> words, why are you left wondering if there's a "better way"? >> > > I was wondering if I was missing a bit of existing magic like, say, this: > > vector v = extract > (l)(); > > Except, of course, I tried that and it didn't work. > > But I kept wondering if, by writing this function, I was reinventing a wheel > already built, probably more elegantly. > > So I asked. Well, Ralf has built the wheel that allows the above; see the Boost.Python FAQ. I guess I should ask myself why we don't provide that conversion as a built-in primitive. It certainly seems doable. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Tue Sep 9 23:19:32 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 9 Sep 2003 22:19:32 +0100 Subject: [C++-sig] pyste -I In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A020B70D8@saturn.aculab.com> Message-ID: <3F5E51F4.1907.1A82A151@localhost> On 9 Sep 2003 at 11:23, Jason.Sibthorpe at aculab.com wrote: > Hardcoded absolute paths are the work of the devil. Sharing generated > sources between my project members requires changes to the sources and > windows paths don't work on Solaris nor Linux etc > > Surely this is exactly what the -I option if for? > > If you agree, I can lend a hand with the implementation. I already > have code that parses files for include directives, (albeit in c) the > port should be easy. Nicodemus, didn't you add that variable preset to the pyste file's absolute path like I had requested ages ago? It's literally two lines of new code. Cheers, Niall From RaoulGough at yahoo.co.uk Wed Sep 10 00:04:59 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 09 Sep 2003 23:04:59 +0100 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> <002701c3747e$df934da0$64646464@godzilla> <002001c37489$06a7aee0$64646464@godzilla> Message-ID: "Joel de Guzman" writes: >> Raoul Gough wrote: >>> I already considered and had to reject an approach like this. >>> Actually, I was thinking of using an iterator pair, but the problem >>> would be the same. A slice on this basis will be in error as soon as >>> an insertion or deletion occurs within the [from,to) range in the >>> original container, since the value lookup is deferred until elements [snip] > Upon deeper analysis, I think you are right. Let me meditate on this > a bit more. I certainly hope there's a better solution. I suspect there is no way around this. Of course, using a std::map for the proxy storage becomes less and less efficient as more and more of the container elements get proxies created for them. In the worst case every value in the container has a corresponding shared_proxy_impl, and it would be better to use std::vector or std::deque to store the proxy pointers (and maintain an invariant that the proxy for the value at index n is also at index n in the pointer store). I guess this is purely a performance issue, and not one of semantics. I've made some progress on integrating the traits and the python implementations. It's somewhat messier than I was hoping, but it supports (where appropriate): o __getitem__ with and without slicing o __setitem__ without slicing o __iter__ o append Works for vector, list, map and iterator_pair (see testsuite.cpp, testmap.py, testvector.py and testarray.py for examples). The suite could trivially support len(), but I forgot to add that at first. There's still more work to be done, e.g. setitem for slices and a traits and/or algorithms specialization for container_proxy. Latest updates are in boost-sandbox/.../indexing, in particular slice_handler.hpp. I went a fairly different way for the slice support, adding a TypeWrapper for Python slice objects and using the Boost.Python overload resolution to pick the right __getitem__ depending on argument types. There is a magic Python function PySlice_GetIndices that does all the index handling for us, and it all seems to work fairly well. This probably needs a configurable result conversion policy when added elements to the returned list. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From RaoulGough at yahoo.co.uk Wed Sep 10 00:23:25 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 09 Sep 2003 23:23:25 +0100 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: David Abrahams writes: > Raoul Gough writes: > >> >> I see. Unless there is some kind of template meta-programming magic to >> detect operator==, we would need a manual switch. Maybe we could break >> this down by introducing not only a container_traits template, but a >> value_traits one as well. The container_traits could then make use of >> value_traits internally to figure out whether >> things like find() are possible, and the client code could specialize >> value_traits where necessary. In most cases, of course, the defaults >> would work, but in special cases only minimal work is required for the >> client code, since value_traits would probably be very simple. > > Yup. This is all starting to sound a lot like Alexander Nasonov's > dynamic_any. I've just had a quick look at dynamic_any, and it looks like it does provide similar proxying features. Were you thinking that we could use it in our implementation? I wonder whether dynamic_any could be refactored to separate the proxying and the "any object holder" facilities? Maybe a smart reference that handles function forwarding could be treated as a separate facility of its own, something like boost::shared_ptr except that it pretends to *be* the referant object, instead of like a pointer to it. This is essentially what the element_proxy has to do for the indexing suite, except that it's currently all hard-coded. For the moment, I prefer the traits approach rather than the typelist that dynamic_any seems to use. In any case, we would still need some kind of decision facility to figure out whether to .def("find"), for example. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From romany at actimize.com Wed Sep 10 07:31:40 2003 From: romany at actimize.com (Roman Yakovenko) Date: Wed, 10 Sep 2003 08:31:40 +0300 Subject: [C++-sig] bug Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020647@exchange.adrembi.com> Hi. I think I find bug. Description. I wrote converter for std::wstring from\to PyUnicodeObject. ( Thanks to Ralf W. Grosse-Kunstleve and his article Converting CString to/from std::string ) After registration it works pretty well ( for me ). But if I want to expose std::vector< std::wstring > using vector_indexing_suite I get error message: TypeError: No Python class registered for C++ class class _STL::basic_string,class _STL::allocator > I append 2 files to this message. cpp - contains registration of converter, test function for it, class that contains vector of wstring. py - contains very little test for converter, and also reproduce the error. Also if David Abrahams thinks that my converter is good enough to be in the library - I may polish it and write a lot of test Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: iter_wrapper.cpp Type: application/octet-stream Size: 2901 bytes Desc: iter_wrapper.cpp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_iter_wrapper.py Type: application/octet-stream Size: 222 bytes Desc: test_iter_wrapper.py URL: From pierre.barbier at cirad.fr Wed Sep 10 13:30:39 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 10 Sep 2003 13:30:39 +0200 Subject: [C++-sig] to_python_converter error question ... Message-ID: <3F5F0B5F.3000105@cirad.fr> When I try to import a module I made, I have the error : RuntimeError: trying to register to_python_converter for a type which already has a registered to_python_converter But when I re-import it, it just works ... is it normal ??? Then another question : how to know which converter is duplicated ? Is it possible to trace what python do when importing ? Thanks, -- 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 From roel at riks.nl Wed Sep 10 15:54:30 2003 From: roel at riks.nl (Roel Vanhout) Date: Wed, 10 Sep 2003 15:54:30 +0200 Subject: [C++-sig] very basic: calling python function from c++ Message-ID: <3F5F2D16.7070106@riks.nl> Hello everybody, I'm only just starting out with boost.python and with python embedding and I have a very basic question. I have found examples of how to get an object into c++ from python and call functions on it, but what I'm trying to do is to get a function pointer to a python function and call that function with two parameters. Basically I have two numbers and users can enter an expression into the gui of the c++ program like this: return num1 + num2 I thought that then in my c++ program, I'd prepend 'function calculate(num1, num2):' to that string, indent the expresson properly and then run the whole thing in python, passing the two numbers that I have in my c++ program to the python function. So I'm looking for a way to get a function pointer that I can pass two numbers and that returns a double. I hope I made myself clear - can anyone help me? Thanks in advance. cheers, roel From dave at boost-consulting.com Wed Sep 10 16:21:14 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 10:21:14 -0400 Subject: [C++-sig] Re: Adding __len__ to range objects References: <021801c3659d$5190a290$64646464@godzilla> <003d01c36682$5ec55c40$0100a8c0@godzilla> <00d101c36adb$0087aea0$64646464@godzilla> <004a01c36b0c$cf71b0e0$50a245ca@godzilla> <00de01c371b4$51acd8c0$64646464@godzilla> <00f101c37416$d520e070$64646464@godzilla> Message-ID: Raoul Gough writes: > David Abrahams writes: > >> Raoul Gough writes: >> >>> >>> I see. Unless there is some kind of template meta-programming magic to >>> detect operator==, we would need a manual switch. Maybe we could break >>> this down by introducing not only a container_traits template, but a >>> value_traits one as well. The container_traits could then make use of >>> value_traits internally to figure out whether >>> things like find() are possible, and the client code could specialize >>> value_traits where necessary. In most cases, of course, the defaults >>> would work, but in special cases only minimal work is required for the >>> client code, since value_traits would probably be very simple. >> >> Yup. This is all starting to sound a lot like Alexander Nasonov's >> dynamic_any. > > I've just had a quick look at dynamic_any, and it looks like it does > provide similar proxying features. Were you thinking that we could > use it in our implementation? Nope; just noting that there are some similar problems. > I wonder whether dynamic_any could be refactored to separate the > proxying and the "any object holder" facilities? Maybe a smart > reference that handles function forwarding could be treated as a > separate facility of its own, something like boost::shared_ptr except > that it pretends to *be* the referant object, instead of like a > pointer to it. This is essentially what the element_proxy has to do > for the indexing suite, except that it's currently all hard-coded. > > For the moment, I prefer the traits approach rather than the typelist > that dynamic_any seems to use. Yeah; traits would let you draw conclusions about known (std) containers without help from the user. > In any case, we would still need some kind of decision facility to > figure out whether to .def("find"), for example. Yep. -- Dave Abrahams Boost Consulting www.boost-consulting.com From mat at matbray.com Wed Sep 10 16:26:18 2003 From: mat at matbray.com (Matthew Bray) Date: Wed, 10 Sep 2003 16:26:18 +0200 Subject: [C++-sig] Is this use of Boost.Python safe? Message-ID: <3F5F348A.9010500@matbray.com> [originally posted to the boost.user list] I have a question regarding the use of Boost.Python. What I would like to do is to provide a simple scripting interface to an application in much the same way as Microsoft use Visual Basic within much of their product line (e.g. Excel) to provide direct access to the applications object model. My design is stunningly rendered below, +-------------------------+ | Application--+ | | | | Dynamically +---------------+ | v | Linked | Python Module | | +--->ObjectModel<------------------| | | | | +---------------+ | +---------------------+ | | | | Python Interpretter |<----------------------+ | | | | ">>> import ..." | +---------------------+ | +-------------------------+ What we have firstly is a our python module, in this case it exports a simple class 'ObjectModel' with various functions, sub objects and whatever else is required for the application to run. This is our Object Model, and is usable from the python interpretter on the command line. For what we have in mind however is for the python interpretter to be running inside the application (through use of the Py* functions from the python API and use of the relevant parts of Boost.Python - handle<>, object). What I want is for the application and the python instance to share the object model, for the interpretter to have knowledge of the ObjectModel it is simply imported from the python module. The application itself is linked against the python module in order to use ObjectModel (the relevant compiler specific code is inserted so that the ObjectModel class is exported/imported - __declspec(dllexport) and dllimport under Visual C++). With this setup, it is now possible to create an instance of ObjectModel within the python interpretter and use extract(...) in order to get access to it within the application, no doubt it is also possible to create the ObjectModel within the application and pass it to the python interpretter to use it there. Now my question basically regards pitfalls in this approach, there are two instances of the Python Module in use here but I'm sure that as long as care is taken to ensure the ObjectModel is destructed on the same heap that it was created on then there shall be no problems. Is there any other, possibly better way to do this perhaps - e.g. without requiring the use of the module at all, simply passing the Boost.Python class descriptions directly to the embedded interpretter. A simple test harness I have /appears/ to work fine with the above design. Here's an extremely cut down bit of code that should show kind of what I'm working on if I'm being a little unclear: my_module.hpp - this is the class that is in the python module that we shall have access to within python and our application: struct PLATFORM_SPECIFIC_DLL_EXPORT_COMMAND ObjectModel { const char * name() const; }; my_application.cpp - assume all the correct headers are included, the module is linked against etc: int main(int argc,char ** argv) { Py_Initialize(); //initialize the environment handle<> main_module(borrowed(PyImport_AddModule("__main__"))); handle<> main_namespace( borrowed(PyModule_GetDict(main_module.get()))); //import our python module handle<>(PyRun_String("import my_module", Py_file_input, main_namespace.get(), main_namespace.get()) ); //create a new instance of ObjectModel within python handle<>(PyRun_String("model = my_module.ObjectModel()", Py_file_input, main_namespace.get(), main_namespace.get())); //get the instance of ObjectModel and use it within our application object tmp(main_namespace); ObjectModel * model = extract(tmp["model"]); //use the model, the function is dispatched to the dynamically //linked &ObjectModel::name method, not the python imported //instance. cout << model->name() << endl; Py_Finalize(); } Mat. From yakumoklesk at yahoo.es Wed Sep 10 17:54:48 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Wed, 10 Sep 2003 17:54:48 +0200 Subject: [C++-sig] very basic: calling python function from c++ In-Reply-To: <3F5F2D16.7070106@riks.nl> Message-ID: <3F5F6568.28502.4D55F20@localhost> Hi, I am also new in Boost.Python. In fact, I just joined this gropu yesterday and downloaded the binaries of libraries. I also compiled them (although I thikn it was not necessary). I have not used Boost.Python yet, but I have been using in the last days some C/Python API functions to access to python objects. This is what I did to call a function from a module of mine: Py_Initialize(); // This loads my python module PyRun_SimpleString("import ModuleLoader"); // This gets the sys.modules dictionary (it shoud have NULL check?) PyObject *dicModuleAdm = PyImport_GetModuleDict(); // This is where I get the my module, no check, I supose I will have to put one PyObject *modModule = PyMapping_GetItemString( dicModuleAdm, "ModuleLoader" ); // I get a class instance generated by ModuleLoader when it was imported and executed (sorry for the coments in spanish ^_^) PyObject* dtTree = PyObject_GetAttrString( modModule, "dtTree" ); if( !dtTree ) { printf("No encontrada instancia ModuleLoader.dtTree" ); return; } // I get the function of the instance PyObject* funcPrintTree = PyObject_GetAttrString( dtTree, "PrintTree" ); if( !dtTree ) { printf("No encontrada funci?n dtTree.PrintTree()" ); return; } // I check if it is callable (don't think is necessary because you defined it) if( PyCallable_Check( funcPrintTree ) ) { // I build the arguments. This function needs one integer value PyObject* argFuncArgs = Py_BuildValue( "(i)", 1 ); // I call the object and get the result (PyNone) PyObject* resNoneResult = PyEval_CallObject( funcPrintTree, argFuncArgs ); // Check if the funtion call went OK if( !resNoneResult ) { PyErr_Print(); printf("Resultados no devueltos, objeto no callable o error" ); return; } } I expect this will help you. And for the rest of programmers, I have a question: I have this code: PyObject *modBuiltIn = PyMapping_GetItemString( dicModuleAdm, "__builtin__" ); PyObject *dicBuiltInDict = PyObject_GetAttrString( modBuiltIn, "__dict__" ); PyObject *funLocals = PyMapping_GetItemString( dicBuiltInDict, "locals" ); PyObject* resLocalsResult = PyEval_CallObject( funLocals, NULL ); That is, I get the builtin module, get the dict, get the local() function and call it. But I get an ACCESS VIOLATION from C++, inside the C fille bltinmodule.c from the python code directories. What it happens is that the line d = PyEval_GetLocals() in bltinmodule.c returns NULL, and inmediately it does: Py_INCREF(d), producing an acces violation. Of course, there is another way to get the locals dictionary: PyRun_SimpleString("LOCALS = locals"); and then get acces to the LOCALS dictionary variable object, through the __builtin__.__dict__, but *I* don't like this way. Why it produces an acces violation? Is a bug or what? Thank you in advance. David Lucena. On 10 Sep 2003 at 15:54, Roel Vanhout wrote: > > Hello everybody, I'm only just starting out with boost.python and with > python embedding and I have a very basic question. I have found examples > of how to get an object into c++ from python and call functions on it, > but what I'm trying to do is to get a function pointer to a python > function and call that function with two parameters. Basically I have > two numbers and users can enter an expression into the gui of the c++ > program like this: > > return num1 + num2 > > I thought that then in my c++ program, I'd prepend 'function > calculate(num1, num2):' to that string, indent the expresson properly > and then run the whole thing in python, passing the two numbers that I > have in my c++ program to the python function. So I'm looking for a way > to get a function pointer that I can pass two numbers and that returns a > double. I hope I made myself clear - can anyone help me? Thanks in advance. > > cheers, > > roel > > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From roel at riks.nl Wed Sep 10 18:01:00 2003 From: roel at riks.nl (Roel Vanhout) Date: Wed, 10 Sep 2003 18:01:00 +0200 Subject: [C++-sig] very basic: calling python function from c++ In-Reply-To: <3F5F6568.28502.4D55F20@localhost> References: <3F5F6568.28502.4D55F20@localhost> Message-ID: <3F5F4ABC.9070006@riks.nl> yakumoklesk at yahoo.es wrote: > Hi, I am also new in Boost.Python. In fact, I just joined this gropu yesterday and > downloaded the binaries of libraries. I also compiled them (although I thikn it was not > necessary). I have not used Boost.Python yet, but I have been using in the last days > some C/Python API functions to access to python objects. > This is what I did to call a function from a module of mine: Thank you very much, I'm going to try this approach too. In fact, just when your message arrived here, I was composing a reply to my own message saying that I had just found http://www.boost.org/libs/python/doc/v2/callbacks.html which describes how to call python functions from with boost.python. My code is compiling right now, so I'm going to check if I understood it all correct ;) Sorry for waisting everybody's time. cheers, roel From eric.anderson at comcast.net Wed Sep 10 20:09:38 2003 From: eric.anderson at comcast.net (=?us-ascii?Q?eric_andersonT?=) Date: Wed, 10 Sep 2003 11:09:38 -0700 Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question Message-ID: <006701c377c6$b326f2d0$bf01a8c0@ea1xp> Hi everyone, I have a question about the macro in the email subject and how to specify return_value_policy() using it. Where does it fit into this (untested pseudo-c++): struct A { int a; }; struct B { A* foo(); }; struct C { B* bar( int a=0 ); }; BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS( bar_overloads, C::bar, 0, 1 ); void GlueToPython() { using boost::python; class( "A", "class A", init<> ) ; class( "B", "class B", init<> ) .def( "foo", &B::foo, "returns object of class A", return_value_policy() ) ; class( "C", "class C", init<> ) // NEEDED HERE: return_value_policy() .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; } Thank you, Eric From yakumoklesk at yahoo.es Wed Sep 10 22:12:31 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Wed, 10 Sep 2003 22:12:31 +0200 Subject: [C++-sig] What is Boos.Python for? In-Reply-To: <3F5F4ABC.9070006@riks.nl> References: <3F5F6568.28502.4D55F20@localhost> Message-ID: <3F5FA1CF.14432.5C14FE2@localhost> For what I have been reading, it seems that Boost.Python is very useful to make extension modules in C++, that is, making DLLs to be imported from python. But, is there a way of using Boost to communicate with python using a C++ program. What I mean is to run a program (an MFC application or a console application) made in C++ that internally calls python. Thank you. David Lucena From simon.ouellet at orthosoft.ca Wed Sep 10 23:28:49 2003 From: simon.ouellet at orthosoft.ca (Simon Ouellet) Date: Wed, 10 Sep 2003 21:28:49 -0000 Subject: [C++-sig] to_python (by-value) converter Message-ID: Hi, I'm using boost::python for embedding python into my application. I defined a module that containt a class_. I can successfully instantiate a Vector in the embedded python but I cannot create a python::object containing a Vector in C++ Vector aVector; python::object(aVector); this statement gave me an error: TypeError: No to_python (by-value) converter found for C++ type: N3Osm13MotionCapture6VectorE Where N3Osm13MotionCapture6VectorE is my class Vector that has a default copy constructor publicly available. What could be the problem? and what should I do to fix it? Thanks This is the code defined: BOOST_PYTHON_MODULE(pythonExtension) { python::class_ ("Vector", python::init()) .add_property("x", &Vector::GetX, &Vector::SetX) .add_property("y", &Vector::GetY, &Vector::SetY) .add_property("z", &Vector::GetZ, &Vector::SetZ) .def("Norm", &Vector::GetNorm) .def("Norm2", &Vector::GetNorm2) .def("Normalize", &Vector::Normalize) .def("Invert", &Vector::Invert) .def(python::self + python::self) .def(python::self - python::self) .def(python::self * double()) .def(double() * python::self) .def(python::self / double()) .def(python::self == python::self) .def(python::self != python::self) .def("DoProduct", &DotProduct); } int main() { Vector aVector(1.1, 23.3 , 2); PyImport_AppendInittab("pythonExtension", initpythonExtension); Py_Initialize(); python::handle<>main(python::borrowed(PyImport_AddModule("__main__"))); mGlobals = python::object(python::borrowed( PyModule_GetDict(main.get()))); /*The followin line is the problematic one */ mGlobals["SomeVector"] = python::object(aVector); ... } -- _________________________________________________________ Simon Ouellet email: simon.ouellet at orthosoft.ca Programmeur tel: 514-861-4074 #269 Orthosoft Inc. fax: 514-866-2197 From nicodemus at globalite.com.br Wed Sep 10 23:51:12 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 10 Sep 2003 18:51:12 -0300 Subject: [C++-sig] pyste -I In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A020B70D8@saturn.aculab.com> References: <8C9A566C643ED6119E8900A0C9DE297A020B70D8@saturn.aculab.com> Message-ID: <3F5F9CD0.8090202@globalite.com.br> Hi Jason, Jason.Sibthorpe at aculab.com wrote: >Hi Nicodemus, > >Thanks for your response. > > > >>Is there any reason that you can't hardcode the paths into the Pyste >>files? >> >> > >Yes and no. > >The problem as I see it. > >Hardcoding relative paths doesn't work if you generate the .cpp in a >different location to that in which you compile your sources. The >-output option doesn't help you here. > >Hardcoded absolute paths are the work of the devil. Sharing generated >sources between my project members requires changes to the sources and >windows paths don't work on Solaris nor Linux etc > >Surely this is exactly what the -I option if for? > > Wait wait. I misread your previous message: I read it in a hurry and understood that you wanted -I to locate *pyste* files, not header files. Really sorry about that! The -I option is intended to work as you expect (see FindHeader in CppParser), the problem is with AllFromHeader, it is broken in the current version. I suggest you use Class and Function until I fix AllFromHeader. 8/ Regards, Nicodemus. From nicodemus at globalite.com.br Wed Sep 10 23:53:55 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 10 Sep 2003 18:53:55 -0300 Subject: [C++-sig] pyste -I In-Reply-To: <3F5E51F4.1907.1A82A151@localhost> References: <3F5E51F4.1907.1A82A151@localhost> Message-ID: <3F5F9D73.6070907@globalite.com.br> Hi Niall! Niall Douglas wrote: >Nicodemus, didn't you add that variable preset to the pyste file's >absolute path like I had requested ages ago? It's literally two lines >of new code. > > Ops! Really sorry about that... I completely forgot. I didn't write it in my TODO because it was only two lines of code as you point it out, and I ended up forgetting it. It is in CVS now, the variable is INTERFACE_FILE, and contains the absolute path of the current pyste file... se os.path functions to extract the parts as needed. Regards, Nicodemus. From nicodemus at globalite.com.br Thu Sep 11 00:04:47 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 10 Sep 2003 19:04:47 -0300 Subject: [C++-sig] very basic: calling python function from c++ In-Reply-To: <3F5F2D16.7070106@riks.nl> References: <3F5F2D16.7070106@riks.nl> Message-ID: <3F5F9FFF.9010500@globalite.com.br> Hi Roel, Roel Vanhout wrote: > > Hello everybody, I'm only just starting out with boost.python and with > python embedding and I have a very basic question. I have found > examples of how to get an object into c++ from python and call > functions on it, but what I'm trying to do is to get a function > pointer to a python function and call that function with two > parameters. Basically I have two numbers and users can enter an > expression into the gui of the c++ program like this: > > return num1 + num2 > > I thought that then in my c++ program, I'd prepend 'function > calculate(num1, num2):' to that string, indent the expresson properly > and then run the whole thing in python, passing the two numbers that I > have in my c++ program to the python function. So I'm looking for a > way to get a function pointer that I can pass two numbers and that > returns a double. I hope I made myself clear - can anyone help me? > Thanks in advance. If you only want to evaluate a Python expression, use PyRun_String: PyObject* PyRun_String(char *str, int start, PyObject *globals, PyObject *locals) Return value: New reference. Execute Python source code from str in the context specified by the dictionaries globals and locals. The parameter start specifies the start token that should be used to parse the source code. Returns the result of executing the code as a Python object, or NULL if an exception was raised. For "start" use Py_eval_input, and wrap the result in a boost::python's object. Example (untested): boost::python::object pyresult = PyRun_String("(1 + 4) * 3", Py_eval_input, NULL, NULL); double result = boost::python::extract(pyresult); If you want to make some variables avaiable for the user ("x", "y", etc), create a dict and pass it as the globals parameter of the function. See the chapter Python/C API of the Python documentation for more info. HTH, Nicodemus. From josevnz at newbreak.com Thu Sep 11 01:48:14 2003 From: josevnz at newbreak.com (Jose Vicente Nunez Z) Date: Wed, 10 Sep 2003 23:48:14 -0000 Subject: [C++-sig] Problems loading installed extensions: help needed Message-ID: <1063237689.29974.47.camel@linux0037> Greetings, I wrote a Pythin extension module but for some reason i cannot load it at runtime: [josevnz at linux0037 TestNative]$ ./scripts/Test.py Traceback (most recent call last): File "./scripts/Test.py", line 6, in ? import test.NativeDummy ImportError: No module named NativeDummy [josevnz at linux0037 TestNative]$ ./scripts/Test.py Traceback (most recent call last): File "./scripts/Test.py", line 6, in ? import test.NativeDummy ImportError: No module named NativeDummy But it seems to be installed on the proper location: [root at linux0037 dist]# rpm -ihv --force python-TestNative-0.0-1.i386.rpm Preparing... ########################################### [100%] 1:python-TestNative ########################################### [100%] [root at linux0037 dist]# rpm -ql python-TestNative /usr/lib/python2.2/site-packages/test/Dummy.py /usr/lib/python2.2/site-packages/test/Dummy.pyc /usr/lib/python2.2/site-packages/test/NativeDummy.so /usr/lib/python2.2/site-packages/test/__init__.py /usr/lib/python2.2/site-packages/test/__init__.pyc So far this is the code (the extension is called NativeDummy): #!/usr/bin/env python2 # # Hello world to test native interfaces in Python # import test.NativeDummy import test.Dummy argument1 = "Test string argument" argument2 = 600000 test.NativeDummy(argument1, argument2) dumber = test.Dummy.Dummy("really dumb") This is my setup.py file (so far i think all here is ok): #!/usr/bin/env python2 # # Hello world to test native interfaces in Python # from distutils.core import setup, Extension VERSION=0 RELEASE=0 extension1 = Extension('test.NativeDummy', define_macros = [('MAJOR_VERSION', VERSION), ('MINOR_VERSION', RELEASE)], include_dirs = ['/include'], libraries = ['m'], library_dirs = ['/lib'], sources = ['src/c/dummy.c']) setup (name = 'python-TestNative', version = VERSION, description = 'My practice native test with Python.', author = 'ZZZZ', author_email = 'XXX', url = 'SSSS', package_dir = {'' : 'src/python'}, packages = ['test'], long_description = ''' My practice native test with Python. Hope this works. ''', ext_modules = [extension1]) This is my current directory layout: [josevnz at linux0037 TestNative]$ find ./ ./ ./Makefile ./src ./src/python ./src/python/test ./src/python/test/Dummy.py ./src/python/test/__init__.py ./src/python/__init__.py ./src/c ./src/c/dummy.c~ ./src/c/dummy.c ./setup.py ./.setup.py.swp ./scripts ./scripts/Test.py ./scripts/Test.py~ ./scripts/.Test.py.swp ./dist ./dist/python-TestNative-0.0.tar.gz ./dist/python-TestNative-0.0-1.src.rpm ./dist/python-TestNative-0.0-1.i386.rpm ./README.txt ./build ./build/bdist.linux-i686 ./build/bdist.linux-i686/rpm ./build/bdist.linux-i686/rpm/SOURCES ./build/bdist.linux-i686/rpm/SOURCES/python-TestNative-0.0.tar.gz ./build/bdist.linux-i686/rpm/SPECS ./build/bdist.linux-i686/rpm/SPECS/python-TestNative.spec ./build/bdist.linux-i686/rpm/BUILD ./build/bdist.linux-i686/rpm/RPMS ./build/bdist.linux-i686/rpm/RPMS/i386 ./build/bdist.linux-i686/rpm/SRPMS ./MANIFEST I'm using Python 2.2, on Redhat 7.2 Any ideas what i'm doing wrong? From eric.anderson at comcast.net Thu Sep 11 01:54:42 2003 From: eric.anderson at comcast.net (=?us-ascii?Q?eric_andersonT?=) Date: Wed, 10 Sep 2003 16:54:42 -0700 Subject: [C++-sig] Problems loading installed extensions: help needed In-Reply-To: <1063237689.29974.47.camel@linux0037> Message-ID: <00d901c377f6$e768c890$bf01a8c0@ea1xp> Was NativeDummy.so built with the DEBUG preprocessor flag defined? I could be wrong here, but I'm pretty sure that if you built the module with the DEBUG flag, you must load it with a debug build of the python interpreter. Eric -----Original Message----- From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On Behalf Of Jose Vicente Nunez Z Sent: Wednesday, September 10, 2003 4:48 PM To: Development of Python/C++ integration Subject: [C++-sig] Problems loading installed extensions: help needed Greetings, I wrote a Pythin extension module but for some reason i cannot load it at runtime: [josevnz at linux0037 TestNative]$ ./scripts/Test.py Traceback (most recent call last): File "./scripts/Test.py", line 6, in ? import test.NativeDummy ImportError: No module named NativeDummy [josevnz at linux0037 TestNative]$ ./scripts/Test.py Traceback (most recent call last): File "./scripts/Test.py", line 6, in ? import test.NativeDummy ImportError: No module named NativeDummy But it seems to be installed on the proper location: [root at linux0037 dist]# rpm -ihv --force python-TestNative-0.0-1.i386.rpm Preparing... ########################################### [100%] 1:python-TestNative ########################################### [100%] [root at linux0037 dist]# rpm -ql python-TestNative /usr/lib/python2.2/site-packages/test/Dummy.py /usr/lib/python2.2/site-packages/test/Dummy.pyc /usr/lib/python2.2/site-packages/test/NativeDummy.so /usr/lib/python2.2/site-packages/test/__init__.py /usr/lib/python2.2/site-packages/test/__init__.pyc So far this is the code (the extension is called NativeDummy): #!/usr/bin/env python2 # # Hello world to test native interfaces in Python # import test.NativeDummy import test.Dummy argument1 = "Test string argument" argument2 = 600000 test.NativeDummy(argument1, argument2) dumber = test.Dummy.Dummy("really dumb") This is my setup.py file (so far i think all here is ok): #!/usr/bin/env python2 # # Hello world to test native interfaces in Python # from distutils.core import setup, Extension VERSION=0 RELEASE=0 extension1 = Extension('test.NativeDummy', define_macros = [('MAJOR_VERSION', VERSION), ('MINOR_VERSION', RELEASE)], include_dirs = ['/include'], libraries = ['m'], library_dirs = ['/lib'], sources = ['src/c/dummy.c']) setup (name = 'python-TestNative', version = VERSION, description = 'My practice native test with Python.', author = 'ZZZZ', author_email = 'XXX', url = 'SSSS', package_dir = {'' : 'src/python'}, packages = ['test'], long_description = ''' My practice native test with Python. Hope this works. ''', ext_modules = [extension1]) This is my current directory layout: [josevnz at linux0037 TestNative]$ find ./ ./ ./Makefile ./src ./src/python ./src/python/test ./src/python/test/Dummy.py ./src/python/test/__init__.py ./src/python/__init__.py ./src/c ./src/c/dummy.c~ ./src/c/dummy.c ./setup.py ./.setup.py.swp ./scripts ./scripts/Test.py ./scripts/Test.py~ ./scripts/.Test.py.swp ./dist ./dist/python-TestNative-0.0.tar.gz ./dist/python-TestNative-0.0-1.src.rpm ./dist/python-TestNative-0.0-1.i386.rpm ./README.txt ./build ./build/bdist.linux-i686 ./build/bdist.linux-i686/rpm ./build/bdist.linux-i686/rpm/SOURCES ./build/bdist.linux-i686/rpm/SOURCES/python-TestNative-0.0.tar.gz ./build/bdist.linux-i686/rpm/SPECS ./build/bdist.linux-i686/rpm/SPECS/python-TestNative.spec ./build/bdist.linux-i686/rpm/BUILD ./build/bdist.linux-i686/rpm/RPMS ./build/bdist.linux-i686/rpm/RPMS/i386 ./build/bdist.linux-i686/rpm/SRPMS ./MANIFEST I'm using Python 2.2, on Redhat 7.2 Any ideas what i'm doing wrong? _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From mike at nospam.com Thu Sep 11 02:10:45 2003 From: mike at nospam.com (Mike Rovner) Date: Wed, 10 Sep 2003 17:10:45 -0700 Subject: [C++-sig] Re: Problems loading installed extensions: help needed References: <1063237689.29974.47.camel@linux0037> <00d901c377f6$e768c890$bf01a8c0@ea1xp> Message-ID: eric andersonT wrote: > Was NativeDummy.so built with the DEBUG preprocessor flag defined? I > could be wrong here, but I'm pretty sure that if you built the module > with the DEBUG flag, you must load it with a debug build of the python > interpreter. You are mistaken. I successfully use regular python with debug bpl and my code. > -----Original Message----- > From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] > On Behalf Of Jose Vicente Nunez Z > /usr/lib/python2.2/site-packages/test/NativeDummy.so Don't you have to name it NativeDummy.pyd (just rename)? HTH, Mike From josevnz at newbreak.com Thu Sep 11 05:00:40 2003 From: josevnz at newbreak.com (Jose Vicente Nunez Zuleta) Date: Thu, 11 Sep 2003 03:00:40 -0000 Subject: [C++-sig] Problems loading installed extensions: help needed In-Reply-To: <00d901c377f6$e768c890$bf01a8c0@ea1xp> References: <00d901c377f6$e768c890$bf01a8c0@ea1xp> Message-ID: <1063249233.2389.2.camel@localhost.localdomain> Hmmm, thats sounds weird. I mean, why the debug symbols should matter to the Python interpreter? Also, renaming the module to pyd should not matter, i guess Python should be able to load the extension as an 'so'. Any ideas? How i can check what Python is trying to load at runtime? (like a verbose flag) Thanks, JV. On Wed, 2003-09-10 at 19:54, eric andersonT wrote: > Was NativeDummy.so built with the DEBUG preprocessor flag defined? I > could be wrong here, but I'm pretty sure that if you built the module > with the DEBUG flag, you must load it with a debug build of the python > interpreter. > > Eric > > -----Original Message----- > From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On > Behalf Of Jose Vicente Nunez Z > Sent: Wednesday, September 10, 2003 4:48 PM > To: Development of Python/C++ integration > Subject: [C++-sig] Problems loading installed extensions: help needed > > > Greetings, > > I wrote a Pythin extension module but for some reason i cannot load it > at runtime: > > > [josevnz at linux0037 TestNative]$ ./scripts/Test.py > Traceback (most recent call last): > File "./scripts/Test.py", line 6, in ? > import test.NativeDummy > ImportError: No module named NativeDummy > [josevnz at linux0037 TestNative]$ ./scripts/Test.py > Traceback (most recent call last): > File "./scripts/Test.py", line 6, in ? > import test.NativeDummy > ImportError: No module named NativeDummy > > But it seems to be installed on the proper location: > > > [root at linux0037 dist]# rpm -ihv --force python-TestNative-0.0-1.i386.rpm > Preparing... ########################################### > [100%] > 1:python-TestNative ########################################### > [100%] > [root at linux0037 dist]# rpm -ql python-TestNative > /usr/lib/python2.2/site-packages/test/Dummy.py > /usr/lib/python2.2/site-packages/test/Dummy.pyc > /usr/lib/python2.2/site-packages/test/NativeDummy.so > /usr/lib/python2.2/site-packages/test/__init__.py > /usr/lib/python2.2/site-packages/test/__init__.pyc > > So far this is the code (the extension is called NativeDummy): > > #!/usr/bin/env python2 > # > # Hello world to test native interfaces in Python > # > import test.NativeDummy > import test.Dummy > > argument1 = "Test string argument" > argument2 = 600000 > test.NativeDummy(argument1, argument2) > dumber = test.Dummy.Dummy("really dumb") > > This is my setup.py file (so far i think all here is ok): > > #!/usr/bin/env python2 > # > # Hello world to test native interfaces in Python > # > from distutils.core import setup, Extension > > VERSION=0 > RELEASE=0 > > extension1 = Extension('test.NativeDummy', > define_macros = [('MAJOR_VERSION', VERSION), > ('MINOR_VERSION', RELEASE)], > include_dirs = ['/include'], > libraries = ['m'], > library_dirs = ['/lib'], > sources = ['src/c/dummy.c']) > > setup (name = 'python-TestNative', > version = VERSION, > description = 'My practice native test with Python.', > author = 'ZZZZ', > author_email = 'XXX', > url = 'SSSS', > package_dir = {'' : 'src/python'}, > packages = ['test'], > long_description = ''' > My practice native test with Python. > Hope this works. > ''', > ext_modules = [extension1]) > > This is my current directory layout: > > [josevnz at linux0037 TestNative]$ find ./ > ./ > ./Makefile > ./src > ./src/python > ./src/python/test > ./src/python/test/Dummy.py > ./src/python/test/__init__.py > ./src/python/__init__.py > ./src/c > ./src/c/dummy.c~ > ./src/c/dummy.c > ./setup.py > ./.setup.py.swp > ./scripts > ./scripts/Test.py > ./scripts/Test.py~ > ./scripts/.Test.py.swp > ./dist > ./dist/python-TestNative-0.0.tar.gz > ./dist/python-TestNative-0.0-1.src.rpm > ./dist/python-TestNative-0.0-1.i386.rpm > ./README.txt > ./build > ./build/bdist.linux-i686 > ./build/bdist.linux-i686/rpm > ./build/bdist.linux-i686/rpm/SOURCES > ./build/bdist.linux-i686/rpm/SOURCES/python-TestNative-0.0.tar.gz > ./build/bdist.linux-i686/rpm/SPECS > ./build/bdist.linux-i686/rpm/SPECS/python-TestNative.spec > ./build/bdist.linux-i686/rpm/BUILD > ./build/bdist.linux-i686/rpm/RPMS > ./build/bdist.linux-i686/rpm/RPMS/i386 > ./build/bdist.linux-i686/rpm/SRPMS > ./MANIFEST > > > I'm using Python 2.2, on Redhat 7.2 > > > Any ideas what i'm doing wrong? > > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- Jose Vicente Nunez Zuleta Newbreak LLC From dave at boost-consulting.com Thu Sep 11 05:34:00 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 23:34:00 -0400 Subject: [C++-sig] Re: Problems loading installed extensions: help needed References: <1063237689.29974.47.camel@linux0037> <00d901c377f6$e768c890$bf01a8c0@ea1xp> Message-ID: "Mike Rovner" writes: > eric andersonT wrote: >> Was NativeDummy.so built with the DEBUG preprocessor flag defined? I >> could be wrong here, but I'm pretty sure that if you built the module >> with the DEBUG flag, you must load it with a debug build of the python >> interpreter. > > You are mistaken. I successfully use regular python with debug bpl and my > code. That's because you use Boost.Build, isn't it? Most problems building or running Boost.Python extensions come from getting "creative" with build systems ;->. Jose, please try your test using Boost.Build first according to the instructions at http://www.boost.org/libs/python/doc/building.html (or, if you're using the CVS version, http://www.boost-consulting.com/boost/libs/python/doc/building.html) It's fairly painless, and once you've done it that way you can translate the results to happen under distutils or whatever your preferred method might be. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 05:42:11 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 23:42:11 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: Message-ID: Simon Ouellet writes: > Hi, > > I'm using boost::python for embedding python into my application. > > I defined a module that containt a class_. > > I can successfully instantiate a Vector in the embedded python but > I cannot create a python::object containing a Vector in C++ > > Vector aVector; > python::object(aVector); > this statement gave me an error: > > TypeError: No to_python (by-value) converter found for C++ type: > N3Osm13MotionCapture6VectorE > > > Where N3Osm13MotionCapture6VectorE is my class Vector that has a default > copy constructor publicly available. > > What could be the problem? and what should I do to fix it? I can only guess that the C++ type "Vector" that you're wrapping below is not the same as Osm::MotionCapture::Vector, the type in the error message. Could you post a complete, reproducible test case? Did you base your code on the contents of the libs/python/test/embedding.cpp file? For what it's worth, this: > mGlobals["SomeVector"] = python::object(aVector); ^^^^^^^^^^^^^^^ ^ is redundant. mGlobals["SomeVector"] = aVector; is equivalent. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 05:44:45 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 23:44:45 -0400 Subject: [C++-sig] Re: BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question References: <006701c377c6$b326f2d0$bf01a8c0@ea1xp> Message-ID: eric andersonT writes: > Where does it fit into this (untested pseudo-c++): Please elaborate. What do you mean by that question? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 05:51:40 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 23:51:40 -0400 Subject: [C++-sig] Re: Is this use of Boost.Python safe? References: <3F5F348A.9010500@matbray.com> Message-ID: Matthew Bray writes: > [originally posted to the boost.user list] > > I have a question regarding the use of Boost.Python. What I would like > to do is to provide a simple scripting interface to an application in > much the same way as Microsoft use Visual Basic within much of their > product line (e.g. Excel) to provide direct access to the applications > object model. > My design is stunningly rendered below, > > +-------------------------+ > | Application--+ | > | | | Dynamically +---------------+ > | v | Linked | Python Module | > | +--->ObjectModel<------------------| | > | | | +---------------+ > | +---------------------+ | | > | | Python Interpretter |<----------------------+ > | | | | ">>> import ..." > | +---------------------+ | > +-------------------------+ > > What we have firstly is a our python module, in this case it exports a > simple class 'ObjectModel' with various functions, sub objects and > whatever else is required for the application to run. This is our > Object Model, and is usable from the python interpretter on the > command line. > For what we have in mind however is for the python interpretter to be > running inside the application (through use of the Py* functions from > the python API and use of the relevant parts of Boost.Python - > handle<>, object). > What I want is for the application and the python instance to share > the object model, for the interpretter to have knowledge of the > ObjectModel it is simply imported from the python module. The > application itself is linked against the python module in order to use > ObjectModel (the relevant compiler specific code is inserted so that > the ObjectModel class is exported/imported - __declspec(dllexport) and > dllimport under Visual C++). You can do that. I'd be inclined to stick the ObjectModel code in a separate DLL that's used by the App and the extension module, but your way works. > With this setup, it is now possible to create an instance of > ObjectModel within the python interpretter and use > extract(...) in order to get access to it within the > application, no doubt it is also possible to create the ObjectModel > within the application and pass it to the python interpretter to use > it there. Yes. > Now my question basically regards pitfalls in this approach, there > are two instances of the Python Module in use here Huh!? What do you mean by "two instances"? > but I'm sure that as long as care is taken to ensure the ObjectModel > is destructed on the same heap that it was created on then there > shall be no problems. I wouldn't count on it. Please elaborate on what you mean by the above "two instances" remark. > Is there any other, possibly better way to do > this perhaps - e.g. without requiring the use of the module at all, > simply passing the Boost.Python class descriptions directly to the > embedded interpretter. See http://www.boost.org/libs/python/test/embedding.cpp. Does that help? > A simple test harness I have /appears/ to work fine with the above > design. > > Here's an extremely cut down bit of code that should show kind of what > I'm working on if I'm being a little unclear: > > my_module.hpp - this is the class that is in the python module that we > shall have access to within python and our application: > > struct PLATFORM_SPECIFIC_DLL_EXPORT_COMMAND ObjectModel > { > const char * name() const; > }; > > my_application.cpp - assume all the correct headers are included, the > module is linked against etc: > > int main(int argc,char ** argv) > { > Py_Initialize(); > > //initialize the environment > handle<> main_module(borrowed(PyImport_AddModule("__main__"))); > handle<> main_namespace( > borrowed(PyModule_GetDict(main_module.get()))); > > //import our python module > handle<>(PyRun_String("import my_module", Py_file_input, > main_namespace.get(), main_namespace.get()) ); > > //create a new instance of ObjectModel within python > handle<>(PyRun_String("model = my_module.ObjectModel()", > Py_file_input, main_namespace.get(), main_namespace.get())); > > //get the instance of ObjectModel and use it within our application > object tmp(main_namespace); > ObjectModel * model = extract(tmp["model"]); > > //use the model, the function is dispatched to the dynamically > //linked &ObjectModel::name method, not the python imported > //instance. > cout << model->name() << endl; > > Py_Finalize(); ^^^^^^^^^^^ This is a pitfall. Boost.Python hasn't been made "finalize-safe", yet. Dirk Gerritts was working on it, but... > } > > > Mat. -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Thu Sep 11 06:04:45 2003 From: romany at actimize.com (Roman Yakovenko) Date: Thu, 11 Sep 2003 07:04:45 +0300 Subject: [C++-sig] Boost.Python bug found Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020649@exchange.adrembi.com> Hi. I think I find bug. Description. I wrote converter for std::wstring from\to PyUnicodeObject. ( Thanks to Ralf W. Grosse-Kunstleve and his article Converting CString to/from std::string ) After registration it works pretty well ( for me ). But if I want to expose std::vector< std::wstring > using vector_indexing_suite I get error message: TypeError: No Python class registered for C++ class class _STL::basic_string,class _STL::allocator > Also the same bug happens with def_readwrite function. But I don't have small reproducable case. I append 2 files to this message. cpp - contains registration of converter, test function for it, class that contains vector of wstring. py - contains very little test for converter, and also reproduce the error. Also if David Abrahams thinks that my converter is good enough to be in the library - I may polish it and write a lot of test Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: iter_wrapper.cpp Type: application/octet-stream Size: 2901 bytes Desc: iter_wrapper.cpp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_iter_wrapper.py Type: application/octet-stream Size: 222 bytes Desc: test_iter_wrapper.py URL: From dave at boost-consulting.com Thu Sep 11 05:43:46 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 10 Sep 2003 23:43:46 -0400 Subject: [C++-sig] Re: What is Boos.Python for? References: <3F5F6568.28502.4D55F20@localhost> <3F5FA1CF.14432.5C14FE2@localhost> Message-ID: yakumoklesk at yahoo.es writes: > For what I have been reading, it seems that Boost.Python is very useful > to make extension modules in C++, that is, making DLLs to be imported > from python. > But, is there a way of using Boost to communicate with python using a > C++ program. What I mean is to run a program (an MFC application or > a console application) made in C++ that internally calls python. Does this answer your question? http://www.boost.org/libs/python/test/embedding.cpp HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From eric.anderson at comcast.net Thu Sep 11 06:32:29 2003 From: eric.anderson at comcast.net (=?us-ascii?Q?eric_andersonT?=) Date: Wed, 10 Sep 2003 21:32:29 -0700 Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question In-Reply-To: <006701c377c6$b326f2d0$bf01a8c0@ea1xp> Message-ID: <014401c3781d$b618d010$bf01a8c0@ea1xp> In this statement from my example below: class( "C", "class C", init<> ) .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; The function bar() is a member of class C. It has a default parameter in it's declaration. I'm using the macro BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS to generate the variants of the function with default parameters supplied and not supplied. The function itself returns a pointer that needs to be adopted by python. I need to specify this to boost. I don't know the syntax for this when wrapping the function using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro. -----Original Message----- From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On Behalf Of David Abrahams Sent: Wednesday, September 10, 2003 8:45 PM To: c++-sig at python.org Subject: [C++-sig] Re: BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question eric andersonT writes: > Where does it fit into this (untested pseudo-c++): Please elaborate. What do you mean by that question? -----Original Message----- From: c++-sig-bounces+eric.anderson=comcast.net at python.org [mailto:c++-sig-bounces+eric.anderson=comcast.net at python.org] On Behalf Of eric andersonT Sent: Wednesday, September 10, 2003 11:10 AM To: c++-sig at python.org Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question Hi everyone, I have a question about the macro in the email subject and how to specify return_value_policy() using it. Where does it fit into this (untested pseudo-c++): struct A { int a; }; struct B { A* foo(); }; struct C { B* bar( int a=0 ); }; BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS( bar_overloads, C::bar, 0, 1 ); void GlueToPython() { using boost::python; class( "A", "class A", init<> ) ; class( "B", "class B", init<> ) .def( "foo", &B::foo, "returns object of class A", return_value_policy() ) ; class( "C", "class C", init<> ) // NEEDED HERE: return_value_policy() .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; } Thank you, Eric _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From eric.anderson at comcast.net Thu Sep 11 06:40:47 2003 From: eric.anderson at comcast.net (=?us-ascii?Q?eric_andersonT?=) Date: Wed, 10 Sep 2003 21:40:47 -0700 Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question In-Reply-To: <014401c3781d$b618d010$bf01a8c0@ea1xp> Message-ID: <014801c3781e$ded83850$bf01a8c0@ea1xp> To put it even simpler: where to I specify "return_value_policy()" in this statement: class( "C", "class C", init<> ) .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; Thanks, Eric -----Original Message----- From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On Behalf Of eric andersonT Sent: Wednesday, September 10, 2003 9:32 PM To: 'Development of Python/C++ integration' Subject: RE: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question In this statement from my example below: class( "C", "class C", init<> ) .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; The function bar() is a member of class C. It has a default parameter in it's declaration. I'm using the macro BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS to generate the variants of the function with default parameters supplied and not supplied. The function itself returns a pointer that needs to be adopted by python. I need to specify this to boost. I don't know the syntax for this when wrapping the function using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro. -----Original Message----- From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On Behalf Of David Abrahams Sent: Wednesday, September 10, 2003 8:45 PM To: c++-sig at python.org Subject: [C++-sig] Re: BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question eric andersonT writes: > Where does it fit into this (untested pseudo-c++): Please elaborate. What do you mean by that question? -----Original Message----- From: c++-sig-bounces+eric.anderson=comcast.net at python.org [mailto:c++-sig-bounces+eric.anderson=comcast.net at python.org] On Behalf Of eric andersonT Sent: Wednesday, September 10, 2003 11:10 AM To: c++-sig at python.org Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question Hi everyone, I have a question about the macro in the email subject and how to specify return_value_policy() using it. Where does it fit into this (untested pseudo-c++): struct A { int a; }; struct B { A* foo(); }; struct C { B* bar( int a=0 ); }; BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS( bar_overloads, C::bar, 0, 1 ); void GlueToPython() { using boost::python; class( "A", "class A", init<> ) ; class( "B", "class B", init<> ) .def( "foo", &B::foo, "returns object of class A", return_value_policy() ) ; class( "C", "class C", init<> ) // NEEDED HERE: return_value_policy() .def( "bar", &C::bar, bar_overloads( args( "a" ), "returns object of class B" ) ; } Thank you, Eric _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From mat at matbray.com Thu Sep 11 10:18:49 2003 From: mat at matbray.com (Matthew Bray) Date: Thu, 11 Sep 2003 10:18:49 +0200 Subject: [C++-sig] Re: Is this use of Boost.Python safe? References: <3F5F348A.9010500@matbray.com> Message-ID: <3F602FE9.1000502@matbray.com> David Abrahams wrote: > Matthew Bray writes: > > [snip] > > > You can do that. I'd be inclined to stick the ObjectModel code in a > separate DLL that's used by the App and the extension module, but > your way works. > I think this is a source of our confusion, I hope to expand on it a little better below (i.e. this is what I hope to do). > >>With this setup, it is now possible to create an instance of >>ObjectModel within the python interpretter and use >>extract(...) in order to get access to it within the >>application, no doubt it is also possible to create the ObjectModel >>within the application and pass it to the python interpretter to use >>it there. > > > Yes. > > >>Now my question basically regards pitfalls in this approach, there >>are two instances of the Python Module in use here > > > Huh!? > > What do you mean by "two instances"? > The class "ObjectModel" is within the dll "my_module.pyd", the python interpretter has one instance of it, i.e. through "import my_module", the application has another instance of it (the one which the application is dynamically linked against). Hence two instances of the same dll are running concurrently. We are passing objects created within python (from the first dll instance) into our application. When a method is called upon this ObjectModel instance within the application then a call is made to code in our second dll instance (the one the application is linked against). Hopefully this explains the issue a little better. +------------------------+ +---------------+ +-------------+ | App +----------+ | | my_module.pyd |--->| Class | | +----| Dll stub |<-----------+---------------+ | ObjectModel | | v +----------+ | Dynamically Linked +-------------+ | ObjectModel instance | | ^ | | +--|----------------+ | +---------------+ +-------------+ | | Py Interpretter <-------------| my_module.pyd |--->| Class | | +-------------------+ | +---------------+ | ObjectModel | +------------------------+ Imported +-------------+ > > >>but I'm sure that as long as care is taken to ensure the ObjectModel >>is destructed on the same heap that it was created on then there >>shall be no problems. > > > I wouldn't count on it. Please elaborate on what you mean by the > above "two instances" remark. > > >>Is there any other, possibly better way to do >>this perhaps - e.g. without requiring the use of the module at all, >>simply passing the Boost.Python class descriptions directly to the >>embedded interpretter. > > > See http://www.boost.org/libs/python/test/embedding.cpp. Does that > help? > yes alot, thanks. > > [snip] >> >> Py_Finalize(); > > ^^^^^^^^^^^ > > This is a pitfall. Boost.Python hasn't been made "finalize-safe", > yet. Dirk Gerritts was working on it, but... > Does this mean that handles aren't invalidated automatically, constructors arent called, memory isnt freed? Is there documentation on that I can find on this. Thanks, Mat. From bob at redivi.com Thu Sep 11 11:22:38 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu, 11 Sep 2003 05:22:38 -0400 Subject: [C++-sig] Building boost.python on Mac OS X Message-ID: <7C9291DE-E439-11D7-BE2C-000A95686CD8@redivi.com> > --- Harri Hakula < Harri.Hakula at hut.fi > wrote: > > > A few months ago one of my regression tests uncovered that some > objects >> are double-destructed. Maybe this is related. I sent a bug > report to >> Apple but never got a confirmation that the issue is > resolved. Would >> you be interested in trying the regression test? > >Yes, of course. Create an empty directory somewhere on your Mac (e.g. > /var/tmp/debug) and > download these two files: > http://cci.lbl.gov/~rwgk/bugs/mac_os/test_for_double_destruction_csh > http://cci.lbl.gov/~rwgk/bugs/mac_os/ > test_for_double_destruction.tar.gz Then > > chmod 755 test_for_double_destruction_csh > ./test_for_double_destruction_csh > > This should unpack the tar file (contains boost, scons and some of our > code) and compiles, links and runs one of our regression tests. > > On our Mac OS 10.2.? (? = 1, I think) with the Jun or Jul developer's > kit + Aug patch the output ends with: > > Total OK: 1300 > a_value_allocation: -12 > > The last line indicates the double-destruction problem. If you don't > see the last line there is no such problem. > > Please let me know how it goes. FYI, scitbx/array_family/tst_af_4.exe Total OK: 1300 [crack:~/tmp/debug] bob% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) This is OS X 10.2.6, with the XCode preview dev tools, the gcc 3.3 compiler selected, and MACOSX_DEPLOYMENT_TARGET=10.2 environment variable I'm just finishing CVS co right now to check out Boost.Python w/ Python 2.3, I'll make another post later about how that goes. -bob From bob at redivi.com Thu Sep 11 12:46:09 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu, 11 Sep 2003 06:46:09 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <7C9291DE-E439-11D7-BE2C-000A95686CD8@redivi.com> Message-ID: <2769D0F8-E445-11D7-BE2C-000A95686CD8@redivi.com> On Thursday, Sep 11, 2003, at 05:22 America/New_York, Bob Ippolito wrote: >> --- Harri Hakula < Harri.Hakula at hut.fi > wrote: >> > > A few months ago one of my regression tests uncovered that some >> objects >> are double-destructed. Maybe this is related. I sent a bug >> report to >> Apple but never got a confirmation that the issue is >> resolved. Would >> you be interested in trying the regression test? >> >Yes, of course. Create an empty directory somewhere on your Mac >> (e.g. /var/tmp/debug) and >> download these two files: >> http://cci.lbl.gov/~rwgk/bugs/mac_os/test_for_double_destruction_csh >> http://cci.lbl.gov/~rwgk/bugs/mac_os/ >> test_for_double_destruction.tar.gz Then >> >> chmod 755 test_for_double_destruction_csh >> ./test_for_double_destruction_csh >> >> This should unpack the tar file (contains boost, scons and some of our >> code) and compiles, links and runs one of our regression tests. >> >> On our Mac OS 10.2.? (? = 1, I think) with the Jun or Jul developer's >> kit + Aug patch the output ends with: >> >> Total OK: 1300 >> a_value_allocation: -12 >> >> The last line indicates the double-destruction problem. If you don't >> see the last line there is no such problem. >> >> Please let me know how it goes. > > FYI, > > scitbx/array_family/tst_af_4.exe > Total OK: 1300 > [crack:~/tmp/debug] bob% gcc -v > Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs > Thread model: posix > gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) > > This is OS X 10.2.6, with the XCode preview dev tools, the gcc 3.3 > compiler selected, and MACOSX_DEPLOYMENT_TARGET=10.2 environment > variable > > I'm just finishing CVS co right now to check out Boost.Python w/ > Python 2.3, I'll make another post later about how that goes. Well aside from the default bjam flags being wrong for making shared libraries on OS X (-shared is not valid), some interesting things happen, like this: (lots more stuff was up here) /usr/include/gcc/darwin/3.3/c++/bits/stl_multimap.h:165: instantiated from `std::multimap<_Key, _Tp, _Compare, _Alloc>::multimap(const _Compare&, typename std::_Rb_tree<_Key, std::pair, std::_Select1st >, _Compare, _Alloc>::allocator_type&) [with _Key = boost::any, _Tp = boost::signals::detail::connection_slot_pair, _Compare = boost::function2 >, _Alloc = std::allocator >]' libs/signals/src/signal_base.cpp:27: instantiated from here /Users/bob/src/Python/boost/boost/function/function_template.hpp:391: internal compiler error: in c_expand_expr, at c-common.c:4752 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Lots of this: /Users/bob/src/Python/boost/boost/python/converter/ rvalue_from_python_data.hpp:100: sorry, unimplemented: ` tree_list' not supported by dump_expr with this at the end: ...failed updating 87 targets... ...skipped 24 targets... Probably because -shared is not how to make dynamic libraries on OS X, but I'm not sure. I can't really put a lot of time into trying to get this to work, but it looks pretty hopeless with this version of gcc due to the internal compiler error. Perhaps a newer version of XCode may not have this problem? -bob From djowel at gmx.co.uk Thu Sep 11 13:51:16 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Thu, 11 Sep 2003 19:51:16 +0800 Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS question References: <014801c3781e$ded83850$bf01a8c0@ea1xp> Message-ID: <013901c3785b$4af47e40$64646464@godzilla> eric andersonT wrote: > To put it even simpler: where to I specify > "return_value_policy()" in this statement: > > class( "C", "class C", init<> ) > .def( "bar", &C::bar, bar_overloads( args( "a" ), > "returns object of class B" ) Hi, The syntax for the overload dispatcher is: X(keywords, docstring)[policies] Have you tried it? Anyway, if you have further problems, it would really be helpful if you can post a minimal working code so I can try it out myself. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Thu Sep 11 15:59:05 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 09:59:05 -0400 Subject: [C++-sig] Re: Building boost.python on Mac OS X References: <7C9291DE-E439-11D7-BE2C-000A95686CD8@redivi.com> <2769D0F8-E445-11D7-BE2C-000A95686CD8@redivi.com> Message-ID: Bob Ippolito writes: > libs/signals/src/signal_base.cpp:27: instantiated from here > /Users/bob/src/Python/boost/boost/function/function_template.hpp:391: > internal compiler error: in > c_expand_expr, at c-common.c:4752 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > Lots of this: > > /Users/bob/src/Python/boost/boost/python/converter/ > rvalue_from_python_data.hpp:100: sorry, unimplemented: ` > tree_list' not supported by dump_expr > > with this at the end: > > ...failed updating 87 targets... > ...skipped 24 targets... > > Probably because -shared is not how to make dynamic libraries on OS X, > but I'm not sure. Almost certainly not. These are internal compiler errors (BUGS) in GCC which have been around for many versions now. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 16:11:33 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 10:11:33 -0400 Subject: [C++-sig] Re: Is this use of Boost.Python safe? References: <3F5F348A.9010500@matbray.com> <3F602FE9.1000502@matbray.com> Message-ID: Matthew Bray writes: > David Abrahams wrote: >> Matthew Bray writes: >> [snip] >> You can do that. I'd be inclined to stick the ObjectModel code in a >> separate DLL that's used by the App and the extension module, but >> your way works. >> > > I think this is a source of our confusion, I hope to expand on it a > little better below (i.e. this is what I hope to do). > >> >>>With this setup, it is now possible to create an instance of >>>ObjectModel within the python interpretter and use >>>extract(...) in order to get access to it within the >>>application, no doubt it is also possible to create the ObjectModel >>>within the application and pass it to the python interpretter to use >>> it there. >> Yes. >> >>>Now my question basically regards pitfalls in this approach, there >>> are two instances of the Python Module in use here >> Huh!? >> What do you mean by "two instances"? >> > > The class "ObjectModel" is within the dll "my_module.pyd", You mean that it's declared __declspec(dll[ex|im]port) and its member function implementations are located there, I assume. > the python interpretter has one instance of it When you say one instance, I presume you do *not* mean what you get by constructing or new'ing ObjectModel in C++. > , i.e. through "import my_module", the application has another > instance of it (the one which the application is dynamically linked > against). my_module.pyd is the same file in both cases? > Hence two instances of the same dll are running concurrently. Are you sure that has any significance? For example, are static initializers run once or twice? Are there one or two copies of the static data (globals) from my_module.pyd in the program? It's easy enough to find out; just embed the following in your module: int x = 42; int __declspec(dllexport) getset(int y) { int z = x; x= y; return z; } ... def("getset", getset); and then call getset(7) from C++, start your interpreter, and invoke print getset(0) from Python. If the result is 7, as I expect, there's only one instance of my_module > We are passing objects created within python (from the > first dll instance) into our application. When a method is called > upon this ObjectModel instance within the application then a call is > made to code in our second dll instance (the one the application is > linked against). Hopefully this explains the issue a little better. > > +------------------------+ +---------------+ +-------------+ > | App +----------+ | | my_module.pyd |--->| Class | > | +----| Dll stub |<-----------+---------------+ | ObjectModel | > | v +----------+ | Dynamically Linked +-------------+ > | ObjectModel instance | > | ^ | > | +--|----------------+ | +---------------+ +-------------+ > | | Py Interpretter <-------------| my_module.pyd |--->| Class | > | +-------------------+ | +---------------+ | ObjectModel | > +------------------------+ Imported +-------------+ If there are really two instances of the DLL, and you're not currently having any trouble, it's purely because of implementation details of your compiler and I certainly can't say "what you're doing is safe". >>>but I'm sure that as long as care is taken to ensure the ObjectModel >>>is destructed on the same heap that it was created on then there >>> shall be no problems. >> I wouldn't count on it. Please elaborate on what you mean by the >> above "two instances" remark. >> >>>Is there any other, possibly better way to do >>>this perhaps - e.g. without requiring the use of the module at all, >>>simply passing the Boost.Python class descriptions directly to the >>> embedded interpretter. >> See http://www.boost.org/libs/python/test/embedding.cpp. Does that >> help? >> > > yes alot, thanks. > >> [snip] >>> >>> Py_Finalize(); >> ^^^^^^^^^^^ >> This is a pitfall. Boost.Python hasn't been made "finalize-safe", >> yet. Dirk Gerritts was working on it, but... >> > > Does this mean that handles aren't invalidated automatically, > constructors arent called, memory isnt freed? Is there documentation > on that I can find on this. See http://www.boost-consulting.com/boost/libs/python/todo.html#pyfinalize-safety HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 16:20:17 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 10:20:17 -0400 Subject: [C++-sig] Re: Boost.Python bug found References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020649@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > > Hi. I think I find bug. > Description. I wrote converter for std::wstring from\to > PyUnicodeObject. > ( Thanks to Ralf W. Grosse-Kunstleve and his article > Converting CString to/from std::string ) > > After registration it works pretty well ( for me ). But if I > want to expose > std::vector< std::wstring > using vector_indexing_suite I get > error message: > > TypeError: No Python class registered for C++ class class > _STL::basic_string _STL::char_traits,class > _STL::allocator > > > Also the same bug happens with def_readwrite function. > But I don't have small reproducable case. It's not a bug. The problem is that the use of proxies in an indexing suite requires that the element type be wrapped as a class. You can either expose class_... (etc) or you can pass NoProxy = true to the indexing suite. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 16:21:47 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 10:21:47 -0400 Subject: [C++-sig] Re: to_python_converter error question ... References: <3F5F0B5F.3000105@cirad.fr> Message-ID: Pierre Barbier de Reuille writes: > When I try to import a module I made, I have the error : > > RuntimeError: trying to register to_python_converter for a type which > already has a registered to_python_converter > > But when I re-import it, it just works ... is it normal ??? I think the module only gets initialized once. > Then another question : how to know which converter is duplicated ? Nasty. I have to improve that message. > Is it possible to trace what python do when importing ? Sure; use your favorite debugger. Search the Boost.Python sources for the error message and set a breakpoint. -- Dave Abrahams Boost Consulting www.boost-consulting.com From simon.ouellet at orthosoft.ca Thu Sep 11 16:42:24 2003 From: simon.ouellet at orthosoft.ca (Simon Ouellet) Date: Thu, 11 Sep 2003 14:42:24 -0000 Subject: [C++-sig] Re: to_python (by-value) converter In-Reply-To: References: Message-ID: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> I attached a complete reproducible test case. The ouptut that I got is: The following error occur in python converter: ================================================ TypeError: No to_python (by-value) converter found for C++ type: 3Foo ================================================ 3 The following error occur in python interpreter: ================================================ Traceback (most recent call last): File "", line 4, in ? NameError: name 'SomeFoo' is not defined ================================================ Thanks On Wed, 2003-09-10 at 23:42, David Abrahams wrote: > Simon Ouellet writes: > > > Hi, > > > > I'm using boost::python for embedding python into my application. > > > > I defined a module that containt a class_. > > > > I can successfully instantiate a Vector in the embedded python but > > I cannot create a python::object containing a Vector in C++ > > > > Vector aVector; > > python::object(aVector); > > this statement gave me an error: > > > > TypeError: No to_python (by-value) converter found for C++ type: > > N3Osm13MotionCapture6VectorE > > > > > > Where N3Osm13MotionCapture6VectorE is my class Vector that has a default > > copy constructor publicly available. > > > > What could be the problem? and what should I do to fix it? > > I can only guess that the C++ type "Vector" that you're wrapping below > is not the same as Osm::MotionCapture::Vector, the type in the error > message. Could you post a complete, reproducible test case? > > Did you base your code on the contents of the > libs/python/test/embedding.cpp file? > > For what it's worth, this: > > > mGlobals["SomeVector"] = python::object(aVector); > ^^^^^^^^^^^^^^^ ^ > > is redundant. > > mGlobals["SomeVector"] = aVector; > > is equivalent. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- _________________________________________________________ Simon Ouellet email: simon.ouellet at orthosoft.ca Programmeur tel: 514-861-4074 #269 Orthosoft Inc. fax: 514-866-2197 -------------- next part -------------- A non-text attachment was scrubbed... Name: Embedded.cc Type: text/x-c++ Size: 1868 bytes Desc: not available URL: From dave at boost-consulting.com Thu Sep 11 16:42:27 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 10:42:27 -0400 Subject: [C++-sig] Re: to_python_converter error question ... References: <3F5F0B5F.3000105@cirad.fr> Message-ID: Pierre Barbier de Reuille writes: > When I try to import a module I made, I have the error : > > RuntimeError: trying to register to_python_converter for a type which > already has a registered to_python_converter > > But when I re-import it, it just works ... is it normal ??? Then > another question : how to know which converter is duplicated ? > Is it possible to trace what python do when importing ? Please try the enclosed patch and let me know how it works out -------------- next part -------------- A non-text attachment was scrubbed... Name: registry.patch Type: text/x-patch Size: 1201 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Thu Sep 11 17:10:11 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Thu, 11 Sep 2003 23:10:11 +0800 Subject: [C++-sig] Re: Boost.Python bug found References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020649@exchange.adrembi.com> Message-ID: <01d201c37876$f4aabc90$64646464@godzilla> David Abrahams wrote: > "Roman Yakovenko" writes: > >> >> Hi. I think I find bug. >> Description. I wrote converter for std::wstring from\to >> PyUnicodeObject. >> ( Thanks to Ralf W. Grosse-Kunstleve and his article >> Converting CString to/from std::string ) >> >> After registration it works pretty well ( for me ). But if I >> want to expose >> std::vector< std::wstring > using vector_indexing_suite I get >> error message: >> >> TypeError: No Python class registered for C++ class class >> _STL::basic_string> _STL::char_traits,class >> _STL::allocator > >> >> Also the same bug happens with def_readwrite function. >> But I don't have small reproducable case. > > It's not a bug. The problem is that the use of proxies in an indexing > suite requires that the element type be wrapped as a class. You can > either expose class_... (etc) or you can pass NoProxy = > true to the indexing suite. Thanks Dave. I'll document that fact. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Thu Sep 11 17:43:59 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 11:43:59 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> Message-ID: Simon Ouellet writes: > I attached a complete reproducible test case. > The ouptut that I got is: > > The following error occur in python converter: > ================================================ > TypeError: No to_python (by-value) converter found for C++ type: 3Foo > ================================================ > 3 > The following error occur in python interpreter: > ================================================ > Traceback (most recent call last): > File "", line 4, in ? > NameError: name 'SomeFoo' is not defined > ================================================ It works perfectly fine for me (with the current CVS state). Are you using Boost.Build or getting "creative" with your build? myjam -sext=1 -sTOOLS=vc7.1 -sBUILD=debug-python --verbose-test ext ...found 2123 targets... ...updating 4 targets... vc-Link c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.exe Creating library c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.lib and object c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.exp execute-test c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.run 1 file(s) copied. ====== BEGIN OUTPUT ====== The following error occur in python converter: ================================================ ================================================ The following error occur in python interpreter: ================================================ 3 ================================================ ====== END OUTPUT ====== **passed** c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.test ...updated 4 targets... -- Dave Abrahams Boost Consulting www.boost-consulting.com From yakumoklesk at yahoo.es Thu Sep 11 17:58:35 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Thu, 11 Sep 2003 17:58:35 +0200 Subject: [C++-sig] Can anybody tell me the other difference between these 2 little programs? In-Reply-To: Message-ID: <3F60B7CB.32559.11D5D17@localhost> //First version int main( int argc, char** argv ) { Py_Initialize(); handle<> main_module(borrowed( PyImport_AddModule("__main__") )); handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) )); handle<> modModuleLoader( PyImport_ImportModule( "ModuleLoader" ) ); handle<> funLoadModules( PyObject_GetAttrString( modModuleLoader.get(), "LoadModules" ) ); handle<> dtTree( PyObject_GetAttrString( modModuleLoader.get(), "dtTree" ) ); handle<> funcPrintTree( PyObject_GetAttrString( dtTree.get(), "PrintTree" ) ); PyObject* argFuncArgs = Py_BuildValue( "(i)", 1 ); handle<> resNoneResult( PyEval_CallObject( funcPrintTree.get(), argFuncArgs ) ); Py_DECREF( argFuncArgs ); Py_Finalize(); return 0; } // Second versiona void test() { Py_Initialize(); handle<> main_module(borrowed( PyImport_AddModule("__main__") )); handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) )); handle<> modModuleLoader( PyImport_ImportModule( "ModuleLoader" ) ); handle<> funLoadModules( PyObject_GetAttrString( modModuleLoader.get(), "LoadModules" ) ); handle<> dtTree( PyObject_GetAttrString( modModuleLoader.get(), "dtTree" ) ); handle<> funcPrintTree( PyObject_GetAttrString( dtTree.get(), "PrintTree" ) ); PyObject* argFuncArgs = Py_BuildValue( "(i)", 1 ); handle<> resNoneResult( PyEval_CallObject( funcPrintTree.get(), argFuncArgs ) ); Py_DECREF( argFuncArgs ); } int main( int argc, char** argv ) { test(); Py_Finalize(); return 0; } The first difference I have found is that the first version exits with an error Fatal Python error: PyThreadState_Get: no current thread while the second version works OK. Thanks in advance. David Lucena. PD.- Using VC++ 6.0 in debug mode, with python 2.2.3 debug libraries and DLL and Boost.Python debug libraries and DLL From pierre.barbier at cirad.fr Thu Sep 11 18:29:16 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Thu, 11 Sep 2003 18:29:16 +0200 Subject: [C++-sig] Re: to_python_converter error question ... In-Reply-To: References: <3F5F0B5F.3000105@cirad.fr> Message-ID: <3F60A2DC.70500@cirad.fr> Great ! It's working ! The only pb is the presence of some strange characters with "ELF" in them ... Thanks, it helps so much ! David Abrahams wrote: >Pierre Barbier de Reuille writes: > > > >>When I try to import a module I made, I have the error : >> >>RuntimeError: trying to register to_python_converter for a type which >>already has a registered to_python_converter >> >>But when I re-import it, it just works ... is it normal ??? Then >>another question : how to know which converter is duplicated ? >>Is it possible to trace what python do when importing ? >> >> > >Please try the enclosed patch and let me know how it works out > > > -- 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 From Jason.Sibthorpe at aculab.com Thu Sep 11 18:36:27 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Thu, 11 Sep 2003 17:36:27 +0100 Subject: [C++-sig] pyste - integration Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70F7@saturn.aculab.com> Hi, Synopsis : I want to know how/if I can integrate my code with pyste to take advantage of its knowledge of function arguments so they don't have to be passed to wrap_out_arg below. Detail : I have written a noddy code generator that takes wrap_out_arg("test.h", "foo", "char *I, int *O") (for any number of input args where 'O' indicates that it is an output argument, and the type is simple - the type need not be simple but if it aint then the result might not compile) and generates tuple return_args_wrapper(char * in0) { int * out0; return make_tuple(foo(in0, out0), out0); } as a wrapper for const char *foo(char *str, int *num) {...} where num is an output argument. It is based on the example supplied by Nicodemus. http://mail.python.org/pipermail/c++-sig/2003-September/005393.html foo_wrapper = Wrapper('foo_wrapper', ''' tuple foo_wrapper(in_type in) { out_type2 out2; out_type1 out1 = foo(in, out2); return make_tuple(out1, out2); } ''') foo = Function(...) set_wrapper(foo, foo_wrapper) ===== I found that I had to have my code in the .pyste file (I could not import my module). When attempting the import I got the following error set_wrapper(Function(self.func, self.header), TypeError: __init__() takes at least 5 arguments (3 given) Which is bizarre. If I add None, None I get a bit further. Wrapper(wrapper_name, code)) NameError: global name 'Wrapper' is not defined even though I explicitly import exporterutils from exporterutils import * Changing the name from Wrapper to FunctionWrapper results in File "/home/jason/src/boost_cvs/boost/libs/python/pyste/src/Pyste/infos.py", line 212, in set_wrap per info._Attribute('wrapper', wrapper) AttributeError: 'Function' object has no attribute '_Attribute' At this point I give up. I suppose my question is, is this related to the execfile(interface, context) call in ExecuteInterface? I assume it is something to do with the context in which my module is imported, mmm... I don't know enough python. ===== I would like to integrate this code with pyste to take advantage of its knowledge of the declaration so users of wrap_out_arg need only specify the out args. Is this possible? Daniel Wallin mentions Lua http://mail.python.org/pipermail/c++-sig/2003-September/005394.html Is what I am attempting going to be soon unnecessary? Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: From dave at boost-consulting.com Thu Sep 11 18:43:38 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 12:43:38 -0400 Subject: [C++-sig] Re: Can anybody tell me the other difference between these 2 little programs? References: <3F60B7CB.32559.11D5D17@localhost> Message-ID: yakumoklesk at yahoo.es writes: > > The first difference I have found is that the first version exits with an error > > Fatal Python error: PyThreadState_Get: no current thread > > while the second version works OK. $ diff bu1.cpp bu2.cpp --- c:/tmp/bu1.cpp 2003-09-11 12:40:06.000000000 -0400 +++ c:/tmp/bu2.cpp 2003-09-11 12:39:55.000000000 -0400 @@ -1,4 +1,4 @@ -int main( int argc, char** argv ) +void test() { Py_Initialize(); @@ -16,6 +16,10 @@ handle<> resNoneResult( PyEval_CallObject( funcPrintTree.get(), argFuncArgs ) ); Py_DECREF( argFuncArgs ); +} +int main( int argc, char** argv ) +{ + test(); Py_Finalize(); ...but seriously, folks: http://www.boost-consulting.com/boost/libs/python/todo.html#pyfinalize-safety HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 18:45:47 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 12:45:47 -0400 Subject: [C++-sig] Re: Converting std::out_of_range to Python IndexError References: Message-ID: Raoul Gough writes: > In working on the indexing suite, I came across a std::out_of_range > exception (thrown by std::vector<>::at) and wanted it to arrive in > Python as an IndexError - this functions similarly to the > StopIteration exception for sequences with __getitem__ rather than > __iter__. Anyway, adding it to libs/python/src/errors.cpp is trivial > (diff follows this paragraph). I also added an explicit include for > , since this header is the one that defines the standard > exception hierarchy. OK to commit these changes? Whoops; I shoulda just said yes. Forgot you had commit permission and did it myself. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 18:44:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 12:44:57 -0400 Subject: [C++-sig] Re: to_python_converter error question ... References: <3F5F0B5F.3000105@cirad.fr> <3F60A2DC.70500@cirad.fr> Message-ID: Pierre Barbier de Reuille writes: > Great ! It's working ! What message do you see? > The only pb is the presence of some strange > characters with "ELF" in them ... Which characters? If you're using GCC < 3.1 you should pass the output through c++filt. -- Dave Abrahams Boost Consulting www.boost-consulting.com From datafeedNOSPAM at SoftHome.net Thu Sep 11 19:04:44 2003 From: datafeedNOSPAM at SoftHome.net (M. Evans) Date: Thu, 11 Sep 2003 10:04:44 -0700 Subject: [C++-sig] OpenOffice Python-UNO Bridge Message-ID: <1656489577.20030911100444@SoftHome.net> The new 1.1 release of OpenOffice includes a Python bridge to the UNO framework. This framework is the internal scaffolding for OpenOffice. The significance is that one may now develop OpenOffice components in Python. OpenOffice can import/export MS Office formats. The 1.1 release does an amazingly good job of it, too. With the new Microsoft Office strategy of subscription-fee services coupled to digital rights management, OpenOffice looks more enticing than ever. http://www.newsfactor.com/perl/story/20982.html UNO Intros http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.htm http://udk.openoffice.org/common/man/uno.html PyUNO http://udk.openoffice.org/python/python-bridge.html C++UNO http://udk.openoffice.org/cpp/man/tutorial/unointro.html From pierre.barbier at cirad.fr Thu Sep 11 19:28:38 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Thu, 11 Sep 2003 19:28:38 +0200 Subject: [C++-sig] Re: to_python_converter error question ... In-Reply-To: References: <3F5F0B5F.3000105@cirad.fr> <3F60A2DC.70500@cirad.fr> Message-ID: <3F60B0C6.1080202@cirad.fr> Here's the error messages I got : __main__:1: RuntimeWarning: to-Python converter for std::_Rb_tree_iterator already registered; second conversion method ignored __main__:1: RuntimeWarning: to-Python converter for __gnu_cxx::_Hashtable_const_iterator, std::_Identity, std::equal_to, std::allocator > already registered; second conversion method ignored ... the "error" was that set and multiset share the same iterator and I exported both ! Ffor the strange chars, it's not doing it anymore ... so I can say anything about it ! David Abrahams wrote: >Pierre Barbier de Reuille writes: > > > >>Great ! It's working ! >> >> > >What message do you see? > > > >>The only pb is the presence of some strange >>characters with "ELF" in them ... >> >> > >Which characters? If you're using GCC < 3.1 you should pass the >output through c++filt. > > > -- 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 From Jason.Sibthorpe at aculab.com Thu Sep 11 19:32:24 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Thu, 11 Sep 2003 18:32:24 +0100 Subject: [C++-sig] pointer to pointer Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70F8@saturn.aculab.com> Hi all, I posted a similar question earlier this week without success. Does anyone know how to wrap a function taking a pointer to pointer to a type? (or where to look in the documentation) Thanks Jason Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: From rwgk at yahoo.com Thu Sep 11 20:07:40 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 11 Sep 2003 11:07:40 -0700 (PDT) Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <7C9291DE-E439-11D7-BE2C-000A95686CD8@redivi.com> Message-ID: <20030911180740.58022.qmail@web20202.mail.yahoo.com> --- Bob Ippolito wrote: > scitbx/array_family/tst_af_4.exe > Total OK: 1300 > [crack:~/tmp/debug] bob% gcc -v > Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs > Thread model: posix > gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) > > This is OS X 10.2.6, with the XCode preview dev tools, the gcc 3.3 > compiler selected, and MACOSX_DEPLOYMENT_TARGET=10.2 environment > variable Ever since May the scitbx and all the other modules in the cctbx (of which scitbx is one) are fully functional under Mac OS X; ever since gcc 3.3.1 was released even with full optimization: http://cci.lbl.gov/cctbx_build/ Follow the "Mac OS X notes" link for more information. I am using gcc 3.3.1 from gcc.gnu.org. Very important: you have to increase the stacksize limit to avoid internal compiler errors! All tests in boost/libs/python/test compile, but some of them don't link and I am not sure if all of the rest run (they might). I also had link problems with some extensions in the cctbx but got around them with some effort by introducing dummy code, i.e. struct dummy {}; class_(...); in extensions that had no other class_<>. I am not using bjam, but Rene made an effort to adjust the flags for gcc from gcc.gnu.org. Apple's compiler needs different flags, so we will need two different toolsets to support both. The Mac OS X cctbx build.log from the build with the tag 2003_09_09_1700 shows all compile and link commands that we use with gcc 3.3.1. The libtbx.mac_os_x_ld_bpl_dll command is a helper script for linking the Boost.Python library. The next three lines in build.log show the commands executed by the helper script. As hinted before, gcc 3.3 from gcc.gnu.org has a severely broken optimizer (even under Linux, but not quite as bad as under OS X; 3.3.1 is perfect on both platforms). I'd expect that Apple's gcc 3.3 has similar problems, but you never know. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From simon.ouellet at orthosoft.ca Thu Sep 11 20:33:04 2003 From: simon.ouellet at orthosoft.ca (Simon Ouellet) Date: Thu, 11 Sep 2003 18:33:04 -0000 Subject: [C++-sig] Re: to_python (by-value) converter In-Reply-To: References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> Message-ID: On Thu, 2003-09-11 at 11:43, David Abrahams wrote: > Simon Ouellet writes: > > > I attached a complete reproducible test case. > > The ouptut that I got is: > > > > The following error occur in python converter: > > ================================================ > > TypeError: No to_python (by-value) converter found for C++ type: 3Foo > > ================================================ > > 3 > > The following error occur in python interpreter: > > ================================================ > > Traceback (most recent call last): > > File "", line 4, in ? > > NameError: name 'SomeFoo' is not defined > > ================================================ > > > It works perfectly fine for me (with the current CVS state). Are you > using Boost.Build or getting "creative" with your build? > I'm using g++3.2 on linux and CC MIPSpro Version 7.3.1.3m on IRIX. I'm using boost_30.2 and I got the error on both platforms. I compile the example with those command: g++ -D_REENTRANT -I/usr/local/include -I/usr/local/include/python2.2 -DBOOST_PYTHON_DYNAMIC_LIB -Wall -ansi -pedantic -ggdb -D DEBUG -c Embedded.cc -o Embedded.o g++ -L/usr/local/ORTHOsoft/lib -o Embedded Embedded.o -lboost_python -L/usr/local/lib/python2.2/config -lpython2.2 -lutil -ldl -lpthread Thanks > myjam -sext=1 -sTOOLS=vc7.1 -sBUILD=debug-python --verbose-test ext > ...found 2123 targets... > ...updating 4 targets... > vc-Link c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.exe > Creating library c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.lib and object c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.exp > execute-test c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.run > 1 file(s) copied. > ====== BEGIN OUTPUT ====== > The following error occur in python converter: > ================================================ > ================================================ > The following error occur in python interpreter: > ================================================ > 3 > ================================================ > ====== END OUTPUT ====== > **passed** c:\build\bin\boost\libs\python\user\ext.test\vc7.1\debug-python\ext.test > ...updated 4 targets... > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- _________________________________________________________ Simon Ouellet email: simon.ouellet at orthosoft.ca Programmeur tel: 514-861-4074 #269 Orthosoft Inc. fax: 514-866-2197 From stefan.seefeld at orthosoft.ca Thu Sep 11 20:39:43 2003 From: stefan.seefeld at orthosoft.ca (Stefan Seefeld) Date: Thu, 11 Sep 2003 14:39:43 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> Message-ID: <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> Simon Ouellet wrote: > On Thu, 2003-09-11 at 11:43, David Abrahams wrote: >>It works perfectly fine for me (with the current CVS state). Are you >>using Boost.Build or getting "creative" with your build? >> > > > I'm using g++3.2 on linux and CC MIPSpro Version 7.3.1.3m on IRIX. > I'm using boost_30.2 and I got the error on both platforms. I tried to download the latest cvs snapshot. sf.net refuses the connection, and checking out from David's backup server will stall around the file 'boost-1.30.2/tools/regression/xsl_reports/xsl/summary_page.xsl', so testing with a 'fresh' checkout isn't possible right now, it seems. Thanks, Stefan From bob at redivi.com Thu Sep 11 20:39:52 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu, 11 Sep 2003 14:39:52 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <20030911180740.58022.qmail@web20202.mail.yahoo.com> Message-ID: <54881B84-E487-11D7-BE2C-000A95686CD8@redivi.com> On Thursday, Sep 11, 2003, at 14:07 America/New_York, Ralf W. Grosse-Kunstleve wrote: > --- Bob Ippolito wrote: >> scitbx/array_family/tst_af_4.exe >> Total OK: 1300 >> [crack:~/tmp/debug] bob% gcc -v >> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs >> Thread model: posix >> gcc version 3.3 20030304 (Apple Computer, Inc. build 1435) >> >> This is OS X 10.2.6, with the XCode preview dev tools, the gcc 3.3 >> compiler selected, and MACOSX_DEPLOYMENT_TARGET=10.2 environment >> variable > > Ever since May the scitbx and all the other modules in the cctbx (of > which > scitbx is one) are fully functional under Mac OS X; ever since gcc > 3.3.1 was > released even with full optimization: > > http://cci.lbl.gov/cctbx_build/ > > Follow the "Mac OS X notes" link for more information. I am using gcc > 3.3.1 > from gcc.gnu.org. Very important: you have to increase the stacksize > limit to > avoid internal compiler errors! > > All tests in boost/libs/python/test compile, but some of them don't > link and I > am not sure if all of the rest run (they might). I also had link > problems with > some extensions in the cctbx but got around them with some effort by > introducing dummy code, i.e. struct dummy {}; class_(...); in > extensions > that had no other class_<>. > > I am not using bjam, but Rene made an effort to adjust the flags for > gcc from > gcc.gnu.org. Apple's compiler needs different flags, so we will need > two > different toolsets to support both. > > The Mac OS X cctbx build.log from the build with the tag > 2003_09_09_1700 shows > all compile and link commands that we use with gcc 3.3.1. The > libtbx.mac_os_x_ld_bpl_dll command is a helper script for linking the > Boost.Python library. The next three lines in build.log show the > commands > executed by the helper script. > > As hinted before, gcc 3.3 from gcc.gnu.org has a severely broken > optimizer > (even under Linux, but not quite as bad as under OS X; 3.3.1 is > perfect on both > platforms). I'd expect that Apple's gcc 3.3 has similar problems, but > you never > know. I had the stacksize set to 16384 when I tried earlier. I just tried again at 65536, and the same error comes up, so the gcc 3.3 in the jaguar preview of XCode is probably busted. I'll have to try it with something else when I get the time. Don't waste yours trying to figure it out, I don't expect to need Boost.Python for anything in the near future, I was just curious. -bob From yakumoklesk at yahoo.es Thu Sep 11 20:56:49 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Thu, 11 Sep 2003 20:56:49 +0200 Subject: [C++-sig] Re: Can anybody tell me the other difference between these 2 little programs? In-Reply-To: Message-ID: <3F60E191.8114.1C08795@localhost> Hehehe, good joke with the "diff" command. Well, if this error is something that is in the TODO list, I'll take the way that does not crash for the moment. Thank you David. David Lucena. On 11 Sep 2003 at 12:43, David Abrahams wrote: > yakumoklesk at yahoo.es writes: > > > > > The first difference I have found is that the first version exits with an error > > > > Fatal Python error: PyThreadState_Get: no current thread > > > > while the second version works OK. > > $ diff bu1.cpp bu2.cpp > --- c:/tmp/bu1.cpp 2003-09-11 12:40:06.000000000 -0400 > +++ c:/tmp/bu2.cpp 2003-09-11 12:39:55.000000000 -0400 > @@ -1,4 +1,4 @@ > -int main( int argc, char** argv ) > +void test() > { > Py_Initialize(); > > @@ -16,6 +16,10 @@ > handle<> resNoneResult( PyEval_CallObject( funcPrintTree.get(), argFuncArgs > ) ); > Py_DECREF( argFuncArgs ); > +} > +int main( int argc, char** argv ) > +{ > + test(); > > Py_Finalize(); > > > ...but seriously, folks: > http://www.boost-consulting.com/boost/libs/python/todo.html#pyfinalize-safety > > HTH, > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From conanb at STCG.net Thu Sep 11 21:03:09 2003 From: conanb at STCG.net (Conan Brink) Date: Thu, 11 Sep 2003 12:03:09 -0700 Subject: [C++-sig] Re: Can anybody tell me the other difference betweenthese 2 little programs? Message-ID: The short description is that the second one works because those handles all pass out of scope before you call Py_Finalize(), so that Boost.Python isn't trying to keep anything alive past the call to Py_Finalize(). The solution (until such time as it gets off the TODO list): Don't call Py_Finalize() if you have any Boost.Python objects still alive. -Conan -----Original Message----- From: yakumoklesk at yahoo.es [mailto:yakumoklesk at yahoo.es] Sent: Thursday, September 11, 2003 11:57 AM To: Development of Python/C++ integration Subject: Re: [C++-sig] Re: Can anybody tell me the other difference betweenthese 2 little programs? Hehehe, good joke with the "diff" command. Well, if this error is something that is in the TODO list, I'll take the way that does not crash for the moment. Thank you David. David Lucena. On 11 Sep 2003 at 12:43, David Abrahams wrote: > yakumoklesk at yahoo.es writes: > > > > > The first difference I have found is that the first version exits with an error > > > > Fatal Python error: PyThreadState_Get: no current thread > > > > while the second version works OK. > [diff humor deleted] > > ...but seriously, folks: > http://www.boost-consulting.com/boost/libs/python/todo.html#pyfinalize-s afety This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive messages for the addressee), you may not use, copy, or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message. Nothing in this message should be interpreted as a digital or electronic signature that can be used to authenticate a contract or any other legal document. From dave at boost-consulting.com Thu Sep 11 21:19:59 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 15:19:59 -0400 Subject: [C++-sig] Re: Boost.Python bug found References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020649@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Also if David Abrahams thinks that my converter is good enough to be > in the library - I may polish it and write a lot of test I think I've checked in a better solution; the converter is builtin for everyone's use. Please see the CVS. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 21:22:45 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 15:22:45 -0400 Subject: [C++-sig] Re: Can anybody tell me the other difference betweenthese 2 little programs? References: Message-ID: "Conan Brink" writes: > The short description is that the second one works because those handles > all pass out of scope before you call Py_Finalize(), so that > Boost.Python isn't trying to keep anything alive past the call to > Py_Finalize(). > > The solution (until such time as it gets off the TODO list): Don't call > Py_Finalize() if you have any Boost.Python objects still alive. Nor even if you don't. The library keeps objects of its own alive. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 21:23:40 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 15:23:40 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> Message-ID: Stefan Seefeld writes: > Simon Ouellet wrote: >> On Thu, 2003-09-11 at 11:43, David Abrahams wrote: > >>>It works perfectly fine for me (with the current CVS state). Are you >>>using Boost.Build or getting "creative" with your build? >>> >> I'm using g++3.2 on linux and CC MIPSpro Version 7.3.1.3m on IRIX. >> I'm using boost_30.2 and I got the error on both platforms. > > I tried to download the latest cvs snapshot. sf.net refuses the > connection, and checking out from David's backup server will stall > around the file > boost-1.30.2/tools/regression/xsl_reports/xsl/summary_page.xsl', > > so testing with a 'fresh' checkout isn't possible right now, it seems. You can just grab the hourly snapshot at http://www.boost-consulting.com/boost.tar.bz2 It's not CVS, but it is relatively current. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 11 21:24:55 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 11 Sep 2003 15:24:55 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> Message-ID: Stefan Seefeld writes: > Simon Ouellet wrote: >> On Thu, 2003-09-11 at 11:43, David Abrahams wrote: > >>>It works perfectly fine for me (with the current CVS state). Are you >>>using Boost.Build or getting "creative" with your build? >>> >> I'm using g++3.2 on linux and CC MIPSpro Version 7.3.1.3m on IRIX. >> I'm using boost_30.2 and I got the error on both platforms. Let me be perfectly clear: How are you doing the build? How are you running the test? Please show command lines and Jamfiles. -- Dave Abrahams Boost Consulting www.boost-consulting.com From simon.ouellet at orthosoft.ca Thu Sep 11 22:53:08 2003 From: simon.ouellet at orthosoft.ca (Simon Ouellet) Date: Thu, 11 Sep 2003 20:53:08 -0000 Subject: [C++-sig] Re: to_python (by-value) converter In-Reply-To: References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> Message-ID: <651b622152e7ace435f70fc619f9d3023f60dedf@Orthosoft.ca> to build boost on my linux station I compiled it with the following command line %bjam An error occured when I built the test embedding.cpp in libs/python/test/ %bjam -d 2 embedding ...found 1959 targets... ...updating 4 targets... gcc-Link-action ../../../libs/python/test/bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding LD_LIBRARY_PATH=/usr/local/lib/python2.2/config:../../../libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true export LD_LIBRARY_PATH g++ -g -o "../../../libs/python/test/bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding" -L"/usr/local/lib/python2.2/config" -L"../../../libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true" "../../../libs/python/test/bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding.o" -lpython2.2 -ldl -lutil -lboost_python -Wl,-rpath-link,. /usr/local/lib/python2.2/config/libpython2.2.a(posixmodule.o): In function `posix_tmpnam': /usr/local/Python-2.2.1/./Modules/posixmodule.c:4501: the use of `tmpnam_r' is dangerous, better use `mkstemp' /usr/local/lib/python2.2/config/libpython2.2.a(posixmodule.o): In function `posix_tempnam': /usr/local/Python-2.2.1/./Modules/posixmodule.c:4451: the use of `tempnam' is dangerous, better use `mkstemp' /usr/local/lib/python2.2/config/libpython2.2.a(thread.o): In function `PyThread_start_new_thread': /usr/local/Python-2.2.1/Python/thread_pthread.h:180: undefined reference to `pthread_sigmask' /usr/local/Python-2.2.1/Python/thread_pthread.h:182: undefined reference to `pthread_create' /usr/local/Python-2.2.1/Python/thread_pthread.h:207: undefined reference to `pthread_sigmask' /usr/local/Python-2.2.1/Python/thread_pthread.h:216: undefined reference to `pthread_detach' collect2: ld returned 1 exit status To built it I added -lpthread at the command line g++ -g -o "../../../libs/python/test/bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding" -L"/usr/local/lib/python2.2/config" -L"../../../libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true" "../../../libs/python/test/bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding.o" -lpython2.2 -ldl -lutil -lboost_python -Wl,-rpath-link,. -lpthread After that I make symbolic link of boost shared libraries in /usr/local/lib/ My LD_LIBRARY_PATH contain /usr/local/lib of course. And I start the test %bin/embedding.test/gcc/debug/runtime-link-dynamic/embedding I have no problem running the current version of embedding.cpp. The output is Hello from C++! Hello from Python! but the test doesn't cover the feature I'm currently looking for. I modified the test to cover the conversion of a C++ object into a python::object and it doesn't work. I attached the diff that I made. I built the the modified embedding.cpp the same way When I ran it I got: TypeError: No to_python (by-value) converter found for C++ type: 10CppDerived Thanks. On Thu, 2003-09-11 at 15:24, David Abrahams wrote: > Stefan Seefeld writes: > > > Simon Ouellet wrote: > >> On Thu, 2003-09-11 at 11:43, David Abrahams wrote: > > > >>>It works perfectly fine for me (with the current CVS state). Are you > >>>using Boost.Build or getting "creative" with your build? > >>> > >> I'm using g++3.2 on linux and CC MIPSpro Version 7.3.1.3m on IRIX. > >> I'm using boost_30.2 and I got the error on both platforms. > > Let me be perfectly clear: > > How are you doing the build? > > How are you running the test? > > Please show command lines and Jamfiles. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- _________________________________________________________ Simon Ouellet email: simon.ouellet at orthosoft.ca Programmeur tel: 514-861-4074 #269 Orthosoft Inc. fax: 514-866-2197 -------------- next part -------------- 75,77c75,79 < python::handle<> main_namespace( < python::borrowed(PyModule_GetDict(main_module.get())) ); < --- > python::object main_namespace = python::object(python::borrowed( > PyModule_GetDict(main_module.get()))); > CppDerived b; > main_namespace["aBase"] = b; > 86c88 < Py_file_input, main_namespace.get(), main_namespace.get()) --- > Py_file_input, main_namespace.ptr(), main_namespace.ptr()) 94c96 < main_namespace.get(), main_namespace.get()) ); --- > main_namespace.ptr(), main_namespace.ptr()) ); From nicodemus at globalite.com.br Fri Sep 12 00:24:38 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Thu, 11 Sep 2003 19:24:38 -0300 Subject: [C++-sig] pyste - integration In-Reply-To: <8C9A566C643ED6119E8900A0C9DE297A020B70F7@saturn.aculab.com> References: <8C9A566C643ED6119E8900A0C9DE297A020B70F7@saturn.aculab.com> Message-ID: <3F60F626.4030801@globalite.com.br> Hi Jason, Jason.Sibthorpe at aculab.com wrote: >Hi, > >Synopsis : > >I want to know how/if I can integrate my code >with pyste to take advantage of its knowledge of function >arguments so they don't have to be passed to wrap_out_arg >below. > >Detail : > >I have written a noddy code generator that takes > >wrap_out_arg("test.h", "foo", "char *I, int *O") > >(for any number of input args where 'O' indicates >that it is an output argument, and the type is simple >- the type need not be simple but if it aint then the result >might not compile) > >and generates > >tuple return_args_wrapper(char * in0) > { > int * out0; > return make_tuple(foo(in0, out0), > out0); > } > >as a wrapper for >const char *foo(char *str, int *num) >{...} > >where num is an output argument. > >It is based on the example supplied by Nicodemus. >http://mail.python.org/pipermail/c++-sig/2003-September/005393.html > >foo_wrapper = Wrapper('foo_wrapper', >''' >tuple foo_wrapper(in_type in) >{ > out_type2 out2; > out_type1 out1 = foo(in, out2); > return make_tuple(out1, out2); >} >''') >foo = Function(...) >set_wrapper(foo, foo_wrapper) > > > Ok, seems nice. >===== > >I found that I had to have my code in the .pyste file (I could not >import my module). > Why not? You can configure PYTHONPATH to point to the location of your files, and import them in the .pyste files. > When attempting the import I got the following >error > > set_wrapper(Function(self.func, self.header), >TypeError: __init__() takes at least 5 arguments (3 given) > >Which is bizarre. > Indeed, but what is self in that code? And there's a "," at the end of it, were there more parameters? >If I add None, None I get a bit further. > > Wrapper(wrapper_name, code)) >NameError: global name 'Wrapper' is not defined > Sorry, I don't see any None in this code... could you post a reproductive test case? This would help a lot to understand your problem. 8) >even though I explicitly import exporterutils >from exporterutils import * > >Changing the name from Wrapper to FunctionWrapper results in > File >"/home/jason/src/boost_cvs/boost/libs/python/pyste/src/Pyste/infos.py", line >212, in set_wrap >per > info._Attribute('wrapper', wrapper) >AttributeError: 'Function' object has no attribute '_Attribute' > >At this point I give up. I suppose my question is, is this related to >the execfile(interface, context) call in ExecuteInterface? I assume it >is something to do with the context in which my module is imported, mmm... >I don't know enough python. > Where do you run this code? In the .pyste file or in your own files? >I would like to integrate this code with pyste to take advantage >of its knowledge of the declaration so users of wrap_out_arg >need only specify the out args. Is this possible? > Sure! Lots of people have contributed with code and ideas: you're welcome too. This feature doesn't seem hard to integrate at all. If you want, mail me off-list so that I guide you in the code. Thanks for the feedback! Nicodemus. From jbrandmeyer at earthlink.net Fri Sep 12 05:31:39 2003 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Thu, 11 Sep 2003 23:31:39 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <20030911180740.58022.qmail@web20202.mail.yahoo.com> References: <20030911180740.58022.qmail@web20202.mail.yahoo.com> Message-ID: <1063337499.4950.19.camel@illuvatar> On Thu, 2003-09-11 at 14:07, Ralf W. Grosse-Kunstleve wrote: > Ever since May the scitbx and all the other modules in the cctbx (of which > scitbx is one) are fully functional under Mac OS X; ever since gcc 3.3.1 was > released even with full optimization: > > http://cci.lbl.gov/cctbx_build/ > Follow the "Mac OS X notes" link for more information. I am using gcc > 3.3.1 I just repeated your results on our machine and have a couple of comments / questions. The source package for Python 2.3 uses build rules that are incompatible with FSF GCC. So, I built Python with the Apple-distributed GCC 3.1 and Boost.Python with the FSF-distributed GCC 3.3.1. > from gcc.gnu.org. Very important: you have to increase the stacksize > limit to > avoid internal compiler errors! I'm using Boost.Python 1.30.0 (with Debian patches) with G++ 3.3.1 on Debian without any ICE's. Can you elaborate? Finally, have you or anyone else had any experience building Boost.Python with a non-framework installation of Python (such as that packaged by fink)? Thanks, Jonathan Brandmeyer From Jason.Sibthorpe at aculab.com Fri Sep 12 13:48:49 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Fri, 12 Sep 2003 12:48:49 +0100 Subject: [C++-sig] pyste - integration Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70FB@saturn.aculab.com> Re : http://mail.python.org/pipermail/c++-sig/2003-September/005462.html Hi, I have constructed a simple example that illustrates my earlier email. Try running pyste against test.pyste as it is. test.cpp is the result. All is well. Of course in order to share (without duplicating the code) I would like to import wrap() as a module. Comment out the definition of wrap in test.pyste and uncomment the import directive. Try running pyste against test.pyste now. All is not well as you will see. Note that I have duplicated the code numerous times with slight modification in wrap.py. Each time resolving a problem. The problems are those I describe (poorly) in the aforementioned post. As you will see it is not a PYTHONPATH issue. I think it is somehow related to the context that is created in pyste.py and used by 'execfile(interface, context)' in ExecuteInterface() (in pyste.py) Any ideas? The .zip just contains the files attached for convenience. pyste is invoked with just test.pyste as an argument Thanks Jason Sibthorpe Software Engineer Aculab Tel: +44 (0) 1908 273 869 Fax: +44 (0) 1908 273 801 Email: jason.sibthorpe at aculab.com Website: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_case.zip Type: application/octet-stream Size: 2446 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrap.py Type: application/octet-stream Size: 1958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pyste Type: application/octet-stream Size: 349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.h Type: application/octet-stream Size: 17 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cpp Type: application/octet-stream Size: 522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Jamfile Type: application/octet-stream Size: 990 bytes Desc: not available URL: From dave at boost-consulting.com Fri Sep 12 13:55:26 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 07:55:26 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> <651b622152e7ace435f70fc619f9d3023f60dedf@Orthosoft.ca> Message-ID: Simon Ouellet writes: > but the test doesn't cover the feature I'm currently looking for. > > I modified the test to cover the conversion of a C++ object into a > python::object and it doesn't work. > > I attached the diff that I made. > > > I built the the modified embedding.cpp the same way > > When I ran it I got: > > TypeError: No to_python (by-value) converter found for C++ type: > 10CppDerived Well of course that fails; CppDerived isn't wrapped and nothing you've done has informed Boost.Python about how to convert it to Python. Try executing class_("CppDerived"); before then. -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Fri Sep 12 14:54:46 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 12 Sep 2003 05:54:46 -0700 (PDT) Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <1063337499.4950.19.camel@illuvatar> Message-ID: <20030912125446.85251.qmail@web20208.mail.yahoo.com> --- Jonathan Brandmeyer wrote: > I just repeated your results on our machine and have a couple of > comments / questions. The source package for Python 2.3 uses build > rules that are incompatible with FSF GCC. So, I built Python with the > Apple-distributed GCC 3.1 and Boost.Python with the FSF-distributed GCC > 3.3.1. That's exactly what I did. > I'm using Boost.Python 1.30.0 (with Debian patches) with G++ 3.3.1 on > Debian without any ICE's. Can you elaborate? Debian sounds like Linux. The stacksize problem is a Mac OS X issue. Also note that the ICE's occur only while compiling files with a fairly large number of Boost.Python bindings. > Finally, have you or anyone else had any experience building > Boost.Python with a non-framework installation of Python (such as that > packaged by fink)? It is my understanding that Boost.Python requires a framework build of Python. Rene had a posting about this almost a year ago: http://mail.python.org/pipermail/c++-sig/2002-October/002397.html Pursuing his ideas eventually lead to success. See also the other postings with the same subject: http://mail.python.org/pipermail/c++-sig/2002-October/date.html Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From dave at boost-consulting.com Fri Sep 12 15:25:52 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 09:25:52 -0400 Subject: [C++-sig] Re: wrapping function taking pointer to pointer References: <20030908213008.32152.qmail@web10503.mail.yahoo.com> Message-ID: jason sibthorpe writes: >>> Hi all, >>> >>> Could someone point me towards the documentation > (if any exists) >>> for wrapping a function taking a pointer to a > pointer to some >>> type. >>> >>> void ptrptr(char **in) >>> {} >>> >>> BOOST_PYTHON_MODULE(test) >>> { >>> def("ptrptr", &ptrptr); >>> } >> >>There's no one way to do this. >> >>> When calling the function from python I get the > following >>> >>> >>> did not match C++ signature: >>> inptrptr(char**) >> >>What kind of Python object do you *expect* to be able > to pass to >>inptrptr? >> >>-- >>Dave Abrahams >>Boost Consulting >>www.boost-consulting.com > > > Hi Dave, > > Thanks for responding. > > I am interested in understanding the process rather > than dealing with a single type Errh. The process is complicated. You can read a little about it at http://www.boost-consulting.com/boost/libs/python/doc/internals.html > but, for the purposes of this discussion, the c++ type is char** and > I would think that a python list do the trick. A list of what? is ptrptr expected to be able to change the char*s that the char** points to? Is it expected to be able to change the chars that those char*s point to? What result would you like to see in Python if it does? I am guessing that you want to convert a list of strings to a zero-terminated array of char*s? The easy way to do that is to write a thin wrapper over ptrptr as in: void ptrptr_wrap(list strings) { std::size_t const length = extract( strings.attr("__len__")()); boost::shared_array in(new char*[length + 1]); for (std::size_t i = 0; i < length; ++i) { in[i] = const_cast( extract(strings[i])()); } in[length] = 0; ptrptr(in.get()); }; > A doco* would be greatly appreciated. There are no docs for your particular problem. At the moment, there isn't even a way to write a converter which would use the above conversion any time a function accepting a char** was called. -- Dave Abrahams Boost Consulting www.boost-consulting.com From simon.ouellet at orthosoft.ca Fri Sep 12 16:44:40 2003 From: simon.ouellet at orthosoft.ca (Simon Ouellet) Date: 12 Sep 2003 10:44:40 -0400 Subject: [C++-sig] Re: to_python (by-value) converter In-Reply-To: References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> <651b622152e7ace435f70fc619f9d3023f60dedf@Orthosoft.ca> Message-ID: <4fde078f856c508c30440dc36f1b23cb3f61da22@Orthosoft.ca> > > Try executing class_("CppDerived"); before then. > Ok I make it work, but that lead me to another question. When I put class_("CppDerived"); in the module definition. Like this BOOST_PYTHON_MODULE(embedded_hello) { python::class_("Base") ; python::class_("CppDerived") .def("hello", &CppDerived::hello); } It didn't work but if I put it before I use the conversion like this: python::class_("CppDerived") .def("hello", &CppDerived::hello); CppDerived b; It work. It is a scope issue? What I'm missing? Thanks -- _________________________________________________________ Simon Ouellet email: simon.ouellet at orthosoft.ca Programmeur tel: 514-861-4074 #269 Orthosoft Inc. fax: 514-866-2197 From dave at boost-consulting.com Fri Sep 12 16:58:16 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 10:58:16 -0400 Subject: [C++-sig] Re: Some patches to make the "Automatic PyUnicode to 'const char*'" possible, and make __stdcall function bindable References: <005701c36567$b3511c20$0200a8c0@barrack> Message-ID: "Lijun Qin" writes: > Hi, > > I have some patches to make the "Automatic PyUnicode to 'const char*'" > possible (please see > http://mail.python.org/pipermail/c++-sig/2003-August/004997.html for > details) Hi Lijun, After having done some research into PyUnicode, I see that it contains an internal buffer for the default decoding of its string. If you can set the default decoding to utf8 (that's what you're using, right?) you may find there's an easier solution to your problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com From Jason.Sibthorpe at aculab.com Fri Sep 12 16:58:55 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Fri, 12 Sep 2003 15:58:55 +0100 Subject: [C++-sig] Re: wrapping function taking pointer to pointer Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B70FD@saturn.aculab.com> Thanks! >A list of what? is ptrptr expected to be able to change the char*s >that the char** points to? Is it expected to be able to change the >chars that those char*s point to? What result would you like to see >in Python if it does? mmm... sorry for the vague problem description >There are no docs for your particular problem. At the moment, there >isn't even a way to write a converter which would use the above >conversion any time a function accepting a char** was called. Is it due to insurmountable technical issues, or lack of time, or priorities, or a combination thereof? It seems to me that this sort of thing (automatic conversion) is quite desirable. Thanks again for your help. -Jason -----Original Message----- From: David Abrahams [mailto:dave at boost-consulting.com] Sent: 12 September 2003 14:26 To: c++-sig at python.org Subject: [C++-sig] Re: wrapping function taking pointer to pointer jason sibthorpe writes: >>> Hi all, >>> >>> Could someone point me towards the documentation > (if any exists) >>> for wrapping a function taking a pointer to a > pointer to some >>> type. >>> >>> void ptrptr(char **in) >>> {} >>> >>> BOOST_PYTHON_MODULE(test) >>> { >>> def("ptrptr", &ptrptr); >>> } >> >>There's no one way to do this. >> >>> When calling the function from python I get the > following >>> >>> >>> did not match C++ signature: >>> inptrptr(char**) >> >>What kind of Python object do you *expect* to be able > to pass to >>inptrptr? >> >>-- >>Dave Abrahams >>Boost Consulting >>www.boost-consulting.com > > > Hi Dave, > > Thanks for responding. > > I am interested in understanding the process rather > than dealing with a single type Errh. The process is complicated. You can read a little about it at http://www.boost-consulting.com/boost/libs/python/doc/internals.html > but, for the purposes of this discussion, the c++ type is char** and > I would think that a python list do the trick. A list of what? is ptrptr expected to be able to change the char*s that the char** points to? Is it expected to be able to change the chars that those char*s point to? What result would you like to see in Python if it does? I am guessing that you want to convert a list of strings to a zero-terminated array of char*s? The easy way to do that is to write a thin wrapper over ptrptr as in: void ptrptr_wrap(list strings) { std::size_t const length = extract( strings.attr("__len__")()); boost::shared_array in(new char*[length + 1]); for (std::size_t i = 0; i < length; ++i) { in[i] = const_cast( extract(strings[i])()); } in[length] = 0; ptrptr(in.get()); }; > A doco* would be greatly appreciated. There are no docs for your particular problem. At the moment, there isn't even a way to write a converter which would use the above conversion any time a function accepting a char** was called. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Fri Sep 12 17:57:07 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 11:57:07 -0400 Subject: [C++-sig] Re: to_python (by-value) converter References: <7869413ef93da3cb03a1c5cc6f7074c23f6087ef@Orthosoft.ca> <337239f626b162c485994d294573d0623f60bf6a@Orthosoft.ca> <651b622152e7ace435f70fc619f9d3023f60dedf@Orthosoft.ca> <4fde078f856c508c30440dc36f1b23cb3f61da22@Orthosoft.ca> Message-ID: Simon Ouellet writes: >> >> Try executing class_("CppDerived"); before then. >> > > Ok I make it work, but that lead me to another question. > > > > When I put > > class_("CppDerived"); > > in the module definition. Like this > > BOOST_PYTHON_MODULE(embedded_hello) > { > python::class_("Base") > ; > python::class_("CppDerived") > .def("hello", &CppDerived::hello); > } > > > It didn't work but if I put it before I use the conversion like this: > python::class_("CppDerived") > .def("hello", &CppDerived::hello); > CppDerived b; > > It work. > > It is a scope issue? What I'm missing? Conversions are registered dynamically. Constructing class_ also registers the conversion for C++ CppDerived objects -> Python. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Sep 12 18:01:34 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 12:01:34 -0400 Subject: [C++-sig] Re: wrapping function taking pointer to pointer References: <8C9A566C643ED6119E8900A0C9DE297A020B70FD@saturn.aculab.com> Message-ID: Jason.Sibthorpe at aculab.com writes: > Thanks! > >>A list of what? is ptrptr expected to be able to change the char*s >>that the char** points to? Is it expected to be able to change the >>chars that those char*s point to? What result would you like to see >>in Python if it does? > mmm... sorry for the vague problem description > > >>There are no docs for your particular problem. At the moment, there >>isn't even a way to write a converter which would use the above >>conversion any time a function accepting a char** was called. > > Is it due to insurmountable technical issues, or lack of time, or > priorities, or a combination thereof? Surmountable technical issues, a lack of time, and priorities (working on stuff I'm being paid for). Those technical problems will probably be surmounted sometime in the next year. > It seems to me that this sort of thing (automatic conversion) is > quite desirable. Automatic conversion is certainly possible. The problem is that your converter requires intermediate storage for more than a single char*, which isn't currently supported for a char** converter. Well, you *can* get the effect you want by specializing arg_from_python. That will make the customized conversion local to the modules which can see the specialization, though. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Fri Sep 12 20:09:03 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 12 Sep 2003 19:09:03 +0100 Subject: [C++-sig] Pyste generating empty file Message-ID: <3F6219CF.22432.A57BE72@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, back to Boost.Python development again. First off, the improved code for invoking GCCXML I see hasn't been added: ... # call gccxml cmd = 'gccxml %s %s %s -fxml=%s' % (includes, defines, filename, xmlfile) sys.stdout.write(cmd+"\n") childinh,childh=os.popen4(cmd) wasout?lse while 1: line=childh.readline() if not line: break sys.stderr.write(" "+line) wasout=True if wasout or not os.path.isfile(xmlfile): raise CppParserError, 'Error executing gccxml' #status = os.system(cmd) #if status!=0: # raise CppParserError, 'Error executing gccxml' # parse the resulting xml ... If you use this code, you don't get the annoying cmd box popping up on Windows. Furthermore, you don't lose the error messages output by GCCXML. Lastly, pyste is still putting backslashes in its paths though it's a lot better than before - the above code ensures all forward slashes. Next problem: I feed pyste this: Include('convFXString.h') Include('../include/fx.h') cclass=AllFromHeader('../include/FXMessageBox.h') ... and all I get is: // Includes ===================================================================#include #include #include <../include/fx.h> // Using =====================================================================using namespace boost::python; // Module =====================================================================void Export_TnFOX_pythonbinds_FXMessageBox() { } What has changed? I also notice that the new command line options and the commands you can use in the pyste are not in the docs. Cheers, Niall - -- PGP secure address: securened at nedprod.com, PGP key id: 0xC518A6CF - -- PGP secure address: securened at nedprod.com, PGP key id: 0xC518A6CF -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2ILwMEcvDLFGKbPEQJpRQCeO4u6VjKqYTMb44L1ShEoDyXnmPMAoPba uQFrg/OTozh6UIWnIogAfSb7 =OpRP -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Fri Sep 12 20:42:19 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 12 Sep 2003 19:42:19 +0100 Subject: [C++-sig] Pyste generating empty file In-Reply-To: <3F6219CF.22432.A57BE72@localhost> Message-ID: <3F62219B.15232.A763372@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Sep 2003 at 19:09, Niall Douglas wrote: > Lastly, pyste is still putting backslashes in its paths though > it's a lot better than before - the above code ensures all forward > slashes. Whoops - forgot the appropriate code but no matter, it's trivial. I should add the problem is like as follows (example): gccxml -I "../../../../../../TnFOX/pythonbinds\../include" -I "D:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/include" -I "D:/Program Files/Microsoft Visual Studio .NET 2003/SDK/v1.1/include/" -I "D:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Include" -I "../../../../../../TnFOX/pythonbinds" -I "../../../../.." ../../../../../../TnFOX/pythonbinds\../include/FXMessageBox.h - fxml=c:\docume~1\ned\locals~1\temp\tmpvvpoii.xml You can see where the backslashes are appearing - in -I, the header file and the -fxml. Cheers, Niall - -- PGP secure address: securened at nedprod.com, PGP key id: 0xC518A6CF -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2ITjMEcvDLFGKbPEQLTTgCdF8EnCIROcwp0TOVmLN7+JeIv5HkAoI91 1+0jYFubpeKgRP5wUebNmVRd =3wwL -----END PGP SIGNATURE----- From mike at nospam.com Fri Sep 12 22:16:31 2003 From: mike at nospam.com (Mike Rovner) Date: Fri, 12 Sep 2003 13:16:31 -0700 Subject: [C++-sig] discard reference Message-ID: Hi all, I'm trying to find an elegant way of discarding python reference. I have a pure virtual base class A, my class implementation AA and a function with wants to take ownership of A*: class A { virtual f1() = 0; virtual ~A() {} }; class AA : public A { AA(int) {...} }; class B { void set_new_owner(A* a) { ... } }; I shall use it that way: b=B() - in C++: b.set_new_owner(new AA(1)); - in Python: b.set_new_owner(AA(1)) Now I wrap it (according to FAQ) with auto_ptr and a small wrapper: void set_new_owner_wrap(B& b, auto_ptr a) { b.set_new_owner(a.get()); a.release(); } ... class_, noncopyable>("A", no_init); class_, noncopyable>("AA", init).def("f1", &AA::f1); class_("B").def("set_new_owner", &set_new_owner_wrap); Now the problem: there is no autoconvertion from AA* to auto_ptr. What will be the correct way to solve the problem? Regards, Mike From dave at boost-consulting.com Fri Sep 12 23:41:46 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 17:41:46 -0400 Subject: [C++-sig] Re: discard reference References: Message-ID: "Mike Rovner" writes: > Hi all, > > I'm trying to find an elegant way of discarding python reference. > > I have a pure virtual base class A, my class implementation AA and > a function with wants to take ownership of A*: > > class A > { > virtual f1() = 0; > virtual ~A() {} > }; > > class AA : public A > { > AA(int) {...} > }; > > class B > { > void set_new_owner(A* a) { ... } > }; > > I shall use it that way: > b=B() > - in C++: b.set_new_owner(new AA(1)); > - in Python: b.set_new_owner(AA(1)) > > Now I wrap it (according to FAQ) with auto_ptr and a small wrapper: > > void set_new_owner_wrap(B& b, auto_ptr a) { b.set_new_owner(a.get()); > a.release(); } > ... > class_, noncopyable>("A", no_init); > class_, noncopyable>("AA", init).def("f1", &AA::f1); > class_("B").def("set_new_owner", &set_new_owner_wrap); > > Now the problem: there is no autoconvertion from AA* to auto_ptr. > What will be the correct way to solve the problem? Why is that a problem? I don't see any A* in wrapped function signatures or returns here, -- Dave Abrahams Boost Consulting www.boost-consulting.com From yakumoklesk at yahoo.es Fri Sep 12 23:51:34 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Fri, 12 Sep 2003 23:51:34 +0200 Subject: [C++-sig] Documentation error or too much newbie? In-Reply-To: Message-ID: <3F625C06.10715.14416C2@localhost> In this page http://www.boost.org/libs/python/doc/tutorial/doc/using_the_interpreter.html there is a piece of code that i pasted into my main program after the Py_Initialize to test and learn the properties of boost.python objects: handle<> main_module(borrowed( PyImport_AddModule("__main__") )); main_namespace dict(handle<>( borrowed( PyModule_GetDict(main_module.get()) ))); First of all I thought that the second line had an error: shouln't it be dict main_namespace(...) instead of dict main_namespace(...)? Because in the version that is in the page just does not compile, and the version I think it is correct at least compiles. But when it arrives to the second line, I get an acces violation exception. What have I forgot? David Lucena. PD.- MSVC++ 6.0 in XP with _DEBUG, python 2.2.3 debug and boost.python 1.30.2 debug From mike at nospam.com Sat Sep 13 00:15:53 2003 From: mike at nospam.com (Mike Rovner) Date: Fri, 12 Sep 2003 15:15:53 -0700 Subject: [C++-sig] Re: discard reference References: Message-ID: David Abrahams wrote: > "Mike Rovner" writes: > >> class B >> { >> void set_new_owner(A* a) { ... } >> }; >> - in Python: b.set_new_owner(AA(1)) >> void set_new_owner_wrap(B& b, auto_ptr a) { ------------------------------------------------^^^ >> Now the problem: there is no autoconvertion from AA* to auto_ptr. >> What will be the correct way to solve the problem? > > Why is that a problem? I don't see any A* in wrapped function > signatures or returns here, Wrapper signature is (_1, ap) and I'm calling with AA* (or ap - doesn't work either). And if I set wrapper as (_1, ap) I'll loose ability to polimorf derived classes and will have to write wrappers for each derived class individually which is inelegant. Mike From jbrandmeyer at earthlink.net Sat Sep 13 01:39:25 2003 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Fri, 12 Sep 2003 19:39:25 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <20030912125446.85251.qmail@web20208.mail.yahoo.com> References: <20030912125446.85251.qmail@web20208.mail.yahoo.com> Message-ID: <1063409965.1803.39.camel@illuvatar> On Fri, 2003-09-12 at 08:54, Ralf W. Grosse-Kunstleve wrote: > --- Jonathan Brandmeyer wrote: > > I just repeated your results on our machine and have a couple of > > comments / questions. The source package for Python 2.3 uses build > > rules that are incompatible with FSF GCC. So, I built Python with the > > Apple-distributed GCC 3.1 and Boost.Python with the FSF-distributed GCC > > 3.3.1. > > That's exactly what I did. I meant, can you specify that requirement on your website? > > I'm using Boost.Python 1.30.0 (with Debian patches) with G++ 3.3.1 on > > Debian without any ICE's. Can you elaborate? > > Debian sounds like Linux. The stacksize problem is a Mac OS X issue. Also note > that the ICE's occur only while compiling files with a fairly large number of > Boost.Python bindings. I had already reduced the size of individual compilation units due to general memory usage constraints (staying under about 300 MB) on my Linux machine, so I never saw this problem on the OSX machine. > It is my understanding that Boost.Python requires a framework build of Python. > Rene had a posting about this almost a year ago: > > http://mail.python.org/pipermail/c++-sig/2002-October/002397.html > > Pursuing his ideas eventually lead to success. See also the other postings with > the same subject: > > http://mail.python.org/pipermail/c++-sig/2002-October/date.html > > Ralf Thanks for these pointers. Based on that information and your public build logs, I was able to build and link libboost_python.dylib and our extension module against a non-framework installation of Python2.3. The following make rule does the job for libboost_python.dylib: libboost_python.dylib: $(BOOST_OBJS) ld -w -d -u -o libboost_python.lo $^ g++ -w -dynamic -undefined suppress -o $@ libboost_python.lo rm -f libboost_python.lo Since all of the resulting undefined symbols are in the python2.3 executable, they are resolved at module-load time. The two-stage linking is a mystery to me, but I did not need to force the linker flags for the second stage. My extension is linked with something like this rule: # python points to the python2.3 executable # libboost_python.dylib is assumed to be on the standard library search # path. myextension.so: $(MYEXTENSION_OBJS) g++ -w -bundle -bundle_loader $(python) -o $@ $^ -lboost_python GCC doesn't parse "-bundle_loader" properly without an option preceding "-bundle". -w is quieter than -v so... -Jonathan Brandmeyer From jbrandmeyer at earthlink.net Sat Sep 13 01:57:15 2003 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Fri, 12 Sep 2003 19:57:15 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <1063409965.1803.39.camel@illuvatar> References: <20030912125446.85251.qmail@web20208.mail.yahoo.com> <1063409965.1803.39.camel@illuvatar> Message-ID: <1063411034.1803.43.camel@illuvatar> On Fri, 2003-09-12 at 19:39, Jonathan Brandmeyer wrote: > Thanks for these pointers. Based on that information and your public > build logs, I was able to build and link libboost_python.dylib and our > extension module against a non-framework installation of Python2.3. The > following make rule does the job for libboost_python.dylib: > libboost_python.dylib: $(BOOST_OBJS) > ld -w -d -u -o libboost_python.lo $^ g++ -w -dynamic -undefined suppress -flat_namespace -o $@ \ libboost_python.lo > rm -f libboost_python.lo > > Since all of the resulting undefined symbols are in the python2.3 > executable, they are resolved at module-load time. The two-stage > linking is a mystery to me, but I did not need to force the linker flags > for the second stage. > "-flat_namespace" is also required due to the "-undefined suppress". -Jonathan Brandmeyer From dave at boost-consulting.com Sat Sep 13 03:09:35 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 21:09:35 -0400 Subject: [C++-sig] Re: discard reference References: Message-ID: "Mike Rovner" writes: > David Abrahams wrote: >> "Mike Rovner" writes: >> >>> class B >>> { >>> void set_new_owner(A* a) { ... } >>> }; > >>> - in Python: b.set_new_owner(AA(1)) > >>> void set_new_owner_wrap(B& b, auto_ptr a) { > ------------------------------------------------^^^ >>> Now the problem: there is no autoconvertion from AA* to auto_ptr. >>> What will be the correct way to solve the problem? >> >> Why is that a problem? I don't see any A* in wrapped function >> signatures or returns here, > > Wrapper signature is (_1, ap) > and I'm calling with AA* (or ap - doesn't work either). > > And if I set wrapper as (_1, ap) I'll loose ability to polimorf derived > classes > and will have to write wrappers for each derived class individually which is > inelegant. Oh, I completely overlooked that. Do you really intend to use auto_ptr? Those point at A* objects, not at A objects. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Sep 13 03:12:13 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 12 Sep 2003 21:12:13 -0400 Subject: [C++-sig] Re: Documentation error or too much newbie? References: <3F625C06.10715.14416C2@localhost> Message-ID: yakumoklesk at yahoo.es writes: > First of all I thought that the second line had an error: shouln't it be > > dict main_namespace(...) instead of dict main_namespace(...)? You typed the same thing twice here. What did you really mean? -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Sat Sep 13 03:36:29 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 12 Sep 2003 18:36:29 -0700 (PDT) Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <1063409965.1803.39.camel@illuvatar> Message-ID: <20030913013629.51403.qmail@web20204.mail.yahoo.com> --- Jonathan Brandmeyer wrote: > > > rules that are incompatible with FSF GCC. So, I built Python with the > > > Apple-distributed GCC 3.1 and Boost.Python with the FSF-distributed GCC > > > 3.3.1. > > > > That's exactly what I did. > > I meant, can you specify that requirement on your website? Done. (I didn't realize that Python's configure picks up gcc instead of cc if gcc is first on PATH.) > Thanks for these pointers. Based on that information and your public > build logs, I was able to build and link libboost_python.dylib and our > extension module against a non-framework installation of Python2.3. Wow! That's very interesting. Did you try using /usr/bin/python? Now I am beginning to wonder if it is better to work with a framework or a non-framework build. I am not an Apple user. Could someone more experienced with OS X name some pros and cons? > The following make rule does the job for libboost_python.dylib: > libboost_python.dylib: $(BOOST_OBJS) > ld -w -d -u -o libboost_python.lo $^ > g++ -w -dynamic -undefined suppress -o $@ libboost_python.lo > rm -f libboost_python.lo > > Since all of the resulting undefined symbols are in the python2.3 > executable, they are resolved at module-load time. The two-stage > linking is a mystery to me, but I did not need to force the linker flags > for the second stage. > > My extension is linked with something like this rule: > # python points to the python2.3 executable > # libboost_python.dylib is assumed to be on the standard library search > # path. > myextension.so: $(MYEXTENSION_OBJS) > g++ -w -bundle -bundle_loader $(python) -o $@ $^ -lboost_python > > GCC doesn't parse "-bundle_loader" properly without an option preceding > "-bundle". -w is quieter than -v so... Thanks for sharing this information! Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From qinlj at solidshare.com Sat Sep 13 03:26:57 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Sat, 13 Sep 2003 09:26:57 +0800 Subject: [C++-sig] Re: Some patches to make the "Automatic PyUnicode to 'const char*'" possible, and make __stdcall function bindable References: <005701c36567$b3511c20$0200a8c0@barrack> Message-ID: <003f01c37996$398293e0$0200a8c0@barrack> Hi, On Windows platform, normally it'll be MBCS, not utf-8, I do not want to change the default encoding to 'mbcs' because I'm afriad this 'program global' action could cause confliction with other python extenstion. Lijun Qin http://www.solidshare.com ----- Original Message ----- From: "David Abrahams" To: Cc: Sent: Friday, September 12, 2003 10:58 PM Subject: [C++-sig] Re: Some patches to make the "Automatic PyUnicode to 'const char*'" possible, and make __stdcall function bindable > "Lijun Qin" writes: > > > Hi, > > > > I have some patches to make the "Automatic PyUnicode to 'const char*'" > > possible (please see > > http://mail.python.org/pipermail/c++-sig/2003-August/004997.html for > > details) > > > Hi Lijun, > > After having done some research into PyUnicode, I see that it > contains an internal buffer for the default decoding of its string. > If you can set the default decoding to utf8 (that's what you're > using, right?) you may find there's an easier solution to your > problem. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From bob at redivi.com Sat Sep 13 04:15:32 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri, 12 Sep 2003 22:15:32 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <20030913013629.51403.qmail@web20204.mail.yahoo.com> Message-ID: <26E43945-E590-11D7-B303-000A95686CD8@redivi.com> On Friday, Sep 12, 2003, at 21:36 America/New_York, Ralf W. Grosse-Kunstleve wrote: >> Thanks for these pointers. Based on that information and your public >> build logs, I was able to build and link libboost_python.dylib and our >> extension module against a non-framework installation of Python2.3. > > Wow! That's very interesting. > Did you try using /usr/bin/python? > Now I am beginning to wonder if it is better to work with a framework > or a > non-framework build. I am not an Apple user. Could someone more > experienced > with OS X name some pros and cons? Frameworks are nicer to work with than libraries because they put everything in one place. They're "opaque directory structures", or Bundles.. For example, in a typical unix application, when you install a library: the library goes in /usr/local/lib the headers go in /usr/local/include its resources go in... who knows, /usr/local/share maybe? it depends. they have no metadata. With a framework: the framework goes in /Library/Frameworks (as frameworkName.framework) the headers go in the framework.. /Headers the library goes in the framework.. frameworkName its resources go in the framework.. /Resources Frameworks also have metadata associated with them in a plist file (xml or NeXT style property list) It's nice for organization. In gcc on OS X, if you say #include you don't even need an -I/Library/Frameworks/frameworkName/Headers as a linker flag. It just knows where to find it. Also, when you're linking, instead of -lsomelibrary you just say -framework frameworkName. There's also more than one place you can put frameworks, /Library/Frameworks, ~/Library/Frameworks, @executable_path/../Frameworks, etc. @executable_path is a special thing in a mach-o header that lets you reference dynamic libraries inside an application bundle. Frameworks can also do lots of things with regard to versioning. For example, you may not know this, but you probably have 3 versions of the Foundation framework installed, so that older applications that link to an older version will find it just fine. That said, they're merely for consistency and organization.. They're great, and I recommend them, but they don't do much for you *technically*. A dylib is a dylib, and frameworks use dylibs. There is nothing super special about them as far as linking is concerned, and they don't get any super special features (other than the features that bundles give you.. really easy localization, easy to move around, stuff like that, but that's mostly at the application level). It is better to work with a framework build if you have one, but distutils fully support frameworks yet so you will have to tweak things if your python module links to other frameworks. -bob From jbrandmeyer at earthlink.net Sat Sep 13 05:19:16 2003 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Fri, 12 Sep 2003 23:19:16 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <20030913013629.51403.qmail@web20204.mail.yahoo.com> References: <20030913013629.51403.qmail@web20204.mail.yahoo.com> Message-ID: <1063423155.1808.80.camel@illuvatar> On Fri, 2003-09-12 at 21:36, Ralf W. Grosse-Kunstleve wrote: > Wow! That's very interesting. > Did you try using /usr/bin/python? No. Based on some messages in the Python-Mac SIG archives that pointed towards serious brain damage in the Apple-shipped Python, we have been distributing our package against the fink-distributed Python 2.2.x. Numeric (which our module requires) does not install with the stock Python's distutils, so I haven't really looked at it further. > Now I am beginning to wonder if it is better to work with a framework or a > non-framework build. I am not an Apple user. Could someone more experienced > with OS X name some pros and cons? In our case, several extra dependencies are supplied by fink, so we are installing our module in that environment. There hasn't been any compelling reason for us to do otherwise. Last time I checked (May?), the Python-Mac SIG was going to try to work with the Darwin developers with the goal of getting a high-quality version of Python included in the next version of OSX. If that goes through, than we will probably install into the stock Python. I'm not really an Apple user either, and do most of my development on Linux and Windows. Since the Darwin installation is more like Linux than the framework method, I'm probably somewhat biased towards Darwin anyway. > Thanks for sharing this information! > > Ralf Thank you for getting the ball rolling. I had read about your work a couple of months back, but I was waiting for GCC 3.3.1 to be released before I tried it. I've been working on a migration from Py::CXX to Boost.Python, which is almost finished. Your work in this area helped us get over a major obstacle to finishing the migration. Thank you, -Jonathan Brandmeyer From bob at redivi.com Sat Sep 13 08:19:20 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat, 13 Sep 2003 02:19:20 -0400 Subject: [C++-sig] Building boost.python on Mac OS X In-Reply-To: <1063423155.1808.80.camel@illuvatar> Message-ID: <361D0CDC-E5B2-11D7-B303-000A95686CD8@redivi.com> On Friday, Sep 12, 2003, at 23:19 America/New_York, Jonathan Brandmeyer wrote: > On Fri, 2003-09-12 at 21:36, Ralf W. Grosse-Kunstleve wrote: >> Wow! That's very interesting. >> Did you try using /usr/bin/python? > > No. Based on some messages in the Python-Mac SIG archives that pointed > towards serious brain damage in the Apple-shipped Python, we have been > distributing our package against the fink-distributed Python 2.2.x. > Numeric (which our module requires) does not install with the stock > Python's distutils, so I haven't really looked at it further. Yes, Apple's Python 2.2.0 is brain damaged. >> Now I am beginning to wonder if it is better to work with a framework >> or a >> non-framework build. I am not an Apple user. Could someone more >> experienced >> with OS X name some pros and cons? > > In our case, several extra dependencies are supplied by fink, so we are > installing our module in that environment. There hasn't been any > compelling reason for us to do otherwise. Last time I checked (May?), > the Python-Mac SIG was going to try to work with the Darwin developers > with the goal of getting a high-quality version of Python included in > the next version of OSX. If that goes through, than we will probably > install into the stock Python. Apple is distributing Python 2.3.0 as a framework build with MacOS X 10.3. It's even usable. -bob From yakumoklesk at yahoo.es Sat Sep 13 09:12:20 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sat, 13 Sep 2003 09:12:20 +0200 Subject: [C++-sig] Re: Documentation error or too much newbie? In-Reply-To: Message-ID: <3F62DF74.17440.3457B1E@localhost> Opps, sorry. In the documentation there is written main_namespace dict(...) I think it is dict main_namespace(...), because dict is an boost.python object representing a python dict, isn't it? But the fact is that dict main_namespace( handle<>( borrowed( PyModule_GetDict( main_module.get() ) ) ); gives me an acces violation whet it is executed. Of course, before this line is executed first I initialize the pyton interpreter with Py_Initialize() and then I add the main module (if it isn't added yet) using the line (as shown in documentation) handle<> main_module(borrowed( PyImport_AddModule("__main__") )); So, what have I forgot to do? How can I avoid the ACCES VIOLATION given by the execution of the "dict main_namespace(..)" statement? Thanks. David Lucena. > > First of all I thought that the second line had an error: shouln't it be > > > > dict main_namespace(...) instead of dict main_namespace(...)? > > You typed the same thing twice here. What did you really mean? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From yakumoklesk at yahoo.es Sat Sep 13 22:52:46 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sat, 13 Sep 2003 22:52:46 +0200 Subject: [C++-sig] Deriving classes In-Reply-To: <3F62DF74.17440.3457B1E@localhost> References: Message-ID: <3F639FBE.21147.6349C78@localhost> It is possible to derive a C++ class from a python class? The dynamism of python respect the static methods of C++ for declaring classes makes me think it won't be possible. Anyway, what I want is to derive from de top class object from python, to take advantage of the use of slots. Can I make it using boost.python or had I to derive from the C++ class in the python source code? Thanks, David Lucena. From dirk at gerrits.homeip.net Sat Sep 13 23:40:22 2003 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Sat, 13 Sep 2003 23:40:22 +0200 Subject: [C++-sig] Re: Documentation error or too much newbie? In-Reply-To: <3F62DF74.17440.3457B1E@localhost> References: <3F62DF74.17440.3457B1E@localhost> Message-ID: yakumoklesk at yahoo.es wrote: > Opps, sorry. In the documentation there is written > > main_namespace dict(...) > > I think it is > > dict main_namespace(...), because dict is an boost.python object > representing a python dict, isn't it? Yes, a very embarassing mistake on my part. But the fix you suggested has been in CVS for quite some time. Even before the 1.30.1 release I believe. That it's not in 1.30.1 or 1.30.2 is perhaps due to my negligance? > But the fact is that > > dict main_namespace( handle<>( borrowed( PyModule_GetDict( > main_module.get() ) ) ); > > gives me an acces violation whet it is executed. Of course, before this > line is executed first I initialize the pyton interpreter with Py_Initialize() > and then I add the main module (if it isn't added yet) using the line (as > shown in documentation) > > handle<> main_module(borrowed( > PyImport_AddModule("__main__") )); > > So, what have I forgot to do? How can I avoid the ACCES VIOLATION > given by the execution of the "dict main_namespace(..)" statement? I just tried the following out on MSVC7.1 with Python 2.3 and a Boost from CVS, though I think it's a few weeks old now. (Better do a CVS update. :)) It worked for me, so I assume you are using a different compiler and/or different versions of Python and Boost.Python. Some more information would help... #include #include using namespace boost::python; int main() { Py_Initialize(); handle<> main_module(borrowed( PyImport_AddModule("__main__") )); dict main_namespace(handle<>(borrowed( PyModule_GetDict(main_module.get()) ))); handle<>( PyRun_String("result = 5 ** 2", Py_file_input, main_namespace.ptr(), main_namespace.ptr()) ); int five_squared = extract( main_namespace["result"] ); std::cout << "5^2 = " << five_squared << "\n"; Py_Finalize(); } Regards, Dirk Gerrits From dave at boost-consulting.com Sun Sep 14 00:27:49 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 13 Sep 2003 18:27:49 -0400 Subject: [C++-sig] Re: Deriving classes References: <3F639FBE.21147.6349C78@localhost> Message-ID: yakumoklesk at yahoo.es writes: > It is possible to derive a C++ class from a python class? Not really. > The dynamism of python respect the static methods of C++ for > declaring classes makes me think it won't be possible. > > Anyway, what I want is to derive from de top class object from > python, to take advantage of the use of slots. Boost.Python extension classes *are* derived from object, so you *should* be able to use slots with Python classes derived from Boost.Python C++ classes... ...argh! That won't work because of the fact that we're using the variable-length part of the Python object to help us store C++ objects directly in the Python instance instead of using a separate dynamic allocation. Python won't let you add slots to subclasses of types with a tp_itemsize. Well, this is just another piece of evidence that in-place storage was a poorly-chosen optimzation. One day we're going to remove it and you'll be able to add slots in subclasses. > Can I make it using boost.python or had I to derive from the C++ > class in the python source code? Well, what you can do is something like the following: void method1(object self, int x); std::string method2(object self, char const*); object make_derived_class(object base_class) { // get the metaclass object object metaclass = base_class.attr("__class__"); // populate method dict dict d; d["method1"] = method1; d["method2"] = method2; // call the metaclass to produce a derived class return metaclass("derived", make_tuple(base_class), d); } If you wrap make_derived_class you can then do: >>> DerivedWithSlots = make_derived_class(MyClassWithSlots) Now you have a new Python class with some wrapped C++ functions for methods. -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Sun Sep 14 07:41:07 2003 From: romany at actimize.com (Roman Yakovenko) Date: Sun, 14 Sep 2003 08:41:07 +0300 Subject: [C++-sig] Re: Boost.Python bug found Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF502064C@exchange.adrembi.com> Hi. Thanks for your help. Next time I will read documentation more careful. Promise :-). I checked CVS and did not see any changes. Also I have small question in this area. Does not injected constructor is better solution? I explain what I mean. All I want is to register conversion from PyObject to std::wstring. I even don't want to export wstring class from DLL. I know in past there was discussion about this, but I can found result of this discussion. Thanks for help. Roman > -----Original Message----- > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: Thursday, September 11, 2003 9:20 PM > To: c++-sig at python.org > Subject: [C++-sig] Re: Boost.Python bug found > > > "Roman Yakovenko" writes: > > > Also if David Abrahams thinks that my converter is good > enough to be > > in the library - I may polish it and write a lot of test > > I think I've checked in a better solution; the converter is builtin > for everyone's use. Please see the CVS. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From romany at actimize.com Sun Sep 14 08:01:14 2003 From: romany at actimize.com (Roman Yakovenko) Date: Sun, 14 Sep 2003 09:01:14 +0300 Subject: [C++-sig] sub modules + test\submod_subclass_api.cpp doesn't compile Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B17@exchange.adrembi.com> Hi. I am looking for solution to divide big module into small sub modules. I found "submod_subclass_api.cpp" file in test folder, but it seems that this file could not be compiled. Compiler can not find definition of boost::python::module. I have 2 question: it seems that boost::python::module existed for some time but then disappeared - why ? And second one how can I do it using boost::python and not native Python C API? Thanks Roman From rpenton at adelphia.net Sun Sep 14 08:40:02 2003 From: rpenton at adelphia.net (Ron Penton) Date: Sun, 14 Sep 2003 02:40:02 -0400 Subject: [C++-sig] Converting a C++ object to python Message-ID: <002301c37a8b$271a1750$0400a8c0@mithrandir> This has been asked many times, in many variants, but I cannot seem to get this working in any shape or form, which leads me to believe I'm doing something numbskulled. I'm trying to perform this sequence of events: 1 create a C++ object 2 convert it into a python object 3 pass it into python as a parameter to a function Part 2 is the part that is holding me up. Observe: class booga { public: booga() : a( 0 ) {} int a; void looga() { a = a + 10; cout << a << endl; } }; BOOST_PYTHON_MODULE( wrap ) { class_( "booga" ) .def( "looga", &booga::looga ); } int main() { Py_Initialize(); PyImport_AppendInittab( "wrap", initwrap ); booga b; object obj( &b ); That last line of code always throws an exception of type error_already_set, from within the function "value_arg_to_python". My thoughts are that I am missing something about a custom converter, or similar, but I've read through the converter docs and I'm quite baffled; they don't explain much. Would the BOOST_PYTHON_MODULE create a custom converter for classes in there, or must I specify one manually, or what? I apologize if this is too simple of a problem, in advance =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From yakumoklesk at yahoo.es Sun Sep 14 12:20:42 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sun, 14 Sep 2003 12:20:42 +0200 Subject: [C++-sig] Re: Documentation error or too much newbie? In-Reply-To: References: <3F62DF74.17440.3457B1E@localhost> Message-ID: <3F645D1A.24650.9184CC3@localhost> I made a chekout from soundforge, compiled the boost libraries, then compiled de C program, and got an error because boost\python\detail\member_function_cast.hpp was not found. CVS did not retrieved it. I made a checkout from boost-consulting in other directory, compiled again the boost libraries and then compiled the C++ program without any errors. But when it is going to convert the handle into a dict object, it results in an acces violation again. What I am doing bad? Do I have to download python 2.3 instead of using python 2.2.3 in debug mode?(python_d.lib). I'll try the release version of the libraries and DLLs to see what happens. David Lucena. On 13 Sep 2003 at 23:40, Dirk Gerrits wrote: > yakumoklesk at yahoo.es wrote: > > Opps, sorry. In the documentation there is written > > > > main_namespace dict(...) > > > > I think it is > > > > dict main_namespace(...), because dict is an boost.python object > > representing a python dict, isn't it? > > Yes, a very embarassing mistake on my part. But the fix you suggested > has been in CVS for quite some time. Even before the 1.30.1 release I > believe. That it's not in 1.30.1 or 1.30.2 is perhaps due to my negligance? > > > But the fact is that > > > > dict main_namespace( handle<>( borrowed( PyModule_GetDict( > > main_module.get() ) ) ); > > > > gives me an acces violation whet it is executed. Of course, before this > > line is executed first I initialize the pyton interpreter with Py_Initialize() > > and then I add the main module (if it isn't added yet) using the line (as > > shown in documentation) > > > > handle<> main_module(borrowed( > > PyImport_AddModule("__main__") )); > > > > So, what have I forgot to do? How can I avoid the ACCES VIOLATION > > given by the execution of the "dict main_namespace(..)" statement? > > I just tried the following out on MSVC7.1 with Python 2.3 and a Boost > from CVS, though I think it's a few weeks old now. (Better do a CVS > update. :)) It worked for me, so I assume you are using a different > compiler and/or different versions of Python and Boost.Python. Some more > information would help... > > #include > #include > > using namespace boost::python; > > int main() > { > Py_Initialize(); > handle<> main_module(borrowed( PyImport_AddModule("__main__") )); > dict main_namespace(handle<>(borrowed( > PyModule_GetDict(main_module.get()) ))); > handle<>( PyRun_String("result = 5 ** 2", Py_file_input, > main_namespace.ptr(), main_namespace.ptr()) ); > int five_squared = extract( main_namespace["result"] ); > std::cout << "5^2 = " << five_squared << "\n"; > Py_Finalize(); > } > > Regards, > Dirk Gerrits > > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From RaoulGough at yahoo.co.uk Sun Sep 14 13:28:13 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Sun, 14 Sep 2003 12:28:13 +0100 Subject: [C++-sig] Re: Converting a C++ object to python References: <002301c37a8b$271a1750$0400a8c0@mithrandir> Message-ID: "Ron Penton" writes: > Oh, no! HTML.... > > > > And a complete lack of style, too :-) > > > This has been asked many times, in many variants, but I cannot seem > to get this working in any shape or form, which leads me to believe > I'm doing something numbskulled. > > I'm trying to perform this sequence of > events: > 1 create a C++ object > 2 convert it into a python object > 3 pass it into python as a parameter to a > function > > > Part 2 is the part that is holding me up. > Observe: > > class booga{public: > booga() : a( 0 ) {} int a; void > looga() { a = a + 10; cout << a << endl; }}; > BOOST_PYTHON_MODULE( wrap ){ class_( "booga" > ) .def( "looga", &booga::looga > );} > int main(){ Py_Initialize(); > > PyImport_AppendInittab( > "wrap", initwrap ); > booga b; > object obj( &b ); > > That last line of code always throws an exception of type > error_already_set, from within the function "value_arg_to_python". If you catch a boost::python::error_already_set in C++, I guess you can get more information by calling PyErr_Print(), which should dump a standard Python traceback on stderr. At a guess, you're getting a Python TypeError from the object constructor, because it doesn't have a converter for booga *. BTW, why are you passing a pointer to b, instead of a reference? > > My thoughts are that I am missing something about a custom > converter, or similar, but I've read through the converter docs and > I'm quite baffled; they don't explain much. Would the > BOOST_PYTHON_MODULE create a custom converter for classes in there, > or must I specify one manually, or what? I don't have any experience embedding Python in C++, because I work the other way around (i.e. using C++ extensions from within Python). However, the documentation for PyImport_AppendInittab says that you should call it *before* Py_Initialize. I would have thought you want a normal import of your module anyway, rather than trying to make it act like a built-in. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From yakumoklesk at yahoo.es Sun Sep 14 16:09:28 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sun, 14 Sep 2003 16:09:28 +0200 Subject: [C++-sig] Cannot believe what my eyes see: ACCES VIOLATION... In-Reply-To: Message-ID: <3F6492B8.19933.1D89A7@localhost> This is the program that causes the acces violation. Can't be more simple... #include #include namespace python = boost::python; void func() { python::handle<> main_module( python::borrowed( PyImport_AddModule( "__main__" ) ) ); //python::handle<> main_namespace( python::borrowed( PyModule_GetDict( main_module.get() ) ) ); PyRun_SimpleString("a = 3"); python::handle<> hmain_namespace( python::borrowed( PyModule_GetDict(main_module.get() ) ) ); python::dict main_namespace( hmain_namespace ); } int main( int argc, char** argv ) { Py_Initialize(); func(); Py_Finalize(); return 0; } The acces violation occurs in the last line of the func() code: python::dict main_namespace( hmain_namespace ); I have been trying to debug what happens. This is what I have got. Don't know if it will be useful: In the template function template explicit dict(T const& data) : base(object(data)) { } data, in this case, the handle<> named main_namespace, holds the following information - data {...} - m_p 0x00ae33b0 + _ob_next 0x00ae3338 + _ob_prev 0x00ae3478 ob_refcnt 2 + ob_type 0x00574038 _PyDict_Type inside the function object object::object(handle<> const& x) : object_base(python::incref(python::expect_non_null(x.get()))) {} x should have the same information as data had before, because is the same handle<>, but I find the following: - x {...} - m_p 0x00ae33b0 ob_refcnt 11416376 + ob_type 0x00ae3478 It seems that the PyObject structure pointed by m_p has... dynamically changed? Well, sorry if I am sayin nonsenses, but I don't know what to do. Maybe it would be better for me to use objects and only use handles, but then there is no sense in using boost, because I could only get the advantage PyObject handling. More details of my project: It is a windows 32 console application, made in Visual C++ 6.0 I am using the directives _DEBUG, and the boost_python_debug.lib library that this morning compiled using bjam and the source code that checked out from boost- consulting.com yesterday at night. The version of the puthon libraries is 2.2.3, but it fails also with 2.2.1. The include path of the proyect is: E:\proxp\prog\DirectX 9.0 SDK\Lib E:\PROXP\PROG\DIRECTX 8.1 SDK VC++\INCLUDE e:\proxp\prog\VC++ 6.0\INCLUDE e:\proxp\prog\VC++ 6.0\ATL\INCLUDE e:\proxp\prog\VC++ 6.0\MFC\INCLUDE E:\PROXP\PROG\PYTHON 2.2.1\INCLUDE (when i tried with 2.2.3 i changed it to 2.2.3 of course) E:\proxp\prog\boost checkout-14-09-2003 boost-consulting.com The library path of the proyect is: E:\proxp\prog\DirectX 9.0 SDK\Lib E:\PROXP\PROG\DIRECTX 8.1 SDK VC++\LIB e:\proxp\prog\VC++ 6.0\LIB e:\proxp\prog\VC++ 6.0\MFC\LIB E:\proxp\prog\Python 2.2.1 source\PCbuild (because I use python_d.dll for debug version. As above, i change to 2.2.3 when i using 2.2.3 includes) E:\proxp\prog\boost checkout-14-09-2003 boost-consulting.com\libs\python\build\bin- stage ( I have also tried E:\proxp\prog\boost checkout-14-09-2003 boost- consulting.com\libs\python\build\bin\boost_python.dll\msvc\debug\runtime-link-dynamic with the same ACCES VIOLATION result ) I also have tried to compile the boost.python libraries using msvc with the project located in E:\proxp\prog\boost checkout-14-09-2003 boost- consulting.com\libs\python\build\VisualStudio but I get tons of erros from the e:\proxp\prog\VC++ 6.0\INCLUDE\mmreg.h file, saying things lik 'WORD' : missing storage-class or type specifiers and other types as well that VC does not find. This seems strange to me, that a file from VC++ include has this kind of errors. Any hint would be appreciate. If need more details, just ask me. David Lucena From rpenton at adelphia.net Sun Sep 14 18:29:57 2003 From: rpenton at adelphia.net (Ron Penton) Date: Sun, 14 Sep 2003 12:29:57 -0400 Subject: [C++-sig] Re: Converting a C++ object to python Message-ID: <000a01c37add$702686c0$0400a8c0@mithrandir> > Oh, no! HTML.... >> > And a complete lack of style, too :-) Oh dear, I forgot to reset my mail program after a recent reformat... oopsie =) >If you catch a boost::python::error_already_set in C++, I guess you >can get more information by calling PyErr_Print(), which should dump a >standard Python traceback on stderr. At a guess, you're getting a >Python TypeError from the object constructor, because it doesn't have >a converter for booga *. BTW, why are you passing a pointer to b, >instead of a reference? PyErr_Print says "TypeError: No Python class registered for C++ class class booga", which confirms what you thought. The part that confuses me is the converter part; I'm not quite sure how to go about creating one. All of the examples I can find go about the creation of the python types manually, rather than using the class_ definition, so I'm really unsure of where to go from here. >I don't have any experience embedding Python in C++, because I work >the other way around (i.e. using C++ extensions from within Python). >However, the documentation for PyImport_AppendInittab says that you >should call it *before* Py_Initialize. I would have thought you want a >normal import of your module anyway, rather than trying to make it act >like a built-in. It works either way. For the time being I'm just playing around trying to see what can be done. From yakumoklesk at yahoo.es Sun Sep 14 19:53:12 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sun, 14 Sep 2003 19:53:12 +0200 Subject: [C++-sig] Cannot believe what my eyes see: ACCES VIOLATION... In-Reply-To: <3F6492B8.19933.1D89A7@localhost> References: Message-ID: <3F64C728.26848.C947AF@localhost> I have tested again this time with python 2.3 libraries, debug and release, and does not work neither. I get the same ACCES VIOLATION when I am trying to convert a handle<> to a PyObjec* that represents the dictionary from main module to an boost.python dict object. Any hints? Should I desist trying? From yakumoklesk at yahoo.es Sun Sep 14 20:06:40 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Sun, 14 Sep 2003 20:06:40 +0200 Subject: [C++-sig] Cannot believe what my eyes see: ACCES VIOLATION... In-Reply-To: <3F64C728.26848.C947AF@localhost> References: <3F6492B8.19933.1D89A7@localhost> Message-ID: <3F64CA50.12395.D59B79@localhost> Sorry for the spam. I have tried adding the preprocessor directive DBOOST_DEBUG_PYTHON and substituting the #include with the #include as is written in the documentation in http://www.boost.org/libs/python/doc/building.html, but it does not work yet, same ACCES VIOLATION. Anyway, I think this last way of doing things is not necessary for me, as I have the Python 2.3 source and have compiled it so the PCBuild directory has the python23_d.lib and python23_d.dll See ya, David Lucena From brett.calcott at paradise.net.nz Mon Sep 15 02:09:59 2003 From: brett.calcott at paradise.net.nz (Brett Calcott) Date: Mon, 15 Sep 2003 10:09:59 +1000 Subject: [C++-sig] Re: Converting a C++ object to python References: <002301c37a8b$271a1750$0400a8c0@mithrandir> Message-ID: > int main() > { > Py_Initialize(); > > PyImport_AppendInittab( "wrap", initwrap ); > > booga b; > object obj( &b ); > > } >From the Docs at: (from http://www.pyzine.com/manual/api/importing.html) int PyImport_AppendInittab(char *name, void (*initfunc)(void)): Add a single module to the existing table of built-in modules. This is a convenience wrapper around PyImport_ExtendInittab(), returning -1 if the table could not be extended. The new module can be imported by the name name, and uses the function initfunc as the initialization function called on the first attempted import. This should be called before Py_Initialize(). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From RaoulGough at yahoo.co.uk Mon Sep 15 13:02:02 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 15 Sep 2003 12:02:02 +0100 Subject: [C++-sig] Re: Converting a C++ object to python References: <000a01c37add$702686c0$0400a8c0@mithrandir> Message-ID: "Ron Penton" writes: >>If you catch a boost::python::error_already_set in C++, I guess you >>can get more information by calling PyErr_Print(), which should dump a >>standard Python traceback on stderr. At a guess, you're getting a >>Python TypeError from the object constructor, because it doesn't have >>a converter for booga *. BTW, why are you passing a pointer to b, >>instead of a reference? > > PyErr_Print says "TypeError: No Python class registered for C++ class class > booga", > which confirms what you thought. Well, not really - I would have thought that there is a problem with booga * (i.e. pointer to booga), but from your error message, that is not the case. I don't suppose it makes any difference to use b instead of &b then? > > The part that confuses me is the converter part; I'm not quite sure how to > go about creating one. All of the examples I can find go about the creation > of the python types manually, rather than using the class_ definition, so > I'm really unsure of where to go from here. Well, we've now snipped the original code, but looking back at it from your original post: > class booga{public: > booga() : a( 0 ) {} int a; void > looga() { a = a + 10; cout << a << endl; }}; > BOOST_PYTHON_MODULE( wrap ){ class_( "booga" > ) .def( "looga", &booga::looga > );} > int main(){ Py_Initialize(); > > PyImport_AppendInittab( > "wrap", initwrap ); > booga b; > object obj( &b ); the class_ constructor should handle all of the converter registration. However, I know that at least *some* of the registration is done at run-time. I'm not sure whether that applies to the to-python converters or not (I would guess not, actually). Anyway, why not add some std::cout in the BOOST_PYTHON_MODULE function to make sure that it is actually being run (especially given the doubt about using PyImport_AppendInittab) > > >>I don't have any experience embedding Python in C++, because I work >>the other way around (i.e. using C++ extensions from within Python). >>However, the documentation for PyImport_AppendInittab says that you >>should call it *before* Py_Initialize. I would have thought you want a >>normal import of your module anyway, rather than trying to make it act >>like a built-in. > > It works either way. For the time being I'm just playing around trying to > see what can be done. You mean it runs initwrap either way? If that is the case, I'm really not sure what else I can suggest. I don't actually understand how the object constructor is supposed to know what to do with a raw C++ reference (or pointer for that matter) since it doesn't know whether to copy the C++ object or wrap a refrence to it. This is normally all handled by the "def" function, where you pass it a return policy specifying the copy or reference behaviour. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Mon Sep 15 14:15:16 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 15 Sep 2003 08:15:16 -0400 Subject: [C++-sig] Re: Boost.Python bug found References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF502064C@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Hi. Thanks for your help. Next time I will read documentation > more careful. Promise :-). > > I checked CVS and did not see any changes. Check again (SF has a delay for anonymous CVS) or get the snapshot from http://www.boost-consulting.com/boost.tar.bz2 > Also I have small question in this area. > Does not injected constructor is better solution? > I explain what I mean. All I want is to register > conversion from PyObject to std::wstring. That's all my patch does. Well, that and the conversion in the opposite direction, also. > I even don't want to export wstring class from DLL. My patch doesn't. -- Dave Abrahams Boost Consulting www.boost-consulting.com From jacek.generowicz at cern.ch Mon Sep 15 16:49:48 2003 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: 15 Sep 2003 16:49:48 +0200 Subject: [C++-sig] Re: Boost: virtual inheritance References: Message-ID: David Abrahams writes: > David Abrahams writes: > > The quick workaround is: > > > > .def("name", object(&Class::name)) Thanks for your quick response (unfortunately I was away last week, so we were not able to continue this work for a while). This allows us to proceed a bit further, however when we make Item::name return a _reference_ to std::string, it all goes wrong again; firstly, we are (quite rightly) asked to specify a return policy. Complying with the request, we are faced with the following error: /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:383: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE' (Full error message included at the bottom, for completeness, once again.) Here's our (updated) minimal test case: ==================================================================== #include struct Item { std::string m_name; Item(const std::string& name):m_name(name) {} const std::string& name() const { return m_name; } virtual ~Item() {}; }; struct Class : virtual public Item { Class():Item("hello"){} }; #include using namespace boost::python; BOOST_PYTHON_MODULE( btry ) { class_("Item", no_init); class_ >("Class") .def("name", object(&Class::name), return_value_policy()); } ==================================================================== > This problem is now fixed in CVS. Great. As we must present our work on our centrally installed version of Boost (currently 1.30.2), we can't really take advantage of this yet. If you believe that all our problems will go away by using the CVS version, then say the word, and we'll find sufficient motivation to install a (locally) non-standard version ... otherwise we'll keep trying to use workarounds, for now. Thanks gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/ -I../../../../Dictionary/Reflection -I/afs/cern.ch/sw/lcg/external/Python/2.2.2/rh73_gcc32/include/python2.2 -c boosttry.cpp -o build/temp.linux-i686-2.2/boosttry.o -g /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp: In member function `void boost::python::class_::def_impl(const char*, F, const boost::python::detail::def_helper&, const boost::python::api::object*) [with F = boost::python::api::object, A1 = boost::python::return_value_policy, T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]': /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:459: instantiated from `void boost::python::class_::def_maybe_overloads(const char*, Fn, const A1&, ...) [with Fn = boost::python::api::object, A1 = boost::python::return_value_policy, T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:253: instantiated from `boost::python::class_& boost::python::class_::def(const char*, A1, const A2&) [with A1 = boost::python::api::object, A2 = boost::python::return_value_policy, T = Class, X1 = boost::python::bases, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' boosttry.cpp:24: instantiated from here /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:383: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/detail/invoke.hpp: In function `PyObject* boost::python::detail::invoke(boost::python::detail::mem_fn_tag, RC*, F&, TC&) [with RC = boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning, F = const std::string&(Item::*)() const, TC = boost::python::detail::nullary >]': /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/detail/caller.hpp:162: instantiated from `PyObject* boost::python::detail::caller_arity<1>::impl::operator()(PyObject*, PyObject*) [with F = const std::string&(Item::*)() const, ConverterGenerators = boost::python::detail::args_from_python, Policies = boost::python::default_call_policies, Sig = boost::mpl::list2]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/function/function_template.hpp:117: instantiated from `static R boost::detail::function::function_obj_invoker2::invoke(boost::detail::function::any_pointer, T0, T1) [with FunctionObj = boost::python::detail::caller >, R = PyObject*, T0 = PyObject*, T1 = PyObject*]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/function/function_template.hpp:481: instantiated from `void boost::function2::assign_to(FunctionObj, boost::detail::function::function_obj_tag) [with FunctionObj = boost::python::detail::caller >, R = PyObject*, T0 = PyObject*, T1 = PyObject*, Allocator = std::allocator]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/function/function_template.hpp:432: instantiated from `void boost::function2::assign_to(Functor) [with Functor = boost::python::detail::caller >, R = PyObject*, T0 = PyObject*, T1 = PyObject*, Allocator = std::allocator]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/function/function_template.hpp:293: instantiated from `boost::function2::function2(Functor, boost::detail::function::enable_if::value>::value, int>::type) [with Functor = boost::python::detail::caller >, R = PyObject*, T0 = PyObject*, T1 = PyObject*, Allocator = std::allocator]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/function_handle.hpp:27: instantiated from `boost::python::handle boost::python::objects::function_handle(const F&, Signature) [with F = const std::string&(Item::*)() const, Signature = boost::mpl::list2]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/function_handle.hpp:39: instantiated from `boost::python::handle boost::python::objects::make_function_handle(F) [with F = const std::string&(Item::*)() const]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/converter/arg_to_python.hpp:205: instantiated from `boost::python::converter::detail::function_arg_to_python::function_arg_to_python(const T&) [with T = const std::string&(Item::*)() const]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/converter/arg_to_python.hpp:258: instantiated from `boost::python::converter::arg_to_python::arg_to_python(const T&) [with T = const std::string&(Item::*)() const]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object_core.hpp:282: instantiated from `static PyObject* boost::python::api::object_initializer::get(const T*, int*) [with T = const std::string&(Item::*)() const, bool is_proxy = false, bool is_object_manager = false]' /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object_core.hpp:225: instantiated from `boost::python::api::object::object(const T&) [with T = const std::string&(Item::*)() const]' boosttry.cpp:24: instantiated from here /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/detail/invoke.hpp:93: no match for call to `( boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning) (const std::basic_string, std::allocator >&)' error: command 'gcc' failed with exit status 1 From dave at boost-consulting.com Mon Sep 15 17:11:08 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 15 Sep 2003 11:11:08 -0400 Subject: [C++-sig] Re: Cannot believe what my eyes see: ACCES VIOLATION... References: <3F6492B8.19933.1D89A7@localhost> Message-ID: yakumoklesk at yahoo.es writes: > This is the program that causes the acces violation. Can't be more simple... Sure it can ;-> > #include ^^^^^^^^^^^^^^^^^^^ Don't do this. You should just include a Boost.Python header to get python.h. When I get rid of that, the only crash I can reproduce goes away. This is due to the debug-mode handling provided by wrap_python.hpp as described in http://www.boost.org/libs/python/doc/building.html#variants > #include > > namespace python = boost::python; > > void func() > { > python::handle<> main_module( python::borrowed( PyImport_AddModule( > "__main__" ) ) ); > //python::handle<> main_namespace( python::borrowed( PyModule_GetDict( > main_module.get() ) ) ); > PyRun_SimpleString("a = 3"); > > python::handle<> hmain_namespace( python::borrowed( > PyModule_GetDict(main_module.get() ) ) ); > python::dict main_namespace( hmain_namespace ); > } namespace py = boost::python; void func() { py::object main_module = py::extract(PyImport_AddModule("__main__")); PyRun_SimpleString("a = 3"); py::dict main_namespace(main_module.attr("__dict__")); } > The acces violation occurs in the last line of the func() code: > > python::dict main_namespace( hmain_namespace ); > > I have been trying to debug what happens. This is what I have > got. Don't know if it will be useful: > > In the template function > > template > explicit dict(T const& data) > : base(object(data)) > { > } > > data, in this case, the handle<> named main_namespace, holds the following > information > > - data {...} > - m_p 0x00ae33b0 > + _ob_next 0x00ae3338 > + _ob_prev 0x00ae3478 > ob_refcnt 2 > + ob_type 0x00574038 _PyDict_Type > > inside the function object > > object::object(handle<> const& x) > : object_base(python::incref(python::expect_non_null(x.get()))) > {} > > x should have the same information as data had before, because is the same handle<>, > but I find the following: > > - x {...} > - m_p 0x00ae33b0 > ob_refcnt 11416376 > + ob_type 0x00ae3478 > > It seems that the PyObject structure pointed by m_p has... dynamically changed? Well, > sorry if I am sayin nonsenses, but I don't know what to do. Maybe it would be better for > me to use objects and only use handles, but then there is no sense in using boost, > because I could only get the advantage PyObject handling. > > More details of my project: > > It is a windows 32 console application, made in Visual C++ 6.0 > I am using the directives _DEBUG, and the boost_python_debug.lib library that this > morning compiled using bjam and the source code that checked out from boost- > consulting.com yesterday at night. > The version of the puthon libraries is 2.2.3, but it fails also with 2.2.1. > > The include path of the proyect is: > > E:\proxp\prog\DirectX 9.0 SDK\Lib > E:\PROXP\PROG\DIRECTX 8.1 SDK VC++\INCLUDE > e:\proxp\prog\VC++ 6.0\INCLUDE > e:\proxp\prog\VC++ 6.0\ATL\INCLUDE > e:\proxp\prog\VC++ 6.0\MFC\INCLUDE > E:\PROXP\PROG\PYTHON 2.2.1\INCLUDE (when i tried with 2.2.3 i changed it to 2.2.3 > of course) > E:\proxp\prog\boost checkout-14-09-2003 boost-consulting.com > > The library path of the proyect is: > > E:\proxp\prog\DirectX 9.0 SDK\Lib > E:\PROXP\PROG\DIRECTX 8.1 SDK VC++\LIB > e:\proxp\prog\VC++ 6.0\LIB > e:\proxp\prog\VC++ 6.0\MFC\LIB > E:\proxp\prog\Python 2.2.1 source\PCbuild (because I use python_d.dll for debug > version. As above, i change to 2.2.3 when i using 2.2.3 includes) > E:\proxp\prog\boost checkout-14-09-2003 boost-consulting.com\libs\python\build\bin- > stage ( I have also tried E:\proxp\prog\boost checkout-14-09-2003 boost- > consulting.com\libs\python\build\bin\boost_python.dll\msvc\debug\runtime-link-dynamic > with the same ACCES VIOLATION result ) > > I also have tried to compile the boost.python libraries using msvc with the project > located in E:\proxp\prog\boost checkout-14-09-2003 boost- > consulting.com\libs\python\build\VisualStudio > but I get tons of erros from the > > e:\proxp\prog\VC++ 6.0\INCLUDE\mmreg.h file, saying things lik > > 'WORD' : missing storage-class or type specifiers > > and other types as well that VC does not find. > > This seems strange to me, that a file from VC++ include has this kind of errors. > > Any hint would be appreciate. If need more details, just ask me. > > David Lucena -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Sep 15 17:25:12 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 15 Sep 2003 11:25:12 -0400 Subject: [C++-sig] Re: Converting a C++ object to python References: <002301c37a8b$271a1750$0400a8c0@mithrandir> Message-ID: "Ron Penton" writes: > I'm trying to perform this sequence of events: > 1 create a C++ object > 2 convert it into a python object > 3 pass it into python as a parameter to a function > > > Part 2 is the part that is holding me up. Observe: > > class booga > { > public: > booga() : a( 0 ) {} > int a; > void looga() { a = a + 10; cout << a << endl; } > }; > > BOOST_PYTHON_MODULE( wrap ) > { > class_( "booga" ) > .def( "looga", &booga::looga ); > } > > int main() > { > Py_Initialize(); > > PyImport_AppendInittab( "wrap", initwrap ); > > booga b; > object obj( &b ); > > > That last line of code always throws an exception of type > error_already_set, from within the function "value_arg_to_python". > > My thoughts are that I am missing something about a custom converter, > or similar, but I've read through the converter docs and I'm quite > baffled; they don't explain much. Would the BOOST_PYTHON_MODULE create > a custom converter for classes in there, or must I specify one > manually, or what? The basic problem is that you haven't done anything to import the "wrap" module (and thus cause the "booga" converters to be registered) at the point you are trying to do the conversion. -- Dave Abrahams Boost Consulting www.boost-consulting.com From yakumoklesk at yahoo.es Mon Sep 15 20:35:14 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Mon, 15 Sep 2003 20:35:14 +0200 Subject: [C++-sig] Re: Cannot believe what my eyes see: ACCES VIOLATION... In-Reply-To: Message-ID: <3F662282.30173.6161E0C@localhost> On 15 Sep 2003 at 11:11, David Abrahams wrote: > > #include > ^^^^^^^^^^^^^^^^^^^ > > Don't do this. You should just include a Boost.Python header to get > python.h. When I get rid of that, the only crash I can reproduce > goes away. This is due to the debug-mode handling provided by > wrap_python.hpp as described in > http://www.boost.org/libs/python/doc/building.html#variants I had already tested the program not including the python.h header but also crashed. The problem is that boost_python_debug.dll points to python23.dll instead of python23_d.dll. How have I to modify the project that builds boost_python_debug.dll in order to point to python23_d.dll instead of python23.dll? > > namespace py = boost::python; > > void func() > { > py::object main_module > = py::extract(PyImport_AddModule("__main__")); > PyRun_SimpleString("a = 3"); > py::dict main_namespace(main_module.attr("__dict__")); > } This does not compile anyway, the first line gives this error: cannot convert from 'struct boost::python::extract' to 'class boost::python::api::object' Thanks. David Lucena. From yakumoklesk at yahoo.es Mon Sep 15 21:10:37 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Mon, 15 Sep 2003 21:10:37 +0200 Subject: [C++-sig] At last! In-Reply-To: <3F662282.30173.6161E0C@localhost> References: Message-ID: <3F662ACD.8444.636856A@localhost> Well, at last I compiled the boost_debug_python.dll correctly and now it points to python32_d.dll and the program does not crash when getting the object from the handle. Thanks for the help and patience. 8) David "Librarian" Lucena. From dave at boost-consulting.com Mon Sep 15 23:05:48 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 15 Sep 2003 17:05:48 -0400 Subject: [C++-sig] Re: Boost: virtual inheritance References: Message-ID: Jacek Generowicz writes: > Thanks for your quick response (unfortunately I was away last week, so > we were not able to continue this work for a while). > > This allows us to proceed a bit further, however when we make > Item::name return a _reference_ to std::string, it all goes wrong > again; firstly, we are (quite rightly) asked to specify a return > policy. Complying with the request, we are faced with the following error: > > /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:383: `sizeof' > applied to incomplete type `boost::STATIC_ASSERTION_FAILURE' > > (Full error message included at the bottom, for completeness, > once again.) > > Here's our (updated) minimal test case: > > ==================================================================== > #include > > struct Item { > std::string m_name; > Item(const std::string& name):m_name(name) {} > const std::string& name() const { return m_name; } > virtual ~Item() {}; > }; > > struct Class : virtual public Item { > Class():Item("hello"){} > }; > > > #include > using namespace boost::python; > > BOOST_PYTHON_MODULE( btry ) { > > > class_("Item", no_init); > > class_ >("Class") > .def("name", object(&Class::name), return_value_policy()); > } > ==================================================================== > >> This problem is now fixed in CVS. > > Great. As we must present our work on our centrally installed version > of Boost (currently 1.30.2), we can't really take advantage of this > yet. If you believe that all our problems will go away by using the > CVS version, then say the word, and we'll find sufficient motivation > to install a (locally) non-standard version ... otherwise we'll keep > trying to use workarounds, for now. you need to pass make_function(&Class::name, return_value_policy()) instead. The static assertion is telling you that the policies are already determined once you write object(&Class::name) Of course, with the CVS version you don't need to do either of these things. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Sep 15 23:07:31 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 15 Sep 2003 17:07:31 -0400 Subject: [C++-sig] Re: Cannot believe what my eyes see: ACCES VIOLATION... References: <3F662282.30173.6161E0C@localhost> Message-ID: yakumoklesk at yahoo.es writes: > On 15 Sep 2003 at 11:11, David Abrahams wrote: > >> > #include >> ^^^^^^^^^^^^^^^^^^^ >> >> Don't do this. You should just include a Boost.Python header to get >> python.h. When I get rid of that, the only crash I can reproduce >> goes away. This is due to the debug-mode handling provided by >> wrap_python.hpp as described in >> http://www.boost.org/libs/python/doc/building.html#variants > > I had already tested the program not including the python.h header but also crashed. > The problem is that boost_python_debug.dll points to python23.dll instead of > python23_d.dll. How have I to modify the project that builds boost_python_debug.dll in > order to point to python23_d.dll instead of python23.dll? Use Boost.Build. It just works. >> namespace py = boost::python; >> >> void func() >> { >> py::object main_module >> = py::extract(PyImport_AddModule("__main__")); >> PyRun_SimpleString("a = 3"); >> py::dict main_namespace(main_module.attr("__dict__")); >> } > > This does not compile anyway, the first line gives this error: > > cannot convert from 'struct boost::python::extract' to > 'class boost::python::api::object' THat's your broken compiler at work. Just add an extra "()" before the ";". -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike at nospam.com Tue Sep 16 00:40:10 2003 From: mike at nospam.com (Mike Rovner) Date: Mon, 15 Sep 2003 15:40:10 -0700 Subject: [C++-sig] Re: discard reference References: Message-ID: David Abrahams wrote: > "Mike Rovner" writes: >> Wrapper signature is (_1, ap) >> and I'm calling with AA* (or ap - doesn't work either). >> >> And if I set wrapper as (_1, ap) I'll loose ability to polimorf >> derived classes >> and will have to write wrappers for each derived class individually >> which is inelegant. > > Oh, I completely overlooked that. Do you really intend to use > auto_ptr? Those point at A* objects, not at A objects. Oh, sorry. It's just mistyping of auto_ptr. (I'm not used to auto_ptr yet.) Everywhere in the code there are auto_ptr. So I'm trying to invent some kind of automatic auto_ptr argument processing policy: release_auto_ptr_policy .def("X", (void)(*X)(auto_ptr(A))&X, release_auto_ptr_policy) which will call X with released A*, e.g. Auto_X_wrapper(auto_ptr ap) { X(ap.get()); ap.release(); } What do you think? I even tryed to look into implementation, but get lost. :( Mike From yakumoklesk at yahoo.es Tue Sep 16 01:47:25 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Tue, 16 Sep 2003 01:47:25 +0200 Subject: [C++-sig] converting dict value to object In-Reply-To: Message-ID: <3F666BAD.30717.733EF20@localhost> Suposing that dictio is a dict boost.python object, making this dictio['a'] = 3; it's ok, supossiing that "a" exists in the dictionary. But how can I retieve the value? How can I extract an integer or converting the object_item returnend by dictio['a'] into a boost.python object? py:object integer_object = CONVERSION_FROM_OBJECT_ITEM_TO_OBJECT(dictio['a']); How can I do the CONVERSION_FROM_OBJECT_ITEM_TO_OBJECT? Thanks. David Lucena. PD.- BTW, Is there any documentation/examples explaining conversion policies? It's a little bit hard for me understanding such conversions. From dave at boost-consulting.com Tue Sep 16 16:46:41 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 10:46:41 -0400 Subject: [C++-sig] Re: discard reference References: Message-ID: "Mike Rovner" writes: > David Abrahams wrote: >> "Mike Rovner" writes: >>> Wrapper signature is (_1, ap) >>> and I'm calling with AA* (or ap - doesn't work either). >>> >>> And if I set wrapper as (_1, ap) I'll loose ability to polimorf >>> derived classes >>> and will have to write wrappers for each derived class individually >>> which is inelegant. >> >> Oh, I completely overlooked that. Do you really intend to use >> auto_ptr? Those point at A* objects, not at A objects. > > Oh, sorry. It's just mistyping of auto_ptr. (I'm not used to auto_ptr > yet.) > Everywhere in the code there are auto_ptr. > > So I'm trying to invent some kind of automatic auto_ptr argument processing > policy: release_auto_ptr_policy > .def("X", (void)(*X)(auto_ptr(A))&X, release_auto_ptr_policy) > which will call X with released A*, e.g. > Auto_X_wrapper(auto_ptr ap) { X(ap.get()); ap.release(); } > > What do you think? I even tryed to look into implementation, but get lost. > :( I think we'll want something like this eventually, anyway. Luabind can do that and the langbinding integration will produce the result you want. I'm not really sure what you mean by "_1" above, but I think you can get the polymorphism you want (laboriously) by using implicitly_convertible,std::auto_ptr >(); for all the appropriate Derived classes. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Sep 16 17:06:13 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 11:06:13 -0400 Subject: [C++-sig] Re: converting dict value to object References: <3F666BAD.30717.733EF20@localhost> Message-ID: yakumoklesk at yahoo.es writes: > Suposing that dictio is a dict boost.python object, making this > > dictio['a'] = 3; > > it's ok, supossiing that "a" exists in the dictionary. But how can I retieve > the value? How can I extract an integer or converting the object_item > returnend by dictio['a'] into a boost.python object? > > py:object integer_object = > CONVERSION_FROM_OBJECT_ITEM_TO_OBJECT(dictio['a']); > > How can I do the > CONVERSION_FROM_OBJECT_ITEM_TO_OBJECT? > > Thanks. > > David Lucena. py::object integer_object = dictio['a']; > PD.- BTW, Is there any documentation/examples explaining conversion > policies? It's a little bit hard for me understanding such conversions. http://www.boost.org/libs/python/doc/v2/CallPolicies.html -- Dave Abrahams Boost Consulting www.boost-consulting.com From yakumoklesk at yahoo.es Tue Sep 16 17:20:46 2003 From: yakumoklesk at yahoo.es (yakumoklesk at yahoo.es) Date: Tue, 16 Sep 2003 17:20:46 +0200 Subject: [C++-sig] Re: converting dict value to object In-Reply-To: Message-ID: <3F67466E.13871.A8B1817@localhost> py::object integer_object = dictio['a']; failed to compile, but py::object integer_object( dictio['a'] ); worked ok. Thanks for the help and the URL of calling Policies. See ya. David "Reading" Lucena > > How can I do the > > CONVERSION_FROM_OBJECT_ITEM_TO_OBJECT? > > > > Thanks. > > > > David Lucena. > > py::object integer_object = dictio['a']; > > > PD.- BTW, Is there any documentation/examples explaining conversion > > policies? It's a little bit hard for me understanding such conversions. > > http://www.boost.org/libs/python/doc/v2/CallPolicies.html > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Tue Sep 16 17:20:09 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 11:20:09 -0400 Subject: [C++-sig] Re: Boost.Python - implementing slicing on extension container class In-Reply-To: <5.1.1.6.0.20030914145505.00aa8030@pop.freeserve.com> (Steve Horne's message of "Sun, 14 Sep 2003 15:41:04 +0100") References: <5.1.1.6.0.20030914145505.00aa8030@pop.freeserve.com> Message-ID: The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.user as well. Steve, First, Boost.Python questions should go to the C++-sig (http://www.boost.org/more/mailing_lists.htm#cplussig). Second, The current CVS has some excellent work on presenting C++ containers as Python containers by Joel de Guzman and Raoul Gough (see vector_indexing_suite). I really suggest you try this stuff; it could save you lots of code and will almost surely work better for you than what you've done by hand because it handles some very subtle issues of Python object lifetime and validity correctly. Steve Horne writes: > I'm currently writing a set of container classes using Boost.Python to > wrap an existing C++ library. Progress has been very good - not even > two days and I've wrapped all the existing C++ methods (at least > 100). But of course a library designed for C++ is not a library > designed for Python. Job 2 is to make it more Pythonic. > > The current problem is implementing slicing in the __getitem__, > __setitem__ and __delitem__ methods. These are already working with > single keys. To handle slicing, I need to identify in the key object > is a slice object. This is the sticking point right now. > > I can access the type of the object using p.attr ("__class__") - but > how do I get access to the slice type object from __builtins__ in > order to compare? > > I could probably use a workaround such as extracting and checking a > string representation from p.attr ("__class__").str (), but it seems > to me that the ability to import symbols from another module (whether > __builtins__ or some other Python or extension module). > > This could reduce to the ability to convert a PyObject* to an object > instance - even more useful for using any C API functions that don't > have a Boost.Python wrapper - but there seems to be no obvious way to > do this. > > In addition, my containers are currently declared as follows... > > class_("classname") > ... > ; > > The boost::noncopyable is there because the containers don't have copy > constructors due to certain issues using the library in > C++. Therefore, I'd like to better understand the implications of > this. > > For instance, in Python the copy constructor is often used to make > copy the entire container (as opposed to just rebinding > names). Presumably Boost.Python supports this using the C++ classes > copy constructor. This raises the questions... > > 1. How can I create an object to return to Python, containing an > instance of the C++ container, without removing > boost::noncopyable? (I need to do this to implement slicing too) > > This, I think, is roughly what is done in the Inheritance section of > the tutorial so I probably need something like the 'factory' > function. So, to reduce it to a simple copy-function example, the > following should be about right... > > Base* container::make_copy () > { > container *temp = new container (); > temp->do_copy (*this); > return temp; > } > > ... > > .def("make_copy", container::make_copy, > return_value_policy()) > > I think this should be right, but confidence is low. > > 2. How can I support the Python copy constructor without having a C++ > copy constructor. > > > > I'm using boost-1.30.2 with Python 2.2.3 and Visual Studio 7. > > Any advice would be appreciated. Thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Tue Sep 16 17:54:55 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 16 Sep 2003 16:54:55 +0100 Subject: [C++-sig] Reference leak in life_support.cpp Message-ID: I've been checking for reference leaks using python_d, and I think I've found one using return_internal_reference where the return value is a null pointer (or even just void). This gets returned to Python as Py_None, and there is a special case in life_support.cpp to handle it: if (nurse == Py_None) return incref(nurse); In my testing, this leaks a reference to Py_None, since the counter already got incremented in the boost::python::detail::none() call that originally introduced the Py_None pointer. This shows up as an increasing total ref count using python_d when invoking the following function: IntWrapper const *foo (IntWrapper const &i) { return 0; } via a Python extension module with def ("foo", foo, return_internal_reference<>()); e.g. >>> foo(IntWrapper(3)) [8453 refs] >>> foo(IntWrapper(3)) [8454 refs] >>> foo(IntWrapper(3)) [8455 refs] >>> foo(IntWrapper(3)) [8456 refs] >>> foo(IntWrapper(3)) [8457 refs] >>> foo(IntWrapper(3)) [8458 refs] [etc...] It also does the same for a function with void return type and return_internal_reference (OK, OK, I know that's weird, but it happened). http://mail.python.org/pipermail/c++-sig/2002-August/001940.html has some previous discussion on this issue. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From RaoulGough at yahoo.co.uk Tue Sep 16 18:16:48 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 16 Sep 2003 17:16:48 +0100 Subject: [C++-sig] return_internal_reference and implicitly_convertible danger Message-ID: Not sure if it's worth looking into this in any depth, but I've discovered that implicitly_convertible and return_internal_reference can combine in a nasty way. If I have a function exposed to Python like this: IntWrapper const *bar (IntWrapper const &i) { return &i; } // ... implicitly_convertible (); def ("bar", bar, return_internal_reference<>()); then calling bar(IntWrapper(3)) is OK, but bar(3) returns a dangling reference: >>> print bar(IntWrapper(3)) 3 >>> print bar(3) 1243312 I suspect there is a problem because the implicit conversion is happening in C++, and that object gets destroyed prematurely (maybe because the Python function call infrastructure doesn't have a reference to it). BTW, I'm not claiming that this client code should work! Then again, maybe there's an easy way to catch this in the library that I don't know about. Actual test code follows for completeness. #include #include #include #include #include #include struct IntWrapper { int mI; IntWrapper (int i) : mI (i) { } std::string repr () const { std::stringstream temp; temp << mI; return temp.str(); } }; IntWrapper const *bar (IntWrapper const &i) { return &i; } BOOST_PYTHON_MODULE (testint) { using namespace boost::python; implicitly_convertible (); class_ ("IntWrapper", init()) .def ("__repr__", &IntWrapper::repr); def ("bar", bar, return_internal_reference<>()); } -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Tue Sep 16 18:22:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 12:22:57 -0400 Subject: [C++-sig] Re: Reference leak in life_support.cpp References: Message-ID: Raoul Gough writes: > I've been checking for reference leaks using python_d, and I think > I've found one using return_internal_reference where the return value > is a null pointer (or even just void). This gets returned to Python as > Py_None, and there is a special case in life_support.cpp to handle it: > > if (nurse == Py_None) > return incref(nurse); > > In my testing, this leaks a reference to Py_None, since the counter > already got incremented in the boost::python::detail::none() call that > originally introduced the Py_None pointer. This shows up as an > increasing total ref count using python_d when invoking the following > function: > > IntWrapper const *foo (IntWrapper const &i) { > return 0; > } > > via a Python extension module with > > def ("foo", foo, return_internal_reference<>()); > > e.g. > >>>> foo(IntWrapper(3)) > [8453 refs] >>>> foo(IntWrapper(3)) > [8454 refs] >>>> foo(IntWrapper(3)) > [8455 refs] >>>> foo(IntWrapper(3)) > [8456 refs] >>>> foo(IntWrapper(3)) > [8457 refs] >>>> foo(IntWrapper(3)) > [8458 refs] > > [etc...] OK, good catch. Feel free to check in a patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Tue Sep 16 19:36:04 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 16 Sep 2003 18:36:04 +0100 Subject: [C++-sig] Re: Reference leak in life_support.cpp References: Message-ID: David Abrahams writes: > Raoul Gough writes: > >>>>> foo(IntWrapper(3)) >> [8453 refs] >>>>> foo(IntWrapper(3)) >> [8454 refs] >>>>> foo(IntWrapper(3)) >> [8455 refs] >>>>> foo(IntWrapper(3)) >> [8456 refs] >>>>> foo(IntWrapper(3)) >> [8457 refs] >>>>> foo(IntWrapper(3)) >> [8458 refs] >> >> [etc...] > > OK, good catch. Feel free to check in a patch. Done. Not that a Py_None reference leak is a drastic problem, but it did make anything running in python_d look like there was a real leak somewhere. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Tue Sep 16 21:15:03 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 15:15:03 -0400 Subject: [C++-sig] [Implementation] Calling wrapped functions, converters, policies Message-ID: I was recently trying to implement http://boost-consulting.com/boost/libs/python/todo.html#injected-constructors and ran into some issues with the way Boost.Python calls wrapped functions. As I began to explore boost/python/detail/caller.hpp and boost/python/detail/invoke.hpp, I realized that the things I wanted to do were very closely tied to some work Lijun Qin has been doing (http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1771145), and with the desired ability to allow converters to execute post-call processing actions. Since the impact of these change has the potential to be quite sweeping, I thought we should discuss the broad requirements here before I start implementing anything. Here are some things I think we need: 1. Per-call state. Example 1: Lijun Qin's patches decode incoming Python unicode object into ordinary Python strings in the Policies' precall function, and rely on the Policies object producing a modified version of the incoming Python arg tuple. Example 2: In implementing injected constructors I want to strip the incoming "self" argument before calling the inner factory function, then install the result in the self object. In both the examples above, we need to maintain a reference to the newly-constructed Python tuple so that we can decrement its reference count when the call completes. This state is "per-call", since there is a new tuple created each time the wrapped function is called. Right now we can maintain per-wrapped-function state in either of two objects: the function itself (when it's a function object with an operator()), or in the Policies object. For all practical purposes, though, that state has to be immutable. Consider a recursive wrapped function call; the inner call will wipe out any information stored in the Policies object during an outer call. Lijun Qin's patch gets around this by storing a std::stack of newly-constructed tuples in the Policies object, but not only is that cumbersome for the implementor, it doesn't interact well with multithreading. If the wrapped function call releases the interpreter lock and another thread returns, the top of the std::stack will contain the wrong argument tuple. What's needed is a way to get the per-call state onto the program stack. I can think of two main approaches: a. A copy of the Policies object is made on the stack and used during the function call; the copy can maintain its own state. An advantage of this approach is simplicity. A disadvantage is that you may for things you don't use: storage for per-call state in the wrapped function itself, and cycles for copying per-call state to the stack. b. The policies object has a init_state() function which produces a new state object of a possibly-different type. This doesn't have the disadvantages above, but costs complexity in several ways: i. The requirements on the Policies class become more complicated. It probably needs to have a nested ::state type. It's possible to get around the need for this typedef by passing the results of init_state() directly to a function template parameter (e.g. into invoke(...)), but that may force us to have a function call boundary at an undesirable place. ii. Policies composition may become much more complicated. How do you come up with the state object corresponding to several composed policies? You could use tuples... hmm, maybe this is a job for mpl::inherit_linearly. I'm leaning towards a. but I'm really not sure which one is best and would appreciate comments. 2. The ability to select a specialized from-Python conversion method for each argument. Right now, we can only select the to-Python conversion method for the result, but Luabind has shown the wisdom of being able to do the converse, and in fact Mike Rovner was just asking how we could implement Luabind's "adopt" policy for stealing ownership of C++ objects held by auto_ptr. Right now, an MPL argument signature sequence gets passed to caller_arity::impl, and the elements of that (except the first, which is the return type) fully determine the _static_ type (see below) of the from-Python argument converters. We need a way to customize the type of the argument converters which are actually used for each argument. I think Luabind has a solution for this. I can imagine several similar approaches, so I don't think this is hard. 3. Dynamic converter per-call state and postcall actions. [Refresher: The standard from-Python converter has a static type that provides per-call storage for an implementation which is dynamically-selected based on the source Python object. If the target argument type is a value or a const reference, the per-call storage is enough to construct an object of the target type, and either rvalue or lvalue converters can be used. Otherwise, a matching lvalue converter is required and the static converter type contains storage for a pointer to the target] It is sometimes desirable to allow a particular dynamically-selected from-python converter to use additional state. For example, people have asked that they be able to pass a Python list where a std::vector& argument is expected, modify the vector, and have the Python list automatically updated when the function call returns. Because this converter requires a std::vector lvalue, it doesn't contain storage for the vector whose lifetime needs to span the length of the call. Furthermore, if the call completes successfully, the source list must be updated to reflect the new contents of the vector. I propose that whichever state model is chosen in item 1 above, the state contains a chain of dynamically-allocated polymorphic postcall objects, and that dynamic converter implementations are passed a reference to that chain so that they can register new postcall actions. The postcall actions are invoked when the call completes successfully, and are unconditionally deleted at the end of the call. One thing I'm still not clear about is whether a converter's convertible() function need access to that chain. 4. The ability to release the Python interpreter lock during the wrapped call based on the choice of Policies. If releasing the lock becomes the default behavior, it's important that it be automatically disabled when the wrapped function is handling python::object or any of its derived classes. The release must happen inside the invoke(...) function, or at least, if the implementation changes, after all converters have completed their work, since the lock must be held while any reference counts are changed. This suggests that there is an inner layer of action needed, and it should probably be generalized. So the flow looks something like: caller::operator()( PyObject* args, PyObject* kw) Create per-call state on stack args,kw = state.precall(args,kw) For each argument Create converter If not convertible, fail overload resolution For each converter c c.convert(state) // optionally register postcall actions inner action (release interpreter lock) PyObject* result = invoke wrapped F with converted arguments inner "un-action" (acquire interpreter lock) if any postcall actions stored, execute them return state.postcall(result, args, kw) I'm not sure how this interacts with Daniel's recursive "best overload" resolution. Comments? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Sep 16 21:55:08 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 15:55:08 -0400 Subject: [C++-sig] Re: sub modules + test\submod_subclass_api.cpp doesn't compile References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B17@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Hi. I am looking for solution to divide big module > into small sub modules. I found "submod_subclass_api.cpp" > file in test folder, but it seems that this file could not > be compiled. Compiler can not find definition of boost::python::module. > > I have 2 question: it seems that boost::python::module existed for some time > but then disappeared - why ? It's a long story. You can read some of it here: http://mail.python.org/pipermail/c++-sig/2002-July/001748.html > And second one how can I do it using boost::python > and not native Python C API? There's no way to do it without touching the Python C API. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Sep 16 23:40:38 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 16 Sep 2003 17:40:38 -0400 Subject: [C++-sig] Re: Converting a C++ object to python References: <000a01c37add$702686c0$0400a8c0@mithrandir> Message-ID: Raoul Gough writes: G> "Ron Penton" writes: > >>>If you catch a boost::python::error_already_set in C++, I guess you >>>can get more information by calling PyErr_Print(), which should dump a >>>standard Python traceback on stderr. At a guess, you're getting a >>>Python TypeError from the object constructor, because it doesn't have >>>a converter for booga *. BTW, why are you passing a pointer to b, >>>instead of a reference? >> >> PyErr_Print says "TypeError: No Python class registered for C++ class class >> booga", >> which confirms what you thought. > > Well, not really - I would have thought that there is a problem with > booga * (i.e. pointer to booga), but from your error message, that is > not the case. I don't suppose it makes any difference to use b instead > of &b then? > >> >> The part that confuses me is the converter part; I'm not quite sure how to >> go about creating one. All of the examples I can find go about the creation >> of the python types manually, rather than using the class_ definition, so >> I'm really unsure of where to go from here. > > Well, we've now snipped the original code, but looking back at it from > your original post: > >> class booga{public: >> booga() : a( 0 ) {} int a; void >> looga() { a = a + 10; cout << a << endl; }}; >> BOOST_PYTHON_MODULE( wrap ){ class_( "booga" >> ) .def( "looga", &booga::looga >> );} >> int main(){ Py_Initialize(); >> >> PyImport_AppendInittab( >> "wrap", initwrap ); >> booga b; >> object obj( &b ); > > the class_ constructor should handle all of the converter > registration. However, I know that at least *some* of the registration > is done at run-time. All of it, except for some built-in to-python conversions like those for int, char const*, etc. -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike at nospam.com Wed Sep 17 00:44:16 2003 From: mike at nospam.com (Mike Rovner) Date: Tue, 16 Sep 2003 15:44:16 -0700 Subject: [C++-sig] Re: discard reference References: Message-ID: David Abrahams wrote: > get the polymorphism you want (laboriously) by using > > implicitly_convertible,std::auto_ptr > >(); > > for all the appropriate Derived classes. Thanks, David. It works perfectly. From pierre.barbier at cirad.fr Wed Sep 17 12:27:55 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 17 Sep 2003 12:27:55 +0200 Subject: [C++-sig] How to add an __init__ function ? Message-ID: <3F68372B.7070808@cirad.fr> I want to add an init function which is not a contructor of the original class. I export a C++ container and I want to be able to import any sequence object, so I created a (working) function "from_list(Container*, boost::pyhon::object obj)" which iterates over every elements of obj if an iterator can be created. But, if I define the '__init__' function with: .def ("__init__", from_list) .def(init<>()) And I try this in python: >>> Container([1,2,3]) I get the error: """ Boost.Python.ArgumentError: Python argument types in Container.__init__(Container, list) did not match C++ signature: __init__(_object*) __init__(Container*, boost::python::api::object) __init__(_object*) """ It seems to me that the second __init__ method just should be ok ... -- 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 From mike.thompson at day8.com.au Wed Sep 17 14:28:38 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Wed, 17 Sep 2003 22:28:38 +1000 Subject: [C++-sig] Re: How to add an __init__ function ? References: <3F68372B.7070808@cirad.fr> Message-ID: "Pierre Barbier de Reuille" wrote: > I want to add an init function which is not a contructor of the original > class. I export a C++ container and I want to be able to import any > sequence object, so I created a (working) function > "from_list(Container*, boost::pyhon::object obj)" which iterates over > every elements of obj if an iterator can be created. But, if I define > the '__init__' function with: > > .def ("__init__", from_list) > .def(init<>()) > > And I try this in python: > > >>> Container([1,2,3]) > > I get the error: > """ > Boost.Python.ArgumentError: Python argument types in > Container.__init__(Container, list) > did not match C++ signature: > __init__(_object*) > __init__(Container*, boost::python::api::object) > __init__(_object*) > """ > > It seems to me that the second __init__ method just should be ok ... > AIUI, David Abrahams refers to these as "injected constructors" and they're not possible right now. See the TODO list item: http://boost-consulting.com/boost/libs/python/todo.html#injected-constructors Then again, their implementation might be available sometime soon-ish because, when viewed through gmane.comp.python.c++, in the thread immediately preceding this one, David explains that he has begun work on the potentially sweeping changes involved in this TODO item. See the thread with subject "[Implementation] Calling wrapped functions, converters,policies" -- Mike From dave at boost-consulting.com Wed Sep 17 15:17:27 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 17 Sep 2003 09:17:27 -0400 Subject: [C++-sig] Re: How to add an __init__ function ? References: <3F68372B.7070808@cirad.fr> Message-ID: "Mike Thompson" writes: > "Pierre Barbier de Reuille" wrote: >> I want to add an init function which is not a contructor of the original >> class. I export a C++ container and I want to be able to import any >> sequence object, so I created a (working) function >> "from_list(Container*, boost::pyhon::object obj)" which iterates over >> every elements of obj if an iterator can be created. But, if I define >> the '__init__' function with: >> >> .def ("__init__", from_list) >> .def(init<>()) >> >> And I try this in python: >> >> >>> Container([1,2,3]) >> >> I get the error: >> """ >> Boost.Python.ArgumentError: Python argument types in >> Container.__init__(Container, list) >> did not match C++ signature: >> __init__(_object*) >> __init__(Container*, boost::python::api::object) >> __init__(_object*) >> """ >> >> It seems to me that the second __init__ method just should be ok ... >> > > AIUI, David Abrahams refers to these as "injected constructors" and they're not > possible right now. The "standard workaround" is to build a virtual function dispatcher class (as in http://tinyurl.com/no5r) and add your new constructors there. -- Dave Abrahams Boost Consulting www.boost-consulting.com From pierre.barbier at cirad.fr Wed Sep 17 18:17:35 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 17 Sep 2003 18:17:35 +0200 Subject: [C++-sig] Re: How to add an __init__ function ? In-Reply-To: References: <3F68372B.7070808@cirad.fr> Message-ID: <3F68891F.6010907@cirad.fr> David Abrahams wrote: >The "standard workaround" is to build a virtual function dispatcher >class (as in http://tinyurl.com/no5r) and add your new constructors there. > > > Yes, it work very fine now. I just needed to import the constructors of the base class, but template does it for me now (at least if there is no more than two args ... but it's the case for STL containers). Thanks, Pierre -- 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 From pierre.barbier at cirad.fr Wed Sep 17 18:22:15 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 17 Sep 2003 18:22:15 +0200 Subject: [C++-sig] Re: How to add an __init__ function ? In-Reply-To: References: <3F68372B.7070808@cirad.fr> Message-ID: <3F688A37.3020500@cirad.fr> I have now another question about __init__ method. I've read in the previous mails about the existence of the raw_function function in order to create a function using the *args and **keywords python stuff. But how can I do the same thing with __init__ ? Thanks, Pierre -- 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 From gdoughtie at anim.dreamworks.com Wed Sep 17 18:43:12 2003 From: gdoughtie at anim.dreamworks.com (Gavin Doughtie) Date: Wed, 17 Sep 2003 09:43:12 -0700 Subject: [C++-sig] sourceforge cvs down and boost mirror out of date? Message-ID: <3F688F20.1060203@anim.dreamworks.com> I cannot seem to do a pserver login to the sourceforge CVS, though connecting to boostconsulting works fine. However, the sources at boostconsulting seem quite out of date compared to those I can see form sourceforge's web interface. I'm downloading the boostconsulting .bz2 now. Is anybody else experiencing problems of this sort? -- Gavin Doughtie DreamWorks SKG (818) 695-3821 From hhakula at math.hut.fi Thu Sep 18 13:28:31 2003 From: hhakula at math.hut.fi (Harri Hakula) Date: Thu, 18 Sep 2003 14:28:31 +0300 Subject: [C++-sig] Improvements on Mac OS X In-Reply-To: <1063411034.1803.43.camel@illuvatar> Message-ID: <3B29BADD-E9CB-11D7-B7D8-000393C34364@math.hut.fi> Good news: With the very latest gcc from Apple everything compiles without errors. Bad news: The problems in running the examples persist. For one fleeting moment I had everything in the example-directory up and running... Then I changed something :-( and broke my setup! However, I am confident that somewhat more knowledgeable can figure out the right flags for linking actions. (Yes, I was playing -undefined suppress -flat_namespace games when my house of cards fell apart.) Cheers, Harri Setup: [naghdi:local/src/boost] hhakula% uname -a Darwin naghdi.hut.fi 6.6 Darwin Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC Power Macintosh powerpc [naghdi:local/src/boost] hhakula% gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1493) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [naghdi:local/src/boost] hhakula% python2.3 Python 2.3 (#1, Sep 18 2003, 11:31:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. From Vincenzo.Innocente at cern.ch Thu Sep 18 16:45:43 2003 From: Vincenzo.Innocente at cern.ch (Vincenzo Innocente) Date: Thu, 18 Sep 2003 16:45:43 +0200 (MEST) Subject: [C++-sig] pyste not supporting return_opaque_pointer Message-ID: it looks to me that pyste (downloaded together with boost 1.30.2) does not support opaque_pointers.. is there a more recent version that does support them? regards, vincenzo From Jason.Sibthorpe at aculab.com Thu Sep 18 16:50:24 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Thu, 18 Sep 2003 15:50:24 +0100 Subject: [C++-sig] pyste not supporting return_opaque_pointer Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B710F@saturn.aculab.com> have you tried set_policy(func, return_value_policy('return_opaque_pointer')) Note the stringification - this has been fixed in cvs I believe It works for me Jason -----Original Message----- From: Vincenzo Innocente [mailto:Vincenzo.Innocente at cern.ch] Sent: 18 September 2003 15:46 To: c++-sig at python.org Subject: [C++-sig] pyste not supporting return_opaque_pointer it looks to me that pyste (downloaded together with boost 1.30.2) does not support opaque_pointers.. is there a more recent version that does support them? regards, vincenzo _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason.Sibthorpe at aculab.com Thu Sep 18 16:56:53 2003 From: Jason.Sibthorpe at aculab.com (Jason.Sibthorpe at aculab.com) Date: Thu, 18 Sep 2003 15:56:53 +0100 Subject: [C++-sig] pyste not supporting return_opaque_pointer Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B7110@saturn.aculab.com> ~/src/boost_cvs/boost/libs/python/pyste/src/Pyste/pyste.py def CreateContext(): should contain the following line context['return_opaque_pointer'] = return_opaque_pointer I am using the a version from the repository, but I think it works with 1.30.2 with the above fix - don't quote me on that :-) -Jason -----Original Message----- From: Vincenzo Innocente [mailto:Vincenzo.Innocente at cern.ch] Sent: 18 September 2003 15:46 To: c++-sig at python.org Subject: [C++-sig] pyste not supporting return_opaque_pointer it looks to me that pyste (downloaded together with boost 1.30.2) does not support opaque_pointers.. is there a more recent version that does support them? regards, vincenzo _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwgk at yahoo.com Thu Sep 18 17:50:48 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 08:50:48 -0700 (PDT) Subject: [C++-sig] Improvements on Mac OS X In-Reply-To: <3B29BADD-E9CB-11D7-B7D8-000393C34364@math.hut.fi> Message-ID: <20030918155048.65305.qmail@web20210.mail.yahoo.com> --- Harri Hakula wrote: > Good news: With the very latest gcc from Apple everything compiles > without errors. > > Bad news: The problems in running the examples persist. In my experience the best long-term strategy is to work with the latest gcc from gcc.gnu.org and to report bugs to the gcc developers directly. Unlike Apple's gcc team, the gcc developers actually respond and fix problems. Eventually these fixes end up in Apple's distribution. I stopped reporting bugs as soon as all our code ran... somehow. I know there are more problems, but I cannot afford spending more time on this right now. If you get stomped by a bug that I managed to work around somehow, go back to the gcc.gnu.org version, verify that it also exists there and report it. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From Vincenzo.Innocente at cern.ch Thu Sep 18 18:21:32 2003 From: Vincenzo.Innocente at cern.ch (Vincenzo Innocente) Date: Thu, 18 Sep 2003 18:21:32 +0200 (MEST) Subject: [C++-sig] pyste not supporting return_opaque_pointer Message-ID: stringification works, even if Context is not defined... thanks, vincenzo Message: 6 Date: Thu, 18 Sep 2003 15:50:24 +0100 From: Jason.Sibthorpe at aculab.com Subject: RE: [C++-sig] pyste not supporting return_opaque_pointer To: c++-sig at python.org Message-ID: <8C9A566C643ED6119E8900A0C9DE297A020B710F at saturn.aculab.com> Content-Type: text/plain; charset="iso-8859-1" have you tried set_policy(func, return_value_policy('return_opaque_pointer')) Note the stringification - this has been fixed in cvs I believe It works for me Jason From rwgk at yahoo.com Thu Sep 18 20:01:44 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 11:01:44 -0700 (PDT) Subject: [C++-sig] [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <20030918180144.45663.qmail@web20203.mail.yahoo.com> --- David Abrahams wrote: > Example 2: In implementing injected constructors I want to strip > the incoming "self" argument before calling the inner factory > function, then install the result in the self object. I am thrilled by the prospect of having this feature :) > I'm leaning towards a. but I'm really not sure which one is best > and would appreciate comments. To repeat my mantra: I very much prefer the simpler approach even if it incurs a runtime penalty. If crossing the language boundary is the rate-limiting step the design is fundamentally wrong anyway. > For example, people have asked that they be able to pass a Python > list where a std::vector& argument is expected, modify the > vector, and have the Python list automatically updated when the > function call returns. Because this converter requires a > std::vector lvalue, it doesn't contain storage for the vector > whose lifetime needs to span the length of the call. Furthermore, > if the call completes successfully, the source list must be updated > to reflect the new contents of the vector. Ah, my "most wanted" feature. > Comments? Yes. There is another most wanted feature on my list: automatic integration of documentation embedded in C++ code. I.e. I'd like to see my Doxygen documentation appear merged with the Python documentation. It seems to me that no amount of meta-programming wizardry will be able to do this. My current state of mind is that gcc-xml/Pyste could potentially provide a solution. Bruno, does gcc-xml preserve the comment blocks in C++ code? If not, could it be made to? Jumping ahead: 1. I find myself quite often adding a thin Python layer on top of the raw Boost.Python bindings, for example to get keyword support without increasing compile times and object code size, or to inject additional methods. 2. To me the popularity of Pyste shows that this is the way of the future. This leads me to drastic suggestions: - Treat the entire C++ layer of the Python-based wrapping system as an implementation detail. - Let the user direct the wrapping process exclusively via a Pyste-style pure Python script. - Simplify the Boost.Python code base by scaling down the amount of work that is done with meta-programming techniques. - Always generate an intermediate Python layer with full, automatic keyword support and a copy of the documentation embedded in the C++ code. - Use SCons (pure Python again) to control the generation of all intermediate files and the management of all dependencies. My suggestions are partially motivated by the belief that some of the problems outlined in David's original posting will be much easier to deal with in a framework as outline above. The critical ingredient that makes this possible is gcc-xml, which provides the tool for analyzing the C++ code to be wrapped "from outside" instead of "from inside" using compile-time introspection facilities that were clearly not designed for this purpose. Ralf P.S.: Is this the same person that tried to talk Bruno out of writing Pyste? :) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From RaoulGough at yahoo.co.uk Thu Sep 18 20:12:20 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Thu, 18 Sep 2003 19:12:20 +0100 Subject: [C++-sig] Reworking of indexing suite Message-ID: I've made some substantial progress on refactoring the indexing suite. The new code passes all but one of the existing tests (more details below). It also splits the proxy facility into a standalone (C++) container wrapper, and this provides Python-compatible slices in a wider range of situations. e.g. slice = c[1:3] c[2].mutate() # Some change to object assert (slice[1] == c[2]) # Slice refers to same object The one test that it doesn't pass is assigning a single element to a slice, e.g.: c[1:3] = 4 Standard Python lists also don't support this. All of the new code is in the boost-sandbox cvs under boost-sandbox/boost/python/suite/indexing and needs a lot of further testing (in particular, with compilers other than gcc). Any help and/or comments much appreciated. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Thu Sep 18 20:32:11 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 18 Sep 2003 14:32:11 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <20030918180144.45663.qmail@web20203.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> Example 2: In implementing injected constructors I want to strip >> the incoming "self" argument before calling the inner factory >> function, then install the result in the self object. > > I am thrilled by the prospect of having this feature :) Well, I ran into problems implementing it, but I learned a lot about what's really needed in the process. >> I'm leaning towards a. but I'm really not sure which one is best >> and would appreciate comments. > > To repeat my mantra: I very much prefer the simpler approach even if it incurs > a runtime penalty. If crossing the language boundary is the rate-limiting step > the design is fundamentally wrong anyway. > >> For example, people have asked that they be able to pass a Python >> list where a std::vector& argument is expected, modify the >> vector, and have the Python list automatically updated when the >> function call returns. Because this converter requires a >> std::vector lvalue, it doesn't contain storage for the vector >> whose lifetime needs to span the length of the call. Furthermore, >> if the call completes successfully, the source list must be updated >> to reflect the new contents of the vector. > > Ah, my "most wanted" feature. Yes, that one. >> Comments? > > Yes. There is another most wanted feature on my list: automatic integration of > documentation embedded in C++ code. I.e. I'd like to see my Doxygen > documentation appear merged with the Python documentation. It seems to me that > no amount of meta-programming wizardry will be able to do this. Not so; you're just thinking of the wrong meta-programming tools ;-> > My current state of mind is that gcc-xml/Pyste could potentially > provide a solution. Bruno, does gcc-xml preserve the comment blocks > in C++ code? If not, could it be made to? That's meta-programming, too ;-> > Jumping ahead: > > 1. I find myself quite often adding a thin Python layer on top of > the raw Boost.Python bindings, for example to get keyword support > without increasing compile times and object code size, or to inject > additional methods. > > 2. To me the popularity of Pyste shows that this is the way of the future. But Pyste doesn't do it that way. > This leads me to drastic suggestions: > > - Treat the entire C++ layer of the Python-based wrapping system as an > implementation detail. > > - Let the user direct the wrapping process exclusively via a Pyste-style pure > Python script. > > - Simplify the Boost.Python code base by scaling down the amount of work that > is done with meta-programming techniques. > > - Always generate an intermediate Python layer with full, automatic keyword > support and a copy of the documentation embedded in the C++ code. These aren't so drastic; I've been saying things like this for several months. However, you might ask yourself "why not just use SWIG?" > - Use SCons (pure Python again) to control the generation of all > intermediate files and the management of all dependencies. > > My suggestions are partially motivated by the belief that some of > the problems outlined in David's original posting will be much > easier to deal with in a framework as outline above. Actually, I don't think it will help with most of the issues I raised. These are fundamental design problems that will arise no matter how you generate the code. > The critical ingredient that makes this possible is gcc-xml, which > provides the tool for analyzing the C++ code to be wrapped "from > outside" instead of "from inside" using compile-time introspection > facilities that were clearly not designed for this purpose. > > Ralf > > P.S.: Is this the same person that tried to talk Bruno out of > writing Pyste? :) -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 18 20:33:22 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 18 Sep 2003 14:33:22 -0400 Subject: [C++-sig] Re: Reworking of indexing suite References: Message-ID: Raoul Gough writes: > I've made some substantial progress on refactoring the indexing > suite. The new code passes all but one of the existing tests (more > details below). It also splits the proxy facility into a standalone > (C++) container wrapper, and this provides Python-compatible slices in > a wider range of situations. e.g. > > slice = c[1:3] > c[2].mutate() # Some change to object > assert (slice[1] == c[2]) # Slice refers to same object > > The one test that it doesn't pass is assigning a single element to a > slice, e.g.: > > c[1:3] = 4 > > Standard Python lists also don't support this. > > All of the new code is in the boost-sandbox cvs under > boost-sandbox/boost/python/suite/indexing and needs a lot of further > testing (in particular, with compilers other than gcc). Any help > and/or comments much appreciated. That's really exciting! Great work! -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Thu Sep 18 21:27:32 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 12:27:32 -0700 (PDT) Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <20030918192732.54534.qmail@web20204.mail.yahoo.com> --- David Abrahams wrote: > These aren't so drastic; I've been saying things like this for > several months. However, you might ask yourself "why not just use > SWIG?" Maybe because it is not written in Python? Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From dave at boost-consulting.com Thu Sep 18 21:58:19 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 18 Sep 2003 15:58:19 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <20030918192732.54534.qmail@web20204.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> These aren't so drastic; I've been saying things like this for >> several months. However, you might ask yourself "why not just use >> SWIG?" > > Maybe because it is not written in Python? Ah, a Python partisan! -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Thu Sep 18 22:03:14 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 13:03:14 -0700 (PDT) Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <20030918200314.71792.qmail@web20208.mail.yahoo.com> --- David Abrahams wrote: > "Ralf W. Grosse-Kunstleve" writes: > > > --- David Abrahams wrote: > >> These aren't so drastic; I've been saying things like this for > >> several months. However, you might ask yourself "why not just use > >> SWIG?" > > > > Maybe because it is not written in Python? > > Ah, a Python partisan! You have to believe in something! Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From s_sourceforge at nedprod.com Thu Sep 18 22:59:32 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 18 Sep 2003 21:59:32 +0100 Subject: [C++-sig] [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <20030918180144.45663.qmail@web20203.mail.yahoo.com> References: Message-ID: <3F6A2AC4.5458.5A35FE8@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Sep 2003 at 11:01, Ralf W. Grosse-Kunstleve wrote: > To repeat my mantra: I very much prefer the simpler approach even if > it incurs a runtime penalty. If crossing the language boundary is the > rate-limiting step the design is fundamentally wrong anyway. I would go further and say that truly obscene implementation is permitted if the end-user's life is made easier. This is the point of a library IMHO. > Yes. There is another most wanted feature on my list: automatic > integration of documentation embedded in C++ code. I.e. I'd like to > see my Doxygen documentation appear merged with the Python > documentation. It seems to me that no amount of meta-programming > wizardry will be able to do this. My current state of mind is that > gcc-xml/Pyste could potentially provide a solution. Bruno, does > gcc-xml preserve the comment blocks in C++ code? If not, could it be > made to? Yes I believe it does. And I strongly second this idea though I'd suggest the python documentation could optionally be a http URL to the relevent doxygen docs. No point making the python files huge if they don't need to be. > 2. To me the popularity of Pyste shows that this is the way of the > future. Agreed. Me personally, and I think most users of Boost.Python will agree, would feel that they don't care how Boost.Python works. They simply want to feed something their existing C++ source and a python loadable DLL is spat out. The less arsing around with config files and boost.python idiosyncracies the better. > - Let the user direct the wrapping process exclusively via a > Pyste-style pure Python script. I'm a great believer in onion style design - layers of functionality so if the top layer won't do what you want, you can hack the lower layers to force the issue. > - Use SCons (pure Python again) to control the generation of all > intermediate files and the management of all dependencies. I'm increasingly using python to manage my project, so this looks good. > My suggestions are partially motivated by the belief that some of the > problems outlined in David's original posting will be much easier to > deal with in a framework as outline above. The critical ingredient > that makes this possible is gcc-xml, which provides the tool for > analyzing the C++ code to be wrapped "from outside" instead of "from > inside" using compile-time introspection facilities that were clearly > not designed for this purpose. GCC-XML is broken in some areas, but I'm sure its bugs will be fixed with time. My only concern is that GCC is overly conservative in its interpretation of the C++ standard - code which MSVC permits (and I would permit) GCC barfs on. Lastly, anything to reduce compile times would be a boon. I have a dual Athlon 1700, yet to compile a full set of bindings will take twenty hours or so. This is unacceptable. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2octMEcvDLFGKbPEQLSZgCfRzHT0awZRzUWzeH53397rtqvF7gAn2+l slloFuqwKdg3yvPoS3NnXOJq =aDc3 -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Thu Sep 18 23:04:40 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 18 Sep 2003 22:04:40 +0100 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6A2BF8.16467.5A8154A@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Sep 2003 at 14:32, David Abrahams wrote: > > - Always generate an intermediate Python layer with full, automatic > > keyword support and a copy of the documentation embedded in the C++ > > code. > > These aren't so drastic; I've been saying things like this for > several months. However, you might ask yourself "why not just use > SWIG?" Bottom-up projects like SWIG easily get success with simple C++ but will find it geometrically harder to add increasingly complex C++. I went with boost.python because it seemed to me to be naturally more easily extendable for advanced C++ features. Also, pyste looked very attractive whereas SWIG requires custom written interface files which would take me weeks to write initially and a high quantity of maintanence time whenever the underlying library was changed (often). Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2od6cEcvDLFGKbPEQImNgCgugwOvXnXyNv+W3qp0lPQGClm1D8An2t2 pLQaXqvcE6yS1ejMxTQXD8zS =w+J/ -----END PGP SIGNATURE----- From dave at boost-consulting.com Thu Sep 18 23:32:11 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 18 Sep 2003 17:32:11 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6A2BF8.16467.5A8154A@localhost> Message-ID: "Niall Douglas" writes: > On 18 Sep 2003 at 14:32, David Abrahams wrote: > >> > - Always generate an intermediate Python layer with full, automatic >> > keyword support and a copy of the documentation embedded in the C++ >> > code. >> >> These aren't so drastic; I've been saying things like this for >> several months. However, you might ask yourself "why not just use >> SWIG?" > > Bottom-up projects like SWIG easily get success with simple C++ but > will find it geometrically harder to add increasingly complex C++. I > went with boost.python because it seemed to me to be naturally more > easily extendable for advanced C++ features. Also, pyste looked very > attractive whereas SWIG requires custom written interface files which > would take me weeks to write initially and a high quantity of > maintanence time whenever the underlying library was changed (often). What's the difference between custom-written interface files and custom-written Pyste scripts? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Thu Sep 18 23:33:01 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 18 Sep 2003 17:33:01 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6A2AC4.5458.5A35FE8@localhost> Message-ID: "Niall Douglas" writes: > On 18 Sep 2003 at 11:01, Ralf W. Grosse-Kunstleve wrote: > >> To repeat my mantra: I very much prefer the simpler approach even if >> it incurs a runtime penalty. If crossing the language boundary is the >> rate-limiting step the design is fundamentally wrong anyway. > > I would go further and say that truly obscene implementation is > permitted if the end-user's life is made easier. This is the point of > a library IMHO. The complexity I was talking about would only show up in the implementation. These are implementation details. >> 2. To me the popularity of Pyste shows that this is the way of the >> future. > > Agreed. Me personally, and I think most users of Boost.Python will > agree, would feel that they don't care how Boost.Python works. They > simply want to feed something their existing C++ source and a python > loadable DLL is spat out. The less arsing around with config files > and boost.python idiosyncracies the better. > >> - Let the user direct the wrapping process exclusively via a >> Pyste-style pure Python script. > > I'm a great believer in onion style design - layers of functionality > so if the top layer won't do what you want, you can hack the lower > layers to force the issue. > >> - Use SCons (pure Python again) to control the generation of all >> intermediate files and the management of all dependencies. > > I'm increasingly using python to manage my project, so this looks > good. I'd love to commence such an effort. It seems fairly obvious to me that it'd require funding, though. >> My suggestions are partially motivated by the belief that some of the >> problems outlined in David's original posting will be much easier to >> deal with in a framework as outline above. The critical ingredient >> that makes this possible is gcc-xml, which provides the tool for >> analyzing the C++ code to be wrapped "from outside" instead of "from >> inside" using compile-time introspection facilities that were clearly >> not designed for this purpose. > > GCC-XML is broken in some areas, but I'm sure its bugs will be fixed > with time. My only concern is that GCC is overly conservative in its > interpretation of the C++ standard - code which MSVC permits (and I > would permit) GCC barfs on. Actually it's the opposite. Those areas where GCC restricts what you can do but MSVC does not are not open to interpretation: GCC gets it right and MSVC gets it wrong. In fact, in some of the areas where different interpretations of the standard are possible (e.g. Koenig Lookup), GCC is IMO far too liberal, which breaks otherwise correct code. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Thu Sep 18 23:53:04 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 18 Sep 2003 22:53:04 +0100 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6A3750.1963.5D4624B@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Sep 2003 at 17:33, David Abrahams wrote: > > GCC-XML is broken in some areas, but I'm sure its bugs will be fixed > > with time. My only concern is that GCC is overly conservative in its > > interpretation of the C++ standard - code which MSVC permits (and I > > would permit) GCC barfs on. > > Actually it's the opposite. Those areas where GCC restricts what you > can do but MSVC does not are not open to interpretation: GCC gets it > right and MSVC gets it wrong. In fact, in some of the areas where > different interpretations of the standard are possible (e.g. Koenig > Lookup), GCC is IMO far too liberal, which breaks otherwise correct > code. I think one can approach this from both angles then. I personally had found GCC to barf on code MSVC7.1 is happy with, but then I write and debug on MSVC7.1 first and then compile on GCC. If you tend to go the other way round, you'd probably find it the other way. My main bugbear with GCC is it forces const temporaries. This makes destructive copy construction semantics severely castrated, so much so you usually must #ifdef hack in a copy constructor taking a const reference just on GCC :( I know all the usual arguments about temporaries should be const. I strongly disagree. C++ is all about giving plenty of rope to the programmer to hang themselves with where that rope /could/ be used for something useful and no other better way is available for doing it. And destructive copy construction is clearly implied when it takes a non-const reference. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2opQMEcvDLFGKbPEQItUgCgm0Mb4VLNpHGNWhHQBoX2zl1LzbIAoJS0 RS0OxLUrEzjk8bZPX8ICiJLM =mjoq -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Thu Sep 18 23:58:24 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 18 Sep 2003 22:58:24 +0100 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6A3890.26190.5D944A8@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Sep 2003 at 17:32, David Abrahams wrote: > > Bottom-up projects like SWIG easily get success with simple C++ but > > will find it geometrically harder to add increasingly complex C++. I > > went with boost.python because it seemed to me to be naturally more > > easily extendable for advanced C++ features. Also, pyste looked very > > attractive whereas SWIG requires custom written interface files > > which would take me weeks to write initially and a high quantity of > > maintanence time whenever the underlying library was changed > > (often). > > What's the difference between custom-written interface files and > custom-written Pyste scripts? pyste scripts are way, way shorter. SWIG interface files are a simplified duplicate of the C++ header - that IMHO is stupid because every time the header file changes, you must mirror the changes in the SWIG interface file. Way I've set it up, I have a python script which inspects the C++ project and generates lots of pyste files using another config file written in python which customises pyste config file generation for each C++ header file. Then pyste spits out boost.python wrappers. Then, theoretically, boost.python compiles into a DLL. This way the C++ project can dramatically change, and all I need to alter at most is the customisation per header config file and often I don't need to alter anything at all. Very sweet for maintanence costs. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2oqgMEcvDLFGKbPEQJH1gCgl9ZktjK0CkOOsSBOgG+XwYD2P/kAmwbn M0p6etOu8xVByk8m/3trMrWG =0DmR -----END PGP SIGNATURE----- From rwgk at yahoo.com Fri Sep 19 00:04:25 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 15:04:25 -0700 (PDT) Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <20030918220425.11308.qmail@web20207.mail.yahoo.com> --- David Abrahams wrote: > What's the difference between custom-written interface files and > custom-written Pyste scripts? Can you have if statements, loops and subroutines in SWIG interface files, or importable modules that concentrate frequently used functionality? Also, how do the C++ parsers in g++ and SWIG compare? Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From mike at nospam.com Fri Sep 19 02:04:45 2003 From: mike at nospam.com (Mike Rovner) Date: Thu, 18 Sep 2003 17:04:45 -0700 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6A2AC4.5458.5A35FE8@localhost> Message-ID: Niall Douglas wrote: > Lastly, anything to reduce compile times would be a boon. I have a > dual Athlon 1700, yet to compile a full set of bindings will take > twenty hours or so. This is unacceptable. I'm happy with precompiled headers. They reduced my compilation time at least tenfold. MSVC7.1, P4 2.4GHz So IMHO they worth give them a try. Mike From s_sourceforge at nedprod.com Fri Sep 19 02:07:44 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 19 Sep 2003 01:07:44 +0100 Subject: [C++-sig] AllFromHeader() in cvs pyste broken? Message-ID: <3F6A56E0.21690.402AA2@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just inserted a manual specification for import and it works fine. Is AllFromHeader() broken? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2pI1MEcvDLFGKbPEQIGMACgoHvIMNd85EwqyZs+rDaizZZwLfQAoJlZ ADUw7RBk5zWYVf2SeRkPIbFw =JIR2 -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Fri Sep 19 02:15:24 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 19 Sep 2003 01:15:24 +0100 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6A58AC.28973.472FF0@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18 Sep 2003 at 17:04, Mike Rovner wrote: > Niall Douglas wrote: > > Lastly, anything to reduce compile times would be a boon. I have a > > dual Athlon 1700, yet to compile a full set of bindings will take > > twenty hours or so. This is unacceptable. > > I'm happy with precompiled headers. They reduced my compilation time > at least tenfold. MSVC7.1, P4 2.4GHz > > So IMHO they worth give them a try. They cause misbehaviour on my large & complex C++ project unfortunately :( Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2pKncEcvDLFGKbPEQKe/QCdGHZGgr947z9Ul2QJq6z7bMr2bbQAnA7e qtv6zx3Ugn5Fsw1q/DYPWm5+ =Y37m -----END PGP SIGNATURE----- From nicodemus at globalite.com.br Fri Sep 19 02:52:59 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Thu, 18 Sep 2003 21:52:59 -0300 Subject: [C++-sig] AllFromHeader() in cvs pyste broken? In-Reply-To: <3F6A56E0.21690.402AA2@localhost> References: <3F6A56E0.21690.402AA2@localhost> Message-ID: <3F6A536B.9020903@globalite.com.br> Hi Niall, Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Just inserted a manual specification for import and it works fine. > >Is AllFromHeader() broken? > > Unfortunatelly, yes. I still didn't got time to fix it (actually, it needs a new implementation with the new system)... heck, I didn't have enough time to read my emails lately! 8( I will anounce here when I get time to get around it. Regards, Nicodemus. From nicodemus at globalite.com.br Fri Sep 19 02:54:20 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Thu, 18 Sep 2003 21:54:20 -0300 Subject: [C++-sig] [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <20030918180144.45663.qmail@web20203.mail.yahoo.com> References: <20030918180144.45663.qmail@web20203.mail.yahoo.com> Message-ID: <3F6A53BC.3050304@globalite.com.br> Ralf W. Grosse-Kunstleve wrote: >There is another most wanted feature on my list: automatic integration of >documentation embedded in C++ code. I.e. I'd like to see my Doxygen >documentation appear merged with the Python documentation. It seems to me that >no amount of meta-programming wizardry will be able to do this. My current >state of mind is that gcc-xml/Pyste could potentially provide a solution. >Bruno, does gcc-xml preserve the comment blocks in C++ code? If not, could it >be made to? > Hi Ralf, It doesn't, and I believe it would be very hard for it to do it, because normally the comments are discarded during the syntax check, so the grammar would have to change to support that... but we should ask Brad King to know for sure. >Jumping ahead: > >1. I find myself quite often adding a thin Python layer on top of the raw >Boost.Python bindings, for example to get keyword support without increasing >compile times and object code size, or to inject additional methods. > >2. To me the popularity of Pyste shows that this is the way of the future. > >This leads me to drastic suggestions: > >- Treat the entire C++ layer of the Python-based wrapping system as an >implementation detail. > >- Let the user direct the wrapping process exclusively via a Pyste-style pure >Python script. > >- Simplify the Boost.Python code base by scaling down the amount of work that >is done with meta-programming techniques. > >- Always generate an intermediate Python layer with full, automatic keyword >support and a copy of the documentation embedded in the C++ code. > >- Use SCons (pure Python again) to control the generation of all intermediate >files and the management of all dependencies. > Seems like a good scenario... the compile times are really a nuisance, and a step in the direction of reducing them would be great. In my company it is not that big of a deal, because the C++ code uses a lot of template metaprogramming also, so that it takes about 70 minutes to compile in my dual Pentium II 800 box at work, so the 15 minutes needed by the bindings are shadowed by the time taken to build the library. 8) Thankfully I wrote a system that distributes the files across de network, allowing all of our computers to compile the files together. But I digress... >My suggestions are partially motivated by the belief that some of the problems >outlined in David's original posting will be much easier to deal with in a >framework as outline above. The critical ingredient that makes this possible is >gcc-xml, which provides the tool for analyzing the C++ code to be wrapped "from >outside" instead of "from inside" using compile-time introspection facilities >that were clearly not designed for this purpose. > >Ralf > >P.S.: Is this the same person that tried to talk Bruno out of writing Pyste? :) > Nah, I don't think so. ;) From rwgk at yahoo.com Fri Sep 19 04:34:07 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 19:34:07 -0700 (PDT) Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <20030919023407.31151.qmail@web20208.mail.yahoo.com> --- Mike Rovner wrote: > Niall Douglas wrote: > > Lastly, anything to reduce compile times would be a boon. I have a > > dual Athlon 1700, yet to compile a full set of bindings will take > > twenty hours or so. This is unacceptable. > > I'm happy with precompiled headers. They reduced my compilation time at > least tenfold. > MSVC7.1, P4 2.4GHz > > So IMHO they worth give them a try. Another option is to use the new dual-CPU Xeons with hyper threading. If I run four compile jobs in parallel (scons -j 4 or bjam -j4) the factor compared to compiling with a single CPU is about 3.8. Ralf P.S.: Strangely, the machines are delivered with hyper threading disabled. Make sure this option is turned on before trying -j 4. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From prabhu at aero.iitm.ernet.in Fri Sep 19 04:35:27 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 19 Sep 2003 08:05:27 +0530 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <3F6A2BF8.16467.5A8154A@localhost> References: <3F6A2BF8.16467.5A8154A@localhost> Message-ID: <16234.27503.196676.291342@enthought.hathway.com> >>>>> "ND" == Niall Douglas writes: >> These aren't so drastic; I've been saying things like this for >> several months. However, you might ask yourself "why not just >> use SWIG?" ND> Bottom-up projects like SWIG easily get success with simple ND> C++ but will find it geometrically harder to add increasingly ND> complex C++. I went with boost.python because it seemed to me ND> to be naturally more easily extendable for advanced C++ Having used both tools I find that hard to believe. SWIG from CVS handles quite complex C++. AFAIK the only thing it does not support yet is nested structures/classes. True, Pyste files are Python files and interface files are not but the SWIG pre-processor is quite powerful. http://www.swig.org/Doc1.3/Preprocessor.html You might also want to look at this: http://pwig.sourceforge.net which is SWIG wrapped in SWIG so you can use it from Python. ND> features. Also, pyste looked very attractive whereas SWIG ND> requires custom written interface files which would take me ND> weeks to write initially and a high quantity of maintanence ND> time whenever the underlying library was changed (often). Huh? Pyste files and SWIG interface files are really quite similar. You need to write the interface files for both and both will need changing if the underlying library changes. I don't see how you avoid that by using Pyste instead of SWIG? cheers, prabhu From prabhu at aero.iitm.ernet.in Fri Sep 19 04:38:25 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 19 Sep 2003 08:08:25 +0530 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <20030918220425.11308.qmail@web20207.mail.yahoo.com> References: <20030918220425.11308.qmail@web20207.mail.yahoo.com> Message-ID: <16234.27681.590344.371439@enthought.hathway.com> >>>>> "RWGK" == Ralf W Grosse-Kunstleve writes: RWGK> --- David Abrahams wrote: >> What's the difference between custom-written interface files >> and custom-written Pyste scripts? RWGK> Can you have if statements, loops and subroutines in SWIG RWGK> interface files, or importable modules that concentrate RWGK> frequently used functionality? Also, how do the C++ parsers RWGK> in g++ and SWIG compare? AFAIK with SWIG, if's are possible, loops are not. You can define quite powerful macros and you could call them 'subroutines'. The SWIG C++ parser is not perfect but works with most C++. It is however *really* fast compared to g++/GCC_XML, I'd say about 10x faster. cheers, prabhu From prabhu at aero.iitm.ernet.in Fri Sep 19 04:44:19 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Fri, 19 Sep 2003 08:14:19 +0530 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <3F6A3890.26190.5D944A8@localhost> References: <3F6A3890.26190.5D944A8@localhost> Message-ID: <16234.28035.913724.290776@enthought.hathway.com> >>>>> "ND" == Niall Douglas writes: >> What's the difference between custom-written interface files >> and custom-written Pyste scripts? ND> pyste scripts are way, way shorter. SWIG interface files are a ND> simplified duplicate of the C++ header - that IMHO is stupid ND> because every time the header file changes, you must mirror ND> the changes in the SWIG interface file. %include "your_header.hpp" How much simpler than that can you get? If you need to pick classes/functions then you can use %ignores to ignore what you don't want. Yes, it is a problem that you can't pick specific classes from a bunch of them. Perhaps that would be a good feature to suggest on the SWIG lists? Note that you do get some extra flexibility with the SWIG approach. prabhu From rwgk at yahoo.com Fri Sep 19 04:47:19 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 18 Sep 2003 19:47:19 -0700 (PDT) Subject: [C++-sig] [Implementation] Calling wrapped functions, converters, policies In-Reply-To: <3F6A53BC.3050304@globalite.com.br> Message-ID: <20030919024719.33404.qmail@web20208.mail.yahoo.com> --- Nicodemus wrote: > Ralf W. Grosse-Kunstleve wrote: > > >There is another most wanted feature on my list: automatic integration of > >documentation embedded in C++ code. I.e. I'd like to see my Doxygen > >documentation appear merged with the Python documentation. It seems to me > that > >no amount of meta-programming wizardry will be able to do this. My current > >state of mind is that gcc-xml/Pyste could potentially provide a solution. > >Bruno, does gcc-xml preserve the comment blocks in C++ code? If not, could > it > >be made to? > > > > Hi Ralf, > > It doesn't, and I believe it would be very hard for it to do it, because > normally the comments are discarded during the syntax check, so the > grammar would have to change to support that... but we should ask Brad > King to know for sure. I can see that it would be hard to extract the comments. Here is a different idea: void foo() { static const char* documentation = "A silly function " " that does nothing."; } class bar { static const char* documentation = "A silly class" " that does nothing."; }; This assumes that it is possible to extract the documentation strings with gcc-xml. Does this sound feasible? Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From stefan.seefeld at orthosoft.ca Fri Sep 19 16:51:02 2003 From: stefan.seefeld at orthosoft.ca (Stefan Seefeld) Date: Fri, 19 Sep 2003 10:51:02 -0400 Subject: [C++-sig] boost.python and python 2.3 Message-ID: <1df3f9327c3c019d331eef38cb3dbbb93f6b1500@Orthosoft.ca> hi there, we'v run into a compile-time error involving boost.python headers when we upgraded to python 2.3. We are using boost 1.30.2, and the error happens on GNU/Linux (RH8) with gcc 3.2.2. It looks like a macro clash or somesuch, but the excessive use of macros inside boost makes it very hard to get a handle of the real problem. The error message is /usr/local/ORTHOsoft/include/boost/python/converter/builtin_converters.hpp:106: parse error before `&' token /usr/local/ORTHOsoft/include/boost/python/converter/builtin_converters.hpp:106: syntax error before `&' token ... (followed by about 250 more lines of this kind). Just downgrading to python 2.2 made the problem disappear. Is this a known problem ? Is it fixed in cvs ? Is there a simple fix to apply to the 1.30.2 release (assuming it is indeed a macro clash) ? Thanks, Stefan From RaoulGough at yahoo.co.uk Fri Sep 19 17:32:32 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Fri, 19 Sep 2003 16:32:32 +0100 Subject: [C++-sig] Re: boost.python and python 2.3 References: <1df3f9327c3c019d331eef38cb3dbbb93f6b1500@Orthosoft.ca> Message-ID: Stefan Seefeld writes: > we'v run into a compile-time error involving boost.python headers > when we upgraded to python 2.3. We are using boost 1.30.2, and the > error happens on GNU/Linux (RH8) with gcc 3.2.2. [snip] > Just downgrading to python 2.2 made the problem disappear. > > Is this a known problem ? Is it fixed in cvs ? Is there a simple fix > to apply to the 1.30.2 release (assuming it is indeed a macro clash) ? Known, and documented (at least on the web site copy of the docs - see http://www.boost.org/libs/python/doc/). Reportedly fixed in CVS, but I haven't tried it myself. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From rwgk at yahoo.com Fri Sep 19 17:38:11 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 19 Sep 2003 08:38:11 -0700 (PDT) Subject: [C++-sig] boost.python and python 2.3 In-Reply-To: <1df3f9327c3c019d331eef38cb3dbbb93f6b1500@Orthosoft.ca> Message-ID: <20030919153811.34384.qmail@web20202.mail.yahoo.com> --- Stefan Seefeld wrote: > Is this a known problem ? Yes. > Is it fixed in cvs ? Yes. > Is there a simple fix to apply to the 1.30.2 release No. Both David and I spent a significant amount of time dealing with the requirement that Python.h has to be included before any system header file. We had to change virtually all boost/python header files and some of the .cpp files. > (assuming it is indeed a macro clash) ? Python.h (or some of the files it includes) unconditionally defines macros related to XOPEN and POSIX compliance. These have to be seen before any system header is included. (I find this requirement horrible, but that's the way it is.) Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From s_sourceforge at nedprod.com Fri Sep 19 04:09:28 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 19 Sep 2003 03:09:28 +0100 Subject: [C++-sig] Pyste bugs again Message-ID: <3F6A7368.2678.AF9D65@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I hate to be a bore but the patches I submitted here last time have not been implemented in the latest CVS version. This means that quite simply pyste DOES NOT WORK on MSVC. Bug 1: Declaring an unnamed namespace in the pyste output causes MSVC7.1 to gobble memory until infinity. My solution: Alter Save() in SingleCodeUnit.py: if declaration: pyste_namespace = namespaces.pyste[:-2] if pyste_namespace: fout.write('namespace %s {\n\n' % pyste_namespace) fout.write(declaration) if pyste_namespace: fout.write('\n}// namespace %s\n' % pyste_namespace) fout.write(space) This simply doesn't write out a namespace declaration if it's unnamed. Bug 2: Unnamed enums are still being called "$_xx". MSVC does not like symbols starting with $. Furthermore the export_values() facility is still not being employed. My solution: Alter Export() in EnumExporter.py: def Export(self, codeunit, exported_names): if not self.info.exclude: indent = self.INDENT in_indent = self.INDENT*2 rename = self.info.rename or self.enum.name full_name = self.enum.FullName() if rename[0:2] == "$_" or rename == '._0': global uniqueTypeCount full_name = 'UniqueInt<%d>' % uniqueTypeCount uniqueTypeCount+=1 rename = "unnamed" code = indent + namespaces.python code += 'enum_< %s >("%s")\n' % (full_name, rename) for name in self.enum.values: rename = self.info[name].rename or name value_fullname = self.enum.ValueFullName(name) code += in_indent + '.value("%s", %s)\n' % (rename, value_fullname) code += in_indent + '.export_values();\n\n' codeunit.Write('module', code) exported_names[self.enum.FullName()] = 1 Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2plW8EcvDLFGKbPEQKhxwCeMhcUiZhmxh/1y1+k+0RX9YTnBrEAn0ep pYXNrv6LWpAcH4zV6LaZvqhl =3YE9 -----END PGP SIGNATURE----- From dave at boost-consulting.com Fri Sep 19 16:57:47 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 19 Sep 2003 10:57:47 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6A3750.1963.5D4624B@localhost> Message-ID: "Niall Douglas" writes: > On 18 Sep 2003 at 17:33, David Abrahams wrote: > >> > GCC-XML is broken in some areas, but I'm sure its bugs will be fixed >> > with time. My only concern is that GCC is overly conservative in its >> > interpretation of the C++ standard - code which MSVC permits (and I >> > would permit) GCC barfs on. >> >> Actually it's the opposite. Those areas where GCC restricts what you >> can do but MSVC does not are not open to interpretation: GCC gets it >> right and MSVC gets it wrong. In fact, in some of the areas where >> different interpretations of the standard are possible (e.g. Koenig >> Lookup), GCC is IMO far too liberal, which breaks otherwise correct >> code. > > I think one can approach this from both angles then. I personally had > found GCC to barf on code MSVC7.1 is happy with, but then I write and > debug on MSVC7.1 first and then compile on GCC. If you tend to go the > other way round, you'd probably find it the other way. > > My main bugbear with GCC is it forces const temporaries. This makes > destructive copy construction semantics severely castrated, so much > so you usually must #ifdef hack in a copy constructor taking a const > reference just on GCC :( > > I know all the usual arguments about temporaries should be const. I > strongly disagree. Disagree all you want. A C++ compiler should conform to the standard or it isn't C++. Which compiler is correct in this regard is not open to debate. > C++ is all about giving plenty of rope to the programmer to hang > themselves with Au contraire, it's about providing abstraction with safety and performance. > where that rope /could/ be used for something useful and no other > better way is available for doing it. And destructive copy > construction is clearly implied when it takes a non-const reference. Maybe you would be interested in a proposal I co-authored: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Sep 19 16:59:43 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 19 Sep 2003 10:59:43 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <20030918220425.11308.qmail@web20207.mail.yahoo.com> <16234.27681.590344.371439@enthought.hathway.com> Message-ID: Prabhu Ramachandran writes: >>>>>> "RWGK" == Ralf W Grosse-Kunstleve writes: > > RWGK> --- David Abrahams wrote: > >> What's the difference between custom-written interface files > >> and custom-written Pyste scripts? > > RWGK> Can you have if statements, loops and subroutines in SWIG > RWGK> interface files, or importable modules that concentrate > RWGK> frequently used functionality? Also, how do the C++ parsers > RWGK> in g++ and SWIG compare? > > AFAIK with SWIG, if's are possible, loops are not. You can define > quite powerful macros and you could call them 'subroutines'. The SWIG > C++ parser is not perfect but works with most C++. It is however > *really* fast compared to g++/GCC_XML, I'd say about 10x faster. I wonder how the parser used in Synopsis (synopsis.sf.net) compares in speed? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Sep 19 17:02:58 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 19 Sep 2003 11:02:58 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <20030918180144.45663.qmail@web20203.mail.yahoo.com> <3F6A53BC.3050304@globalite.com.br> Message-ID: Nicodemus writes: > Ralf W. Grosse-Kunstleve wrote: > >>There is another most wanted feature on my list: automatic integration of >>documentation embedded in C++ code. I.e. I'd like to see my Doxygen >>documentation appear merged with the Python documentation. It seems to me that >>no amount of meta-programming wizardry will be able to do this. My current >>state of mind is that gcc-xml/Pyste could potentially provide a solution. >>Bruno, does gcc-xml preserve the comment blocks in C++ code? If not, could it >>be made to? >> > > Hi Ralf, > > It doesn't, and I believe it would be very hard for it to do it, > because normally the comments are discarded during the syntax check, > so the grammar would have to change to support that... but we should > ask Brad King to know for sure. The Synopsis (http://synopsis.sf.net) parser has access to enough information to extract comments. On the other hand, if you get line number information from GCC_XML, you could post-process the original C++ source to find associated comments. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Fri Sep 19 20:50:22 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Fri, 19 Sep 2003 19:50:22 +0100 Subject: [C++-sig] SWIG vs Pyste (was: Re: [Implementation] Calling wrapped functions, converters, policies) In-Reply-To: <16234.28035.913724.290776@enthought.hathway.com> References: <3F6A3890.26190.5D944A8@localhost> Message-ID: <3F6B5DFE.15766.443F6E8@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Sep 2003 at 8:14, Prabhu Ramachandran wrote: > ND> Bottom-up projects like SWIG easily get success with simple > ND> C++ but will find it geometrically harder to add increasingly ND> > complex C++. I went with boost.python because it seemed to me ND> to > be naturally more easily extendable for advanced C++ > > Having used both tools I find that hard to believe. SWIG from CVS > handles quite complex C++. AFAIK the only thing it does not support > yet is nested structures/classes. It also didn't play nice with compile-time metaprogramming constructs when I tried it. I was also slightly concerned about exception translation if I remember, but that could simply be the lack of docs SWIG suffers from. Either way, SWIG's C++ parser will likely never be able to handle full unadulterated C++. It'll always need some form of simplification or hinting. That's because SWIG can't "understand" C++, whereas Boost.Python does through compile-time introspection. > True, Pyste files are Python files and > interface files are not but the SWIG pre-processor is quite powerful. I am absolutely sure it can be nowhere near as powerful as a python script. > ND> features. Also, pyste looked very attractive whereas SWIG > ND> requires custom written interface files which would take me > ND> weeks to write initially and a high quantity of maintanence > ND> time whenever the underlying library was changed (often). > > Huh? Pyste files and SWIG interface files are really quite similar. They're not. A pyste file for an entire complex header file can be five lines including setting return policies. And if you base your return policy setting code around the object hierarchy, you can substantially save on that again. SWIG interface files are usually the same size as the header file they're specifying. > You need to write the interface files for both and both will need > changing if the underlying library changes. I don't see how you avoid > that by using Pyste instead of SWIG? I've gone further though and have a python script which scans the include directory of the C++ library, generates a pyste file for each one which has changed since last invocation using a customisable rule set defining differences and then invokes pyste. This means the total maintanence cost is merely maintaining the return policies file - everything else is totally automated. > ND> pyste scripts are way, way shorter. SWIG interface files are a > ND> simplified duplicate of the C++ header - that IMHO is stupid > ND> because every time the header file changes, you must mirror > ND> the changes in the SWIG interface file. > > %include "your_header.hpp" > > How much simpler than that can you get? SWIG barfed loudly with the unmodified headers I tried feeding it. I'm sure things have improved, but quite honestly either maintaining alternative code within #ifdef SWIG areas or even a simplified duplicate is too expensive when you have 232 header files exposing a public interface - and that number is growing. > If you need to pick > classes/functions then you can use %ignores to ignore what you don't > want. Yes, it is a problem that you can't pick specific classes from > a bunch of them. Perhaps that would be a good feature to suggest on > the SWIG lists? Note that you do get some extra flexibility with the > SWIG approach. Out of interest, if you had to produce python bindings for the whole Boost library, would you use SWIG or Pyste? I should also that I haven't looked at SWIG in the last few months and when I did, it was purely in evaluation terms - not for serious bashing. So I may be wrong, but I'm pretty sure as a general rule I'm right. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2tP7sEcvDLFGKbPEQJmDwCcCq7zbdbY6ATpLX5SMMWrahYHS2gAn0pJ YMBypcIjG6Nrpa1qH+kWxxeA =Cke7 -----END PGP SIGNATURE----- From mike at nospam.com Fri Sep 19 22:49:53 2003 From: mike at nospam.com (Mike Rovner) Date: Fri, 19 Sep 2003 13:49:53 -0700 Subject: [C++-sig] Re: Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6A58AC.28973.472FF0@localhost> Message-ID: Niall Douglas wrote: >> I'm happy with precompiled headers. They reduced my compilation time >> at least tenfold. MSVC7.1, P4 2.4GHz > They cause misbehaviour on my large & complex C++ project > unfortunately :( I mentioned my compiler on purpose. VC7.1 has a known bug with PCH. However I decided to track down and change a couple of places in (all of) my codebase to gain compilation speed. So far, the only change is from global data in anonimous namespace to static. Mike From prabhu at aero.iitm.ernet.in Sat Sep 20 00:18:23 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Sat, 20 Sep 2003 03:48:23 +0530 Subject: [C++-sig] SWIG vs Pyste (was: Re: [Implementation] Calling wrapped functions, converters, policies) In-Reply-To: <3F6B5DFE.15766.443F6E8@localhost> References: <3F6A3890.26190.5D944A8@localhost> <3F6B5DFE.15766.443F6E8@localhost> Message-ID: <16235.32943.186349.501087@enthought.hathway.com> >>>>> "ND" == Niall Douglas writes: >> complex C++. I went with boost.python because it seemed to me >> to be naturally more easily extendable for advanced C++ >> >> Having used both tools I find that hard to believe. SWIG from >> CVS handles quite complex C++. AFAIK the only thing it does >> not support yet is nested structures/classes. ND> It also didn't play nice with compile-time metaprogramming ND> constructs when I tried it. I was also slightly concerned ND> about exception translation if I remember, but that could ND> simply be the lack of docs SWIG suffers from. As I said, its not perfect and will not improve without users reporting problems. ND> Either way, SWIG's C++ parser will likely never be able to ND> handle full unadulterated C++. It'll always need some form of ND> simplification or hinting. That's because SWIG can't ND> "understand" C++, whereas Boost.Python does through ND> compile-time introspection. True, but a while back C++ compilers didn't understand C++ either. >> True, Pyste files are Python files and interface files are not >> but the SWIG pre-processor is quite powerful. ND> I am absolutely sure it can be nowhere near as powerful as a ND> python script. Sure, its not as powerful as Python and it would be nice if interface files were Python files. However, interface files are certainly quite powerful enough to do quite a bit. [snip] >> You need to write the interface files for both and both will >> need changing if the underlying library changes. I don't see >> how you avoid that by using Pyste instead of SWIG? ND> I've gone further though and have a python script which scans ND> the include directory of the C++ library, generates a pyste ND> file for each one which has changed since last invocation ND> using a customisable rule set defining differences and then ND> invokes pyste. This means the total maintanence cost is merely ND> maintaining the return policies file - everything else is ND> totally automated. Interesting, but what prevents you from generating SWIG interface files in similar manner? [snip] >> %include "your_header.hpp" >> >> How much simpler than that can you get? ND> SWIG barfed loudly with the unmodified headers I tried feeding ND> it. I'm sure things have improved, but quite honestly either ND> maintaining alternative code within #ifdef SWIG areas or even ND> a simplified duplicate is too expensive when you have 232 ND> header files exposing a public interface - and that number is ND> growing. Yes, the parser will need work but I find that the developers are quite responsive when bug reports are submitted. >> If you need to pick classes/functions then you can use %ignores >> to ignore what you don't want. Yes, it is a problem that you >> can't pick specific classes from a bunch of them. Perhaps that >> would be a good feature to suggest on the SWIG lists? Note >> that you do get some extra flexibility with the SWIG approach. ND> Out of interest, if you had to produce python bindings for the ND> whole Boost library, would you use SWIG or Pyste? I don't know. I'd probably try both and see which does the job. Given the state of gcc my guess is that just compiling the Boost.Python version will take forever. ND> I should also that I haven't looked at SWIG in the last few ND> months and when I did, it was purely in evaluation terms - not ND> for serious bashing. So I may be wrong, but I'm pretty sure as ND> a general rule I'm right. Well, in my personal evaluation I've been a more successful with SWIG in less time than with Pyste. I've wrapped about 90 odd classes. Sure, the code I've wrapped is *nowhere* near as complex as the Boost library but its something and a decent data point for me. This is not to say that Boost.Python is not good enough, its probably just me but hey I would not be on this list if I didn't think highly of Boost.Python and Pyste. The only reason I am replying on this thread is that I think you are being a little too dismissive of SWIG and that goes against my (admittedly limited) experience. cheers, prabhu From nicodemus at globalite.com.br Sat Sep 20 01:12:43 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Fri, 19 Sep 2003 20:12:43 -0300 Subject: [C++-sig] Pyste bugs again In-Reply-To: <3F6A7368.2678.AF9D65@localhost> References: <3F6A7368.2678.AF9D65@localhost> Message-ID: <3F6B8D6B.7080502@globalite.com.br> Hi Niall, Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I hate to be a bore but the patches I submitted here last time have >not been implemented in the latest CVS version. > > No bore: bug reports and suggestions are welcome. 8) >This means that quite simply pyste DOES NOT WORK on MSVC. > >Bug 1: Declaring an unnamed namespace in the pyste output causes >MSVC7.1 to gobble memory until infinity. > >My solution: Alter Save() in SingleCodeUnit.py: > > if declaration: > pyste_namespace = namespaces.pyste[:-2] > if pyste_namespace: > fout.write('namespace %s {\n\n' % >pyste_namespace) > fout.write(declaration) > if pyste_namespace: > fout.write('\n}// namespace %s\n' % >pyste_namespace) > fout.write(space) > >This simply doesn't write out a namespace declaration if it's >unnamed. > > Sorry, but I replied to your message, and suggested that you try out the --pyste-ns option. So you could run pyste with --pyste-ns=pyste or something, and the namespace wouldn't be empty anymore. I believe that MSVC does support namespaces, right? ;) If that doesn't work, I think your approach (not writing the declarations inside a namespace at all if no namespace is specified) is feasible. >Bug 2: Unnamed enums are still being called "$_xx". MSVC does not >like symbols starting with $. Furthermore the export_values() >facility is still not being employed. > >My solution: Alter Export() in EnumExporter.py: > > def Export(self, codeunit, exported_names): > if not self.info.exclude: > indent = self.INDENT > in_indent = self.INDENT*2 > rename = self.info.rename or self.enum.name > full_name = self.enum.FullName() > if rename[0:2] == "$_" or rename == '._0': > global uniqueTypeCount > full_name = 'UniqueInt<%d>' % uniqueTypeCount > uniqueTypeCount+=1 > rename = "unnamed" > code = indent + namespaces.python > code += 'enum_< %s >("%s")\n' % (full_name, rename) > for name in self.enum.values: > rename = self.info[name].rename or name > value_fullname = self.enum.ValueFullName(name) > code += in_indent + '.value("%s", %s)\n' % (rename, >value_fullname) > code += in_indent + '.export_values();\n\n' > codeunit.Write('module', code) > exported_names[self.enum.FullName()] = 1 > > I'm really sorry about that, this one passed through. I implemented it in CVS, but not verbatim as in here. First, only unnamed enums are exported with export_values() by default. If you want a normal enum to be exported, you have to call export_values on it: color = Enum('color',...) export_values(color) The reason is that if we made it so that all enums were exported with export_values, then it would break code that expected the old behaviour. But I must say that I prefer enums with export_values, since they mirror better in Python the same semathics of enums in C++. Thanks a lot for the feedback Niall! Nicodemus. Ps: I also implemented the change so that any \ will be translated to / before being passed to gccxml. From s_sourceforge at nedprod.com Sat Sep 20 02:50:41 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 20 Sep 2003 01:50:41 +0100 Subject: [C++-sig] Pyste bugs again In-Reply-To: <3F6B8D6B.7080502@globalite.com.br> References: <3F6A7368.2678.AF9D65@localhost> Message-ID: <3F6BB271.23944.58DD716@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Sep 2003 at 20:12, Nicodemus wrote: > The reason is that if we made it so that all enums were exported with > export_values, then it would break code that expected the old > behaviour. But I must say that I prefer enums with export_values, > since they mirror better in Python the same semathics of enums in C++. Cool. And thanks. BTW what do the new commands do? There's nothing in the docs yet. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2ukYcEcvDLFGKbPEQI3ugCggmjMQXz0jcAmGKRbH2pm583/0mYAnioJ nEvYj7w7p7vC5MJ9NAWTncHS =7t6e -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sat Sep 20 02:47:55 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 20 Sep 2003 01:47:55 +0100 Subject: [C++-sig] SWIG vs Pyste (was: Re: [Implementation] Calling wrapped functions, converters, policies) In-Reply-To: <16235.32943.186349.501087@enthought.hathway.com> References: <3F6B5DFE.15766.443F6E8@localhost> Message-ID: <3F6BB1CB.23419.58B4F43@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 3:48, Prabhu Ramachandran wrote: > ND> I've gone further though and have a python script which scans > ND> the include directory of the C++ library, generates a pyste > ND> file for each one which has changed since last invocation ND> > using a customisable rule set defining differences and then ND> > invokes pyste. This means the total maintanence cost is merely ND> > maintaining the return policies file - everything else is ND> > totally automated. > > Interesting, but what prevents you from generating SWIG interface > files in similar manner? Because getting python to parse C++ is tough. Boost.Python & Pyste does that for you with a real C++ compiler. > ND> I should also that I haven't looked at SWIG in the last few > ND> months and when I did, it was purely in evaluation terms - not > ND> for serious bashing. So I may be wrong, but I'm pretty sure as > ND> a general rule I'm right. > > Well, in my personal evaluation I've been a more successful with SWIG > in less time than with Pyste. I've wrapped about 90 odd classes. > Sure, the code I've wrapped is *nowhere* near as complex as the Boost > library but its something and a decent data point for me. This is not > to say that Boost.Python is not good enough, its probably just me but > hey I would not be on this list if I didn't think highly of > Boost.Python and Pyste. The only reason I am replying on this thread > is that I think you are being a little too dismissive of SWIG and that > goes against my (admittedly limited) experience. I should clarify my statements then - I completely agree that SWIG is an excellent tool and for years has provided and still provides the optimum way of generating cross-language bindings. I cannot praise the tool enough. What I was doing was saying why I personally chose Boost.Python over SWIG based on the needs of this particular library. I did not intend to diss SWIG or say it was inferior. In fact I most certainly would not choose Boost.Python for other solutions because in those SWIG is stronger and more importantly, I actually understand SWIG and how it works whereas all this metaprogramming stuff is still beyond me. And I find it very frustrating working with software which I don't understand :( Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2uju8EcvDLFGKbPEQIeWQCgjw+pzyAMEwM/Nd3m7PB8y/ZTM4EAn1iV k9J7+SMtv8oy/MPw31/NaZPr =clxU -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sat Sep 20 02:40:35 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 20 Sep 2003 01:40:35 +0100 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6BB013.17301.58498E0@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Sep 2003 at 10:57, David Abrahams wrote: > > My main bugbear with GCC is it forces const temporaries. This makes > > destructive copy construction semantics severely castrated, so much > > so you usually must #ifdef hack in a copy constructor taking a const > > reference just on GCC :( > > > > I know all the usual arguments about temporaries should be const. I > > strongly disagree. > > Disagree all you want. A C++ compiler should conform to the standard > or it isn't C++. Which compiler is correct in this regard is not open > to debate. My 1996 draft (which is all I can afford) doesn't say all temporaries are const. I take it this has changed? I don't get why this was done. Sure making temporaries created from a conversion cast const is a good idea but temporaries returned from a function or produced through the action of an operator are quite different beasts - there is no danger of state changes getting lost in an unintended way. And besides, some objects you use clearly can have only one instance. > > where that rope /could/ be used for something useful and no other > > better way is available for doing it. And destructive copy > > construction is clearly implied when it takes a non-const reference. > > Maybe you would be interested in a proposal I co-authored: > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm I support that document. My only concern is that using && as the token is a bad idea because if the proposed extension to permit taking references of references goes through, this might cause confusion in the debugger. I would suggest ~& is much better. The ~ says it's destructive/move and the & denotes a reference. Much clearer. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2uiA8EcvDLFGKbPEQKTyACg+a+FutbsuDEWoCK3ejXTLRLgH1gAnixF wT13RFnHxU+ElSNbJXcJSY6X =CnEx -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sat Sep 20 02:27:26 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 20 Sep 2003 01:27:26 +0100 Subject: [C++-sig] Re: Re: [Implementation] Calling wrapped functions, converters, policies In-Reply-To: Message-ID: <3F6BACFE.13558.5788E1D@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Sep 2003 at 13:49, Mike Rovner wrote: (I would have sent this off-list, but your email address is false?) > I mentioned my compiler on purpose. VC7.1 has a known bug with PCH. > However I decided to track down and change a couple of places in (all > of) my codebase to gain compilation speed. > > So far, the only change is from global data in anonimous namespace to > static. Ah, thanks for that tip. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2ue7sEcvDLFGKbPEQLboQCgnY8XJ4AUQwmsOoWf1HSk/rktJcgAn1qs QCUD5W/b3UIV9ZR1gvhzn5iu =TeNA -----END PGP SIGNATURE----- From dave at boost-consulting.com Sat Sep 20 05:45:13 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 19 Sep 2003 23:45:13 -0400 Subject: [C++-sig] Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6BB013.17301.58498E0@localhost> Message-ID: "Niall Douglas" writes: > On 19 Sep 2003 at 10:57, David Abrahams wrote: > >> > My main bugbear with GCC is it forces const temporaries. This makes >> > destructive copy construction semantics severely castrated, so much >> > so you usually must #ifdef hack in a copy constructor taking a const >> > reference just on GCC :( >> > >> > I know all the usual arguments about temporaries should be const. I >> > strongly disagree. >> >> Disagree all you want. A C++ compiler should conform to the standard >> or it isn't C++. Which compiler is correct in this regard is not open >> to debate. > > My 1996 draft (which is all I can afford) $18 is beyond your means? > doesn't say all temporaries are const. Neither does the C++98 standard. What they *both* say is that a non-const reference won't bind to an rvalue (8.5.3/5) and that temporaries are rvalues (3.10/5,6) > I take it this has changed? No change. > I don't get why this was done. Sure making temporaries created from a > conversion cast const is a good idea but temporaries returned from a > function user-defined conversion operators are functions. > or produced through the action of an operator are quite different > beasts - there is no danger of state changes getting lost in an > unintended way. And besides, some objects you use clearly can have > only one instance. Read D&E if you want to know, and don't ask me because I had nothing to do with it ;-) >> > where that rope /could/ be used for something useful and no other >> > better way is available for doing it. And destructive copy >> > construction is clearly implied when it takes a non-const reference. >> >> Maybe you would be interested in a proposal I co-authored: >> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm > > I support that document. My only concern is that using && as the > token is a bad idea because if the proposed extension to permit > taking references of references goes through It already went through. > this might cause confusion in the debugger. There's no confusion possible. && is already a token and unless && gets the additional meaning we proposed X&& will be a syntax error when X is a type. > I would suggest ~& is much better. The ~ says it's destructive/move > and the & denotes a reference. Much clearer. ~& was my idea but there are problems with it according to the compiler implementors (I forget what; ask EDG). -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sun Sep 21 02:43:49 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 01:43:49 +0100 Subject: [C++-sig] Way to insert code in _main.cpp in pyste Message-ID: <3F6D0255.30802.AADEC08@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd really like a way of inserting code into _main.cpp automagically. Basically I have a list of converters which need to be registered with boost.python just after the BOOST_PYTHON_MODULE() and if one could specify a list of functions (eg; RegisterConvFXString(), RegisterDefines() etc) on the command line then that would be really cool. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2z0RsEcvDLFGKbPEQKJygCePp7j78h7tdyxIZ+dcD0e9KUTlJ0AnA3w k11GOMnqlaQ4cE60Yzbt8ajL =eHVA -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 02:13:09 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 01:13:09 +0100 Subject: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC Message-ID: <3F6CFB25.8233.A91D878@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It outputs things like "long long unsigned int" which MSVC barfs on. Fix is in GCCXMLParser.py: def ParseFundamentalType(self, id, element): name = element.get('name') if name=="long long int": name="__int64" elif name=="long long unsigned int": name="unsigned __int64" type_ = FundamentalType(name) self.Update(id, type_) Obviously this would break GCC. Nicodemus I think you'll need a -- msvc switch which lets you switch in MSVC specific output. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2ztFsEcvDLFGKbPEQJEVACfWV5weucczHYZizKJwokFM2z34AUAnisu M+sUm4jMxcfWIVasicRoxFSN =8EEJ -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 03:08:57 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 02:08:57 +0100 Subject: [C++-sig] Boost.Python not resolving overloads Message-ID: <3F6D0839.12117.AC4ED60@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> from TnFOX import * >>> fh=FXFile("fred.txt") >>> print fh.name() Traceback (most recent call last): File "", line 1, in ? Boost.Python.ArgumentError: Python argument types in FXFile.name() did not match C++ signature: name(class FX::FXString) name(class FX::FXFile {lvalue}) >>> print fh.name(fh) fred.txt As it says, there are two name()'s defined. I tried a number of other functions with no parameters and all of them cause an error if there are overloads present. The only way to make them work is to include the instance as the first parameter. Is this right? It's counter-intuitive and inconvenient - surely boost.python can try inserting the instance if no parameters are present? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2z6KcEcvDLFGKbPEQJcSgCfZNc5wkAmHRBa0oXDomv1477lk00AoKTS 18vL47KQJtCgO9sT3xv6yJZT =eQsv -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 02:33:24 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 01:33:24 +0100 Subject: [C++-sig] Where is return_by_value policy in pyste? Message-ID: <3F6CFFE4.26896.AA46148@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can't see any way to do return_value_policy. Why is this missing? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2zx1MEcvDLFGKbPEQLW9wCg4INLWHiZHHFTs3FJOEh+OWk4Q2kAn2VG QIy+ffQQtfQR3LQ8uhbjHh4P =tzjq -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 02:23:41 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 01:23:41 +0100 Subject: [C++-sig] Pyste bug: can't set different return policies on method Message-ID: <3F6CFD9D.12779.A9B7B44@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In a class like as follows: class FXFile { const FXString &name() const; static FXString name(const FXString &file); }; Pyste gets the two name()'s confused and tries to apply return_internal_reference to both. If I try to override and set one of the name()'s to something different, the pyste syntax doesn't let me. Solutions? I figured I can temporarily return_value_policy(manage_new_object)) but in other situations this wouldn't be possible. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2zvjcEcvDLFGKbPEQLXwwCgrdpzWFnFFnCogaUHqRaZJkaHof0AoNyg mWYNTTRsjOlUQf6vnClNRVB/ =4EYE -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 03:00:05 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 02:00:05 +0100 Subject: [C++-sig] Boost.Python does not translate bool to Python boolean Message-ID: <3F6D0625.27867.ABCD1B1@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was just wondering how easy this would be? I know this requires python v2.3 though which is possibly too new and besides, it's more for aesthetics than functionality. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2z4FsEcvDLFGKbPEQLvXACeNbnQlGgxynvwpjUmVeiVNhKSdWoAnA0I X8FpvnKISi2IFUwzv/KgBgPw =NVxX -----END PGP SIGNATURE----- From dave at boost-consulting.com Sun Sep 21 03:38:21 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 20 Sep 2003 21:38:21 -0400 Subject: [C++-sig] injected constructors Message-ID: Injected constructors are implemented, but not yet documented. See libs/python/test/injected.[py/cpp] for examples. There have also been some changes to the concept requirements for CallPolicies which have not yet been documented. If you have problems with your custom-made policies with the current CVS state, please let me know. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Sun Sep 21 03:45:47 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sat, 20 Sep 2003 22:45:47 -0300 Subject: [C++-sig] Way to insert code in _main.cpp in pyste In-Reply-To: <3F6D0255.30802.AADEC08@localhost> References: <3F6D0255.30802.AADEC08@localhost> Message-ID: <3F6D02CB.8030005@globalite.com.br> Hi Niall, Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I'd really like a way of inserting code into _main.cpp automagically. >Basically I have a list of converters which need to be registered >with boost.python just after the BOOST_PYTHON_MODULE() and if one >could specify a list of functions (eg; RegisterConvFXString(), >RegisterDefines() etc) on the command line then that would be really >cool. > > Must it be after BOOST_PYTHON_MODULE? If not, you can use the function declaration_code() in your Pyste file. To insert code inside BOOST_PYTHON_MODULE, use module_code(). Regards, Nicodemus. From dave at boost-consulting.com Sun Sep 21 03:46:46 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 20 Sep 2003 21:46:46 -0400 Subject: [C++-sig] Re: Boost.Python not resolving overloads References: <3F6D0839.12117.AC4ED60@localhost> Message-ID: "Niall Douglas" writes: >>>> from TnFOX import * >>>> fh=FXFile("fred.txt") >>>> print fh.name() > Traceback (most recent call last): > File "", line 1, in ? > Boost.Python.ArgumentError: Python argument types in > FXFile.name() > did not match C++ signature: > name(class FX::FXString) > name(class FX::FXFile {lvalue}) >>>> print fh.name(fh) > fred.txt > > As it says, there are two name()'s defined. Clearly it's a static method which takes a single argument. if you want to call it as fh.name() you can't make it static (or you need an overload which takes no arguments). > I tried a number of other > functions with no parameters and all of them cause an error if there > are overloads present. The only way to make them work is to include > the instance as the first parameter. > > Is this right? It's counter-intuitive and inconvenient - surely > boost.python can try inserting the instance if no parameters are > present? Wha??? No, it can't just guess at what you mean. The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! It works just the same way Python does. If that's not intuitive enough for you, you should take it up with Guido! -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sun Sep 21 03:47:55 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 20 Sep 2003 21:47:55 -0400 Subject: [C++-sig] Re: Boost.Python does not translate bool to Python boolean References: <3F6D0625.27867.ABCD1B1@localhost> Message-ID: "Niall Douglas" writes: > I was just wondering how easy this would be? It would be easy. > I know this requires python v2.3 though which is possibly too new > and besides, it's more for aesthetics than functionality. Patches welcomed. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Sun Sep 21 04:04:56 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sat, 20 Sep 2003 23:04:56 -0300 Subject: [C++-sig] Where is return_by_value policy in pyste? In-Reply-To: <3F6CFFE4.26896.AA46148@localhost> References: <3F6CFFE4.26896.AA46148@localhost> Message-ID: <3F6D0748.9060902@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I can't see any way to do return_value_policy. Why >is this missing? > Overlooked. 8) It's in CVS now, thanks for the pointer. Regards, Nicodemus. From s_sourceforge at nedprod.com Sun Sep 21 04:06:09 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 03:06:09 +0100 Subject: [C++-sig] Re: Boost.Python not resolving overloads In-Reply-To: Message-ID: <3F6D15A1.6789.AF94A67@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 21:46, David Abrahams wrote: > >>>> from TnFOX import * > >>>> fh=FXFile("fred.txt") > >>>> print fh.name() > > Traceback (most recent call last): > > File "", line 1, in ? > > Boost.Python.ArgumentError: Python argument types in > > FXFile.name() > > did not match C++ signature: > > name(class FX::FXString) > > name(class FX::FXFile {lvalue}) > >>>> print fh.name(fh) > > fred.txt > > > > As it says, there are two name()'s defined. > > Clearly it's a static method which takes a single argument. if you > want to call it as fh.name() you can't make it static (or you need an > overload which takes no arguments). Yes sorry - it's 3am here. One of the name()'s is static but the other one isn't: class FXFile { const FXString &name() const; static FXString name(const FXString &file); }; Now in my example above, I was calling name(void), not name(file). If you call name(fh) then it correctly calls the name(void). > > I tried a number of other > > functions with no parameters and all of them cause an error if there > > are overloads present. The only way to make them work is to include > > the instance as the first parameter. > > > > Is this right? It's counter-intuitive and inconvenient - surely > > boost.python can try inserting the instance if no parameters are > > present? > > Wha??? No, it can't just guess at what you mean. I don't see why. If one of my name()'s is zero parameters and the other one takes a string, and I call name(), then it's obvious I want the zero parameter one. Besides, the error message is from Boost.Python, not Python. If this is not known behaviour, I'll make you a demo though it would be trivial for you to write yourself. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP20HkcEcvDLFGKbPEQIAuQCfYg5xUp1xXmR2fgrHDfErGccMHeoAoJRD 9VEDNekkWKakxg2DE2gxYc9n =g+T/ -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 04:13:12 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 03:13:12 +0100 Subject: [C++-sig] Where is return_by_value policy in pyste? In-Reply-To: <3F6D0748.9060902@globalite.com.br> References: <3F6CFFE4.26896.AA46148@localhost> Message-ID: <3F6D1748.5027.AFFBFE8@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 23:04, Nicodemus wrote: > >I can't see any way to do return_value_policy. Why > >is this missing? > > Overlooked. 8) > It's in CVS now, thanks for the pointer. Hmm, makes me wonder how many people are actually using pyste in anger?!? Anyway, looking forward to a CVS grab tomorrow night when the Boost consulting copy gets refreshed. I've given up on CVS updates, my modem keeps disconnecting before it's done :( (Crappy telephone lines we have here in Ireland, can only do 33k though you get 45k at night time if it isn't raining :( ) Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP20JOMEcvDLFGKbPEQL76QCfYi9YmtSYhyYQSIJuIV5Hslj/xBQAoJ70 uNtEkpLoae2pVU2X/iX3gVdQ =3px7 -----END PGP SIGNATURE----- From dave at boost-consulting.com Sun Sep 21 04:10:37 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 20 Sep 2003 22:10:37 -0400 Subject: [C++-sig] Re: Boost.Python not resolving overloads References: <3F6D15A1.6789.AF94A67@localhost> Message-ID: "Niall Douglas" writes: > On 20 Sep 2003 at 21:46, David Abrahams wrote: > >> >>>> from TnFOX import * >> >>>> fh=FXFile("fred.txt") >> >>>> print fh.name() >> > Traceback (most recent call last): >> > File "", line 1, in ? >> > Boost.Python.ArgumentError: Python argument types in >> > FXFile.name() >> > did not match C++ signature: >> > name(class FX::FXString) >> > name(class FX::FXFile {lvalue}) >> >>>> print fh.name(fh) >> > fred.txt >> > >> > As it says, there are two name()'s defined. >> >> Clearly it's a static method which takes a single argument. if you >> want to call it as fh.name() you can't make it static (or you need an >> overload which takes no arguments). > > Yes sorry - it's 3am here. One of the name()'s is static but the > other one isn't: > > class FXFile > { > const FXString &name() const; > static FXString name(const FXString &file); > }; There's no such thing as that in Python. Overloading is somewhat of a simulation too. Any given name can only be static or non-static. > Now in my example above, I was calling name(void), not name(file). If > you call name(fh) then it correctly calls the name(void). > >> > I tried a number of other >> > functions with no parameters and all of them cause an error if there >> > are overloads present. The only way to make them work is to include >> > the instance as the first parameter. >> > >> > Is this right? It's counter-intuitive and inconvenient - surely >> > boost.python can try inserting the instance if no parameters are >> > present? >> >> Wha??? No, it can't just guess at what you mean. > > I don't see why. If one of my name()'s is zero parameters and the > other one takes a string Neither is zero parameters, as the error indicates. One takes an FXString and the other takes an FXFile. > , and I call name(), then it's obvious I want > the zero parameter one. > > Besides, the error message is from Boost.Python, not Python. Boost.Python uses the Python staticmethod wrapper to create static methods. > If this is not known behaviour, I'll make you a demo though it would > be trivial for you to write yourself. a demo from you is always less trivial than making it myself. In this case, though, the behavior is known and expected. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sun Sep 21 04:25:46 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 03:25:46 +0100 Subject: [C++-sig] Exception translation to python classes Message-ID: <3F6D1A3A.27565.B0B4109@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Wow, I really have made a lot of posts today, but I guess that's the result of actual progress for the first time in a month) I was wondering if anyone had any experience or could point me to some example code for translating C++ exceptions by using PyErr_SetObject to the Boost.Python wrap of the appropriate C++ exception object. Would it be as simple as creating the python version and calling operator=? If so then this is actually quite hard for me as I've not use the python C interface before. Also you'd need to ask Boost.Python what python type corresponds to the exception type and I can't see docs for that call? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP20MKsEcvDLFGKbPEQLpSgCeMS5o8ThOzOAD1YUy5P0SweSmx1sAoNSE eUOVqfUE5TbnQQuRiRxsCeKc =EZ0j -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 21 04:34:04 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 21 Sep 2003 03:34:04 +0100 Subject: [C++-sig] Re: Boost.Python not resolving overloads In-Reply-To: Message-ID: <3F6D1C2C.15686.B12DB63@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 22:10, David Abrahams wrote: > >> Wha??? No, it can't just guess at what you mean. > > > > I don't see why. If one of my name()'s is zero parameters and the > > other one takes a string > > Neither is zero parameters, as the error indicates. One takes an > FXString and the other takes an FXFile. As in, the non-static version takes "self", yes I get that ... > Boost.Python uses the Python staticmethod wrapper to create static > methods. Which I used. And I should add there's no docs saying that you can't mix static and non-static names though I admit it's implied by how staticmethod() works. > In this case, though, the behavior is known and expected. Might it be an idea in the name of flexibility that boost.python marks mixed static and non-static functions and tries matching the static one first. If that fails, then it makes the first parameter "self" and tries again. That way you get both working nicely in almost all cases, and a more accurate interface is provided to python? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP20OHMEcvDLFGKbPEQLIeQCfZSFZ5ZQGXu6fl3VCzyPrgwx45HMAoJuX lobGKR9LQrTiwdg6fCnvjAZQ =QWz8 -----END PGP SIGNATURE----- From dave at boost-consulting.com Sun Sep 21 05:42:07 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 20 Sep 2003 23:42:07 -0400 Subject: [C++-sig] Re: Boost.Python not resolving overloads References: <3F6D1C2C.15686.B12DB63@localhost> Message-ID: "Niall Douglas" writes: > On 20 Sep 2003 at 22:10, David Abrahams wrote: > >> >> Wha??? No, it can't just guess at what you mean. >> > >> > I don't see why. If one of my name()'s is zero parameters and the >> > other one takes a string >> >> Neither is zero parameters, as the error indicates. One takes an >> FXString and the other takes an FXFile. > > As in, the non-static version takes "self", yes I get that ... > >> Boost.Python uses the Python staticmethod wrapper to create static >> methods. > > Which I used. And I should add there's no docs saying that you can't > mix static and non-static names though I admit it's implied by how > staticmethod() works. > >> In this case, though, the behavior is known and expected. > > Might it be an idea in the name of flexibility that boost.python > marks mixed static and non-static functions and tries matching the > static one first. If that fails, then it makes the first parameter > "self" and tries again. It *might* be an idea. If you can figure out how to make it work, I'll be glad to review your patch. From what I know about descriptors and how method binding works, though, I bet it's nontrivial. -- Dave Abrahams Boost Consulting www.boost-consulting.com From gideon at computer.org Sun Sep 21 17:14:09 2003 From: gideon at computer.org (Gideon May) Date: Sun, 21 Sep 2003 17:14:09 +0200 Subject: [C++-sig] injected constructors In-Reply-To: References: Message-ID: <187922348.1064164449@localhost> --On Saturday, September 20, 2003 9:38 PM -0400 David Abrahams wrote: > Injected constructors are implemented, but not yet documented. See > libs/python/test/injected.[py/cpp] for examples. Great! Arrived exactly when I had a definite need for them. > > There have also been some changes to the concept requirements for > CallPolicies which have not yet been documented. If you have > problems with your custom-made policies with the current CVS state, > please let me know. Dave, when using return_internal_reference<>() with MSVC 7.0 I get the following warning using the most current CVS. Ciao, Gideon Warning dump : --------------------------------------------------------------------------- ---------------------------------------- vc-C++ ..\..\..\bin\boost\libs\python\osg\osg.pyd\vc7\release\BoundingSphere.obj BoundingSphere.cpp C:\cvs_rep\boost\boost\python\detail\caller.hpp(54) : warning C4307: '*' : integral constant overflow C:\cvs_rep\boost\boost\python\with_custodian_and_ward.hpp(84) : see reference to function template instantiation 'PyObje ct *boost::python::detail::get<-1>(PyObject *const & )' being compiled C:\cvs_rep\boost\boost\python\detail\caller.hpp(218) : see reference to function template instantiation 'PyObject *boost ::python::with_custodian_and_ward_postcall::pos tcall(const ArgumentPackage & ,PyObject *)' being com piled with [ custodian=0, ward=1, BasePolicy_=boost::python::default_call_policies, ArgumentPackage=argument_package ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(193) : while compiling class-template member function 'PyObject *boost:: python::detail::caller_arity<__formal>::impl::operator ()(PyObject *,PyObject *)' with [ __formal=1, F=osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void), Policies=boost::python::return_internal_reference<1,boost::python::default_ call_policies>, Sig=boost::mpl::vector2::ty pe &> ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(162) : see reference to class template instantiation 'boost::python::det ail::caller_arity<__formal>::impl' being compiled with [ __formal=1, F=osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void), Policies=boost::python::return_internal_reference<1,boost::python::default_ call_policies>, Sig=boost::mpl::vector2::ty pe &> ] C:\cvs_rep\boost\boost\python\make_function.hpp(62) : see reference to class template instantiation 'boost::python::deta il::caller' being compiled with [ F=osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void), CallPolicies=boost::python::return_internal_reference<1,boost::python::defa ult_call_policies>, Sig=boost::mpl::vector2::ty pe &> ] C:\cvs_rep\boost\boost\python\make_function.hpp(144) : see reference to function template instantiation 'boost::python:: api::object boost::python::detail::make_function_aux(F,const boost::python::return_internal_reference &,c onst boost::mpl::vector2 &,const boost::python::detail::keyword_range &,boost::mpl::int_)' being co mpiled with [ F=osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void), owner_arg=1, BasePolicy_=boost::python::default_call_policies, T0=osg::Vec3 &, T1=boost::python::detail::most_derived::type &, BOOST_PP_ITERATION_0=0 ] C:\cvs_rep\boost\boost\python\class.hpp(506) : see reference to function template instantiation 'boost::python::api::obj ect boost::python::make_function(F,const boost::python::return_internal_reference &,const boost::python:: detail::tuple_extract_impl::apply::result_type &,const boost::mpl::vector2 &)' being compiled with [ F=osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void), owner_arg=1, BasePolicy_=boost::python::default_call_policies, matched=false, Tuple=boost::python::detail::def_helper,boost::python::detail::not_specified,boost::python::detail::not_specif ied,boost::python::detail::not_specified>::all_t, Predicate=boost::mpl::aux::lambda_impl<1,true>::result_,boost::mpl::void_>::type, T0=osg::Vec3 &, T1=boost::python::detail::most_derived::type & ] C:\cvs_rep\boost\boost\python\class.hpp(571) : see reference to function template instantiation 'void boost::python::cla ss_::def_impl(const char *,osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void),const boost::python::detail::def_he lper &,...)' being compiled with [ T=osg::BoundingSphere, X1=boost::python::detail::not_specified, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified, T1=boost::python::return_internal_reference<1,boost::python::default_call_p olicies>, T2=boost::python::detail::not_specified, T3=boost::python::detail::not_specified, T4=boost::python::detail::not_specified ] C:\cvs_rep\boost\boost\python\class.hpp(304) : see reference to function template instantiation 'void boost::python::cla ss_::def_maybe_overloads(const char *,osg::Vec3 &(__thiscall osg::BoundingSphere::* )(void),const boost::python::ret urn_internal_reference &,...)' being compiled with [ T=osg::BoundingSphere, X1=boost::python::detail::not_specified, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified, owner_arg=1, BasePolicy_=boost::python::default_call_policies ] ..\..\..\libs\python\osg\osg\BoundingSphere.cpp(46) : see reference to function template instantiation 'boost::python::c lass_::self &boost::python::class_::def(const char *,osg::Vec3 &(__thiscall osg::BoundingSphere::* )(voi d),const boost::python::return_internal_reference &)' being compiled with [ T=osg::BoundingSphere, X1=boost::python::detail::not_specified, X2=boost::python::detail::not_specified, X3=boost::python::detail::not_specified, owner_arg=1, BasePolicy_=boost::python::default_call_policies ] --------------------------------------------------------------------------- ----------------------------------------- The code snippet is here : class_("BoundingSphere", "General purpose bounding sphere class for enclosing nodes/objects/vertices.\n" "Used to bound internal osg::Node's in the scene,\n" "to assist in view frustum culling etc. Similar in function to BoundingBox\n" "but is quicker for evaluating culling, but generally encloses a greater volume\n" "than a BoundingBox so will not cull so aggressively.\n") .def_readwrite("_center", &osg::BoundingSphere::_center) .def_readwrite("_radius", &osg::BoundingSphere::_radius) .def(init()) .def("init", &osg::BoundingSphere::init, "initialize to invalid values to represent an unset bounding sphere.") .def("valid", &osg::BoundingSphere::valid, "return true if the bounding sphere contains valid values,\n" "false if the bounding sphere is effectively unset.") .def("set", &osg::BoundingSphere::set, "set bounding sphere.") .def("radius", (float(osg::BoundingSphere::*)()const)&osg::BoundingSphere::radius) .def("center", (osg::Vec3&(osg::BoundingSphere::*)()) &osg::BoundingSphere::center, return_internal_reference<>()) // <------------- Warning occurs here .def("contains", &osg::BoundingSphere::contains, "return true is vertex v is within the sphere.") .def("intersects", &osg::BoundingSphere::intersects, "return true if bounding sphere's intersect each other.") ; From dave at boost-consulting.com Sun Sep 21 17:18:06 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 21 Sep 2003 11:18:06 -0400 Subject: [C++-sig] Re: injected constructors References: <187922348.1064164449@localhost> Message-ID: Gideon May writes: > --On Saturday, September 20, 2003 9:38 PM -0400 David Abrahams > wrote: >> Injected constructors are implemented, but not yet documented. See >> libs/python/test/injected.[py/cpp] for examples. > > Great! Arrived exactly when I had a definite need for them. > >> >> There have also been some changes to the concept requirements for >> CallPolicies which have not yet been documented. If you have >> problems with your custom-made policies with the current CVS state, >> please let me know. > > Dave, when using return_internal_reference<>() with MSVC 7.0 I get > the following warning using the most current CVS. The code snippet is missing the definitions of classes, etc. Can't you produce a minimal test case? I don't even see make_constructor in here. > The code snippet is here : > > class_("BoundingSphere", > "General purpose bounding sphere class for enclosing > nodes/objects/vertices.\n" > "Used to bound internal osg::Node's in the scene,\n" > "to assist in view frustum culling etc. Similar in > function to BoundingBox\n" > "but is quicker for evaluating culling, but generally > encloses a greater volume\n" > "than a BoundingBox so will not cull so aggressively.\n") > .def_readwrite("_center", &osg::BoundingSphere::_center) > .def_readwrite("_radius", &osg::BoundingSphere::_radius) > .def(init()) > .def("init", &osg::BoundingSphere::init, > "initialize to invalid values to represent an unset > bounding sphere.") > .def("valid", &osg::BoundingSphere::valid, > "return true if the bounding sphere contains valid values,\n" > "false if the bounding sphere is effectively unset.") > .def("set", > &osg::BoundingSphere::set, > "set bounding sphere.") > .def("radius", > (float(osg::BoundingSphere::*)()const)&osg::BoundingSphere::radius) > .def("center", > (osg::Vec3&(osg::BoundingSphere::*)()) > &osg::BoundingSphere::center, > return_internal_reference<>()) // > <------------- Warning occurs here > .def("contains", &osg::BoundingSphere::contains, > "return true is vertex v is within the sphere.") > .def("intersects", &osg::BoundingSphere::intersects, > "return true if bounding sphere's intersect each other.") > ; -- Dave Abrahams Boost Consulting www.boost-consulting.com From gideon at computer.org Sun Sep 21 18:52:15 2003 From: gideon at computer.org (Gideon May) Date: Sun, 21 Sep 2003 18:52:15 +0200 Subject: [C++-sig] Re: injected constructors In-Reply-To: References: <187922348.1064164449@localhost> Message-ID: <193808201.1064170335@localhost> Dave, I need some more time on the test case, a simple one compiles fine. But the compiler gives an error while compiling the opaque test from the test directory. Here is the output : vc-C++ ..\..\..\bin\boost\libs\python\test\opaque_ext.pyd\vc7\release\opaque.obj opaque.cpp C:\cvs_rep\boost\boost\python\detail\invoke.hpp(76) : error C2662: 'boost::python::detail::opaque_conversion_holder::operator`()'' : cannot convert 'this' pointer from 'const result_converter' to 'boost::python::detail::opaque_conversion_ holder &' with [ Pointer=result_t ] Conversion loses qualifiers C:\cvs_rep\boost\boost\python\detail\caller.hpp(216) : see reference to function template instantiation 'PyObject *boost ::python::detail::invoke(boost::python::detail::invoke_tag_,const result_converter &,opaque_ (__cdecl *& )(v oid))' being compiled with [ void_return=false, member=false ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(193) : while compiling class-template member function 'PyObject *boost:: python::detail::caller_arity<__formal>::impl::operator ()(PyObject *,PyObject *)' with [ __formal=0, F=opaque_ (__cdecl *)(void), Policies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(162) : see reference to class template instantiation 'boost::python::det ail::caller_arity<__formal>::impl' being compiled with [ __formal=0, F=opaque_ (__cdecl *)(void), Policies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\make_function.hpp(62) : see reference to class template instantiation 'boost::python::deta il::caller' being compiled with [ F=opaque_ (__cdecl *)(void), CallPolicies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\make_function.hpp(79) : see reference to function template instantiation 'boost::python::a pi::object boost::python::detail::make_function_aux(F,const boost::python::return_value_policy &,const boost::mpl::vector1 &,const boost::python::detail::keyword_range &,boost::mpl::int_)' bei ng compiled with [ F=opaque (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, T0=opaque , BOOST_PP_ITERATION_0=0 ] C:\cvs_rep\boost\boost\python\make_function.hpp(127) : see reference to function template instantiation 'boost::python:: api::object boost::python::detail::make_function_dispatch(F,const boost::python::return_value_policy &,const boost::python::detail::tuple_extract_impl::apply: :result_type &,boost::mpl::true_)' being compiled with [ F=opaque (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, matched=false, Tuple=boost::python::detail::def_helper,boost::python::detail::not_specified,boos t::python::detail::not_specified,boost::python::detai l::not_specified>::all_t, Predicate=boost::mpl::aux::lambda_impl<1,true>::result_,boost::mpl::void_>::type ] C:\cvs_rep\boost\boost\python\def.hpp(47) : see reference to function template instantiation 'boost::python::api::object boost::python::make_function(F,const boost::python::return_value_policy &,const boost::py thon::detail::tuple_extract_impl::apply::result_t ype &)' being compiled with [ F=opaque (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, matched=false, Tuple=boost::python::detail::def_helper,boost::python::detail::not_specified,boos t::python::detail::not_specified,boost::python::detai l::not_specified>::all_t, Predicate=boost::mpl::aux::lambda_impl<1,true>::result_,boost::mpl::void_>::type ] C:\cvs_rep\boost\boost\python\def.hpp(66) : see reference to function template instantiation 'void boost::python::detail ::def_from_helper(const char *,opaque_ (__cdecl *const & )(void),const boost::python::detail::def_helper &)' being compiled with [ T1=boost::python::return_value_policy, T2=boost::python::detail::not_specified, T3=boost::python::detail::not_specified, T4=boost::python::detail::not_specified ] C:\cvs_rep\boost\boost\python\def.hpp(98) : see reference to function template instantiation 'void boost::python::detail ::def_maybe_overloads(const char *,opaque_ (__cdecl *)(void),const boost::python::return_value_policy &,...)' being compiled with [ ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies ] ..\..\..\libs\python\test\opaque.cpp(63) : see reference to function template instantiation 'void boost::python::def(con st char *,opaque_ (__cdecl *)(void),const boost::python::return_value_policy &)' being com piled with [ ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies ] C:\cvs_rep\boost\boost\python\detail\invoke.hpp(76) : error C2064: term does not evaluate to a function C:\cvs_rep\boost\boost\python\detail\invoke.hpp(76) : error C2662: 'boost::python::detail::opaque_conversion_holder::operator`()'' : cannot convert 'this' pointer from 'const result_converter' to 'boost::python::detail::opaque_conversion _holder &' with [ Pointer=result_t ] Conversion loses qualifiers C:\cvs_rep\boost\boost\python\detail\caller.hpp(216) : see reference to function template instantiation 'PyObject *boost ::python::detail::invoke(boost::python::detail::invoke_tag_,const result_converter &,opaque2_ (__cdecl *& )( void))' being compiled with [ void_return=false, member=false ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(193) : while compiling class-template member function 'PyObject *boost:: python::detail::caller_arity<__formal>::impl::operator ()(PyObject *,PyObject *)' with [ __formal=0, F=opaque2_ (__cdecl *)(void), Policies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\detail\caller.hpp(162) : see reference to class template instantiation 'boost::python::det ail::caller_arity<__formal>::impl' being compiled with [ __formal=0, F=opaque2_ (__cdecl *)(void), Policies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\make_function.hpp(62) : see reference to class template instantiation 'boost::python::deta il::caller' being compiled with [ F=opaque2_ (__cdecl *)(void), CallPolicies=boost::python::return_value_policy, Sig=boost::mpl::vector1 ] C:\cvs_rep\boost\boost\python\make_function.hpp(79) : see reference to function template instantiation 'boost::python::a pi::object boost::python::detail::make_function_aux(F,const boost::python::return_value_policy &,const boost::mpl::vector1 &,const boost::python::detail::keyword_range &,boost::mpl::int_)' bei ng compiled with [ F=opaque2 (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, T0=opaque2 , BOOST_PP_ITERATION_0=0 ] C:\cvs_rep\boost\boost\python\make_function.hpp(127) : see reference to function template instantiation 'boost::python:: api::object boost::python::detail::make_function_dispatch(F,const boost::python::return_value_policy &,const boost::python::detail::tuple_extract_impl::apply: :result_type &,boost::mpl::true_)' being compiled with [ F=opaque2 (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, matched=false, Tuple=boost::python::detail::def_helper,boost::python::detail::not_specified,boos t::python::detail::not_specified,boost::python::detai l::not_specified>::all_t, Predicate=boost::mpl::aux::lambda_impl<1,true>::result_,boost::mpl::void_>::type ] C:\cvs_rep\boost\boost\python\def.hpp(47) : see reference to function template instantiation 'boost::python::api::object boost::python::make_function(F,const boost::python::return_value_policy &,const boost::py thon::detail::tuple_extract_impl::apply::result_t ype &)' being compiled with [ F=opaque2 (__cdecl *)(void), ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies, matched=false, Tuple=boost::python::detail::def_helper,boost::python::detail::not_specified,boos t::python::detail::not_specified,boost::python::detai l::not_specified>::all_t, Predicate=boost::mpl::aux::lambda_impl<1,true>::result_,boost::mpl::void_>::type ] C:\cvs_rep\boost\boost\python\def.hpp(66) : see reference to function template instantiation 'void boost::python::detail ::def_from_helper(const char *,opaque2_ (__cdecl *const & )(void),const boost::python::detail::def_helper &)' being compiled with [ T1=boost::python::return_value_policy, T2=boost::python::detail::not_specified, T3=boost::python::detail::not_specified, T4=boost::python::detail::not_specified ] C:\cvs_rep\boost\boost\python\def.hpp(98) : see reference to function template instantiation 'void boost::python::detail ::def_maybe_overloads(const char *,opaque2_ (__cdecl *)(void),const boost::python::return_value_policy &,...)' being compiled with [ ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies ] ..\..\..\libs\python\test\opaque.cpp(72) : see reference to function template instantiation 'void boost::python::def(con st char *,opaque2_ (__cdecl *)(void),const boost::python::return_value_policy &)' being co mpiled with [ ResultConverterGenerator=boost::python::return_opaque_pointer, BasePolicy_=boost::python::default_call_policies ] C:\cvs_rep\boost\boost\python\detail\invoke.hpp(76) : error C2064: term does not evaluate to a function "cl" /Zm800 -nologo -GX -c -DNDEBUG -DNDEBUG -DBOOST_PYTHON_DYNAMIC_LIB /Ogity /O2 /Gs /Ob2 /GX /GR /MD /Op /Zc:wchar_t, forScope -I"..\..\..\bin\boost\libs\python\test" -I"C:\cvs_rep\boost" -I"C:\Python22\include" -I"C:\Program Files\Microsoft Vi sual Studio .NET\VC7\include" -Fo"..\..\..\bin\boost\libs\python\test\opaque_ext.pyd\vc7\release\opaque.o bj" -Tp"..\..\..\lib s\python\test\opaque.cpp" ...failed vc-C++ ..\..\..\bin\boost\libs\python\test\opaque_ext.pyd\vc7\release\opaque.obj... ...skipped <@boost!libs!python!test\opaque_ext.pyd\vc7\release>opaque_ext.CMD for lack of <@boost!libs!python!test\opaque_ext.py d\vc7\release>opaque.obj... ...skipped <@boost!libs!python!test\opaque_ext.pyd\vc7\release>opaque_ext.pyd for lack of <@boost!libs!python!test\opaque_ext.py d\vc7\release>opaque_ext.CMD... ...skipped <@boost!libs!python!test\opaque_ext.pyd\vc7\release>opaque_ext.lib for lack of <@boost!libs!python!test\opaque_ext.py d\vc7\release>opaque_ext.CMD... vc-C++ ..\..\..\bin\boost\libs\python\test\raw_pyobject_fail1.test\vc7\release\raw _pyobject_fail1.obj raw_pyobject_fail1.cpp C:\cvs_rep\boost\boost\python\converter\arg_to_python.hpp(182) : error C2027: use of undefined type 'boost::python::converter::d etail::cannot_convert_raw_PyObject' with [ T=PyTypeObject * ] C:\cvs_rep\boost\boost\python\converter\arg_to_python.hpp(181) : while compiling class-template member function 'void bo ost::python::converter::detail::reject_raw_object_helper: :error(Convertibility)' with [ T=PyTypeObject, Convertibility=boost::python::detail::no_convertible ] C:\cvs_rep\boost\boost\python\converter\arg_to_python.hpp(195) : see reference to class template instantiation 'boost::p ython::converter::detail::reject_raw_object_helper' being compiled with [ T=PyTypeObject, Convertibility=boost::python::detail::no_convertible ] C:\cvs_rep\boost\boost\python\converter\arg_to_python.hpp(218) : see reference to function template instantiation 'void boost::python::converter::detail::reject_raw_object_ptr(T *)' being compiled with [ T=PyTypeObject ] C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xlocnum(80) : while compiling class-template member function ' boost::python::converter::detail::pointer_deep_arg_to_python::pointer_ deep_arg_to_python(Ptr)' with [ Ptr=_typeobject * ] C:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xmemory(136) : while compiling class-template member function 'boost::python::converter::arg_to_python::arg_to_python(const T & )' with [ T=PyTypeObject * ] ..\..\..\libs\python\test\raw_pyobject_fail1.cpp(10) : see reference to class template instantiation 'boost::python::con verter::arg_to_python' being compiled with [ T=PyTypeObject * ] C:\cvs_rep\boost\boost\python\converter\arg_to_python.hpp(182) : error C2065: 'to_python_use_handle_instead' : undeclared identi fier Ciao, Gideon From dave at boost-consulting.com Sun Sep 21 19:22:45 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 21 Sep 2003 13:22:45 -0400 Subject: [C++-sig] Re: injected constructors References: <187922348.1064164449@localhost> <193808201.1064170335@localhost> Message-ID: Gideon May writes: > Dave, > > I need some more time on the test case, a simple one compiles fine. > But the compiler gives an error while compiling the opaque test from > the test directory. Thanks for the report; it's an easy fix: -------------- next part -------------- A non-text attachment was scrubbed... Name: return_opaque_pointer.patch Type: text/x-patch Size: 629 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Sun Sep 21 19:28:35 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sun, 21 Sep 2003 14:28:35 -0300 Subject: [C++-sig] Pyste bugs again In-Reply-To: <3F6BB271.23944.58DD716@localhost> References: <3F6A7368.2678.AF9D65@localhost> <3F6BB271.23944.58DD716@localhost> Message-ID: <3F6DDFC3.9010303@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 19 Sep 2003 at 20:12, Nicodemus wrote: > > > >>The reason is that if we made it so that all enums were exported with >>export_values, then it would break code that expected the old >>behaviour. But I must say that I prefer enums with export_values, >>since they mirror better in Python the same semathics of enums in C++. >> >> > >Cool. And thanks. > >BTW what do the new commands do? There's nothing in the docs yet. > > Depends on the commands. 8) I plan to have the documentation updated soon, btw. Regards, Nicodemus. From nicodemus at globalite.com.br Sun Sep 21 19:32:52 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sun, 21 Sep 2003 14:32:52 -0300 Subject: [C++-sig] Pyste bug: can't set different return policies on method In-Reply-To: <3F6CFD9D.12779.A9B7B44@localhost> References: <3F6CFD9D.12779.A9B7B44@localhost> Message-ID: <3F6DE0C4.6010201@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >In a class like as follows: > >class FXFile >{ > const FXString &name() const; > static FXString name(const FXString &file); >}; > >Pyste gets the two name()'s confused and tries to apply >return_internal_reference to both. If I try to override and set one >of the name()'s to something different, the pyste syntax doesn't let >me. > >Solutions? I figured I can temporarily >return_value_policy(manage_new_object)) but in other situations this >wouldn't be possible. > That's a limitation of Pyste right now. One of the future plans is to allow metaprogramming inside the pyste files, which would allow you to do something like this: FXFile = Class(...) if not FXFile.name.static: set_policy(FXFile.name, return_internal_reference) But this might take a while to be implemented... I haven't had much time to work on Pyste lately. But what you think of this solution? Regards, Nicodemus. From nicodemus at globalite.com.br Sun Sep 21 19:34:49 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sun, 21 Sep 2003 14:34:49 -0300 Subject: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC In-Reply-To: <3F6CFB25.8233.A91D878@localhost> References: <3F6CFB25.8233.A91D878@localhost> Message-ID: <3F6DE139.4030203@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >It outputs things like "long long unsigned int" which MSVC barfs on. > >Fix is in GCCXMLParser.py: > > def ParseFundamentalType(self, id, element): > name = element.get('name') > if name=="long long int": > name="__int64" > elif name=="long long unsigned int": > name="unsigned __int64" > type_ = FundamentalType(name) > self.Update(id, type_) > >Obviously this would break GCC. Nicodemus I think you'll need a -- >msvc switch which lets you switch in MSVC specific output. > > Seems like so, unfortunately. How about a --msvc command line switch? Regards, Nicodemus. From gideon at computer.org Sun Sep 21 20:01:45 2003 From: gideon at computer.org (Gideon May) Date: Sun, 21 Sep 2003 20:01:45 +0200 Subject: [C++-sig] Re: injected constructors In-Reply-To: References: <187922348.1064164449@localhost> Message-ID: <197977857.1064174505@localhost> Dave, --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams wrote: > The code snippet is missing the definitions of classes, etc. Can't > you produce a minimal test case? I don't even see make_constructor > in here. I just realized that I compiled with warning level 3. The warning doesn't show up with the default warning level. I've created a simple (contrived) test case which shows the warning : ----------------------------------------------- #include #include #include #include using namespace boost::python; struct Vec3 { }; struct Bound { Vec3& getVec() { return _vec; } protected: Vec3 _vec; }; BOOST_PYTHON_MODULE(test_internal_reference) { class_("Vec3"); class_("Bound") .def("getVec", &Bound::getVec, return_internal_reference<>()) ; } #include "module_tail.cpp" --------------------------------------------------------- This is the entry in the test/Jamfile : -------------------------------------------------------- bpl-test internal_reference : : "-W3 -EHa" ; -------------------------------------------------------- Ciao, Gideon From dave at boost-consulting.com Sun Sep 21 20:48:38 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 21 Sep 2003 14:48:38 -0400 Subject: [C++-sig] Re: injected constructors References: <187922348.1064164449@localhost> <197977857.1064174505@localhost> Message-ID: Gideon May writes: > Dave, > > --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams > wrote: >> The code snippet is missing the definitions of classes, etc. Can't >> you produce a minimal test case? I don't even see make_constructor >> in here. > > I just realized that I compiled with warning level 3. The warning doesn't > show up with the default warning level. I've created a simple > (contrived) test case which > shows the warning : Oh, how annoying! But thanks for the pointer. The enclosed patch fixes it. -------------- next part -------------- A non-text attachment was scrubbed... Name: with_custodian_and_ward.patch Type: text/x-patch Size: 1309 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sun Sep 21 20:50:07 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 21 Sep 2003 14:50:07 -0400 Subject: [C++-sig] Re: injected constructors References: <187922348.1064164449@localhost> <197977857.1064174505@localhost> Message-ID: David Abrahams writes: > Gideon May writes: > >> Dave, >> >> --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams >> wrote: >>> The code snippet is missing the definitions of classes, etc. Can't >>> you produce a minimal test case? I don't even see make_constructor >>> in here. >> >> I just realized that I compiled with warning level 3. The warning doesn't >> show up with the default warning level. I've created a simple >> (contrived) test case which >> shows the warning : > > Oh, how annoying! But thanks for the pointer. The enclosed patch > fixes it. Whoops, I mean this: -------------- next part -------------- A non-text attachment was scrubbed... Name: with_custodian_and_ward.patch Type: text/x-patch Size: 1546 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From gideon at computer.org Sun Sep 21 21:10:36 2003 From: gideon at computer.org (Gideon May) Date: Sun, 21 Sep 2003 21:10:36 +0200 Subject: [C++-sig] Re: injected constructors In-Reply-To: References: <187922348.1064164449@localhost> <197977857.1064174505@localhost> Message-ID: <202108656.1064178636@localhost> --On Sunday, September 21, 2003 2:50 PM -0400 David Abrahams wrote: >> Gideon May writes: >> >>> Dave, >>> >>> --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams >>>> The code snippet is missing the definitions of classes, etc. Can't >>>> you produce a minimal test case? I don't even see make_constructor >>>> in here. >>> >>> I just realized that I compiled with warning level 3. The warning >>> doesn't show up with the default warning level. I've created a simple >>> (contrived) test case which >> >> Oh, how annoying! But thanks for the pointer. The enclosed patch >> fixes it. > > Whoops, I mean this: > Hmmm, deep zen :) But, I applied the patch from the previous message and now the compiler is happily, silently crunching away. Thanks! PS, the injected constructors work great! Not to bug, but can we expect a release soonish ? There are so many new features which I am using and I would love to release an update of my bindings based on the current BPL. Ciao, Gideon From gideon at computer.org Sun Sep 21 21:12:05 2003 From: gideon at computer.org (Gideon May) Date: Sun, 21 Sep 2003 21:12:05 +0200 Subject: [C++-sig] Re: injected constructors In-Reply-To: <202108656.1064178636@localhost> References: <187922348.1064164449@localhost> <197977857.1064174505@localhost> mxzilla1.xs4all.nl <202108656.1064178636@localhost> Message-ID: <202197494.1064178725@localhost> Was too fast and didn't see the attachment, still BPL is magic :) --On Sunday, September 21, 2003 9:10 PM +0200 Gideon May wrote: > > > --On Sunday, September 21, 2003 2:50 PM -0400 David Abrahams > wrote: > >>> Gideon May writes: >>> >>>> Dave, >>>> >>>> --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams >>>>> The code snippet is missing the definitions of classes, etc. Can't >>>>> you produce a minimal test case? I don't even see make_constructor >>>>> in here. >>>> >>>> I just realized that I compiled with warning level 3. The warning >>>> doesn't show up with the default warning level. I've created a simple >>>> (contrived) test case which >>> >>> Oh, how annoying! But thanks for the pointer. The enclosed patch >>> fixes it. >> >> Whoops, I mean this: >> > > Hmmm, deep zen :) > > But, I applied the patch from the previous message and now > the compiler is happily, silently crunching away. > > Thanks! > > PS, the injected constructors work great! > Not to bug, but can we expect a release soonish ? There > are so many new features which I am using and I would love > to release an update of my bindings based on the current BPL. > > Ciao, > Gideon > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > From dave at boost-consulting.com Sun Sep 21 23:06:24 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 21 Sep 2003 17:06:24 -0400 Subject: [C++-sig] Re: injected constructors References: <187922348.1064164449@localhost> <197977857.1064174505@localhost> <202108656.1064178636@localhost> Message-ID: Gideon May writes: > --On Sunday, September 21, 2003 2:50 PM -0400 David Abrahams > wrote: > >>> Gideon May writes: >>> >>>> Dave, >>>> >>>> --On Sunday, September 21, 2003 11:18 AM -0400 David Abrahams >>>>> The code snippet is missing the definitions of classes, etc. Can't >>>>> you produce a minimal test case? I don't even see make_constructor >>>>> in here. >>>> >>>> I just realized that I compiled with warning level 3. The warning >>>> doesn't show up with the default warning level. I've created a simple >>>> (contrived) test case which >>> >>> Oh, how annoying! But thanks for the pointer. The enclosed patch >>> fixes it. >> >> Whoops, I mean this: >> > > Hmmm, deep zen :) > > But, I applied the patch from the previous message and now > the compiler is happily, silently crunching away. > > Thanks! > > PS, the injected constructors work great! > Not to bug, but can we expect a release soonish ? There > are so many new features which I am using and I would love > to release an update of my bindings based on the current BPL. Ask on the Boost developers' list. It's not up to me alone. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Mon Sep 22 19:20:59 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 22 Sep 2003 18:20:59 +0100 Subject: [C++-sig] Way to insert code in _main.cpp in pyste In-Reply-To: <3F6D02CB.8030005@globalite.com.br> References: <3F6D0255.30802.AADEC08@localhost> Message-ID: <3F6F3D8B.17179.136534A6@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 22:45, Nicodemus wrote: > Must it be after BOOST_PYTHON_MODULE? If not, you can use the function > declaration_code() in your Pyste file. To insert code inside > BOOST_PYTHON_MODULE, use module_code(). Kinda like this: // Exports ====================================================================void RegisterConvFXString(); void RegisterExceptionTrans(); void Export_TnFOX_Python_FXFile(); // Module =====================================================================BOOST_PYTHON_MODULE(TnFOX) { RegisterConvFXString(); RegisterExceptionTrans(); Export_TnFOX_Python_FXFile(); } BTW those two commands you suggest don't appear to have any docs. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP28ve8EcvDLFGKbPEQIB8ACg+UhLP9vSvSSUfm4zQ3hSPpYgNooAoN8S J3hcXlX2HPaE5f0fL3dYbAbP =e8bF -----END PGP SIGNATURE----- From mike at nospam.com Mon Sep 22 21:24:28 2003 From: mike at nospam.com (Mike Rovner) Date: Mon, 22 Sep 2003 12:24:28 -0700 Subject: [C++-sig] Re: Re: Re: [Implementation] Calling wrapped functions, converters, policies References: <3F6BACFE.13558.5788E1D@localhost> Message-ID: Niall Douglas wrote: > (I would have sent this off-list, but your email address is false?) See Reply-To field ;) > Ah, thanks for that tip. You are welcome. Mike From mike at nospam.com Mon Sep 22 21:50:11 2003 From: mike at nospam.com (Mike Rovner) Date: Mon, 22 Sep 2003 12:50:11 -0700 Subject: [C++-sig] Re: Exception translation to python classes References: <3F6D1A3A.27565.B0B4109@localhost> Message-ID: Niall Douglas wrote: > I was wondering if anyone had any experience or could point me to > some example code for translating C++ exceptions by using > PyErr_SetObject to the Boost.Python wrap of the appropriate C++ > exception object. I'm not quite sure what are you talking about. PyErr_SetString is a simple wrapper for the PyErr_SetObject to make your life easier Consider: try: some() except Exception, e: recover(e) You can have any 'e' as you wish. First call set it to a string, second to any python object. So in my code: static void exc_translator(Env::EGeneric* const& x) { PyErr_SetString(PyExc_RuntimeError, x->what() ); } ...// later register_exception_translator(&exc_translator); I use a string but (I suppose) you can put: { PyErr_SetObject(PyExc_RuntimeError, python::object(x) ); } for any wrapped C++ instance 'x'; get it in your python code above as 'e' and go from there, say call any (wrapped) method of x. HTH, Mike From s_sourceforge at nedprod.com Tue Sep 23 00:25:42 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 22 Sep 2003 23:25:42 +0100 Subject: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC In-Reply-To: <3F6DE139.4030203@globalite.com.br> References: <3F6CFB25.8233.A91D878@localhost> Message-ID: <3F6F84F6.20950.147C30C1@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Sep 2003 at 14:34, Nicodemus wrote: > >Obviously this would break GCC. Nicodemus I think you'll need a -- > >msvc switch which lets you switch in MSVC specific output. > > Seems like so, unfortunately. How about a --msvc command line switch? Actually I had a thought on this. Doesn't Boost provide a macro resolving to a signed and unsigned 64 bit int? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2925sEcvDLFGKbPEQJXLgCeK9HKdWWkiBFZs2Di0Uypv9tsCFIAn2+w U6du6pLKXjvEqizpkNTDXE9+ =sFaq -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Tue Sep 23 00:21:55 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 22 Sep 2003 23:21:55 +0100 Subject: [C++-sig] Re: Boost.Python not resolving overloads In-Reply-To: Message-ID: <3F6F8413.8392.1478BAC5@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Sep 2003 at 23:42, David Abrahams wrote: > > Might it be an idea in the name of flexibility that boost.python > > marks mixed static and non-static functions and tries matching the > > static one first. If that fails, then it makes the first parameter > > "self" and tries again. > > It *might* be an idea. If you can figure out how to make it work, > I'll be glad to review your patch. From what I know about descriptors > and how method binding works, though, I bet it's nontrivial. I had an awful feeling you might say that. Ok, tell me this: is function::call() the right place to alter? If so, it would appear to me to be trivial - just insert the object instance as the first parameter if all else fails. As for adding knowledge if there are mixed static and non-static methods, well, as I've said before in here I really don't understand most of Boost.Python. I would imagine though that just altering the parameter matching loop wouldn't cause any existing code to break - so it should be okay? Would I post a patch here, or to you directly? And is GNU diff format okay? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP292BMEcvDLFGKbPEQI7qwCeILPv8uNmMFFjwSM+sf7kS+KaUVAAoPCx EJ+1PHie9aQvdTcUBGSsub89 =Ptl/ -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Tue Sep 23 00:24:32 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 22 Sep 2003 23:24:32 +0100 Subject: [C++-sig] Pyste bug: can't set different return policies on method In-Reply-To: <3F6DE0C4.6010201@globalite.com.br> References: <3F6CFD9D.12779.A9B7B44@localhost> Message-ID: <3F6F84B0.20799.147B1EA5@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Sep 2003 at 14:32, Nicodemus wrote: > That's a limitation of Pyste right now. One of the future plans is to > allow metaprogramming inside the pyste files, which would allow you to > do something like this: > > FXFile = Class(...) > > if not FXFile.name.static: > set_policy(FXFile.name, return_internal_reference) > > But this might take a while to be implemented... I haven't had much > time to work on Pyste lately. But what you think of this solution? Looks to me like you're making work for yourself. How about instead when pyste encounters two methods with the same name it puts an array at FXFile.name ie; now it's FXFile.name[0] and FXFile.name[1]. This ensures you don't accidentally set the policy incorrectly for both when you meant one of them, plus it's much easier to code. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA+AwUBP292oMEcvDLFGKbPEQIM1gCVG9/s4uRM2nea4hPOXanaiIzvaACdEvYD S8a1XOFcXvM6aCxaYMDxP4Y= =Yvy1 -----END PGP SIGNATURE----- From conanb at STCG.net Tue Sep 23 00:56:07 2003 From: conanb at STCG.net (Conan Brink) Date: Mon, 22 Sep 2003 15:56:07 -0700 Subject: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC Message-ID: There appear to be boost::int64_t and boost::uint64_t in , as part of the integer library, for those systems where they are not already defined in (cstdint.hpp will include stdint.h if it is available, or typedef the various integer types for itself if not) -Conan -----Original Message----- From: Niall Douglas [mailto:s_sourceforge at nedprod.com] Sent: Monday, September 22, 2003 3:26 PM To: c++-sig at python.org Subject: Re: [C++-sig] Bug: Pyste misoutputs 64 bit ints on MSVC -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Sep 2003 at 14:34, Nicodemus wrote: > >Obviously this would break GCC. Nicodemus I think you'll need a -- > >msvc switch which lets you switch in MSVC specific output. > > Seems like so, unfortunately. How about a --msvc command line switch? Actually I had a thought on this. Doesn't Boost provide a macro resolving to a signed and unsigned 64 bit int? Cheers, Niall This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive messages for the addressee), you may not use, copy, or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message. Nothing in this message should be interpreted as a digital or electronic signature that can be used to authenticate a contract or any other legal document. From dave at boost-consulting.com Tue Sep 23 01:11:48 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 22 Sep 2003 19:11:48 -0400 Subject: [C++-sig] Re: Boost.Python not resolving overloads References: <3F6F8413.8392.1478BAC5@localhost> Message-ID: "Niall Douglas" writes: > On 20 Sep 2003 at 23:42, David Abrahams wrote: > >> > Might it be an idea in the name of flexibility that boost.python >> > marks mixed static and non-static functions and tries matching the >> > static one first. If that fails, then it makes the first parameter >> > "self" and tries again. >> >> It *might* be an idea. If you can figure out how to make it work, >> I'll be glad to review your patch. From what I know about descriptors >> and how method binding works, though, I bet it's nontrivial. > > I had an awful feeling you might say that. > > Ok, tell me this: is function::call() the right place to alter? If I knew what the right place to alter was, I would probably think it's easy. I don't. I don't think you could do it correctly just by making changes in function::call. > If so, it would appear to me to be trivial - just insert the object > instance as the first parameter if all else fails. That is *not* the right fix. A regular member function with signature void (A::*)(A&, int); might inadvertently be called via >>> A().f(3) without issuing an error. Errors are good. If you want the library/language to guess at what you meant when you screw up instead of telling you what went wrong, you should be using Perl, not Python. > As for adding knowledge if there are mixed static and non-static > methods, well, as I've said before in here I really don't understand > most of Boost.Python. I would imagine though that just altering the > parameter matching loop wouldn't cause any existing code to break - > so it should be okay? Not a chance, sorry. I'll tell you what. Why don't you start by writing a doctest case which would succeed only with your proposed feature, and also includes calls like my example above that should fail overload resolution. We can look that over, and if it's acceptable to me, you can try to write a patch which makes the tests pass. > Would I post a patch here, or to you directly? And is GNU diff format > okay? Here and yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Tue Sep 23 01:16:26 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 23 Sep 2003 00:16:26 +0100 Subject: [C++-sig] Re: Exception translation to python classes In-Reply-To: Message-ID: <3F6F90DA.1998.14AAA49A@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Sep 2003 at 12:50, Mike Rovner wrote: > Niall Douglas wrote: > > > I was wondering if anyone had any experience or could point me to > > some example code for translating C++ exceptions by using > > PyErr_SetObject to the Boost.Python wrap of the appropriate C++ > > exception object. > > I'm not quite sure what are you talking about. Ok, an example then: FXException is my generic base class for all exceptions. It has bindings for Python ie; a FXException is available there too. I've registered an exception translator for FXException. If what you say below is correct, then it merely needs to be: void FXException_translator(const FXException &e) { PyErr_SetObject(PyExc_RuntimeError, python::object(e)); } ... and all should be good. If so, then my thanks again. This makes error reporting in python much more useful indeed as my exception class provides a stack backtrace plus line and file info of the C++ side. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2+Cy8EcvDLFGKbPEQKZPQCggXJIiovsg+j3r71fRKJ2FvmCZOEAn2GH bUFfXBN3Ju7JJVNIyxUOZt04 =BGwZ -----END PGP SIGNATURE----- From dave at boost-consulting.com Tue Sep 23 01:17:04 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 22 Sep 2003 19:17:04 -0400 Subject: [C++-sig] Re: Pyste bug: can't set different return policies on method References: <3F6CFD9D.12779.A9B7B44@localhost> <3F6F84B0.20799.147B1EA5@localhost> Message-ID: "Niall Douglas" writes: > On 21 Sep 2003 at 14:32, Nicodemus wrote: > >> That's a limitation of Pyste right now. One of the future plans is to >> allow metaprogramming inside the pyste files, which would allow you to >> do something like this: >> >> FXFile = Class(...) >> >> if not FXFile.name.static: >> set_policy(FXFile.name, return_internal_reference) >> >> But this might take a while to be implemented... I haven't had much >> time to work on Pyste lately. But what you think of this solution? > > Looks to me like you're making work for yourself. > > How about instead when pyste encounters two methods with the same > name it puts an array at FXFile.name ie; now it's FXFile.name[0] and > FXFile.name[1]. This ensures you don't accidentally set the policy > incorrectly for both when you meant one of them, plus it's much > easier to code. I like that idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Tue Sep 23 01:45:56 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Mon, 22 Sep 2003 20:45:56 -0300 Subject: [C++-sig] Way to insert code in _main.cpp in pyste In-Reply-To: <3F6F3D8B.17179.136534A6@localhost> References: <3F6D0255.30802.AADEC08@localhost> <3F6F3D8B.17179.136534A6@localhost> Message-ID: <3F6F89B4.4030501@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 20 Sep 2003 at 22:45, Nicodemus wrote: > > > >>Must it be after BOOST_PYTHON_MODULE? If not, you can use the function >>declaration_code() in your Pyste file. To insert code inside >>BOOST_PYTHON_MODULE, use module_code(). >> >> > >Kinda like this: > >// Exports >====================================================================void RegisterConvFXString(); >void RegisterExceptionTrans(); >void Export_TnFOX_Python_FXFile(); > >// Module >=====================================================================BOOST_PYTHON_MODULE(TnFOX) >{ > RegisterConvFXString(); > RegisterExceptionTrans(); > Export_TnFOX_Python_FXFile(); >} > > declaration_code('void Export_TnFOX_Python_FXFile();\n') module_code(' Export_TnFOX_Python_FXFile();\n') But I see you want it inside _main.cpp... there's currently no way to do that explicitly, but you can put it inside any other Pyste file and the effect will be the same, since inside BOOST_PYTHON_MODULE your Export_MyPysteFile() will called, which will then call your ExportExceptionTrans(), for example. Try that and see if it works. >BTW those two commands you suggest don't appear to have any docs. > They don't, that's why I posted an example. I plan to update the documentation by the end of the week. Thanks, Nicodemus. From qinlj at solidshare.com Tue Sep 23 03:17:03 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Tue, 23 Sep 2003 09:17:03 +0800 Subject: A feature request, and, Re: [C++-sig] Re: Exception translation to python classes References: <3F6F90DA.1998.14AAA49A@localhost> Message-ID: <00c401c38170$6db514d0$0200a8c0@barrack> Hi, I have the same problem several days ago, and I have found that Python (at least 2.2) need the exception class derived (directly or indirectly) from the standard "PyExc_Exception" class, so to use the ideal PyErr_SetObject(PyExc_MyException, InstanceOfMyException) -or in python- raise mymodule.MyException(arg1, arg2) form of code, you need to use the PyErr_NewException() API to create a new exception class derived from PyExc_Exception class. And to create '__init__' and '__str__' function, you also need to create two method object for two callable object. I have managed to make it work, but it need a lot of handcraft. I this process, I have found that if boost.python can support specifing an existing Python class as base class (or one of the basses), such as specify 'PyExc_Excetion' as the base class of the generated python class, it'll be a much simpler life for us. Lijun Qin http://www.solidshare.com ----- Original Message ----- From: "Niall Douglas" To: Sent: Tuesday, September 23, 2003 7:16 AM Subject: Re: [C++-sig] Re: Exception translation to python classes > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22 Sep 2003 at 12:50, Mike Rovner wrote: > > > Niall Douglas wrote: > > > > > I was wondering if anyone had any experience or could point me to > > > some example code for translating C++ exceptions by using > > > PyErr_SetObject to the Boost.Python wrap of the appropriate C++ > > > exception object. > > > > I'm not quite sure what are you talking about. > > Ok, an example then: > > FXException is my generic base class for all exceptions. It has > bindings for Python ie; a FXException is available there too. > > I've registered an exception translator for FXException. If what you > say below is correct, then it merely needs to be: > > void FXException_translator(const FXException &e) > { > PyErr_SetObject(PyExc_RuntimeError, python::object(e)); > } > > ... and all should be good. > > If so, then my thanks again. This makes error reporting in python > much more useful indeed as my exception class provides a stack > backtrace plus line and file info of the C++ side. > > Cheers, > Niall > > > > > > -----BEGIN PGP SIGNATURE----- > Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 > > iQA/AwUBP2+Cy8EcvDLFGKbPEQKZPQCggXJIiovsg+j3r71fRKJ2FvmCZOEAn2GH > bUFfXBN3Ju7JJVNIyxUOZt04 > =BGwZ > -----END PGP SIGNATURE----- > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From xavier.warin at der.edfgdf.fr Tue Sep 23 15:58:50 2003 From: xavier.warin at der.edfgdf.fr (Xavier WARIN(Compte LOCAL) - I23) Date: Tue, 23 Sep 2003 15:58:50 +0200 Subject: [C++-sig] Code Warrior and Boost python Message-ID: <3F70519A.6040302@der.edfgdf.fr> Hi , I try to use Boost V2 with codewarrior. I use version 7.0 that I have just upgraded to 7.2. While trying to compile the Boost python source files i get a weird error in cstdio generated by boost/comptibility/generate_cpp_c_headers.py I've got a lot of errors like : undefined identifier 'FILE' cstdio line 12 using::FILE ; undefined identifier 'fpos_t' cstdio line 13 using::fpos_t; etc ... What did i do wrong ? Any idea ? Thank you Xavier Warin From blais at discreet.com Mon Sep 22 20:22:40 2003 From: blais at discreet.com (Martin Blais) Date: Mon, 22 Sep 2003 14:22:40 -0400 Subject: [C++-sig] location of initialization matters? Message-ID: hi guys I've got a query related to initialization and Boost.Python. in a project i'm working on for a client, they have a pretty involved initialization framework which allows dynamically-loaded libraries to be initialized in the same order as the inter-library dependencies. Basically, for each package, they have a registration procedure that occurs upon loading the library (using static initialization), each package registers itself to a global singleton, and after all the libraries are loaded, the registered initialize/finalize functions are called in the proper order, order which is determined at compile time with auto-generated code that uses the linking info from their makefile. This requires specific function calls to their single library registry before loading any DLLs and after DLL loading has terminated, to trigger the initialization. They have a C++ interface for that (i.e. a guard). To solve the problem of loading Python extension modules linked with their C++ libraries, I have overridden the definition of import to make the calls to their init begin (before performing the real import) and init end (right after) which then triggers their init framework calls. Thus the initialization order is: 0. a call to import one of the extension modules is made; 1. from my overridden import, I call their init singleton to prepare for lib registration; 2. then I call original python import mechanism to load the ext. module as usual 3. the library gets loaded and registers itself to their init singleton; all dependent DLLs are also loaded and register to the init singleton as well (also registering their dependencies); 4. the usual ``initMODULE`` gets called by python, Boost.Python's init_module gets called; 5. import exits, and i make a call to their init singleton to signal we're done; at this point, all of their libraries' initialize() functions are called in the appropriate dependency order by their init singleton. The problem I'm having, is that I need for their libraries to have been initialized before I run the my Boost.Python code to export references, because some values that I want to export get set only during their initialization framework. Now this means that I need to perform the last two steps like this instead: ... 4. initMODULE gets called by python, does nothing because I declared almost nothing (just the module_builder object); 5. import exits, and i call their init singleton to termination initialization; at this point, all of their libraries' initialize() functions are called in the appropriate order by their init singleton. 6. within those initialize functions of each package, I run the code that I wrote that uses Boost.Python to register the classes and references to be exported to the Python interface. Basically, this means that the Boost.Python declarations are not executed within the ``init`` function/scope anymore, but rather a little bit later, within their own init framework. This used to work with Boost.Python v1; now, I'm porting to v2, and peeking inside the new Boost.Python, I see that there is the notion of a "current scope". The only thing that seems a prerequisite is that when initMODULE gets called, Python seems to require that Py_InitModule gets called. I can do that by using the usual Boost.Python macro, with an empty body for that function (i.e. not export any symbols). (I hope my description was clear enough.) A few questions: ---------------- A. do I need to recreate that scope object to be able to register new definitions? Will new definitions work fine even if not run from within the initMODULE function called from Python? In other words, can I arbitrarily define new types and bind new functions after initialization? B. I couldn't find documentation other than a note about "Automatic Cross-Module Type Conversions" about cross-module linking and usage. If my module links with other extension modules, do I need to call ``PyImport_ImportModule`` for this to work? I need to link with the other module for the symbols to resolve (this is under XP). I figure that if I do indeed move the init code within their own init framework, simply linking with another ext. module will call the boost code without having to tell Python about the virtual "import" that this creates (and I want to avoid having that function called twice, or at least protect against it). I'm not sure if that will register the module that is linked to properly though, i.e. if module B links with module A but does not otherwise import it, will module A show up as imported to the script? And what if module A is imported beforehand in the script? Hmm... C. Do you see any issues that may arise from this funky usage? From s_sourceforge at nedprod.com Tue Sep 23 05:07:24 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 23 Sep 2003 04:07:24 +0100 Subject: A feature request, and, Re: [C++-sig] Re: Exception translation to python classes In-Reply-To: <00c401c38170$6db514d0$0200a8c0@barrack> Message-ID: <3F6FC6FC.8418.157E17D3@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Sep 2003 at 9:17, Lijun Qin wrote: > form of code, you need to use the PyErr_NewException() API to create a > new exception class derived from PyExc_Exception class. And to create > '__init__' and '__str__' function, you also need to create two method > object for two callable object. I have managed to make it work, but it > need a lot of handcraft. Thanks for telling me this, you've just saved me a day of work. Dave, what do you think? > I this process, I have found that if boost.python can support > specifing an existing Python class as base class (or one of the > basses), such as specify 'PyExc_Excetion' as the base class of the > generated python class, it'll be a much simpler life for us. I agree. But it's not crucial for what I need, so I'll have my exception class generate a textual description and report that to python (ie; I'm going to cheat :) ) Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP2+47MEcvDLFGKbPEQKvCgCgwakEJYQp2pcr2g/JqqzZkW1LiVMAn30b wg9jEFvGmW25lYbrcCQYBv6F =bEB8 -----END PGP SIGNATURE----- From blais at iro.umontreal.ca Tue Sep 23 20:05:04 2003 From: blais at iro.umontreal.ca (Martin Blais) Date: Tue, 23 Sep 2003 14:05:04 -0400 Subject: [C++-sig] Re: location of initialization matters? In-Reply-To: References: Message-ID: just a follow up on this: I was able to recreate the scope object for my module by import "itself" from the project's init framework, which is executed after the Python initMODULE function is called, and since at that point the module has had its Py_InitModule() called, I assume that doing a PyImport_ImportModuleEx() after that won't have any other consequences. Here is the relevant code:: InInit::performInitialize() { ... initialize buff here { using namespace python; // Obtain the handle on the already imported module to create a // scope. PyObject* m = ::PyImport_ImportModuleEx( "libDLpyextModuleA", 0, 0, 0 ); assert( m != 0 ); scope module_scope( object( borrowed( m ) ) ); // Boost.Python declarations using initialized objects here. module_scope.attr( "buff" ) = buff; } } This "seems to work" (i.e. it compiles and doesn't crash and I can obtain the correct initialized value for the initialized buff). I think with this in mind, I could probably leave the initMODULE functions empty and always put my Boost.Python declarations in the project's performInitialize() methods. Do you see any potential problems with this? I'm sure some other projects must have had to do a similar trick. I guess my question boils down to: "can one safely declare new things for Python once the module has already been initialized?" (i.e. by "declare new things" I mean insert Boost.Python declarations, for example, could I declare a new class within a function call? (i.e not the initMODULE function)) From blais at iro.umontreal.ca Tue Sep 23 22:27:08 2003 From: blais at iro.umontreal.ca (Martin Blais) Date: Tue, 23 Sep 2003 16:27:08 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string In-Reply-To: <20030527184242.56902.qmail@web20210.mail.yahoo.com> References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> Message-ID: <3F70AC9C.1040907@iro.umontreal.ca> Hi guys I just found the mail below, answers one of my questions, and AFAIK the answer for my query is not clearly there in the Boost.Python docos. In fact, porting code from v1 to v2, I think that this should be in the FAQ for the following question: "How do I register automatic conversions to/from a specific C++ class without exposing the C++ class itself to the Python interface?" in v1, I used to do with by declaring to_python and from_python converter methods in the appropriate namespace. The C++ class that was converted was not known to the Python interface at all. I think the example below seems to address my query, I tried it and it works. It would be nice to add this capability to the FAQ or docs. also, maybe I'm going about this wrong, but it seems to perform this task in v1 was cleaner... is there a better way? I'm sure there must be but I just didn't find it. If there is no better way, some C++ code magic to wrap this up and make it look nicer would be a desired feature IMHO. Note that I wouldn't mind wrapping up and exposing the class instead, if the implicit converters would always be triggered such that my users never have to be aware of the existence of the corresponding C++ class; I tried changing my C++ class to add implicit conversions but it doesn't get triggered somehow, here is an example, with a MyPath class that I would like to be automatically convertible from/to a Python string:: class MyPath { public: /*----- member functions -----*/ MyPath(); MyPath( const char* ); operator const char* (); ... In initmodule: class_ clsMyPath( "MyPath", init() ); implicitly_convertible(); Then from Python calling:: objin('/some/path') Which is supposed to be able to call a function wrapped in C++:: void objin( MyPath a ) const I get:: Traceback (most recent call last): File "c:/tmp/aaa", line 16, in ? a.objin('/some/path') Boost.Python.ArgumentError: Python argument types in ClassA.objin(ClassA, str) did not match C++ signature: objin(class Dl::PyextModuleA::ClassA {lvalue}, class Dl::PyextModuleA::MyPath) Also, if my function takes a ``const MyPath&``, it behaves the same (but I did not expect this one to work though). any info greatly appreciated. cheers, Ralf W. Grosse-Kunstleve wrote: > --- Kirsebom Nikolai wrote: > >>Some time ago I made a 'socket based' system (using BISON/FLEX for parsing) >>where I expose C++ objects to python. In this system CStrings are regular >>Python strings. > > > Attached is a small, self-contained demo extension module that shows how to do > what you want. Here is the corresponding trivial regression test: > > from sandbx_boost import custom_string > assert custom_string.hello() == "Hello world." > assert custom_string.size("california") == 10 > > If you look at the code you will find: > > 1. A custom to_python converter (easy): custom_string_to_python_str > > 2. A custom lvalue converter (needs more code): custom_string_from_python_str > > The custom converters are registered in the global Boost.Python registry near > the top of the module initialization function. Once flow control has passed > through the registration code the automatic conversions from and to Python > strings will work in any module imported in the same process. > > HTH, > Ralf > > #include > #include > #include > > namespace sandbx { namespace { > > class custom_string > { > public: > custom_string() {} > custom_string(std::string const& value) : value_(value) {} > std::string const& value() const { return value_; } > private: > std::string value_; > }; > > struct custom_string_to_python_str > { > static PyObject* convert(custom_string const& s) > { > return boost::python::incref(boost::python::object(s.value()).ptr()); > } > }; > > struct custom_string_from_python_str > { > custom_string_from_python_str() > { > boost::python::converter::registry::push_back( > &convertible, > &construct, > boost::python::type_id()); > } > > static void* convertible(PyObject* obj_ptr) > { > if (!PyString_Check(obj_ptr)) return 0; > return obj_ptr; > } > > static void construct( > PyObject* obj_ptr, > boost::python::converter::rvalue_from_python_stage1_data* data) > { > const char* value = PyString_AsString(obj_ptr); > if (value == 0) boost::python::throw_error_already_set(); > void* storage = ( > (boost::python::converter::rvalue_from_python_storage*) > data)->storage.bytes; > new (storage) custom_string(value); > data->convertible = storage; > } > }; > > custom_string hello() { return custom_string("Hello world."); } > > std::size_t size(custom_string const& s) { return s.value().size(); } > > void init_module() > { > using namespace boost::python; > > boost::python::to_python_converter< > custom_string, > custom_string_to_python_str>(); > > custom_string_from_python_str(); > > def("hello", hello); > def("size", size); > } > > }} // namespace sandbx:: > > BOOST_PYTHON_MODULE(custom_string) > { > sandbx::init_module(); > } > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com From blais at iro.umontreal.ca Tue Sep 23 22:27:08 2003 From: blais at iro.umontreal.ca (Martin Blais) Date: Tue, 23 Sep 2003 16:27:08 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string In-Reply-To: <20030527184242.56902.qmail@web20210.mail.yahoo.com> References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> Message-ID: <3F70AC9C.1040907@iro.umontreal.ca> Hi guys I just found the mail below, answers one of my questions, and AFAIK the answer for my query is not clearly there in the Boost.Python docos. In fact, porting code from v1 to v2, I think that this should be in the FAQ for the following question: "How do I register automatic conversions to/from a specific C++ class without exposing the C++ class itself to the Python interface?" in v1, I used to do with by declaring to_python and from_python converter methods in the appropriate namespace. The C++ class that was converted was not known to the Python interface at all. I think the example below seems to address my query, I tried it and it works. It would be nice to add this capability to the FAQ or docs. also, maybe I'm going about this wrong, but it seems to perform this task in v1 was cleaner... is there a better way? I'm sure there must be but I just didn't find it. If there is no better way, some C++ code magic to wrap this up and make it look nicer would be a desired feature IMHO. Note that I wouldn't mind wrapping up and exposing the class instead, if the implicit converters would always be triggered such that my users never have to be aware of the existence of the corresponding C++ class; I tried changing my C++ class to add implicit conversions but it doesn't get triggered somehow, here is an example, with a MyPath class that I would like to be automatically convertible from/to a Python string:: class MyPath { public: /*----- member functions -----*/ MyPath(); MyPath( const char* ); operator const char* (); ... In initmodule: class_ clsMyPath( "MyPath", init() ); implicitly_convertible(); Then from Python calling:: objin('/some/path') Which is supposed to be able to call a function wrapped in C++:: void objin( MyPath a ) const I get:: Traceback (most recent call last): File "c:/tmp/aaa", line 16, in ? a.objin('/some/path') Boost.Python.ArgumentError: Python argument types in ClassA.objin(ClassA, str) did not match C++ signature: objin(class Dl::PyextModuleA::ClassA {lvalue}, class Dl::PyextModuleA::MyPath) Also, if my function takes a ``const MyPath&``, it behaves the same (but I did not expect this one to work though). any info greatly appreciated. cheers, Ralf W. Grosse-Kunstleve wrote: > --- Kirsebom Nikolai wrote: > >>Some time ago I made a 'socket based' system (using BISON/FLEX for parsing) >>where I expose C++ objects to python. In this system CStrings are regular >>Python strings. > > > Attached is a small, self-contained demo extension module that shows how to do > what you want. Here is the corresponding trivial regression test: > > from sandbx_boost import custom_string > assert custom_string.hello() == "Hello world." > assert custom_string.size("california") == 10 > > If you look at the code you will find: > > 1. A custom to_python converter (easy): custom_string_to_python_str > > 2. A custom lvalue converter (needs more code): custom_string_from_python_str > > The custom converters are registered in the global Boost.Python registry near > the top of the module initialization function. Once flow control has passed > through the registration code the automatic conversions from and to Python > strings will work in any module imported in the same process. > > HTH, > Ralf > > #include > #include > #include > > namespace sandbx { namespace { > > class custom_string > { > public: > custom_string() {} > custom_string(std::string const& value) : value_(value) {} > std::string const& value() const { return value_; } > private: > std::string value_; > }; > > struct custom_string_to_python_str > { > static PyObject* convert(custom_string const& s) > { > return boost::python::incref(boost::python::object(s.value()).ptr()); > } > }; > > struct custom_string_from_python_str > { > custom_string_from_python_str() > { > boost::python::converter::registry::push_back( > &convertible, > &construct, > boost::python::type_id()); > } > > static void* convertible(PyObject* obj_ptr) > { > if (!PyString_Check(obj_ptr)) return 0; > return obj_ptr; > } > > static void construct( > PyObject* obj_ptr, > boost::python::converter::rvalue_from_python_stage1_data* data) > { > const char* value = PyString_AsString(obj_ptr); > if (value == 0) boost::python::throw_error_already_set(); > void* storage = ( > (boost::python::converter::rvalue_from_python_storage*) > data)->storage.bytes; > new (storage) custom_string(value); > data->convertible = storage; > } > }; > > custom_string hello() { return custom_string("Hello world."); } > > std::size_t size(custom_string const& s) { return s.value().size(); } > > void init_module() > { > using namespace boost::python; > > boost::python::to_python_converter< > custom_string, > custom_string_to_python_str>(); > > custom_string_from_python_str(); > > def("hello", hello); > def("size", size); > } > > }} // namespace sandbx:: > > BOOST_PYTHON_MODULE(custom_string) > { > sandbx::init_module(); > } > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com From alellem at student.cs.uwaterloo.ca Tue Sep 23 23:06:39 2003 From: alellem at student.cs.uwaterloo.ca (Andrew L Ellem) Date: Tue, 23 Sep 2003 17:06:39 -0400 (EDT) Subject: [C++-sig] Problems with embedding.cpp with VC7 Message-ID: I've been trying the get embedding.cpp example to work. I have the latest CVS version of boost::python, and I am using VC7 (not the 2003 edition) with Python 2.3. It complies fine except with a few warnings: C:\boost\boost\python\converter\builtin_converters.hpp(114) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data But throws an exception when calling the py.hello(): python::object py_base = PythonDerived(); Base& py = python::extract(py_base)(); std::cout << py.hello() << std::endl; Does anyone know what the problem is? or any possible fix? Thanks, Andrew Ellem From s_sourceforge at nedprod.com Tue Sep 23 21:02:30 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 23 Sep 2003 20:02:30 +0100 Subject: [C++-sig] Re: Boost.Python not resolving overloads In-Reply-To: Message-ID: <3F70A6D6.2153.18E88335@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Sep 2003 at 19:11, David Abrahams wrote: > > If so, it would appear to me to be trivial - just insert the object > > instance as the first parameter if all else fails. > > That is *not* the right fix. A regular member function with signature > > void (A::*)(A&, int); > > might inadvertently be called via > > >>> A().f(3) > > without issuing an error. Errors are good. If you want the > library/language to guess at what you meant when you screw up instead > of telling you what went wrong, you should be using Perl, not Python. Mmm, agreed. The mixed static/normal method flag is needed. > I'll tell you what. Why don't you start by writing a doctest case > which would succeed only with your proposed feature, and also includes > calls like my example above that should fail overload resolution. We > can look that over, and if it's acceptable to me, you can try to write > a patch which makes the tests pass. I've thought about this at length. I'd really like it, true, but after weighing up the consequenes to my users of having an incomplete interface - well, right now, I'm tending to think they can manage without. However if there were sufficient demand, I'd probably come back to this. We'll see. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3CYxsEcvDLFGKbPEQKukQCg3fZZZ1xcc+hzSVvayIw9Nh6RQH4AoJYC nhAMgIbPgL1ZfB/cXnkoSO2V =CLVX -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Tue Sep 23 21:06:10 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 23 Sep 2003 20:06:10 +0100 Subject: [C++-sig] Way to insert code in _main.cpp in pyste In-Reply-To: <3F6F89B4.4030501@globalite.com.br> References: <3F6F3D8B.17179.136534A6@localhost> Message-ID: <3F70A7B2.24078.18EBDFEC@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Sep 2003 at 20:45, Nicodemus wrote: > declaration_code('void Export_TnFOX_Python_FXFile();\n') > module_code(' Export_TnFOX_Python_FXFile();\n') > > But I see you want it inside _main.cpp... there's currently no way to > do that explicitly, but you can put it inside any other Pyste file and > the effect will be the same, since inside BOOST_PYTHON_MODULE your > Export_MyPysteFile() will called, which will then call your > ExportExceptionTrans(), for example. Try that and see if it works. Hmm. Still not as nice as specifying the registrants on the command line when generating _main.cpp. The modules shouldn't have to worry about this, plus also it's likely I'll foul up not putting it into the first module being compiled in. I suppose I could go for a dummy module starting with the letter A? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3CZo8EcvDLFGKbPEQI/dgCeKJw/Io6FvLxvEpxowD6vj4pt6pYAoLQp 3q9zLJjoJsshzLuX28OD2fcO =jMCn -----END PGP SIGNATURE----- From nicodemus at globalite.com.br Wed Sep 24 00:16:40 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Tue, 23 Sep 2003 19:16:40 -0300 Subject: [C++-sig] Way to insert code in _main.cpp in pyste In-Reply-To: <3F70A7B2.24078.18EBDFEC@localhost> References: <3F6F3D8B.17179.136534A6@localhost> <3F70A7B2.24078.18EBDFEC@localhost> Message-ID: <3F70C648.2000700@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 22 Sep 2003 at 20:45, Nicodemus wrote: > > > >>declaration_code('void Export_TnFOX_Python_FXFile();\n') >>module_code(' Export_TnFOX_Python_FXFile();\n') >> >>But I see you want it inside _main.cpp... there's currently no way to >>do that explicitly, but you can put it inside any other Pyste file and >>the effect will be the same, since inside BOOST_PYTHON_MODULE your >>Export_MyPysteFile() will called, which will then call your >>ExportExceptionTrans(), for example. Try that and see if it works. >> >> > >Hmm. Still not as nice as specifying the registrants on the command >line when generating _main.cpp. The modules shouldn't have to worry >about this, plus also it's likely I'll foul up not putting it into >the first module being compiled in. > >I suppose I could go for a dummy >module starting with the letter A? > Sure, that would do. You could also create a Pyste file named OtherExports.pyste and put this code there... seems good enough. Regards, Nicodemus. From nicodemus at globalite.com.br Wed Sep 24 00:25:14 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Tue, 23 Sep 2003 19:25:14 -0300 Subject: [C++-sig] Pyste bug: can't set different return policies on method In-Reply-To: <3F6F84B0.20799.147B1EA5@localhost> References: <3F6CFD9D.12779.A9B7B44@localhost> <3F6F84B0.20799.147B1EA5@localhost> Message-ID: <3F70C84A.2090302@globalite.com.br> Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 21 Sep 2003 at 14:32, Nicodemus wrote: > > > >>That's a limitation of Pyste right now. One of the future plans is to >>allow metaprogramming inside the pyste files, which would allow you to >>do something like this: >> >>FXFile = Class(...) >> >>if not FXFile.name.static: >> set_policy(FXFile.name, return_internal_reference) >> >>But this might take a while to be implemented... I haven't had much >>time to work on Pyste lately. But what you think of this solution? >> >> > >Looks to me like you're making work for yourself. > >How about instead when pyste encounters two methods with the same >name it puts an array at FXFile.name ie; now it's FXFile.name[0] and >FXFile.name[1]. This ensures you don't accidentally set the policy >incorrectly for both when you meant one of them, plus it's much >easier to code. > > Hmm, I will take a look at it, thanks for the suggestion. Just can't promise it for right now, because I'm pretty busy. I'll probably be able to code something next week. Regards, Nicodemus. From dave at boost-consulting.com Wed Sep 24 00:39:37 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 23 Sep 2003 18:39:37 -0400 Subject: [C++-sig] Re: A feature request, and, Re: Re: Exception translation to python classes References: <00c401c38170$6db514d0$0200a8c0@barrack> <3F6FC6FC.8418.157E17D3@localhost> Message-ID: "Niall Douglas" writes: > On 23 Sep 2003 at 9:17, Lijun Qin wrote: > >> form of code, you need to use the PyErr_NewException() API to create a >> new exception class derived from PyExc_Exception class. And to create >> '__init__' and '__str__' function, you also need to create two method >> object for two callable object. I have managed to make it work, but it >> need a lot of handcraft. > > Thanks for telling me this, you've just saved me a day of work. Dave, > what do you think? I'm not quite sure what you're asking my opinion about. I think the base class capability described below is a really good idea. Lijun posted some code which does this IIRC, but I can't find it. It also sounds like you're asking me about something else. If someone can come up with code, docs, and tests, I'd like to put it in the library. I don't think I have time to do it myself at the moment. >> I this process, I have found that if boost.python can support >> specifing an existing Python class as base class (or one of the >> basses), such as specify 'PyExc_Excetion' as the base class of the >> generated python class, it'll be a much simpler life for us. > > I agree. But it's not crucial for what I need, so I'll have my > exception class generate a textual description and report that to > python (ie; I'm going to cheat :) ) -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Sep 24 00:49:25 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 23 Sep 2003 18:49:25 -0400 Subject: [C++-sig] Re: location of initialization matters? References: Message-ID: Martin Blais writes: > just a follow up on this: I was able to recreate the scope object for > my module by import "itself" from the project's init framework, which > is executed after the Python initMODULE function is called, and since > at that point the module has had its Py_InitModule() called, I assume > that doing a PyImport_ImportModuleEx() after that won't have any other > consequences. Here is the relevant code:: > > > InInit::performInitialize() > { > > ... initialize buff here > > { > using namespace python; > > // Obtain the handle on the already imported module to create a > // scope. > PyObject* m = ::PyImport_ImportModuleEx( "libDLpyextModuleA", > 0, 0, 0 ); > assert( m != 0 ); > scope module_scope( object( borrowed( m ) ) ); > > // Boost.Python declarations using initialized objects here. > module_scope.attr( "buff" ) = buff; > } > } > > > This "seems to work" (i.e. it compiles and doesn't crash and I can > obtain the correct initialized value for the initialized buff). > > I think with this in mind, I could probably leave the initMODULE > functions empty and always put my Boost.Python declarations in the > project's performInitialize() methods. > > Do you see any potential problems with this? No serious ones, but I've not done an in-depth analysis. Don't forget to do C++ -> Python exception handling as neccessary... whatever that means for your application. > I'm sure some other projects must have had to do a similar trick. > > I guess my question boils down to: "can one safely declare new things > for Python once the module has already been initialized?" You can see everything that goes on in the module initialization function, so it shouldn't be too hard to analyze. > (i.e. by "declare new things" I mean insert Boost.Python > declarations, for example, could I declare a new class within a > function call? (i.e not the initMODULE function)) Surely you realize that: >>> import foo >>> class X: pass >>> foo.X = X (and such) are legal? I don't think there are any major problems, as long as you have a scope(...) set up. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Sep 24 00:43:18 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 23 Sep 2003 18:43:18 -0400 Subject: [C++-sig] Re: Code Warrior and Boost python References: <3F70519A.6040302@der.edfgdf.fr> Message-ID: "Xavier WARIN(Compte LOCAL) - I23" writes: > Hi , > > I try to use Boost V2 with codewarrior. I use version 7.0 that I have > just upgraded to 7.2. I dropped support for CW 7.x in the current CVS. It doesn't support one very important metaprogramming technique (i.e. it is nonconforming in an important way), the workarounds for which tend to be very costly in development time. CW 8.3 works great, though. I *think* Boost 1.30.2 still supports CW 7.x as well, but I'm not positive. > While trying to compile the Boost python source files i get a weird > error in cstdio generated by > boost/comptibility/generate_cpp_c_headers.py Whoa. You shouldn't be using the compatibility library with Metrowerks. It has a very good standard library of its own. > I've got a lot of errors like : > undefined identifier 'FILE' > cstdio line 12 using::FILE ; > > undefined identifier 'fpos_t' > cstdio line 13 using::fpos_t; > > etc ... > > What did i do wrong ? Any idea ? > Thank you -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Sep 24 01:36:20 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 23 Sep 2003 19:36:20 -0400 Subject: [C++-sig] Re: Problems with embedding.cpp with VC7 References: Message-ID: Andrew L Ellem writes: > I've been trying the get embedding.cpp example to work. > I have the latest CVS version of boost::python, and I am using > VC7 (not the 2003 edition) with Python 2.3. > > It complies fine except with a few warnings: > C:\boost\boost\python\converter\builtin_converters.hpp(114) : warning > C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of > data > > But throws an exception when calling the py.hello(): > > python::object py_base = PythonDerived(); > Base& py = python::extract(py_base)(); > std::cout << py.hello() << std::endl; > > Does anyone know what the problem is? or any possible fix? Run the tests this way: cd c:/boost/libs/python/test/ bjam -sTOOLS=vc7 embedding ...found 2074 targets... ...updating 1 target... **passed** c:\build\bin\boost\libs\python\test\embedding.test\vc7\debug\embedding.test ...updated 1 target... Works perfectly well for me. -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike.thompson at day8.com.au Wed Sep 24 02:41:04 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Wed, 24 Sep 2003 10:41:04 +1000 Subject: [C++-sig] Re: injected constructors References: Message-ID: "David Abrahams" wrote: > > Injected constructors are implemented, but not yet documented. See > libs/python/test/injected.[py/cpp] for examples. > I'm as keen as mustard to use and test this feature but can't seem to get my hands on it!! I've been downloading the cvs HEAD from boost-consulting for the last couple of days but there's no sign of libs/python/test/injected.[py/cpp]. I've taken the existence of these two files as a marker for this feature's inclusion in my downloaded version. The latest modification I have in ' libs/python/test/' is test_builtin_converters.[py/cpp] which is 18/9/2003 (dd/m/yyyy). Even allowing for some delay in boost-consulting getting the latest sourceforge CVS changes, it should be there, I would have thought. Particularly when the posts of others indicate they have it. Perhaps its not in cvs HEAD? Am I looking in the wrong branch? -- Mike From dave at boost-consulting.com Wed Sep 24 04:55:56 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 23 Sep 2003 22:55:56 -0400 Subject: [C++-sig] Re: injected constructors References: Message-ID: "Mike Thompson" writes: > "David Abrahams" wrote: >> >> Injected constructors are implemented, but not yet documented. See >> libs/python/test/injected.[py/cpp] for examples. >> > > I'm as keen as mustard to use and test this feature but can't seem to get my > hands on it!! > > I've been downloading the cvs HEAD from boost-consulting for the last couple of > days Try the sourceforge CVS (They seem to have improved things for Boost), or grab the snapshot from http://www.boost-consulting.com/boost.tar.bz2. > but there's no sign of libs/python/test/injected.[py/cpp]. I've taken > the existence of these two files as a marker for this feature's inclusion in my > downloaded version. > > The latest modification I have in ' libs/python/test/' is > test_builtin_converters.[py/cpp] which is 18/9/2003 (dd/m/yyyy). > > Even allowing for some delay in boost-consulting getting the latest sourceforge > CVS changes, it should be there, I would have thought. Particularly when the > posts of others indicate they have it. > > Perhaps its not in cvs HEAD? Am I looking in the wrong branch? It's definitely available from SF. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/python/test/injected.py http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/python/test/injected.cpp -- Dave Abrahams Boost Consulting www.boost-consulting.com From alellem at uwaterloo.ca Wed Sep 24 07:02:41 2003 From: alellem at uwaterloo.ca (Andrew Ellem) Date: Wed, 24 Sep 2003 01:02:41 -0400 Subject: [C++-sig] Re: Problems with embedding.cpp with VC7 Message-ID: <000001c38259$162a7f90$0300a8c0@bender> When I run: cd c:/boost/libs/python/test/ bjam -sTOOLS=vc7 embedding ...found 2074 targets... ...updating 1 target... **passed** c:\build\bin\boost\libs\python\test\embedding.test\vc7\debug\embedding.t est ...updated 1 target... I get: C:\boost\libs\python\test>bjam -sTOOLS=vc7 test --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "c:\python2.3/include" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:\python2.3" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.3" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently "c:\python2.3/libs" --------------------------------------------------------------------- unknown dependent target <@boost!libs!python!build>libboost_python.lib From xavier.warin at der.edfgdf.fr Wed Sep 24 09:13:24 2003 From: xavier.warin at der.edfgdf.fr (Xavier WARIN(Compte LOCAL) - I23) Date: Wed, 24 Sep 2003 09:13:24 +0200 Subject: [C++-sig] Re: Code Warrior and Boost python In-Reply-To: References: <3F70519A.6040302@der.edfgdf.fr> Message-ID: <3F714414.7030304@der.edfgdf.fr> David Abrahams wrote: >>While trying to compile the Boost python source files i get a weird >>error in cstdio generated by >>boost/comptibility/generate_cpp_c_headers.py > > > Whoa. You shouldn't be using the compatibility library with > Metrowerks. It has a very good standard library of its own. > > Thank you for the answer. I didn't do it on purpose.I corrected my path and now it's better. I only have an error with boost_1.30_2 within class.cpp It doesn't understand line 31: namespace self_ns { self_t self; } I think i will have to upgrade my compiler. From dave at boost-consulting.com Wed Sep 24 14:09:42 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 24 Sep 2003 08:09:42 -0400 Subject: [C++-sig] Re: Problems with embedding.cpp with VC7 References: <000001c38259$162a7f90$0300a8c0@bender> Message-ID: "Andrew Ellem" writes: > When I run: > > cd c:/boost/libs/python/test/ > bjam -sTOOLS=vc7 embedding > ...found 2074 targets... > ...updating 1 target... > **passed** > c:\build\bin\boost\libs\python\test\embedding.test\vc7\debug\embedding.t > est > ...updated 1 target... > > I get: > > C:\boost\libs\python\test>bjam -sTOOLS=vc7 test > --------------------------------------------------------------------- > skipping Boost.Python library build due to missing or incorrect > configuration > > couldn't find Python.h in "c:\python2.3/include" > > You can configure the location of your python installation by setting: > PYTHON_ROOT - currently "c:\python2.3" > PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. > "2.2", NOT "2.2.1") - currently "2.3" > > The following are automatically configured from PYTHON_ROOT if not > otherwise set: > > PYTHON_LIB_PATH - path to Python library object; currently > "c:\python2.3/libs" > --------------------------------------------------------------------- > unknown dependent target <@boost!libs!python!build>libboost_python.lib We went to great lengths to make that message helpful. Do you have Python.h in c:\python2.3\include, or is it, perchance, in c:\python23\include (no dot)? The instructions for using bjam to build/run the tests are in http://www.boost.org/libs/python/doc/building.html I'm not sure what else to do for you. -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike.thompson at day8.com.au Wed Sep 24 16:03:15 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Thu, 25 Sep 2003 00:03:15 +1000 Subject: [C++-sig] Re: injected constructors References: Message-ID: "David Abrahams" wrote: > "Mike Thompson" writes: > > > "David Abrahams" wrote: > >> > >> Injected constructors are implemented, but not yet documented. See > >> libs/python/test/injected.[py/cpp] for examples. > >> > > > > I'm as keen as mustard to use and test this feature but can't seem to get my > > hands on it!! > > > > I've been downloading the cvs HEAD from boost-consulting for the last couple of > > days > > Try the sourceforge CVS (They seem to have improved things for Boost), ..... Okay, I've successfully downloaded from sourceforge. I'm a bit thrilled to see "injected constructors", I need them. And from a glance at the test code, they look a breeze to use. Thanks! Back to the download issue ... I'm puzzled about why the version at boost-consulting was so out of date (three days?), when I thought it could only ever be 24hrs out, which is exactly why I used it over public sourceforge access which can be miles behind sometimes, for some projects. Anyway, now I have what I want, I only mention this because it might flag a problem in the link between boost-consulting and sourceforge or the like. -- Mike From shahid.k.munshi at hp.com Wed Sep 24 18:17:03 2003 From: shahid.k.munshi at hp.com (Munshi, Shahid K. (Manpower Contract)) Date: Wed, 24 Sep 2003 11:17:03 -0500 Subject: [C++-sig] POPEN Query Message-ID: I am trying to capture network traffic for 60 seconds using windump utility for windows under Windows 2000 Server platform. When I open the Captured file , There is nothing in file.... Anybody explain me why ? import os,win32pipe TooMuchTime = 60 x = win32pipe.popen("windump > Test.txt",'w+') w = time.time() TotalTime = time.time() + TooMuchTime while time.time() < TotalTime: time.sleep(1.0) print ".", x.close() Shahid From dave at boost-consulting.com Wed Sep 24 18:17:13 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 24 Sep 2003 12:17:13 -0400 Subject: [C++-sig] Re: injected constructors References: Message-ID: "Mike Thompson" writes: > "David Abrahams" wrote: >> "Mike Thompson" writes: >> >> > "David Abrahams" wrote: >> >> >> >> Injected constructors are implemented, but not yet documented. See >> >> libs/python/test/injected.[py/cpp] for examples. >> >> >> > >> > I'm as keen as mustard to use and test this feature but can't seem to get > my >> > hands on it!! >> > >> > I've been downloading the cvs HEAD from boost-consulting for the last > couple of >> > days >> >> Try the sourceforge CVS (They seem to have improved things for Boost), ..... > > > Okay, I've successfully downloaded from sourceforge. I'm a bit thrilled to see > "injected constructors", I need them. And from a glance at the test code, they > look a breeze to use. Thanks! > > Back to the download issue ... I'm puzzled about why the version at > boost-consulting was so out of date (three days?), when I thought it could only > ever be 24hrs out, which is exactly why I used it over public sourceforge > access which can be miles behind sometimes, for some projects. The boost-consulting CVS was never ahead of the SF public CVS; just more accessible (fewer communication errors). We create it by downloading the *public repository* snapshot, which is only done every 24 hrs. If the download fails or it happens before they post the snapshot, it will be behind. If the SF public CVS is behind, it will be behind. The snapshots at http://www.boost-consulting.com/boost.tar.bz2 are usually only an hour or 2 behind. I get a few failure notices about the cvs export command which creates them daily. > Anyway, now I have what I want, I only mention this because it might > flag a problem in the link between boost-consulting and sourceforge > or the like. It doesn't indicate anything surprising. -- Dave Abrahams Boost Consulting www.boost-consulting.com From blais at iro.umontreal.ca Wed Sep 24 21:09:50 2003 From: blais at iro.umontreal.ca (Martin Blais) Date: Wed, 24 Sep 2003 15:09:50 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string In-Reply-To: <3F70AC9C.1040907@iro.umontreal.ca> References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> <3F70AC9C.1040907@iro.umontreal.ca> Message-ID: Me again. I wrapped up the ugly bits of the automated conversion to do some of the cooking automatically. I use it like this, for an hypothetical MyPath class for which I want to declare automatic conversion to/from a string (without exposing MyPath):: template <> python::object AutoConverter::toObject( MyPath const& s ) { return python::str( s.cstr() ); } template <> void* AutoConverter::convertible( PyObject* obj_ptr ) { if ( !PyString_Check(obj_ptr) ) return 0; return obj_ptr; } template <> void AutoConverter::fromPython( PyObject* obj_ptr, void* memblock ) { const char* value = PyString_AsString( obj_ptr ); if (value == 0) { python::throw_error_already_set(); } new ( memblock ) MyPath( value ); } Then in my initmodule definition I add:: ... AutoConverter(); ... I tested this with MSVC7.1 (2003/.NET) on Windows XP. Works for me, does the gig for now. But somehow, I feel like I'm not doing something right, there must be a better way to do this. I'm sure Dave thought about some way for automatic conversions to occur but I am not finding it. The template file that wraps this up is attached. (Dave: feel free to massage and include the file in attachment to Boost.Python, if you think it's worth anything.) comments appreciated. cheers, Martin Blais wrote: > Hi guys > > I just found the mail below, answers one of my questions, and > AFAIK the answer for my query is not clearly there in the > Boost.Python docos. In fact, porting code from v1 to v2, I > think that this should be in the FAQ for the following > question: > > "How do I register automatic conversions to/from a specific > C++ class without exposing the C++ class itself to the > Python interface?" > > in v1, I used to do with by declaring to_python and from_python > converter methods in the appropriate namespace. The C++ class > that was converted was not known to the Python interface at > all. I think the example below seems to address my query, I > tried it and it works. > > It would be nice to add this capability to the FAQ or docs. > > also, maybe I'm going about this wrong, but it seems to perform > this task in v1 was cleaner... is there a better way? I'm sure > there must be but I just didn't find it. > > If there is no better way, some C++ code magic to wrap this up > and make it look nicer would be a desired feature IMHO. > > Note that I wouldn't mind wrapping up and exposing the class > instead, if the implicit converters would always be triggered > such that my users never have to be aware of the existence of > the corresponding C++ class; I tried changing my C++ class to > add implicit conversions but it doesn't get triggered somehow, > here is an example, with a MyPath class that I would like to > be automatically convertible from/to a Python string:: > > class MyPath { > > public: > > /*----- member functions -----*/ > > MyPath(); > MyPath( const char* ); > operator const char* (); > > ... > > In initmodule: > > class_ clsMyPath( "MyPath", init() ); > implicitly_convertible(); > > > Then from Python calling:: > > objin('/some/path') > > > Which is supposed to be able to call a function wrapped in C++:: > > void objin( MyPath a ) const > > > I get:: > > Traceback (most recent call last): > File "c:/tmp/aaa", line 16, in ? > a.objin('/some/path') > Boost.Python.ArgumentError: Python argument types in > ClassA.objin(ClassA, str) > did not match C++ signature: > objin(class Dl::PyextModuleA::ClassA {lvalue}, class > Dl::PyextModuleA::MyPath) > > > Also, if my function takes a ``const MyPath&``, it behaves the > same (but I did not expect this one to work though). > > > any info greatly appreciated. > > cheers, > > > > > > > > > Ralf W. Grosse-Kunstleve wrote: > >> --- Kirsebom Nikolai wrote: >> >>> Some time ago I made a 'socket based' system (using BISON/FLEX for >>> parsing) >>> where I expose C++ objects to python. In this system CStrings are >>> regular >>> Python strings. >> >> >> >> Attached is a small, self-contained demo extension module that shows >> how to do >> what you want. Here is the corresponding trivial regression test: >> >> from sandbx_boost import custom_string >> assert custom_string.hello() == "Hello world." >> assert custom_string.size("california") == 10 >> >> If you look at the code you will find: >> >> 1. A custom to_python converter (easy): custom_string_to_python_str >> >> 2. A custom lvalue converter (needs more code): >> custom_string_from_python_str >> >> The custom converters are registered in the global Boost.Python >> registry near >> the top of the module initialization function. Once flow control has >> passed >> through the registration code the automatic conversions from and to >> Python >> strings will work in any module imported in the same process. >> >> HTH, >> Ralf >> >> #include >> #include >> #include >> >> namespace sandbx { namespace { >> >> class custom_string >> { >> public: >> custom_string() {} >> custom_string(std::string const& value) : value_(value) {} >> std::string const& value() const { return value_; } >> private: >> std::string value_; >> }; >> >> struct custom_string_to_python_str >> { >> static PyObject* convert(custom_string const& s) >> { >> return >> boost::python::incref(boost::python::object(s.value()).ptr()); >> } >> }; >> >> struct custom_string_from_python_str >> { >> custom_string_from_python_str() >> { >> boost::python::converter::registry::push_back( >> &convertible, >> &construct, >> boost::python::type_id()); >> } >> >> static void* convertible(PyObject* obj_ptr) >> { >> if (!PyString_Check(obj_ptr)) return 0; >> return obj_ptr; >> } >> >> static void construct( >> PyObject* obj_ptr, >> boost::python::converter::rvalue_from_python_stage1_data* data) >> { >> const char* value = PyString_AsString(obj_ptr); >> if (value == 0) boost::python::throw_error_already_set(); >> void* storage = ( >> >> (boost::python::converter::rvalue_from_python_storage*) >> data)->storage.bytes; >> new (storage) custom_string(value); >> data->convertible = storage; >> } >> }; >> >> custom_string hello() { return custom_string("Hello world."); } >> >> std::size_t size(custom_string const& s) { return s.value().size(); } >> >> void init_module() >> { >> using namespace boost::python; >> >> boost::python::to_python_converter< >> custom_string, >> custom_string_to_python_str>(); >> >> custom_string_from_python_str(); >> >> def("hello", hello); >> def("size", size); >> } >> >> }} // namespace sandbx:: >> >> BOOST_PYTHON_MODULE(custom_string) >> { >> sandbx::init_module(); >> } >> >> >> __________________________________ >> Do you Yahoo!? >> The New Yahoo! Search - Faster. Easier. Bingo. >> http://search.yahoo.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: caba.cpp URL: From dave at boost-consulting.com Wed Sep 24 22:30:59 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 24 Sep 2003 16:30:59 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> <3F70AC9C.1040907@iro.umontreal.ca> Message-ID: Martin Blais writes: > Me again. > > I wrapped up the ugly bits of the automated conversion to do some of > the cooking automatically. I use it like this, for an hypothetical > MyPath class for which I want to declare automatic conversion to/from > a string (without exposing MyPath):: > > template <> > python::object AutoConverter::toObject( MyPath const& s ) > { > return python::str( s.cstr() ); > } > > template <> > void* AutoConverter::convertible( PyObject* obj_ptr ) > { > if ( !PyString_Check(obj_ptr) ) return 0; > return obj_ptr; > } > > template <> > void AutoConverter::fromPython( > PyObject* obj_ptr, > void* memblock > ) > { > const char* value = PyString_AsString( obj_ptr ); > if (value == 0) { > python::throw_error_already_set(); > } > new ( memblock ) MyPath( value ); > } > > Then in my initmodule definition I add:: > > ... > AutoConverter(); > ... > > > I tested this with MSVC7.1 (2003/.NET) on Windows XP. Works for me, > does the gig for now. It's an interesting interface, the idea of using member function specialization to provide the functionality. The downside is that a failure to implement the member functions shows up only at runtime. If you left out the default implementations, you could get it to fail at link time, but I'd much rather see a solution that fails at compile time. It's easy enough to do. Another minor issue is that your converters force you to register conversions in both directions (not always desired), and only handle rvalue from-python conversions. That may be what most people want, most of the time... though I'm not sure. > But somehow, I feel like I'm not doing something right, there must be > a better way to do this. I'm sure Dave thought about some way for > automatic conversions to occur but I am not finding it. Well, not really anything beyond the low-level facilities your little wrapper takes advantage of. > (Dave: feel free to massage and include the file in attachment to > Boost.Python, if you think it's worth anything.) Well, it's got at least one serious problem: > template > void AutoConverter::construct( > PyObject* obj_ptr, > python::converter::rvalue_from_python_stage1_data* data > ) > { > // This should be exception-safe if the conversion fails (i.e. auto_ptr will > // take care of freeing memory. > std::auto_ptr storage( > reinterpret_cast< python::converter::rvalue_from_python_storage* >( > data > )->storage.bytes > ); This whole statement is just wrong. You shouldn't be using reinterpret_cast (static_cast through void* or plain-old C-style cast will do) and you *definitely* shouldn't be trying to manage that memory with an auto_ptr. It's owned elsewhere. -- Dave Abrahams Boost Consulting www.boost-consulting.com From blais at iro.umontreal.ca Wed Sep 24 23:11:20 2003 From: blais at iro.umontreal.ca (Martin Blais) Date: Wed, 24 Sep 2003 17:11:20 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string In-Reply-To: References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> <3F70AC9C.1040907@iro.umontreal.ca> Message-ID: David Abrahams wrote: > Martin Blais writes: > > > It's an interesting interface, the idea of using member function > specialization to provide the functionality. The downside is that a > failure to implement the member functions shows up only at runtime. > If you left out the default implementations, you could get it to fail > at link time, but I'd much rather see a solution that fails at compile > time. It's easy enough to do. well, the fact is you have a choice to specialize the method that uses PyObject* or the one that uses/returns boost::python::object. whichever one you decide to use the other one has to be defined (even if not called i think, iirc that's a compiler-dependent behaviour, not sure). > Another minor issue is that your converters force you to register > conversions in both directions (not always desired), and only handle > rvalue from-python conversions. That may be what most people want, > most of the time... though I'm not sure. i assumed that for that you would use the code you provide. i wonder if we could split in two base classes and mixin. > Well, it's got at least one serious problem: > > >>template >>void AutoConverter::construct( >> PyObject* obj_ptr, >> python::converter::rvalue_from_python_stage1_data* data >>) >>{ >> // This should be exception-safe if the conversion fails (i.e. auto_ptr will >> // take care of freeing memory. >> std::auto_ptr storage( >> reinterpret_cast< python::converter::rvalue_from_python_storage* >( >> data >> )->storage.bytes >> ); > > > This whole statement is just wrong. You shouldn't be using > reinterpret_cast (static_cast through void* or plain-old C-style cast > will do) and you *definitely* shouldn't be trying to manage that > memory with an auto_ptr. It's owned elsewhere. you're so totally right, i screwed up, somehow i got into thinking about the in-place allocation later on and i was mentally adding a call to a user-provided function, thinking, it might raise an exception. (and i had not written a test for the case where it fails yet). thanks for your comments! :-) cheers, From dave at boost-consulting.com Thu Sep 25 14:46:38 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 25 Sep 2003 08:46:38 -0400 Subject: [C++-sig] Re: Converting CString to/from std::string References: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no> <20030527184242.56902.qmail@web20210.mail.yahoo.com> <3F70AC9C.1040907@iro.umontreal.ca> Message-ID: Martin Blais writes: > David Abrahams wrote: >> Martin Blais writes: >> It's an interesting interface, the idea of using member function >> specialization to provide the functionality. The downside is that a >> failure to implement the member functions shows up only at runtime. >> If you left out the default implementations, you could get it to fail >> at link time, but I'd much rather see a solution that fails at compile >> time. It's easy enough to do. > > well, the fact is you have a choice to specialize the method that uses > PyObject* or the one that uses/returns > boost::python::object. whichever one you decide to use the other one > has to be defined (even if not called i think, iirc that's a > compiler-dependent behaviour, not sure). I'm not sure which of my points you're addressing, but it's possible to design an interface that lets you define your to-python converter as returning either object or PyObject*, and fails at compile-time if it's not defined. >> Another minor issue is that your converters force you to register >> conversions in both directions (not always desired), and only handle >> rvalue from-python conversions. That may be what most people want, >> most of the time... though I'm not sure. > > i assumed that for that you would use the code you provide. i wonder > if we could split in two base classes and mixin. I think that design sounds a little bit too complicated for what it actually accomplishes. Maybe I'll work out a small proposal. template <> python::object AutoConverter::toObject( MyPath const& s ) { return python::str( s.cstr() ); } template <> void* AutoConverter::convertible( PyObject* obj_ptr ) { if ( !PyString_Check(obj_ptr) ) return 0; return obj_ptr; } template <> void AutoConverter::fromPython( PyObject* obj_ptr, void* memblock ) { const char* value = PyString_AsString( obj_ptr ); if (value == 0) { python::throw_error_already_set(); } new ( memblock ) MyPath( value ); } Then in my initmodule definition I add:: ... AutoConverter(); ... -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Thu Sep 25 06:27:23 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 25 Sep 2003 05:27:23 +0100 Subject: [C++-sig] Any way of executing something on unload of a Boost.Python module? Message-ID: <3F727CBB.16526.20140A0B@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Firstly, I'll just thank everything in here for all the help over the last few weeks. In fact: >>> from TnFOX import * Thread 0x42c (Randomness monitor) started >>> a=FXFile("foo.txt") >>> a.writeBlock("Niall", 5) Traceback (most recent call last): File "", line 1, in ? IOError: Not open for writing (code 0xFFFA file d:\tornado\tclient\tnfox\src\fxfile.cxx line 398) Stack backtrace: 0x00B5D0EA: (file line no 0) 0x00B5DA5F:TnFOX-0.4d7.dll FX::operator- +0x104be (file line no 0) Wow! You all might not quite appreciate how much this means to me. More than a month of labouring part-time and it finally all works! The single caveat is that the randomness thread you see started above gets terminated when you unload the module (I'd much prefer a chance to shut it down nicely). I can't find anything in the docs about how to do this. BTW if you're thinking "have a static variable shut it down on destruct" well I tried that, but unfortunately the threads on Win32 get killed before destructing static variables. Hmm, I just thought of atexit()?!? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3Juq8EcvDLFGKbPEQLRxgCeK379oX4MB50/mXRKa5DfpEVJcFwAoL9L Mu6jxjYRFsB3VbqcAFSQVN8Q =wHaC -----END PGP SIGNATURE----- From dave at boost-consulting.com Thu Sep 25 22:29:08 2003 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 25 Sep 2003 16:29:08 -0400 Subject: [C++-sig] Re: Any way of executing something on unload of a Boost.Python module? References: <3F727CBB.16526.20140A0B@localhost> Message-ID: "Niall Douglas" writes: > Firstly, I'll just thank everything in here for all the help over the > last few weeks. In fact: > >>>> from TnFOX import * > Thread 0x42c (Randomness monitor) started >>>> a=FXFile("foo.txt") >>>> a.writeBlock("Niall", 5) > Traceback (most recent call last): > File "", line 1, in ? > IOError: Not open for writing (code 0xFFFA file > d:\tornado\tclient\tnfox\src\fxfile.cxx line 398) > Stack backtrace: > 0x00B5D0EA: > (file line > no 0) > 0x00B5DA5F:TnFOX-0.4d7.dll FX::operator- +0x104be > (file line > no 0) > > > Wow! You all might not quite appreciate how much this means to me. > More than a month of labouring part-time and it finally all works! *That's* called "working?" I guess if you're happy, I'm happy. > The single caveat is that the randomness thread you see started above > gets terminated when you unload the module (I'd much prefer a chance > to shut it down nicely). I can't find anything in the docs about how > to do this. ?? Python extension modules are never unloaded. Do you mean you're calling Py_Finalize()? Because that's not supported by Boost.Python (yet). -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Fri Sep 26 00:58:02 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Thu, 25 Sep 2003 23:58:02 +0100 Subject: [C++-sig] Re: Any way of executing something on unload of a Boost.Python module? In-Reply-To: Message-ID: <3F73810A.18883.240CDCCE@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25 Sep 2003 at 16:29, David Abrahams wrote: > > Wow! You all might not quite appreciate how much this means to me. > > More than a month of labouring part-time and it finally all works! > > *That's* called "working?" I guess if you're happy, I'm happy. I always say error handling is the beginning of all good coding! > > The single caveat is that the randomness thread you see started > > above gets terminated when you unload the module (I'd much prefer a > > chance to shut it down nicely). I can't find anything in the docs > > about how to do this. > > ?? Python extension modules are never unloaded. > > Do you mean you're calling Py_Finalize()? Because that's not > supported by Boost.Python (yet). No, I was doing Ctrl + Z and Return. I looked around the call stack in MSVC and I think python's console control handler is immediately calling ExitProcess() which dooms any threads currently running. Shame as now I'll have to wrap the python interpreter in other code so cleanups can be invoked correctly. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3Ny+sEcvDLFGKbPEQKXgQCfbOePVc8dGy/93tlT7ALvL7KV6+YAnjvZ 1X5I2k9V3a/Prf4BnrR3Htn5 =A57h -----END PGP SIGNATURE----- From s_fsfeurope2 at nedprod.com Fri Sep 26 02:17:31 2003 From: s_fsfeurope2 at nedprod.com (Niall Douglas) Date: Fri, 26 Sep 2003 01:17:31 +0100 Subject: [C++-sig] Re: [Fsfe-ie] 1-page letter, faxes at the ready (IFSO, irish org) In-Reply-To: <20030925234420.GA19865@pagh.compsoc.com> References: <3F7361AD.2964.23925ADE@localhost> Message-ID: <3F7393AB.3860.2455A1E5@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Sep 2003 at 0:44, Ciaran O'Riordan wrote: > what FSF resources would we want access to? > (I have access now. When IFSO is formed, it will have access) Hmm, not sure. I was thinking of things like if someone asks the FSF in the US if they know someone free software organised in Ireland, they'd get put onto you. Also, the FSF attracts money, though not a lot. Wouldn't an Irish branch deserve some of it? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3OFm8EcvDLFGKbPEQJeEgCfR3SmqI/oqcf/4+lmcQHiPmSLQK8An2jk 9cqShMnkE4JMiDa6520jbZ5C =q1ib -----END PGP SIGNATURE----- From lkunert at mpi-sb.mpg.de Fri Sep 26 19:23:14 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Fri, 26 Sep 2003 19:23:14 +0200 Subject: [C++-sig] calling a python-callback-function from a c++thread... Message-ID: Hi! I am trying to implement a Qt-application, which after beeing lauched from the IDLE creates and lives on its own thread. The idea is, that the program may be called from other python-programs and may itself call other python programs. Python-functions, which should be called from the program, register themself prior to their invocation. I think my problem is that I do not aquire the python-interpreter lock before using the callback... PyApp.* wraps QtApplication by exporting selected methods to pyton, launches the thread, QtApp lives on, and locks/unlockes (syncs) accesses to the internal state of QtApp. PyApp.h class PyApp { private: Thread *thread; QtApp *app; ... void set_callback( PyObject *callback ); }; PyApp.cxx BOOST_PYTHON_MODULE(PyApp_module) { class_< PyApp >("App", init< >()) .def(init< const PyApp & >()) .def("set_callback", &PyApp::set_callback) ; } void PyApp::set_callback( PyObject *callback ) { app->lock(); { app->set_callback( callback ); }; app->unlock(); }; QtApp.* is a "normal"QtApplication, which tries to use a callback and dies... QtApp.h: class QtApp : public QtApplication { ... private: PyObject *_callback; public void set_callback( PyObject *callback ); void callback(); ... } QtApp.cxx: ... void QtApp::callback() { boost::python::call( _callback ); }; EXAMPLE >>> from PyApp_module import App >>> a=App() >>> dir(a) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__instance_size__', '__module__', '__new__', '__reduce__', '__repr__', '__setattr__', '__str__', '__weakref__', 'exec', 'set_callback', 'set_text', 'text'] >>> def ph(): ... print( "hallo" ) ... >>> ph() hallo >>> a.set_callback( ph ) <----now I invoke the callback (by pressing a button on the application window) >>> Segmentation fault I hope the preceeding code-snips will help to explain the situation sufficiently. If there are requests, I can also post the complete test-application... Thanks for your help, Lars From llywelyn.geo at yahoo.com Fri Sep 26 20:40:12 2003 From: llywelyn.geo at yahoo.com (Joel Gerard) Date: Fri, 26 Sep 2003 11:40:12 -0700 (PDT) Subject: [C++-sig] Boost.Python : Byref parameters Message-ID: <20030926184012.24356.qmail@web41504.mail.yahoo.com> Hi All, I'm trying to call a C++ member function from Python that takes three ints by reference, and modifies them. static f32 Normalize (f32& fx, f32& fy, f32& fz); Furthermore, its overloaded: f32 Normalize (void); static f32 Normalize (Vector& kV); I've wrapped it like so: f32 (Vector::*VectorNormalize1)(void) = &Vector::Normalize; f32 (*VectorNormalize2)(Vector&)= &Vector::Normalize; f32 (*VectorNormalize3)(f32&,f32&,f32&) = &Vector::Normalize; .def("Normalize",VectorNormalize1) .def("Normalize",VectorNormalize2) .def("Normalize",VectorNormalize3) Only Normalize defined by VectorNormalize3 is broken saying: "TypeError: unbound method Boost.Python.function object must be called with Vector instance as first argument (got float instance instead)" I think I'm doing something wrong with the call-policies (since I have none), but I don't know which ones to use. What am I doing wrong? Can somebody explain what Boost is trying to do here? Thanks, Joel ===== -------------------------------------- Email: joelgerard at canada.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From mike at nospam.com Fri Sep 26 21:48:50 2003 From: mike at nospam.com (Mike Rovner) Date: Fri, 26 Sep 2003 12:48:50 -0700 Subject: [C++-sig] Re: Boost.Python : Byref parameters References: <20030926184012.24356.qmail@web41504.mail.yahoo.com> Message-ID: Joel Gerard wrote: > .def("Normalize",VectorNormalize1) > .def("Normalize",VectorNormalize2) > .def("Normalize",VectorNormalize3) You have to say .staticmethod("Normalize") > Only Normalize defined by VectorNormalize3 is broken > saying: "TypeError: unbound method > Boost.Python.function object must be called with > Vector instance as first argument (got float instance > instead)" They were wrapped as non-static methods thus require a 'self' class instance argument first. HTH, Mike From dave at boost-consulting.com Fri Sep 26 23:05:45 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 26 Sep 2003 17:05:45 -0400 Subject: [C++-sig] Re: Boost.Python : Byref parameters References: <20030926184012.24356.qmail@web41504.mail.yahoo.com> Message-ID: "Mike Rovner" writes: > Joel Gerard wrote: > >> .def("Normalize",VectorNormalize1) >> .def("Normalize",VectorNormalize2) >> .def("Normalize",VectorNormalize3) > > You have to say .staticmethod("Normalize") Well, except he has a static method overloaded with a non-static one, and Boost.Python doesn't really support that idiom (see thread at http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1811696). I suggest forgoing instance-less access for the static method as follows: f32 nonstatic_Normalize(Vector&, Vector& kV) { return Vector::Normalize(kV); } .def("Normalize",VectorNormalize1) .def("Normalize",nonstatic_Normalize) .def("Normalize",VectorNormalize3) You can also def() the static normalize at module scope: def("Normalize", VectorNormalize2); and then: >>> v = Vector() >>> Normalize(v) which in many ways is a more natural interface anyway. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com From mike at nospam.com Fri Sep 26 23:35:11 2003 From: mike at nospam.com (Mike Rovner) Date: Fri, 26 Sep 2003 14:35:11 -0700 Subject: [C++-sig] Re: Boost.Python : Byref parameters References: <20030926184012.24356.qmail@web41504.mail.yahoo.com> Message-ID: David Abrahams wrote: > "Mike Rovner" writes: > Well, except he has a static method overloaded with a non-static one, > and Boost.Python doesn't really support that idiom Stand corrected. Thank you for clarification. BTW I think that mixing static and non-static mothods under the same name isn't pythonic enough to justify modification (if it's mossible) IMHO. Mike From dave at boost-consulting.com Fri Sep 26 23:49:52 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 26 Sep 2003 17:49:52 -0400 Subject: [C++-sig] Re: calling a python-callback-function from a c++thread... References: Message-ID: Lars Kunert writes: > Hi! > > I am trying to implement a Qt-application, which after beeing lauched from > the IDLE creates and lives on its own thread. The idea is, that the > program may be called from other python-programs and may itself call other > python programs. > Python-functions, which should be called from the program, register > themself prior to their invocation. I think my problem is that I do not > aquire the python-interpreter lock before using the callback... > > PyApp.* wraps QtApplication by exporting selected methods to pyton, > launches the thread, QtApp lives on, and locks/unlockes (syncs) accesses > to the internal state of QtApp. > PyApp.h Are you sure that when your QtApp::callback() is invoked it's on the same thread as the Python interpreter? See http://www.python.org/peps/pep-0311.html and the related sections of the Python/'C' API documentation if you don't know what I mean. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sat Sep 27 18:51:58 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sat, 27 Sep 2003 17:51:58 +0100 Subject: [C++-sig] calling a python-callback-function from a c++thread... In-Reply-To: Message-ID: <3F75CE3E.12803.2D0A7117@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 Sep 2003 at 19:23, Lars Kunert wrote: > PyApp.* wraps QtApplication by exporting selected methods to pyton, > launches the thread, QtApp lives on, and locks/unlockes (syncs) > accesses to the internal state of QtApp. PyApp.h You cannot properly run Qt GUI functions from ANY thread other than the primary one. This is a Qt limitation. You *can* run python in other threads, but it may not call any code in Qt which uses a GUI class. You could use the Qt global lock but I recommend you don't and recode your app instead to invoke GUI functions by sending APC messages to the GUI loop. I have written large heavily multithreaded apps with Qt and the global lock system creates more problems (deadlocks) than it solves. > QtApp.* is a "normal"QtApplication, which tries to use a callback and > dies... QtApp.h: > [snip] > void QtApp::callback() > { > boost::python::call( _callback ); > }; Why aren't you locking python before you enter it? If Qt and python run in two different threads, you must do this. > >>> from PyApp_module import App > >>> a=App() > >>> dir(a) > ['__class__', '__delattr__', '__dict__', '__doc__', > '__getattribute__', '__hash__', '__init__', '__instance_size__', > '__module__', '__new__', '__reduce__', '__repr__', '__setattr__', > '__str__', '__weakref__', 'exec', 'set_callback', 'set_text', 'text'] > >>> def ph(): ... print( "hallo" ) ... >>> ph() hallo >>> > a.set_callback( ph ) <----now I invoke the callback (by pressing a > button on the application window) >>> Segmentation fault You also appear to not be initialising Qt by creating an instance of QApplication at the start before calling any other Qt code. > I hope the preceeding code-snips will help to explain the situation > sufficiently. If there are requests, I can also post the complete > test-application... How are you proposing to implement signals and slots in python? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3XALsEcvDLFGKbPEQIrWgCdGJX9WZvur6kFwSvxhIFETozck2UAnR+R fCtUtNIFoIz3WtmK6dFPFTrU =WNda -----END PGP SIGNATURE----- From lkunert at mpi-sb.mpg.de Sun Sep 28 01:09:09 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Sun, 28 Sep 2003 01:09:09 +0200 Subject: [C++-sig] Re: calling a python-callback-function - switching to python 2.3 Message-ID: Hi! Thanks for pointing me to the pep 311 documents. This patch seem to be the solution to problems. Anyway it also opens up a bunch of new ones. I have just installed python 2.3.1 (to get the pep 311 stuff) and the current boost-cvs-snapshot to get a boost.python version wich works together with pyhton 2.3. Then I tried to recompile my program. I got the following error message: >In file included from /usr/local/include/python2.3/Python.h:69, > from /usr/local/include/boost/python/detail/wrap_python.hpp:121, > from /usr/local/include/boost/python/detail/prefix.hpp:13, > from /usr/local/include/boost/python/args.hpp:9, > from /usr/local/include/boost/python.hpp:12, > from QtApp.h:21, > from Thread.cxx:2: >/usr/local/include/python2.3/object.h:343: error: parse error before `;' token in the file Python.h line 69 I find the the following code: >typedef struct _heaptypeobject { > /* Note: there's a dependency on the order of these members > in slotptr() in typeobject.c . */ > PyTypeObject type; > PyNumberMethods as_number; > PyMappingMethods as_mapping; > PySequenceMethods as_sequence; /* as_sequence comes after as_mapping, > so that the mapping wins when both > the mapping and the sequence define > a given operator (e.g. __getitem__). > see add_operators() in typeobject.c . */ > PyBufferProcs as_buffer; > PyObject *name, *slots; <---LINE 69 > /* here are optional user slots, followed by the members. */ >} PyHeapTypeObject; I have not changed anything else in my code yet. But I think, what I have to do, is to wrap the callback into a PyGILState_Ensure/Release pair >void QtApp::callback() >{ > PyGILState_STATE state = PyGILState_Ensure(); > { > boost::python::call( _callback ); > > }; PyGILState_Release( state ); >}; I do not feel quite comfortable with this approch for two reasons: - I have to use a cvs (non-release) library and - The python IDLE I have to use is linked the application, my Qt-program wants to interact with. And I am not sure if the developer of that application give me the opportunity to exchange the python version they are linking to... Do you see any other way to call the callback with the facilities python 2.2 and boost-1.30.2 are offering to me? I enclose a complete set of files, which are cooked down to the essentials... Thanks for your help, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.h Type: application/octet-stream Size: 950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.cxx Type: application/octet-stream Size: 1364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Thread.h Type: application/octet-stream Size: 257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Thread.cxx Type: application/octet-stream Size: 343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.pyste Type: application/octet-stream Size: 57 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QtApp.h Type: application/octet-stream Size: 1090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QtApp.cxx Type: application/octet-stream Size: 1101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.am Type: application/octet-stream Size: 731 bytes Desc: not available URL: From dave at boost-consulting.com Sun Sep 28 01:40:52 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 27 Sep 2003 19:40:52 -0400 Subject: [C++-sig] Re: calling a python-callback-function - switching to python 2.3 References: Message-ID: Lars Kunert writes: > Hi! > > Thanks for pointing me to the pep 311 documents. This patch seem to be the > solution to problems. > Anyway it also opens up a bunch of new ones. > > I have just installed python 2.3.1 (to get the pep 311 stuff) and the > current boost-cvs-snapshot to get a boost.python version wich works > together with pyhton 2.3. > Then I tried to recompile my program. I got the following error message: > >>In file included from /usr/local/include/python2.3/Python.h:69, >> from > /usr/local/include/boost/python/detail/wrap_python.hpp:121, >> from > /usr/local/include/boost/python/detail/prefix.hpp:13, >> from /usr/local/include/boost/python/args.hpp:9, >> from /usr/local/include/boost/python.hpp:12, >> from QtApp.h:21, >> from Thread.cxx:2: >>/usr/local/include/python2.3/object.h:343: error: parse error before `;' > token > > in the file Python.h line 69 I find the the following code: I'd be more concerned about line 343 of object.h. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sun Sep 28 04:09:22 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 28 Sep 2003 03:09:22 +0100 Subject: [C++-sig] Unlocking the python interpreter lock when entering Boost.Python Message-ID: <3F7650E2.26988.2F08C2D0@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was figuring that it would be pretty easy to hack in a guaranteed unlock and lock every time Boost.Python went into C++ code. But it also occurred to me that this isn't hugely efficient. I have certain parts of my library where it waits for more data to arrive. Thus if my python thread were waiting it could lock out all other python code (bad). Would it not be a good idea if one could specify a policy to Boost.Python to have it unlock and lock around a specific wrap? Anyway just a suggestion. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3ZC08EcvDLFGKbPEQI40wCg7WO842xcsJz+jBg4aXVsbn4saxEAn1j5 pLlglmjs7iiMlf1wrg5Zluur =Jy+t -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Sun Sep 28 04:13:42 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 28 Sep 2003 03:13:42 +0100 Subject: [C++-sig] Pyste problem: 2k limit in Windows command line Message-ID: <3F7651E6.3261.2F0CB938@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unfortunately if you try invoking pyste using more than 2Kb of command line, Win2k barfs. Any chance of being able to tell pyste to fetch its file list from a file? I can send you my patch if you want it? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3ZD1sEcvDLFGKbPEQJenQCg3Q7nWRxaO53SkdxcFlWBLJc7+xAAoJM0 rpkiE7LX9NqQhkrwh3Q74R4C =9SFt -----END PGP SIGNATURE----- From lkunert at mpi-sb.mpg.de Sun Sep 28 10:58:06 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Sun, 28 Sep 2003 10:58:06 +0200 Subject: [C++-sig] Re: calling a python-callback-function - switching to python 2.3 Message-ID: >> Sorry I just recognized, that I had a typo in my mail (line 343 instead of 69), but that does not change anything, cause I had a look at the right place of the file (and I also included the right snip). I just mixed it up when I wrote the mail. Hi! Thanks for pointing me to the pep 311 documents. This patch seem to be the solution to problems. Anyway it also opens up a bunch of new ones. I have just installed python 2.3.1 (to get the pep 311 stuff) and the current boost-cvs-snapshot to get a boost.python version wich works together with pyhton 2.3. Then I tried to recompile my program. I got the following error message: >In file included from /usr/local/include/python2.3/Python.h:69, > from /usr/local/include/boost/python/detail/wrap_python.hpp:121, > from /usr/local/include/boost/python/detail/prefix.hpp:13, > from /usr/local/include/boost/python/args.hpp:9, > from /usr/local/include/boost/python.hpp:12, > from QtApp.h:21, > from Thread.cxx:2: >/usr/local/include/python2.3/object.h:343: error: parse error before `;' token in the file Python.h line 69 I find the the following code: >typedef struct _heaptypeobject { > /* Note: there's a dependency on the order of these members > in slotptr() in typeobject.c . */ > PyTypeObject type; > PyNumberMethods as_number; > PyMappingMethods as_mapping; > PySequenceMethods as_sequence; /* as_sequence comes after as_mapping, > so that the mapping wins when both > the mapping and the sequence define > a given operator (e.g. __getitem__). > see add_operators() in typeobject.c . */ > PyBufferProcs as_buffer; > PyObject *name, *slots; <---LINE 343 > /* here are optional user slots, followed by the members. */ >} PyHeapTypeObject; I have not changed anything else in my code yet. But I think, what I have to do, is to wrap the callback into a PyGILState_Ensure/Release pair >void QtApp::callback() >{ > PyGILState_STATE state = PyGILState_Ensure(); > { > boost::python::call( _callback ); > > }; PyGILState_Release( state ); >}; I do not feel quite comfortable with this approch for two reasons: - I have to use a cvs (non-release) library and - The python IDLE I have to use is linked the application, my Qt-program wants to interact with. And I am not sure if the developer of that application give me the opportunity to exchange the python version they are linking to... Do you see any other way to call the callback with the facilities python 2.2 and boost-1.30.2 are offering to me? I enclose a complete set of files, which are cooked down to the essentials... Thanks for your help, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.h Type: application/octet-stream Size: 950 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.cxx Type: application/octet-stream Size: 1364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Thread.h Type: application/octet-stream Size: 257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Thread.cxx Type: application/octet-stream Size: 343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PyApp.pyste Type: application/octet-stream Size: 57 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QtApp.h Type: application/octet-stream Size: 1090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QtApp.cxx Type: application/octet-stream Size: 1101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.am Type: application/octet-stream Size: 731 bytes Desc: not available URL: From mike.thompson at day8.com.au Sun Sep 28 14:12:44 2003 From: mike.thompson at day8.com.au (Mike Thompson) Date: Sun, 28 Sep 2003 22:12:44 +1000 Subject: [C++-sig] vector_indexing_suite too defensive ... Message-ID: I've found a small difference between the behaviour of python lists and vector's wrapped by using the talented vector_indexing_suite. Let's say I write a python function which forces a list to be a particular size by padding it (if below the required size), or chopping it down (if above the required size): >>> def padOrChop(lst, size, padValue=0): ... diff = size- len(lst) ... lst[size:] = [padValue] * diff ... This function work nicely with normal python lists .... >>> >>> L = [2, 3, 4, 5] >>> padOrChop(L, 10) >>> L [2, 3, 4, 5, 0, 0, 0, 0, 0, 0] >>> padOrChop(L, 2) >>> L [2, 3] >>> but it will fail with an object created through vector_indexing_suite whenever it has to pad: >>> L = IntVec() # really a vector >>> L[:] = [2, 3, 4, 5] >>> padOrChop(L, 10) Traceback (most recent call last): File "", line 1, in ? File "", line 3, in padOrChop IndexError: Index out of range >>> padOrChop(L, 2) >>> [i for i in L] [2, 3] >>> The IndexError arises because vector_indexing_suite defends against an slice index being too big, rather than the python list approach which regards a slice index > len(L) as equal to len(L). So, the line of padOrChop() which says: lst[size:] = [padValue] * diff causes an exception when size > len(lst). Should vector_indexing_suite be altered to give behaviour more like that of lists in this regard? -- Mike From domma at procoders.net Sun Sep 28 15:24:12 2003 From: domma at procoders.net (Achim Domma (Procoders)) Date: Sun, 28 Sep 2003 15:24:12 +0200 Subject: [C++-sig] boost.python with gcc 3.3 on Suse 8.1 Message-ID: Hi, I have not worked with boost.python for some time now, but now I have to compile code with was working before. I'm using gcc 3.3 on Suse Linux 8.1 and get some internal compiler errors in function_templates.hpp. Should this work or what's the status of boost.python and gcc 3.3? regards, Achim From jbrandmeyer at earthlink.net Sun Sep 28 16:50:44 2003 From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer) Date: Sun, 28 Sep 2003 10:50:44 -0400 Subject: [C++-sig] boost.python with gcc 3.3 on Suse 8.1 In-Reply-To: References: Message-ID: <1064760644.982.16.camel@illuvatar> On Sun, 2003-09-28 at 09:24, Achim Domma (Procoders) wrote: > Hi, > > I have not worked with boost.python for some time now, but now I have to > compile code with was working before. I'm using gcc 3.3 on Suse Linux 8.1 > and get some internal compiler errors in function_templates.hpp. Should this > work or what's the status of boost.python and gcc 3.3? > > regards, > Achim G++ 3.3.0 has several debilitating bugs in it. Upgrading to 3.3.1 solved all of them for me. You may also need to upgrade to Boost 1.30.2. -Jonathan Brandmeyer From dave at boost-consulting.com Sun Sep 28 17:12:24 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 28 Sep 2003 11:12:24 -0400 Subject: [C++-sig] Re: calling a python-callback-function - switching to python 2.3 References: Message-ID: Lars Kunert writes: >>> Sorry I just recognized, that I had a typo in my mail (line 343 instead > of 69), but that does not change anything, cause I had a look at the right > place of the file (and I also included the right snip). I just mixed it up > when I wrote the mail. Well, your snip doesn't indicate which is line 343, but fundamentally this bug has nothing to do with Boost.Python AFAICT, since the error appears in the Python headers. My bet is that one of your Qt headers is defining a macro which stomps on a symbol used by Python. I suggest preprocessing your C++ file, stripping all the #... (preprocessor directive) lines, and compiling *that* to see if there's some obviously messed-up syntax. Also, you really need to be including your Boost.Python headers before anything that might bring in a system header when compiling under POSIX. This restriction is actually imposed by Python and POSIX, unfortunately. -- Dave Abrahams Boost Consulting www.boost-consulting.com From alellem at uwaterloo.ca Sun Sep 28 23:21:25 2003 From: alellem at uwaterloo.ca (Andrew Ellem) Date: Sun, 28 Sep 2003 17:21:25 -0400 Subject: [C++-sig] (no subject) Message-ID: <000001c38606$798faa50$0300a8c0@bender> I am having problems with Boost.Python (attempting to) delete classes passed to it. This is being done in the Battle constructor (which is invoked from C++). I'm basing my work off the embedding.cpp example, and I am creating the Python-derived class like this: (Where Script is a .py file and Script.Standard is derived from the Script in the Battle module below). [...] handle<> class_ptr( PyRun_String("Script.Standard\n", Py_eval_input, main_namespace.get(), main_namespace.get()) ); object PythonDerived(class_ptr); object py_base = PythonDerived(this); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This line is the problem [...] My module is defined like this: BOOST_PYTHON_MODULE(Battle) { class_("Battle", no_init) .def("GetHandle", &Battle::GetHandle) ; class_ ("Script", init()) ; } The PythonDerived constructor is called successfully (it prints, etc). However in the PythonDerived(this) call, I get error about an invalid HANDLE, in the Boost.Python instance_dealloc function at the line 284 of class.cpp: instance_holder::deallocate(inst, dynamic_cast(p)); It seems that Boost is trying to delete the Battle class that is being passed to it. Is this correct? How do I prevent this? I tried adding return_value_policy() to the init<> of Script, but it didn't' seem to change anything. Is this even what I want to do? I also tried to add boost::noncopyable to my definition of Battle, in hopes that it would prevent this, but then I would get errors about no to_python converter. I guess that I'm a little confused as to what exactly is going on, and how to go about fixing it. Thanks, Andrew From lkunert at mpi-sb.mpg.de Sun Sep 28 23:46:08 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Sun, 28 Sep 2003 23:46:08 +0200 Subject: [C++-sig] Re: calling a python-callback... Qt & boost & python Message-ID: Hi! It looks like I have finally solved my problem - despite there are some open questions. To launch a Qt-application from python into its own thread and to communicate between them, you can use the hippodraw-project strategy (like I have done) The trick in their approach is -to create a new thread first (using QThread) -then create an empty QApp-Singelton on the new Thread (with no child's...) -wait till the thread has completed doing this and then add the children of the QApp from the main thread. communication to the QtApp can be solves by wrapped methods... communication from the QtApp into python can be solved by registered callbacks: -at the time the new Thread is created, the interpreter-state of the old (main) thread can be accessed and used to create a new thread-state -the thread state (a pointer) has to be saved as a static class pointer // I hope someone can tell me why a normal class pointer (provided, that the instance does not change) is not good enough. >... > Thread *m_thread = new Thread(); > > m_thread->set_py_thread_state( PyThreadState_New( PyThreadState_Get()->interp )); > m_thread->start(); > ... -the python-callback-function pointers can be stored in the QtApp by use of normal wrapped set-methods -when the QtApp wants to use one of the callbacks it uses the stored threadstate to access the gil > PyEval_RestoreThread( m_thread->py_thread_state()); > boost::python::call( _clicked_callback ); > m_thread->set_py_thread_state( PyEval_SaveThread()); I have used: gcc version 3.3.1 boost 1.30.2 qt 3.1.1 OPEN QUESTIONS - why do I have to use a static class pointer to hold the result of the "PyThreadState_New"-call ? - how can I tell pyste (or gccxml) not to parse every included header - the problem is, that I had to include the boost/python-header into my python/c++ interface file Thanks for your help, Lars From dave at boost-consulting.com Mon Sep 29 01:24:11 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 28 Sep 2003 19:24:11 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38606$798faa50$0300a8c0@bender> Message-ID: "Andrew Ellem" writes: > I am having problems with Boost.Python (attempting to) delete classes > passed to it. > > This is being done in the Battle constructor (which is invoked from > C++). > I'm basing my work off the embedding.cpp example, and I am creating the > Python-derived class like this: (Where Script is a .py file and > Script.Standard is derived from the Script in the Battle module below). > > [...] > handle<> class_ptr( > PyRun_String("Script.Standard\n", Py_eval_input, > main_namespace.get(), main_namespace.get()) ); > > object PythonDerived(class_ptr); > > object py_base = PythonDerived(this); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This line is the problem > [...] > > > My module is defined like this: > > BOOST_PYTHON_MODULE(Battle) > { > class_("Battle", no_init) > .def("GetHandle", &Battle::GetHandle) > ; > > class_ > ("Script", init()) > ; > } > > > The PythonDerived constructor is called successfully (it prints, etc). > However in the PythonDerived(this) call, I get error about an invalid > HANDLE, in the Boost.Python instance_dealloc function at the line 284 of > class.cpp: > > instance_holder::deallocate(inst, dynamic_cast(p)); Andrew, Clearly the error must be coming from somewhere else, for example a destructor of one of your objects which uses a HANDLE. None of the Boost.Python code manipulates any type called HANDLE. > It seems that Boost is trying to delete the Battle class that is being > passed to it. Is this correct? It's impossible to tell much of anything from your example. Too much information is missing. Can you post a small reproducible case? > How do I prevent this? I tried adding > return_value_policy() to the init<> of > Script, but it didn't' seem to change anything. An __init__ function with a return value policy?? What is it returning? > Is this even what I want to do? Doesn't seem to be. > I also tried to add boost::noncopyable to my definition of Battle, in > hopes that it would prevent this, but then I would get errors about no > to_python converter. I guess that I'm a little confused as to what > exactly is going on, and how to go about fixing it. Yes, it seems like you're taking shots in the dark. Have you tried reading the documentation on Call Policies and/or stepping through the code that's crashing with a debugger? -- Dave Abrahams Boost Consulting www.boost-consulting.com From alellem at uwaterloo.ca Mon Sep 29 03:30:36 2003 From: alellem at uwaterloo.ca (Andrew Ellem) Date: Sun, 28 Sep 2003 21:30:36 -0400 Subject: [C++-sig] Re: (no subject) In-Reply-To: Message-ID: <000001c38629$49a11360$0300a8c0@bender> > Andrew, > > Clearly the error must be coming from somewhere else, for example > a destructor of one of your objects which uses a HANDLE. None of the > Boost.Python code manipulates any type called HANDLE. > You are correct in that it is my code that is causing the problem. More specifically, it is that Boost.Python is deleting one of my objects when I don't want it to. My problem is this: In my class's constructor, I create a class that is implemented in Python. The constructor takes a pointer to the calling class. Some pseudo-code for clarity's sake: class X { X() { Y y = PythonClass( this ) } } The problem is that after the __init__ method is called, Boost tries to clean up the arguments, which causes my calling class to be deleted, hence the crash. So my problem is how do I prevent this? I'm guessing the problem is that by default Python passes by value, and so does Boost. How do I do otherwise? I'm guessing call-policies, but in all honesty I'm having some trouble getting my head around them all. > Yes, it seems like you're taking shots in the dark. Have you tried > reading the documentation on Call Policies and/or stepping through the > code that's crashing with a debugger? I've read the documentation, but I admit I don't understand it 100%. From what I've read, I need to use a precall policy that tells Boost not to manage the variable I'm passing. But I'm really not sure which policy does this, or even one exists. I've been trying to find an example, the closest I can find is from the init.html example, which uses with_custodian_and_ward. Is this what I want to do? I don't really want to just throw it in and see if it works. Perhaps a better question, where can I find a thorough explanation of the way Python, and Boost.Python handle arguments? Thanks for your help, Andrew Ellem From domma at procoders.net Mon Sep 29 13:28:11 2003 From: domma at procoders.net (Achim Domma (Procoders)) Date: Mon, 29 Sep 2003 13:28:11 +0200 Subject: [C++-sig] boost.python with gcc 3.3 on Suse 8.1 In-Reply-To: <1064760644.982.16.camel@illuvatar> Message-ID: > G++ 3.3.0 has several debilitating bugs in it. Upgrading to 3.3.1 > solved all of them for me. You may also need to upgrade to Boost > 1.30.2. Upgrading to gcc 3.3.1 solved the problems! thanks, Achim From dave at boost-consulting.com Mon Sep 29 13:31:00 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 07:31:00 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: "Andrew Ellem" writes: >> Andrew, >> >> Clearly the error must be coming from somewhere else, for example a >> destructor of one of your objects which uses a HANDLE. None of the >> Boost.Python code manipulates any type called HANDLE. >> > > You are correct in that it is my code that is causing the problem. > More > > specifically, it is that Boost.Python is deleting one of my objects > when I don't want it to. > > My problem is this: In my class's constructor, I create a class that > is implemented in Python. The constructor takes a pointer to the > calling class. Some pseudo-code for clarity's sake: > > class X { X() { Y y = PythonClass( this ) } } > > The problem is that after the __init__ method is called, Boost tries > to clean up the arguments, which causes my calling class to be > deleted, hence the crash. So my problem is how do I prevent this? > > I'm guessing the problem is that by default Python passes by value, No, Python passes by reference always. > and so does Boost. How do I do otherwise? I'm guessing > call-policies, but in all honesty I'm having some trouble getting my > head around them all. Call policies are only for when Python is calling your C++ function. Does this help? http://www.boost.org/libs/python/doc/v2/ptr.html >> Yes, it seems like you're taking shots in the dark. Have you tried >> reading the documentation on Call Policies and/or stepping through >> the code that's crashing with a debugger? > > I've read the documentation, but I admit I don't understand it 100%. > From what I've read, I need to use a precall policy that tells Boost > not to manage the variable I'm passing. But I'm really not sure which > policy does this, or even one exists. > > I've been trying to find an example, the closest I can find is from > the init.html example, which uses with_custodian_and_ward. Is this > what I want to do? I don't really want to just throw it in and see if > it works. > > Perhaps a better question, where can I find a thorough explanation of > the way Python, and Boost.Python handle arguments? Unfortunately nowhere. -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Mon Sep 29 13:35:44 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Mon, 29 Sep 2003 19:35:44 +0800 Subject: [C++-sig] vector_indexing_suite too defensive ... References: Message-ID: <00a801c3867d$d7cd3610$64646464@godzilla> Mike Thompson wrote: > I've found a small difference between the behaviour of python lists and > vector's wrapped by using the talented vector_indexing_suite. > > Let's say I write a python function which forces a list to be a particular > size by padding it (if below the required size), or chopping it down (if > above the required size): > >>>> def padOrChop(lst, size, padValue=0): > ... diff = size- len(lst) > ... lst[size:] = [padValue] * diff > ... > > This function work nicely with normal python lists .... > >>>> >>>> L = [2, 3, 4, 5] >>>> padOrChop(L, 10) >>>> L > [2, 3, 4, 5, 0, 0, 0, 0, 0, 0] >>>> padOrChop(L, 2) >>>> L > [2, 3] >>>> > > but it will fail with an object created through vector_indexing_suite whenever > it has to pad: > >>>> L = IntVec() # really a vector >>>> L[:] = [2, 3, 4, 5] >>>> padOrChop(L, 10) > Traceback (most recent call last): > File "", line 1, in ? > File "", line 3, in padOrChop > IndexError: Index out of range >>>> padOrChop(L, 2) >>>> [i for i in L] > [2, 3] >>>> > > The IndexError arises because vector_indexing_suite defends against an slice > index being too big, rather than the python list approach which regards a > slice index > len(L) as equal to len(L). So, the line of padOrChop() which > says: > > lst[size:] = [padValue] * diff > > causes an exception when size > len(lst). > > Should vector_indexing_suite be altered to give behaviour more like that of > lists in this regard? It should. I think you uncovered a vector_indexing_suite bug. I'll correct this as soon as I can. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From RaoulGough at yahoo.co.uk Mon Sep 29 13:51:51 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 29 Sep 2003 12:51:51 +0100 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: "Andrew Ellem" writes: >> Andrew, >> >> Clearly the error must be coming from somewhere else, for example >> a destructor of one of your objects which uses a HANDLE. None of the >> Boost.Python code manipulates any type called HANDLE. >> > > You are correct in that it is my code that is causing the problem. More > > specifically, it is that Boost.Python is deleting one of my objects when > I > don't want it to. > > My problem is this: > In my class's constructor, I create a class that is implemented in > Python. > The constructor takes a pointer to the calling class. > Some pseudo-code for clarity's sake: > > class X { > X() { > Y y = PythonClass( this ) > } > } > > The problem is that after the __init__ method is called, Boost tries to > clean up the arguments, which causes my calling class to be deleted, > hence > the crash. So my problem is how do I prevent this? Without really understanding your example, I would *guess* that this is a Python reference counting issue. Have you read the docs under http://www.python.org/doc/current/ext/refcounts.html ? Also, if you want to manage Python objects in C++, the Boost.Python library has some code to help with the reference count management, mostly in the "object" class. Maybe grepping for the (undocumented?) borrowed_reference or new_reference in the libs/python/src tree will provide suitable examples? -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Mon Sep 29 15:53:54 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 09:53:54 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: Raoul Gough writes: > Also, if you want to manage Python objects in C++, the Boost.Python > library has some code to help with the reference count management, > mostly in the "object" class. Maybe grepping for the (undocumented?) > borrowed_reference or new_reference in the libs/python/src tree will > provide suitable examples? Uhm. Those are really not for user consumption, which is why they're not in namespace boost::python::. I'm not sure it was the right choice, but users are supposed to go through handle<> to acquire references. Either: handle<> x(whatever); // new reference handle<> x(borrowed(whatever)); // borrowed reference object(x); // now we have an object. I've been thinking a bit about this interface recently. I think something like the following might be better: class reference { public: PyObject* get() const; ... protected: reference(PyObject*); reference(); private: void operator delete(void*); // not defined void operator delete(void*, size_t); }; class borrowed_reference : reference { public: borrowed_reference(PyObject*); }; class new_reference : reference { public: new_reference(PyObject*); }; This allows python::references to be passed around, but not constructed. You have to say borrowed_reference or new_reference explicitly. -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Mon Sep 29 16:46:32 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 29 Sep 2003 15:46:32 +0100 Subject: [C++-sig] Re: vector_indexing_suite too defensive ... References: <00a801c3867d$d7cd3610$64646464@godzilla> Message-ID: "Joel de Guzman" writes: > Mike Thompson wrote: [snip] >> The IndexError arises because vector_indexing_suite defends against >> an slice index being too big, rather than the python list approach >> which regards a slice index > len(L) as equal to len(L). So, the >> line of padOrChop() which says: >> >> lst[size:] = [padValue] * diff >> >> causes an exception when size > len(lst). >> >> Should vector_indexing_suite be altered to give behaviour more like >> that of lists in this regard? > > It should. I think you uncovered a vector_indexing_suite bug. I'll > correct this as soon as I can. Hi Joel, You might find the PySlice_GetIndices function useful - it take a Python slice object and a container length and returns normalized start and stop values (even handling negative indices, IIRC). At a guess, this is probably how the Python list works internally too. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From RaoulGough at yahoo.co.uk Mon Sep 29 17:19:57 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 29 Sep 2003 16:19:57 +0100 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: David Abrahams writes: > Raoul Gough writes: > >> Also, if you want to manage Python objects in C++, the Boost.Python >> library has some code to help with the reference count management, >> mostly in the "object" class. Maybe grepping for the (undocumented?) >> borrowed_reference or new_reference in the libs/python/src tree will >> provide suitable examples? > > Uhm. Those are really not for user consumption, which is why they're > not in namespace boost::python::. Oh, OK. I should have been using this all along. That's what I get for learning from the implementation code instead of reading the documentation! > I'm not sure it was the right choice, but users are supposed to go > through handle<> to acquire references. Either: > > handle<> x(whatever); // new reference > handle<> x(borrowed(whatever)); // borrowed reference > > object(x); // now we have an object. Well this interface seems OK to me. If anything is wrong with it, maybe it would be safer not to accept plain pointers, and require something like new_reference for new references. This would force the user to make the decision explicitly, rather than possibly getting it by mistake. BTW, does this work without partial template specialization support? > I've been thinking a bit about this interface recently. I think > something like the following might be better: > > class reference > { > public: > PyObject* get() const; > ... > protected: > reference(PyObject*); > reference(); > private: > void operator delete(void*); // not defined > void operator delete(void*, size_t); > }; > > class borrowed_reference : reference > { > public: > borrowed_reference(PyObject*); > }; > > class new_reference : reference > { > public: > new_reference(PyObject*); > }; > > This allows python::references to be passed around, but not > constructed. You have to say borrowed_reference or new_reference > explicitly. Using this approach would cause me to worry about object slicing (C++ object slicing, I mean) since I would probably tend to pass and certainly return reference objects by value. I suppose the base class would actually be equipped to handle everything internally, but I would *usually* assume that the following code is wrong: reference make_python_object () { return new_reference (/*...*/); // Slices object on return } The overloaded constructor approach has the advantage that it makes it clear that the type of the constructed object is the same whatever the original source of the raw pointer. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From dave at boost-consulting.com Mon Sep 29 17:47:09 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 11:47:09 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: Raoul Gough writes: > David Abrahams writes: > >> Raoul Gough writes: >> >>> Also, if you want to manage Python objects in C++, the Boost.Python >>> library has some code to help with the reference count management, >>> mostly in the "object" class. Maybe grepping for the (undocumented?) >>> borrowed_reference or new_reference in the libs/python/src tree will >>> provide suitable examples? >> >> Uhm. Those are really not for user consumption, which is why they're >> not in namespace boost::python::. > > Oh, OK. I should have been using this all along. That's what I get for > learning from the implementation code instead of reading the > documentation! > >> I'm not sure it was the right choice, but users are supposed to go >> through handle<> to acquire references. Either: >> >> handle<> x(whatever); // new reference >> handle<> x(borrowed(whatever)); // borrowed reference >> >> object(x); // now we have an object. > > Well this interface seems OK to me. If anything is wrong with it, > maybe it would be safer not to accept plain pointers, and require > something like new_reference for new references. This would force > the user to make the decision explicitly, rather than possibly > getting it by mistake. > > BTW, does this work without partial template specialization support? Of course. >> I've been thinking a bit about this interface recently. I think >> something like the following might be better: >> >> class reference >> { >> public: >> PyObject* get() const; >> ... >> protected: >> reference(PyObject*); >> reference(); >> private: >> void operator delete(void*); // not defined >> void operator delete(void*, size_t); >> }; >> >> class borrowed_reference : reference >> { >> public: >> borrowed_reference(PyObject*); >> }; >> >> class new_reference : reference >> { >> public: >> new_reference(PyObject*); >> }; >> >> This allows python::references to be passed around, but not >> constructed. You have to say borrowed_reference or new_reference >> explicitly. > > Using this approach would cause me to worry about object slicing (C++ > object slicing, I mean) since I would probably tend to pass and > certainly return reference objects by value. I suppose the base class > would actually be equipped to handle everything internally, but I > would *usually* assume that the following code is wrong: > > reference make_python_object () { > return new_reference (/*...*/); // Slices object on return > } There's nothing wrong with "slicing". Its dangers are vastly overrated. Think of it as an implicit conversion operator. > The overloaded constructor approach has the advantage that it makes it > clear that the type of the constructed object is the same whatever the > original source of the raw pointer. Well, my point was that I thought it was more useful and safer to encode the acquisition method in the type. Could be wrong, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com From lkunert at mpi-sb.mpg.de Mon Sep 29 18:04:48 2003 From: lkunert at mpi-sb.mpg.de (Lars Kunert) Date: Mon, 29 Sep 2003 18:04:48 +0200 Subject: [C++-sig] python-list to c++-vector Message-ID: Hi! Is this here really the easiest and the fastest way to transfer a small (<10000) python-list of integers into a std::vector?! #include #include #include class Ints { private: std::vector _ints; public: void set( boost::python::object o ) { boost::python::list list = boost::python::extract(o); try { _ints.clear(); bool is_ok = true; while( is_ok ) { boost::python::extract x( list.pop( 0 )); if( x.check()) { _ints.push_back( x()); } else { is_ok = false; }; }; } catch ( ... ) { std::cerr << "exception thrown"; }; }; }; // Using ======================================================================= using namespace boost::python; // Module ====================================================================== BOOST_PYTHON_MODULE(Iterator_module) { class_< Ints >("Ints", init<>()) .def("set", &Ints::set ) ; }; From pierre.barbier at cirad.fr Mon Sep 29 18:00:35 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Mon, 29 Sep 2003 18:00:35 +0200 Subject: [C++-sig] python-list to c++-vector In-Reply-To: References: Message-ID: <1064851235.960.12.camel@pbarbier> Mmmm ... if you really want to only have list, you may use boost::python::list as argument : simpler, clearer and boost.python does the verification job for you ! But if you want to be able to extract every sequence, I would suggest the use of python iterator as it's more general. For that, you should use the PyObject_GetIter function (or there is a boost object ???) and then use the "next" attribute like this : void set( boost::python::object o ) { try { object iter_obj = object( handle<>( PyObject_GetIter( o.ptr() ) ) ); while( 1 ) { object obj = extract( iter_obj.attr( "next" )() ); // Should always work int val = extract( obj ); // Should launch an exception if you wannot extract an int ... _ints.push_back(val); } } catch( error_already_set ) { PyErr_Clear(); // If there is an exception (no iterator, extract failed or end of the list reached), clear it and exit the function return; } } The only pb I have with my function is you cannot make the difference between the various exceptions. Le lun 29/09/2003 ? 18:04, Lars Kunert a ?crit : > Hi! > > Is this here really the easiest and the fastest way to transfer a small > (<10000) python-list of integers into a std::vector?! > > > // Using > ======================================================================= > using namespace boost::python; > > // Module > ====================================================================== > BOOST_PYTHON_MODULE(Iterator_module) > { > class_< Ints >("Ints", init<>()) > .def("set", &Ints::set ) > ; > }; > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- 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 From RaoulGough at yahoo.co.uk Mon Sep 29 18:29:13 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Mon, 29 Sep 2003 17:29:13 +0100 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: David Abrahams writes: > Raoul Gough writes: [snip] >> Using this approach would cause me to worry about object slicing (C++ >> object slicing, I mean) since I would probably tend to pass and >> certainly return reference objects by value. I suppose the base class >> would actually be equipped to handle everything internally, but I >> would *usually* assume that the following code is wrong: >> >> reference make_python_object () { >> return new_reference (/*...*/); // Slices object on return >> } > > There's nothing wrong with "slicing". Its dangers are vastly > overrated. Think of it as an implicit conversion operator. I don't think I overrate the dangers of slicing - they are real and should be considered when slicing happens. Pass or return by value could be totally wrong, depending on the implementation details. For instance, assume that ~reference() does nothing, and only ~new_reference() does a Py_DECREF. This would be a workable implementation, and would mean that borrowed_reference doesn't have to increment the reference count to compensate for the base class destructor. Unfortunately, returning the base-class part of a new_reference object would then delete the target object immediately. I guess my point is that without investigating further, somebody reading the code can't tell if the slicing is benign or not. Of course, any experienced C++ programmer chooses return by value vs. by smart pointer "automatically" depending on the situation - thus neatly avoiding the potential problems. >> The overloaded constructor approach has the advantage that it makes it >> clear that the type of the constructed object is the same whatever the >> original source of the raw pointer. > > Well, my point was that I thought it was more useful and safer to > encode the acquisition method in the type. > > Could be wrong, though. It also seems safer to me, since the base class constructor is protected. On the other hand, maybe removing the plain pointer overload for handle<>::handle() would be just as good? -- Raoul Gough. (setq dabbrev-case-fold-search nil) From llywelyn.geo at yahoo.com Mon Sep 29 19:05:36 2003 From: llywelyn.geo at yahoo.com (Joel Gerard) Date: Mon, 29 Sep 2003 10:05:36 -0700 (PDT) Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with static/non-static overloading In-Reply-To: Message-ID: <20030929170536.70200.qmail@web41507.mail.yahoo.com> Thanks for the advice. There are a few things I'm still vague on though. I've been overloading static, and non-static members without apparent problems, but I'm now starting to be suspicious. For instance, I have: Vector (Vector::*CreateCross1)(const Vector&) const = &Vector::CreateCross ; Vector (*CreateCross2)(const Vector&, const Vector&) = &Vector::CreateCross; .def("CreateCross",CreateCross1) .def("CreateCross",CreateCross2) The one I call as a bound method, and the other unbound, i.e.: Vector2 = Vector1.CreateCross(Vector3) Vector2 = module.Vector.CreateCross(Vector1,Vector3) Is something going on here that I'm not seeing. They work ok apparently. Regarding the vector problem. I cannot modify the original C++ code. I want to keep Normalize as an unbound method in Vector since I might have name collisions if I put them at the module level. I tried .def("Yahoo",Normalize3) but it too gave me a type error. What is Boost trying to do? The function pointer is poiting to the correct function. Furthermore, don't you have to do something different than just a plain .def since the arguments to Normalize are references? Does Boost automatically detect this? How does it deal with something like: Add(int x, int y, int &result) So when you do >>>Add(x,y,result) in python, what happens? I think I'm missing something fundamental here... :( Thanks for your help. Joel --- David Abrahams <> wrote: > "Mike Rovner" <> writes: > > > Joel Gerard wrote: > > > >> .def("Normalize",VectorNormalize1) > >> .def("Normalize",VectorNormalize2) > >> .def("Normalize",VectorNormalize3) > > > > You have to say .staticmethod("Normalize") > > Well, except he has a static method overloaded with > a non-static one, > and Boost.Python doesn't really support that idiom > (see thread at > http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1811696). > I > suggest forgoing instance-less access for the static > method as > follows: > > f32 nonstatic_Normalize(Vector&, Vector& kV) { > return Vector::Normalize(kV); } > > > .def("Normalize",VectorNormalize1) > .def("Normalize",nonstatic_Normalize) > .def("Normalize",VectorNormalize3) > > You can also def() the static normalize at module > scope: > > def("Normalize", VectorNormalize2); > > and then: > > >>> v = Vector() > >>> Normalize(v) > > which in many ways is a more natural interface > anyway. > > > HTH, > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From s_sourceforge at nedprod.com Mon Sep 29 19:16:58 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 29 Sep 2003 18:16:58 +0100 Subject: [C++-sig] return_existing_reference Message-ID: <3F78771A.18929.376E0EA9@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Out of interest (couldn't find this in the docs), if the C++ code returns a NULL pointer does Boost.Python translate this under return_existing_reference and return_internal_reference as None? Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3hpC8EcvDLFGKbPEQKhfQCgoPqXSXVeFApiKOexfAgP11yV0kMAoI6D Lnma/g7MR46TAD0m4Py5Lz7z =1Yrs -----END PGP SIGNATURE----- From s_sourceforge at nedprod.com Mon Sep 29 18:52:14 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 29 Sep 2003 17:52:14 +0100 Subject: [C++-sig] Two Pyste suggestions Message-ID: <3F78714E.30515.37576749@localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yeah, more ideas! The first is a bit radical. I've organised the policies for my project into a python package called "Policies". Within it is a .py file for every class in my library and within each of those is an apply() method. In the pyste files, each class imports its policy from Policies. and calls Policies..apply(). This in turn imports the policy .py files for each of the base classes the class inherits from and calls their apply() methods first before setting its own policies for its own local class. Thus you see a change to a base class automatically propagates through the policy hierarchy. Now my suggestion is that since pyste knows what classes any class inherits, it could spit out the import's and apply()'s for each policy for class. It would save some work (I've already done it manually, wish I'd thought of it sooner). The second suggestion was as I made last time, a --files parameter to specify a file from which to read the list of pyste files as Win2k has a 2Kb limit. I've attached the pyste.py file for an example. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP3hjPsEcvDLFGKbPEQJanACg8exEBe66enOWYGcMeMEAh1bXbF4An1QO BYYW2KwFEC8mV+ITYUtJAKxz =4Y4o -----END PGP SIGNATURE----- From dave at boost-consulting.com Mon Sep 29 20:05:07 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 14:05:07 -0400 Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with static/non-static overloading References: <20030929170536.70200.qmail@web41507.mail.yahoo.com> Message-ID: Joel Gerard writes: > Thanks for the advice. There are a few things I'm still vague on though. I've been overloading > static, and non-static members without apparent problems, but I'm now starting to be suspicious. > > For instance, I have: > > Vector (Vector::*CreateCross1)(const Vector&) const = &Vector::CreateCross ; > Vector (*CreateCross2)(const Vector&, const Vector&) = &Vector::CreateCross; > > .def("CreateCross",CreateCross1) > .def("CreateCross",CreateCross2) > > The one I call as a bound method, and the other unbound, i.e.: > > Vector2 = Vector1.CreateCross(Vector3) > Vector2 = module.Vector.CreateCross(Vector1,Vector3) > > Is something going on here that I'm not seeing. They work ok apparently. Both are calling CreateCross2. > Regarding the vector problem. I cannot modify the original C++ code. I want to keep Normalize as > an unbound method in Vector since I might have name collisions if I > put them at the module level. What collisions? There's overloading at the module level too, you know. > I tried .def("Yahoo",Normalize3) but it too gave me a type > error. What is Boost trying to do? I have no idea; post a reproducible test case. Maybe you forgot to make it static? > The function pointer is poiting to the correct function. > > Furthermore, don't you have to do something different than just a > plain .def since the arguments to Normalize are references? No. > Does Boost automatically detect this? It does detect that they are references. > How does it deal with something like: > > Add(int x, int y, int &result) > > So when you do >>>Add(x,y,result) in python, what happens? argument error, but that's because Python ints are immutable. Classes don't play by the same rules. > I think I'm missing something fundamental here... :( > > Thanks for your help. > Joel Sure thing. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Sep 29 20:06:03 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 14:06:03 -0400 Subject: [C++-sig] Re: return_existing_reference References: <3F78771A.18929.376E0EA9@localhost> Message-ID: "Niall Douglas" writes: > Out of interest (couldn't find this in the docs), if the C++ code > returns a NULL pointer does Boost.Python translate this under > return_existing_reference and return_internal_reference as None? Yes. You can see that in the tests, if not in the docs (not that that is any excuse for not documenting it). -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Sep 29 23:40:02 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 29 Sep 2003 17:40:02 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: Raoul Gough writes: > David Abrahams writes: > >> Raoul Gough writes: > [snip] >>> Using this approach would cause me to worry about object slicing (C++ >>> object slicing, I mean) since I would probably tend to pass and >>> certainly return reference objects by value. I suppose the base class >>> would actually be equipped to handle everything internally, but I >>> would *usually* assume that the following code is wrong: >>> >>> reference make_python_object () { >>> return new_reference (/*...*/); // Slices object on return >>> } >> >> There's nothing wrong with "slicing". Its dangers are vastly >> overrated. Think of it as an implicit conversion operator. > > I don't think I overrate the dangers of slicing - they are real and > should be considered when slicing happens. Pass or return by value > could be totally wrong, depending on the implementation details. For > instance, assume that ~reference() does nothing, and only > ~new_reference() does a Py_DECREF. This would be a workable > implementation, and would mean that borrowed_reference doesn't have to > increment the reference count to compensate for the base class > destructor. Unfortunately, returning the base-class part of a > new_reference object would then delete the target object > immediately. I guess my point is that without investigating further, > somebody reading the code can't tell if the slicing is benign or > not. OK, good point. >> Well, my point was that I thought it was more useful and safer to >> encode the acquisition method in the type. >> >> Could be wrong, though. > > It also seems safer to me, since the base class constructor is > protected. On the other hand, maybe removing the plain pointer > overload for handle<>::handle() would be just as good? Can't do that without providing a new_reference(...) wrapper. > -- > Raoul Gough. > (setq dabbrev-case-fold-search nil) Interesting sig. Do you want me to `C-x C-e' it? -- Dave Abrahams Boost Consulting www.boost-consulting.com From djowel at gmx.co.uk Tue Sep 30 01:08:18 2003 From: djowel at gmx.co.uk (Joel de Guzman) Date: Tue, 30 Sep 2003 07:08:18 +0800 Subject: [C++-sig] Re: vector_indexing_suite too defensive ... References: <00a801c3867d$d7cd3610$64646464@godzilla> Message-ID: <004101c386de$979baed0$450caccb@godzilla> Raoul Gough wrote: > "Joel de Guzman" writes: > >> Mike Thompson wrote: > [snip] >>> The IndexError arises because vector_indexing_suite defends against >>> an slice index being too big, rather than the python list approach >>> which regards a slice index > len(L) as equal to len(L). So, the >>> line of padOrChop() which says: >>> >>> lst[size:] = [padValue] * diff >>> >>> causes an exception when size > len(lst). >>> >>> Should vector_indexing_suite be altered to give behaviour more like >>> that of lists in this regard? >> >> It should. I think you uncovered a vector_indexing_suite bug. I'll >> correct this as soon as I can. > > Hi Joel, > > You might find the PySlice_GetIndices function useful - it take a > Python slice object and a container length and returns normalized > start and stop values (even handling negative indices, IIRC). At a > guess, this is probably how the Python list works internally too. I *was* using PySlice_GetIndices. The problem was (if I'm not mistaken), is that it does not handle non-integer inteces. Correct me if I'm wrong. For example, I have a case where the indexes are dates that I must convert to a valid index. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From nicodemus at globalite.com.br Tue Sep 30 06:10:16 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Tue, 30 Sep 2003 01:10:16 -0300 Subject: [C++-sig] Two Pyste suggestions In-Reply-To: <3F78714E.30515.37576749@localhost> References: <3F78714E.30515.37576749@localhost> Message-ID: <3F790228.7010503@globalite.com.br> Hi Niall, Niall Douglas wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Yeah, more ideas! > >The first is a bit radical. I've organised the policies for my >project into a python package called "Policies". Within it is a .py >file for every class in my library and within each of those is an >apply() method. > >In the pyste files, each class imports its policy from >Policies. and calls Policies..apply(). This in >turn imports the policy .py files for each of the base classes the >class inherits from and calls their apply() methods first before >setting its own policies for its own local class. Thus you see a >change to a base class automatically propagates through the policy >hierarchy. > >Now my suggestion is that since pyste knows what classes any class >inherits, it could spit out the import's and apply()'s for each >policy for class. It would save some work (I've already done it >manually, wish I'd thought of it sooner). > Unfortunately, Pyste at that point (while executing the Pyste files) doesn't know anything about the bases. For that matter, it doesn't know any details about the class. The header file will be parsed only later, when the code is about to be generated. To implement something that would allow you to do what you want, all the class information should be avaiable as you execute the Pyste file, ie, a Class(...) would return an object with the methods, bases, etc, of the C++ class, which doesn't happen right now. But I plan to make a change like that in the future, so we can think about how to integrate a facility that would make it easy to do stuff like you want. >The second suggestion was as I made last time, a --files parameter to >specify a file from which to read the list of pyste files as Win2k >has a 2Kb limit. I've attached the pyste.py file for an example. > Sure thing, it's in my TODO list. It should be ready tomorrow, with some updated documentation (at last!). Thanks for the feedback! Regards, Nicodemus. From ejoy at 163.com Tue Sep 30 08:46:40 2003 From: ejoy at 163.com (Zhang Le) Date: Tue, 30 Sep 2003 14:46:40 +0800 Subject: [C++-sig] On wrapping vector > In-Reply-To: <20030319170009.26215.8977.Mailman@mail.python.org> References: <20030319170009.26215.8977.Mailman@mail.python.org> Message-ID: Hello, I'm trying to wrap a function that takes a vector > as input and return a list. The original function is vector eval(const vector >&); to use boost python, I write a wrapper function: python::list py_eval(python::tuple input) { here I want to use python::extract(input[i][0]) and python::extract(py_context[i][1]) to transform python input [('A', 1.0), ('B', 2.0), ...] into a new vector > for calling real eval() } Compilation is ok and I get an error in python code: obj.py_eval([('A', 1.0), ('B', 2.0)]) TypeError: No registered converter was able to produce a C++ rvalue of type j from this Python object of type str I change the declaration to python::list input, python::object input and get the same error result. Am I missing anything? -- Sincerely yours, Zhang Le From gero_mailinglist at gmx.de Tue Sep 30 09:54:09 2003 From: gero_mailinglist at gmx.de (gero_mailinglist at gmx.de) Date: Tue, 30 Sep 2003 09:54:09 +0200 (MEST) Subject: [C++-sig] constructing datetime objects References: Message-ID: <8899.1064908449@www48.gmx.net> Hi, I am pretty new to boost python and consider integrating an existing C++ library into python 2.3. My C++ library defines its own datetime class, but I think it is nicer if the python functions use the Python datetime module. How do I write a function that returns a python datetime object, initialised e.g. via an ordinal number or maybe year, month, day, etc. I have not found out yet how to call a constructor in boost::python (Is there something in the tutorial?). The other way, e.g. getting the year from a python datetime object dt is no problem using python::extract(dt.attr("year")). Thanks in advance, Gero -- NEU F?R ALLE - GMX MediaCenter - f?r Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gru?, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse f?r Mail, Message, More! +++ From nicodemus at globalite.com.br Tue Sep 30 13:06:31 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Tue, 30 Sep 2003 08:06:31 -0300 Subject: [C++-sig] On wrapping vector > In-Reply-To: References: <20030319170009.26215.8977.Mailman@mail.python.org> Message-ID: <3F7963B7.3030904@globalite.com.br> Zhang Le wrote: >Hello, > I'm trying to wrap a function that takes a vector > > as input and return a list. The original function is > vector eval(const vector >&); > > to use boost python, I write a wrapper function: > python::list py_eval(python::tuple input) { > here I want to use python::extract(input[i][0]) > and python::extract(py_context[i][1]) > to transform python input [('A', 1.0), ('B', 2.0), ...] > into a new vector > for calling real > eval() > } > > Compilation is ok and I get an error in python code: > obj.py_eval([('A', 1.0), ('B', 2.0)]) > TypeError: No registered converter was able to produce a C++ rvalue > of type j from this Python object of type str > > I change the declaration to python::list input, python::object input > and get the same error result. > > Am I missing anything? > > It is hard to tell by your description of the problem alone, some code would help. But try this: py::list py_eval(py::list v) { vector< pair > input; int i; int len = py::extract(v.attr("__len__")()); for (i = 0; i < len; ++i) { string s = py::extract(v[i][0]); double d = py::extract(v[i][1]); input.push_back(pair(s, d)); } vector result = eval(input); py::list pyresult; for (i = 0; i < result.size(); ++i) { pyresult.append(result[i]); } return pyresult; } HTH, Nicodemus. From RaoulGough at yahoo.co.uk Tue Sep 30 13:08:45 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 30 Sep 2003 12:08:45 +0100 Subject: [C++-sig] Re: vector_indexing_suite too defensive ... References: <00a801c3867d$d7cd3610$64646464@godzilla> <004101c386de$979baed0$450caccb@godzilla> Message-ID: "Joel de Guzman" writes: > Raoul Gough wrote: >> "Joel de Guzman" writes: >> >>> Mike Thompson wrote: >> [snip] >>>> The IndexError arises because vector_indexing_suite defends against >>>> an slice index being too big, rather than the python list approach >>>> which regards a slice index > len(L) as equal to len(L). So, the >>>> line of padOrChop() which says: >>>> >>>> lst[size:] = [padValue] * diff >>>> >>>> causes an exception when size > len(lst). >>>> >>>> Should vector_indexing_suite be altered to give behaviour more like >>>> that of lists in this regard? >>> >>> It should. I think you uncovered a vector_indexing_suite bug. I'll >>> correct this as soon as I can. >> >> Hi Joel, >> >> You might find the PySlice_GetIndices function useful - it take a >> Python slice object and a container length and returns normalized >> start and stop values (even handling negative indices, IIRC). At a >> guess, this is probably how the Python list works internally too. > > I *was* using PySlice_GetIndices. The problem was (if I'm not mistaken), > is that it does not handle non-integer inteces. Correct me if I'm wrong. > For example, I have a case where the indexes are dates that I must convert > to a valid index. Well, it only works for slices, which (AFAIK) rules out non-integer values anyway. I'm confused now about what the original problem was, because I think using PySlice_GetIndices would already rule out any problems with lst[99999:] and so on. Problems with lst[99999] (i.e. not a slice) are a different matter, and even Python lists barf on indexes out of range here. -- Raoul Gough. (setq dabbrev-case-fold-search nil) From RaoulGough at yahoo.co.uk Tue Sep 30 13:03:14 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 30 Sep 2003 12:03:14 +0100 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: David Abrahams writes: > Raoul Gough writes: > >> David Abrahams writes: [snip] >>> Well, my point was that I thought it was more useful and safer to >>> encode the acquisition method in the type. >>> >>> Could be wrong, though. >> >> It also seems safer to me, since the base class constructor is >> protected. On the other hand, maybe removing the plain pointer >> overload for handle<>::handle() would be just as good? > > Can't do that without providing a new_reference(...) wrapper. That's more or less what I was thinking, too. Is this a bad idea? > >> -- >> Raoul Gough. >> (setq dabbrev-case-fold-search nil) > > Interesting sig. Do you want me to `C-x C-e' it? Well, sure. Unless you think it's a Trojan horse :-) I was trying to think of a handy Emacs feature from my .emacs to publicize, but dabbrev was all I came up with. Maybe I should move on to (add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode)) -- Raoul Gough. (add-hook 'python-mode-hook 'turn-on-font-lock) From dave at boost-consulting.com Tue Sep 30 13:54:21 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 30 Sep 2003 07:54:21 -0400 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: Raoul Gough writes: > David Abrahams writes: > >> Raoul Gough writes: >> >>> David Abrahams writes: > [snip] >>>> Well, my point was that I thought it was more useful and safer to >>>> encode the acquisition method in the type. >>>> >>>> Could be wrong, though. >>> >>> It also seems safer to me, since the base class constructor is >>> protected. On the other hand, maybe removing the plain pointer >>> overload for handle<>::handle() would be just as good? >> >> Can't do that without providing a new_reference(...) wrapper. > > That's more or less what I was thinking, too. Is this a bad idea? > >> >>> -- >>> Raoul Gough. >>> (setq dabbrev-case-fold-search nil) >> >> Interesting sig. Do you want me to `C-x C-e' it? > > Well, sure. Unless you think it's a Trojan horse :-) I was trying to > think of a handy Emacs feature from my .emacs to publicize, but > dabbrev was all I came up with. Maybe I should move on to What's handy about that? The emacs help for it doesn't really tell me why I'd want to use it. > (add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode)) That one *is* a trojan. I'm not sure python-mode is standard in many emacs installations. ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com From RaoulGough at yahoo.co.uk Tue Sep 30 15:01:47 2003 From: RaoulGough at yahoo.co.uk (Raoul Gough) Date: Tue, 30 Sep 2003 14:01:47 +0100 Subject: [C++-sig] Re: (no subject) References: <000001c38629$49a11360$0300a8c0@bender> Message-ID: David Abrahams writes: > Raoul Gough writes: > >> David Abrahams writes: >> >>> Raoul Gough writes: >>>> (setq dabbrev-case-fold-search nil) >>> >>> Interesting sig. Do you want me to `C-x C-e' it? >> >> Well, sure. Unless you think it's a Trojan horse :-) I was trying to >> think of a handy Emacs feature from my .emacs to publicize, but >> dabbrev was all I came up with. Maybe I should move on to > > What's handy about that? The emacs help for it doesn't really tell > me why I'd want to use it. Well the C-h v help for dabbrev-case-fold-search doesn't say much, I admit - the really useful information is in the Emacs "Abbrevs" info nodes. Since C++ is case sensitive, I find dynamic expansion more natural if it doesn't use expansions with the wrong case. YMMV. I'd used Emacs on and off for about /five years/ before somebody told me about M-/ -- Raoul Gough. (setq dabbrev-case-fold-search nil) From llywelyn.geo at yahoo.com Tue Sep 30 23:12:40 2003 From: llywelyn.geo at yahoo.com (Joel Gerard) Date: Tue, 30 Sep 2003 14:12:40 -0700 (PDT) Subject: [C++-sig] Re: Boost.Python : Byref parameters - no problems with static/non-static overloading In-Reply-To: Message-ID: <20030930211240.98818.qmail@web41511.mail.yahoo.com> Ok. I've got things mostly sorted out. You can't overload static and non-static member functions, which is fine, but how do you use a static (not overloaded) function in Python? I need to keep the static function in the class scope. The reason is name collision, i.e. class A { static void foo(); } class B { static void foo(); } I have: class Vector { public: static void Orthonormalize (Vector& kU, Vector& kV, Vector& kW); } Wrapped as: void (*Orthonormalize2)(Vector&, Vector&, Vector&) = &Vector::Orthonormalize; .def("Orthonormalize",Orthonormalize2) .staticmethod("Orthonormalize") In python, do you just use it as an unbound method? Is the self argument non-existent in this case, or do I do something different? Currently I have: Vector.Orthonormalize (Vector1, Vector2, Vector3) Also, is there a good place to look for python examples. I didn't see a python example in the docs, but perhaps there is something else? Thanks, Joel --- David Abrahams <> wrote: > Joel Gerard <> writes: > > > Thanks for the advice. There are a few things I'm still vague on though. I've been overloading > > static, and non-static members without apparent problems, but I'm now starting to be > suspicious. > > > > For instance, I have: > > > > Vector (Vector::*CreateCross1)(const Vector&) const = &Vector::CreateCross ; > > Vector (*CreateCross2)(const Vector&, const Vector&) = &Vector::CreateCross; > > > > .def("CreateCross",CreateCross1) > > .def("CreateCross",CreateCross2) > > > > The one I call as a bound method, and the other unbound, i.e.: > > > > Vector2 = Vector1.CreateCross(Vector3) > > Vector2 = module.Vector.CreateCross(Vector1,Vector3) > > > > Is something going on here that I'm not seeing. They work ok apparently. > > Both are calling CreateCross2. > > > Regarding the vector problem. I cannot modify the original C++ code. I want to keep Normalize > as > > an unbound method in Vector since I might have name collisions if I > > put them at the module level. > > What collisions? There's overloading at the module level too, you > know. > > > I tried .def("Yahoo",Normalize3) but it too gave me a type > > error. What is Boost trying to do? > > I have no idea; post a reproducible test case. > > Maybe you forgot to make it static? > > > The function pointer is poiting to the correct function. > > > > Furthermore, don't you have to do something different than just a > > plain .def since the arguments to Normalize are references? > > No. > > > Does Boost automatically detect this? > > It does detect that they are references. > > > How does it deal with something like: > > > > Add(int x, int y, int &result) > > > > So when you do >>>Add(x,y,result) in python, what happens? > > argument error, but that's because Python ints are immutable. Classes > don't play by the same rules. > > > I think I'm missing something fundamental here... :( > > > > Thanks for your help. > > Joel > > Sure thing. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig ===== -------------------------------------- Email: joelgerard at canada.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com