, argc=2, ubp_av=0xbffffb54, init=0x80522d4 <_init>, fini=0x80cf610 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffb4c) at ../sysdeps/generic/libc-start.c:129 (gdb) On the line of the error oldtype = tstate->curexc_type; (gdb) p tstate $1 = (PyThreadState *) 0x0 (gdb) It really appears to me that Boost.Python extensions and SIP Python extensions are incompatible with each other. Or there is still something that I'm doing wrong. Any suggestions on how to proceed? From langston at SLAC.Stanford.EDU Tue Dec 10 04:08:02 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Mon, 09 Dec 2002 19:08:02 -0800 Subject: [C++-sig] how to wrap getter returning shared_ptr Message-ID: I answered my own question through trial-and-error experimentation. If I want to have Boost.Python return a "shared_ptr < Bar >", then I must export Bar to python using the second template argument to class_ as follows: class_< Bar, shared_ptr < Bar > > ( "Bar" ).add_property ("message", &Bar::get_Message); Matt -----Original Message----- From: Langston, Matthew David Sent: Monday, December 09, 2002 4:09 PM To: 'c++-sig at python.org' Subject: [C++-sig] how to wrap getter returning shared_ptr How do I wrap a C++ member function that returns a shared_ptr? Here is an example of what I want to do: class Bar { private: std::string m_message; public: Bar() { m_message = "Bar: Hello, world"; } std::string get_Message() { return m_message; } }; class Foo { private: shared_ptr m_bar; public: Foo() : m_bar( new Bar() ) {} shared_ptr get_Bar() const { return m_bar; } }; BOOST_PYTHON_MODULE(PyTest) { class_< Bar > ( "Bar" ).add_property ("message", &Bar::get_Message); class_< Foo > ( "Foo" ).add_property ("bar" , &Foo::get_Bar ); } This code compiles and links fine, but when I try to access Foo::get_Bar from python I get the python error message " TypeError: bad argument type for built-in operation". This is the python script I used: foo = Foo() print foo.bar.message I naively expected Boost.Python to just "do the right thing" w.r.t. a member function returning a boost::shared_ptr. What am I doing wrong? Warmest regards, Matt -- Matthew D. Langston SLD, Stanford Linear Accelerator Center langston at SLAC.Stanford.EDU _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Tue Dec 10 04:52:30 2002 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 09 Dec 2002 22:52:30 -0500 Subject: [C++-sig] how to wrap getter returning shared_ptr In-Reply-To: ("Langston, Matthew David"'s message of "Mon, 09 Dec 2002 19:08:02 -0800") References: Message-ID: "Langston, Matthew David" writes: > I answered my own question through trial-and-error experimentation. If > I want to have Boost.Python return a "shared_ptr < Bar >", then I must > export Bar to python using the second template argument to class_ as > follows: > > class_< Bar, shared_ptr < Bar > > ( "Bar" ).add_property ("message", > &Bar::get_Message); > > Matt > I naively expected Boost.Python to just "do the right thing" w.r.t. a > member function returning a boost::shared_ptr. What am I doing wrong? > > Warmest regards, Matt Matt, Please see http://aspn.activestate.com/ASPN/Mail/Message/1456023 (especially the non-quoted section at the bottom). I've been waiting for more feedback about the issues discussed there. So far I'm leaning fairly strongly away from the "just do the right thing" approach and toward the register_shared_ptr() approach on the "don't pay for what you don't use" theory. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Tue Dec 10 04:54:04 2002 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 09 Dec 2002 22:54:04 -0500 Subject: [C++-sig] __getitem__ and __setitem__ for a Matrix class In-Reply-To: <3DF53975.9000700@ihug.co.nz> (sashan's message of "Tue, 10 Dec 2002 13:46:45 +1300") References: <3DF53975.9000700@ihug.co.nz> Message-ID: sashan writes: > Hi > > I want to expose a matrix class's operator[]. To expose it as an > rvalue I did the following > > boost::python::list GetList(Matrix3& self, int i) > { > if (!(i < 3 && i > -1)) > { > PyErr_SetObject(PyExc_IndexError, PyInt_FromLong(i)); > boost::python::throw_error_already_set(); > } > boost::python::list list; > list.append(self[i][0]); > list.append(self[i][1]); > list.append(self[i][2]); > return list; > } > . > . > . > classMatrix3.def("__getitem__", &GetList); > > However I don't know/can't figure out how to expose it as an lvalue? You can't; there are no lvalues in Python. That's why there's a separate __setitem__ method. > P: Egad! You astound me, Brain! > B: That's a simple task, Pinky. Noit! -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Tue Dec 10 05:03:31 2002 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 09 Dec 2002 23:03:31 -0500 Subject: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> ("Paul F. Kunz"'s message of "Mon, 09 Dec 2002 17:21:54 -0800") References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> Message-ID: "Paul F. Kunz" writes: > Its me again. This time, I've got my Python extension modules > working completely with Boost.Python wrapped alone. That is... > > [pfkeb at Kunz-pbdsl1 testsuite]$ python > Python 2.2.2 (#1, Oct 15 2002, 07:42:56) > [GCC 2.95.3 20010315 (release)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> from hippo import * >>>> app = HDApp(1) >>>> cw = CanvasWindow() >>>> cw.show() >>>> app.exec_loop() > > works fine. In the above, `HDApp' is not derived from > QApplication, but delegates to a class which does. CanvasWindow > wraps a C++ class which derives from QMainWindow. > > Now I modify the dclock.py example that comes with PyQt to... Hmm, does dclock.py by any chance use threads? > a = QApplication(sys.argv) > clock = DigitalClock() > clock.resize(170,80) > a.setMainWidget(clock) > clock.show() > > cw = CanvasWindow() # added > cw.show() # added > > a.exec_loop() > > and get ... > > Starting program: /usr/local/bin/python /home/pfkeb/hippodraw-BUILD/testsuite/dclock.py > [New Thread 1024 (LWP 5948)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 5948)] > PyErr_SetObject (exception=0x8108a8c, value=0x81ab208) at Python/errors.c:39 > (gdb) bt > (gdb) > > On the line of the error > > oldtype = tstate->curexc_type; > > (gdb) p tstate > $1 = (PyThreadState *) 0x0 > (gdb) Well, the thread state is NULL. I don't know what this means, but I think it's premature to conclude that SIP and Boost.Python are incompatible with one another. As far as I can tell, they should not interact in any particular way, any more than Boost.Python should interact with, say, the CPickle extension module which comes with Python's standard library. I know relatively little about Python threading, except that only one thread may be executing core Python code at any given time. That means that if your C++ code is being called from multiple threads it must acquire something called the global interpreter lock (GIL) before it touches any Python objects. If you have any virtual function dispatching back to Python going on in your C++ objects (i.e. using call_method), you could easily be running into this issue. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From phil at river-bank.demon.co.uk Tue Dec 10 10:53:53 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Tue, 10 Dec 2002 09:53:53 +0000 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> Message-ID: <200212100953.53131.phil@river-bank.demon.co.uk> On Tuesday 10 December 2002 1:21 am, Paul F. Kunz wrote: > Its me again. This time, I've got my Python extension modules > working completely with Boost.Python wrapped alone. That is... > > [pfkeb at Kunz-pbdsl1 testsuite]$ python > Python 2.2.2 (#1, Oct 15 2002, 07:42:56) > [GCC 2.95.3 20010315 (release)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > > >>> from hippo import * > >>> app = HDApp(1) > >>> cw = CanvasWindow() > >>> cw.show() > >>> app.exec_loop() > > works fine. In the above, `HDApp' is not derived from > QApplication, but delegates to a class which does. CanvasWindow > wraps a C++ class which derives from QMainWindow. > > Now I modify the dclock.py example that comes with PyQt to... > > a = QApplication(sys.argv) > clock = DigitalClock() > clock.resize(170,80) > a.setMainWidget(clock) > clock.show() > > cw = CanvasWindow() # added > cw.show() # added > > a.exec_loop() > > and get ... > > Starting program: /usr/local/bin/python > /home/pfkeb/hippodraw-BUILD/testsuite/dclock.py [New Thread 1024 (LWP > 5948)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 5948)] > PyErr_SetObject (exception=0x8108a8c, value=0x81ab208) at > Python/errors.c:39 (gdb) bt > #0 PyErr_SetObject (exception=0x8108a8c, value=0x81ab208) > at Python/errors.c:39 > #1 0x08087ac7 in PyErr_Format (exception=0x8108a8c, > format=0x80df620 "%.50s instance has no attribute '%.400s'") > at Python/errors.c:408 > #2 0x080b0467 in instance_getattr1 (inst=0x82c5654, name=0x8154558) > at Objects/classobject.c:678 > #3 0x080b3e35 in instance_getattr (inst=0x82c5654, name=0x8154558) > at Objects/classobject.c:715 > #4 0x40cd2a43 in instanceGetAttr () > from /usr/local/lib/python2.2/site-packages/libsip.so > #5 0x08056794 in PyObject_GetAttr (v=0x82c5654, name=0x8154558) > at Objects/object.c:1108 > #6 0x0807705e in eval_frame (f=0x811a974) at Python/ceval.c:1784 > #7 0x0807866e in PyEval_EvalCodeEx (co=0x8161de0, globals=0x81139b4, > locals=0x81139b4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, > defcount=0, closure=0x0) at Python/ceval.c:2595 > #8 0x0807a700 in PyEval_EvalCode (co=0x8161de0, globals=0x81139b4, > locals=0x81139b4) at Python/ceval.c:481 > #9 0x080950b1 in run_node (n=0x81263b8, > filename=0xbffffca2 "/home/pfkeb/hippodraw-BUILD/testsuite/dclock.py", > globals=0x81139b4, locals=0x81139b4, flags=0xbffffac4) > at Python/pythonrun.c:1079 > #10 0x08095062 in run_err_node (n=0x81263b8, > filename=0xbffffca2 "/home/pfkeb/hippodraw-BUILD/testsuite/dclock.py", > globals=0x81139b4, locals=0x81139b4, flags=0xbffffac4) > at Python/pythonrun.c:1066 > #11 0x08094ccb in PyRun_FileExFlags (fp=0x8104038, > filename=0xbffffca2 "/home/pfkeb/hippodraw-BUILD/testsuite/dclock.py", > start=257, globals=0x81139b4, locals=0x81139b4, closeit=1, > flags=0xbffffac4) at Python/pythonrun.c:1057 > #12 0x080938b1 in PyRun_SimpleFileExFlags (fp=0x8104038, > filename=0xbffffca2 "/home/pfkeb/hippodraw-BUILD/testsuite/dclock.py", > closeit=1, flags=0xbffffac4) at Python/pythonrun.c:685 > #13 0x0809481f in PyRun_AnyFileExFlags (fp=0x8104038, > filename=0xbffffca2 "/home/pfkeb/hippodraw-BUILD/testsuite/dclock.py", > closeit=1, flags=0xbffffac4) at Python/pythonrun.c:495 > #14 0x08053632 in Py_Main (argc=2, argv=0xbffffb54) at Modules/main.c:364 > #15 0x08052ee6 in main (argc=2, argv=0xbffffb54) at Modules/python.c:10 > #16 0x40088627 in __libc_start_main (main=0x8052ed0

, argc=2, > ubp_av=0xbffffb54, init=0x80522d4 <_init>, fini=0x80cf610 <_fini>, > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffb4c) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > On the line of the error > > oldtype = tstate->curexc_type; > > (gdb) p tstate > $1 = (PyThreadState *) 0x0 > (gdb) > > It really appears to me that Boost.Python extensions and SIP Python > extensions are incompatible with each other. Or there is still > something that I'm doing wrong. The only area of possible conflict I can think of is threads, the following is from the PyQt docs... "PyQt implements the full set of Qt's thread classes. Python, of course, also has its own thread extension modules. It is possible to use either of the APIs so long as you follow some simple rules. If you use the Qt API then the very first import of one of the PyQt modules must be done from the main thread. If you use the Python API then all calls to PyQt (including any imports must be done from one thread only. Therefore, if you want to make calls to PyQt from several threads then you must use the Qt API. If you want to use both APIs in the same application then all calls to PyQt must be done from threads created using the Qt API." Another possible conflict, perhaps more likely, is the two modules fighting over the Qt API. Phil From dave at boost-consulting.com Tue Dec 10 11:17:04 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 05:17:04 -0500 Subject: [C++-sig] Re: C++/Boost vs. Python object memory footprint In-Reply-To: <1039509266.15013.10.camel@localhost> (Stephen Davies's message of "10 Dec 2002 19:34:26 +1100") References: <1039509266.15013.10.camel@localhost> Message-ID: Stephen Davies writes: > Hi Dave, > > I was wondering what the memory usage of Synopsis would be if I > converted the in-memory AST to be C++ objects with Boost.Python > wrappers. > > I had 350MB of AST in memory yesterday and my system didn't cope too > well. I figure each object has at least one dictionary which can't be > cheap memory wise. The question is, will I still have proxy objects > floating around if I use Boost.Python, or will the python code directly > use the C++ objects without creating the instance dictionary et.al.? All the code for implementing C++ object wrappers is in libs/python/src/object/class.cpp. Instance dictionaries are created only "on demand", the first time the instance's __dict__ attribute is accessed (see instance_get_dict), but I have no idea whether that tends to happen almost always or almost never. In general, a wrapped C++ object with a corresponding Python object is the size of a new-style class (derived from 'object' in Python) instance plus the extra size required to allow variable-length data in the instance, plus the size of the C++ object, plus the size of a vtable pointer, plus a pointer to the C++ object's instanceholder, plus zero or more bytes of padding required to ensure that the instanceholder is properly aligned. You can see this in boost/python/object/instance.hpp. Most Python objects are represented by instance >, for some C++ class T. I'm not sure what you mean by your question "will I still have proxy objects floating around...?" If your C++ data structure contains pointers or smart pointers, you can arrange for Python objects to be created which only embed those pointers (instance >). These Python objects will be in existence only as long as your Python code holds a reference to them. So, for example, it should be possible for Python code to do a walk over your C++ AST, with only O(log(N)) Python objects in existence corresponding to those N C++ objects at any given time. > A related question is what the speed is like calling the C++ objects vs. > normal Python objects. I can't imagine it would be slower. I haven't done any tests, but it certainly could be slower if used poorly. There is some overhead at the Python/C++ boundary associated with looking for eligible type converters, overloading, etc. However, I imagine that ends up being negligible in most cases. The best use of a Boost.Python C++ binding puts a large amount of computation on the C++ side of the language boundary. One way I could imagine slowing down a Python program would be to translate a very large number of trivial functions to C++. C++ function wrappers will certainly occupy more memory than the corresponding Python code would, and this could eventually affect cache locality. > The pickling/unpickling speed is also of some concern > currently. Would this be affected? Probably, one way or the other ;-) I think that if you treat your tree as one monolithic Python object from the standpoint of pickling, you could probably achieve much better speed than you currently have by writing some C++ serialization/deserialization code and pickling it as one long string. Whether or not that's practical for you, of course, I can't say. > Perhaps you can add these to the Boost.Python FAQ :) If you'll help me edit them into a suitable form, I'd be most happy to! -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Tue Dec 10 11:47:57 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 05:47:57 -0500 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212100953.53131.phil@river-bank.demon.co.uk> (Phil Thompson's message of "Tue, 10 Dec 2002 09:53:53 +0000") References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> Message-ID: Phil Thompson writes: > Another possible conflict, perhaps more likely, is the two modules > fighting over the Qt API. Could you be a little more specific about what this might mean? Thanks, Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From phil at river-bank.demon.co.uk Tue Dec 10 14:28:58 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Tue, 10 Dec 2002 13:28:58 +0000 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> Message-ID: <200212101328.58246.phil@river-bank.demon.co.uk> On Tuesday 10 December 2002 10:47 am, David Abrahams wrote: > Phil Thompson writes: > > Another possible conflict, perhaps more likely, is the two modules > > fighting over the Qt API. > > Could you be a little more specific about what this might mean? Not really - just an uncomfortable feeling about events being dispatched from an object wrapped by one module to an object wrapped by another module that calls a virtual re-implemented in the first module etc, etc. BTW, dclock.py doesn't use threads explicitly, but any SIP generated code will cooperate with the Python thread infrastructure and the GIL. Phil From greglandrum at mindspring.com Tue Dec 10 14:47:56 2002 From: greglandrum at mindspring.com (greg Landrum) Date: Tue, 10 Dec 2002 05:47:56 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> Message-ID: <5.1.0.14.2.20021210054614.03cdbe50@mail.mindspring.com> At 05:21 PM 12/9/2002, Paul F. Kunz wrote: > It really appears to me that Boost.Python extensions and SIP Python >extensions are incompatible with each other. Or there is still >something that I'm doing wrong. > > Any suggestions on how to proceed? I'm afraid I don't have any helpful suggestions, but I can provide the data point that I use Boost.Python modules from within PyQt apps all the time without any problems. -greg From Paul_Kunz at SLAC.Stanford.EDU Tue Dec 10 16:25:07 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Tue, 10 Dec 2002 07:25:07 -0800 Subject: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> Message-ID: <200212101525.gBAFP7A24034@libra3.slac.stanford.edu> >>>>> On Mon, 09 Dec 2002 23:03:31 -0500, David Abrahams said: > Hmm, does dclock.py by any chance use threads? No, but it does use timer. Maybe that's it. > If you have any virtual > function dispatching back to Python going on in your C++ objects > (i.e. using call_method), you could easily be running into this > issue. No call backs to Python from my code. I better try another example without a timer. From Paul_Kunz at SLAC.Stanford.EDU Tue Dec 10 16:29:35 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Tue, 10 Dec 2002 07:29:35 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <5.1.0.14.2.20021210054614.03cdbe50@mail.mindspring.com> References: <5.1.0.14.2.20021210054614.03cdbe50@mail.mindspring.com> Message-ID: <200212101529.gBAFTZv24038@libra3.slac.stanford.edu> >>>>> On Tue, 10 Dec 2002 05:47:56 -0800, greg Landrum said: > At 05:21 PM 12/9/2002, Paul F. Kunz wrote: >> It really appears to me that Boost.Python extensions and SIP Python >> extensions are incompatible with each other. Or there is still >> something that I'm doing wrong. >> >> Any suggestions on how to proceed? > I'm afraid I don't have any helpful suggestions, but I can provide > the data point that I use Boost.Python modules from within PyQt apps > all the time without any problems. Do any of your Boost.Python modules use Qt directly? From Paul_Kunz at SLAC.Stanford.EDU Tue Dec 10 16:38:43 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Tue, 10 Dec 2002 07:38:43 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212101328.58246.phil@river-bank.demon.co.uk> References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> <200212101328.58246.phil@river-bank.demon.co.uk> Message-ID: <200212101538.gBAFcho24045@libra3.slac.stanford.edu> >>>>> On Tue, 10 Dec 2002 13:28:58 +0000, Phil Thompson said: > On Tuesday 10 December 2002 10:47 am, David Abrahams wrote: >> Phil Thompson writes: > Another >> possible conflict, perhaps more likely, is the two modules > >> fighting over the Qt API. >> >> Could you be a little more specific about what this might mean? > Not really - just an uncomfortable feeling about events being > dispatched from an object wrapped by one module to an object wrapped > by another module that calls a virtual re-implemented in the first > module etc, etc. In Boost.Python terms, my CanvasWindow module is class_ < CanvasWindow > ( "CanvasWindow" ) .def ( "show", &CanvasWindow::show ) .def ( "fileNew", &CanvasWindow::fileNew ) ; In SIP terms that's class CanvasWindow { public: CanvasWindow (); void show(); void fileNew ( const std::string & ); }; In C++, CanvasWindow inherits from CanvasWindowBase created by Qt Designer which inherits from QMainWindow. All the above member functions are virtual. From camelo at esss.com.br Tue Dec 10 18:20:32 2002 From: camelo at esss.com.br (Marcelo A. Camelo) Date: Tue, 10 Dec 2002 14:20:32 -0300 Subject: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: Message-ID: <000001c2a070$71950c90$0d00000a@esss.com.br> >>> Another possible conflict, perhaps more likely, is the two >>> modules fighting over the Qt API. >> Could you be a little more specific about what this might mean? > Not really - just an uncomfortable feeling about events being > dispatched from an object wrapped by one module to an object > wrapped by another module that calls a virtual re-implemented > in the first module etc, etc. I'm having a very similar problem. I'm using boost::python to wrap C++/Win32/DirectX code and I'm also using PyQt to create user interfaces. In three similar situations I've got the infamous error "Fatal Error: Thread state is Null" (or something like that). I haven't nailed down the bug yet, but I've found that it is related to calling back my C++/Win32/DirectX library (wrapped in boost) from an event triggered from Qt main event loop. Not every callback will fail. Some Win32 api calls will make it fail (SetWindowPos will make it fail, MoveWindow won't). Some DirectX calls also fail (if I comment those calls, everything goes fine). The error is generated after the wrapped method call has been completed, but before control is passed back to python. I've also had some problems related to Win32 message queue. The WindowProc message for my own Window Classes is being called from the Qt main event loop. If I dispatch those messages and generate events to python code that calls back to my C++ library, bang!!! In this case, I don't know if the crash only occurs when making win32 API calls. Hope this information is of some value. Cheers, Marcelo A. Camelo, M. Eng. - Project Leader ESSS - Engineering Simulation and Scientific Software E-mail: camelo at esss.com.br Phone: +55-48-239-2226 From dirk at gerrits.homeip.net Tue Dec 10 18:47:47 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Tue, 10 Dec 2002 18:47:47 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python In-Reply-To: References:

Message-ID: David Abrahams wrote: > Dirk Gerrits writes: > > >>David Abrahams wrote: > > >>>I also confess to not having any idea what piece of code you're >>>talking about ;-) >> >>The two code examples in the manual reference counting section. ;) > > > Ah. It's really good to have that section somewhere in the tutorial or > maybe in the rationale documentation, to show why you want a C++ > wrapper over the 'C' API. Then I shall compress it so that it can become a sidebar or a part of the rationale. With the upcoming embedding features of Boost.Python I would really prefer not to document both the 'C'-way and the BPL-way of doing everything. ;) >>>See also http://www.mcmillan-inc.com/embed.html, FWIW. >> >>Thanks for the link. Taught me two things: >>1) Any sane person will prefer Boost.Python over the Python C API ;) >>2) It is possible to create multiple interpreters, even in different >>threads. This could lead to a very cool python::interpreter class >>indeed. :) > > > That's a neat idea. I await your specific interface suggestions. Well nothing concrete so far but I think you'll agree that the constructor and destructor are the most vital parts of the class. They do practically all the work of setting up/release (sub-)interpreters. Furthermore, there should be a way to set/query the currently active interpreter. Member functions like this: bool is_current() const; void make_current(); were the first things that came to mind. I also thought about a free function along the lines of: interpreter* current_interpreter(); But that would only make sense if the public class interface is expanded. After all, is_current() on the current_interpreter() is always true and make_current() is always a no-op, right? (Also, it would probably not work too well with threading maybe?) A pseudo-implementation of the constructor and destructor could look like: interpreter() { // Create the main interpreter if (interpreter_count == 0) { Py_Initialize(); ... } // Create a sub-interpreter else { ... } interpreter_count++; } ~interpreter() { // Release the main interpreter if (interpreter_count == 1) { Py_Finalize(); ... } // Release a sub-interpreter else { ... } interpreter_count--; } ... treating the main interpreter and sub-interpreters equally as python::interpreter instances. I'm not sure if this is the best solution though, because there are some (very) subtle differences between the main interpreter and sub-interpreters. (http://www.python.org/doc/current/api/initialization.html#l2h-657) Not making the distinction seems more natural though. ("Beautiful is better than ugly." "Simple is better than complex." ;)) >>>>However, adding Boost.Python facilities for the PyRun_ functions >>>>probably means adding a load of other Python C API facilites as >>>>well. >> >>>Yup. It was always the intention to add these. Dave Hawkes made a >>>valiant effort: >>>http://mail.python.org/pipermail/c++-sig/2002-June/001503.html, but it >>>was in some ways just too much to take into the library at once. >> >>I see. Pity. Let's see how the incremental approach will fare. > > > > OK! > > For reference you might want to look at Dave's work. I've attached > a CVS log | cvslogfilter -b of his checkins at the bottom of the > message. Thanks. Downloaded the files to my harddrive for future reference. :) >>>>I would like to have something like this in Boost.Python: >>>> >>>>object run_python_code(InputIterator begin, InputIterator end); >>> >>>These must have char as their value_type? >> >>I suppose so. At least I don't see any unicode/wchar_t in the Python C >>API. ;) I was under the impression that Python supported unicode >>source files though. How does that work then? > > > Search me! Searched for unicode (7 hits), wchar_t (no hits) and utf-8 (1 hit) on the C++ Sig archive on ASPN but couldn't find it, sorry. >>Also, while this interface is nicely STL-ish, it is probably not very >>efficient. I don't see how this can be implemented without some >>std::copy to std::vector or std::string. Thoughts? > > > I don't know. Based on your remarks I'm guessing that the interface is > a case of premature generalization. Suppose we just do this: > > object run_python_code(object x); > > template > object run_python_code(T const& x) > { > return run_python_code(object(x)); > } > > ?? > > Now anything that can be converted to a Python string will work. Just > a thought. FWIW, I like it. :) I think though that running code from a file would be at least as important as running it from a string. So the implementation of run_python_code (name might need work?) should IMHO check to see if x is (convertable to) a Python file. If so, then it should use PyRun_File with a FILE*, otherwise it should use PyRun_String with a char const*. >>>>Also, it might be a good idea to wrap Py_Initialize and Py_Finalize in >>>>a RAII class? >> >>>Absolutely. Just as soon as Py_Finalize becomes safe for us ;-) >>>That might be a good project for you... >> >>I've been meaning to look into BPL's internals in more detail >>anyway. :) I'm not sure if university will leave me with enough spare >>time though. I think I should concentrate on the tutorial first. > > > OK. BTW, this is not a hard problem to solve and it doesn't require a > deep understanding of the internals. The first step is to identify all > the places where static/global object or handle<> instances are > created in the library or user code. There is also some global data in > the registry. Then we'll need to set up some code for releasing the > resources with Python's atexit() module. Doesn't sound too hard. I'll get on it when I see the time (probably in the weekend). Perhaps somebody reading this thread will beat me to it though. ;) Dirk Gerrits From Paul_Kunz at SLAC.Stanford.EDU Tue Dec 10 19:07:55 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Tue, 10 Dec 2002 10:07:55 -0800 Subject: [C++-sig] Re: [PyKDE] Are Python extenstions built with SIP and Boost.Python in compatible? In-Reply-To: "Paul_Kunz@SLAC.Stanford.EDU"'s message of Sat, 07 Dec 2002 12:55:51 -0800 Message-ID: <200212101807.gBAI7tx24610@libra3.slac.stanford.edu> I mae the test even simplier and still crash... [pfkeb at Kunz-pbdsl1 python]$ python Python 2.2.2 (#1, Oct 15 2002, 07:42:56) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, string >>> from qt import * >>> app = QApplication ( sys.argv) >>> from hippo import * >>> cw = CanvasWindow() Fatal Python error: PyThreadState_Get: no current thread Abort (core dumped) [pfkeb at Kunz-pbdsl1 python]$ At least I got error message now. To try it the other way around [pfkeb at Kunz-pbdsl1 python]$ python Python 2.2.2 (#1, Oct 15 2002, 07:42:56) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from hippo import * >>> app = HDApp(1) >>> from qt import * >>> cw = QMainWindow() >>> cw.show() >>> app.exec_loop() Fatal Python error: PyThreadState_Get: no current thread Abort (core dumped) [pfkeb at Kunz-pbdsl1 python]$ In the above, QApplication is created by HDApp(1) and we attempt to create a window with PyQt. From dave at boost-consulting.com Tue Dec 10 19:19:40 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 13:19:40 -0500 Subject: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <000001c2a070$71950c90$0d00000a@esss.com.br> ("Marcelo A. Camelo"'s message of "Tue, 10 Dec 2002 14:20:32 -0300") References: <000001c2a070$71950c90$0d00000a@esss.com.br> Message-ID: "Marcelo A. Camelo" writes: >>>> Another possible conflict, perhaps more likely, is the two >>>> modules fighting over the Qt API. > >>> Could you be a little more specific about what this might mean? > >> Not really - just an uncomfortable feeling about events being >> dispatched from an object wrapped by one module to an object >> wrapped by another module that calls a virtual re-implemented >> in the first module etc, etc. > > I'm having a very similar problem. > > I'm using boost::python to wrap C++/Win32/DirectX code and I'm > also using PyQt to create user interfaces. > > In three similar situations I've got the infamous error > "Fatal Error: Thread state is Null" (or something like that). > > I haven't nailed down the bug yet, but I've found that it is > related to calling back my C++/Win32/DirectX library (wrapped in > boost) from an event triggered from Qt main event loop. > > Not every callback will fail. Some Win32 api calls will make it > fail (SetWindowPos will make it fail, MoveWindow won't). Some > DirectX calls also fail (if I comment those calls, everything > goes fine). > > The error is generated after the wrapped method call has been > completed, but before control is passed back to python. > > I've also had some problems related to Win32 message queue. The > WindowProc message for my own Window Classes is being called > from the Qt main event loop. If I dispatch those messages and > generate events to python code that calls back to my C++ > library, bang!!! In this case, I don't know if the crash only > occurs when making win32 API calls. > > Hope this information is of some value. Is it possible to post code for a small Windows application or extension, not dependent on Qt, which demonstrates this? One of the odd things about Windows event loops (and COM, AFAIK) is that various calls to the OS can cause your event loop to be invoked, and which calls these are is not documented. It's possible that some of the code in Boost.Python or Qt is not "reentrant" in this sense. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From greglandrum at mindspring.com Tue Dec 10 20:03:15 2002 From: greglandrum at mindspring.com (greg Landrum) Date: Tue, 10 Dec 2002 11:03:15 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212101529.gBAFTZv24038@libra3.slac.stanford.edu> References: <5.1.0.14.2.20021210054614.03cdbe50@mail.mindspring.com> <5.1.0.14.2.20021210054614.03cdbe50@mail.mindspring.com> Message-ID: <5.1.0.14.2.20021210110212.03b12b30@mail.mindspring.com> At 07:29 AM 12/10/2002, Paul F. Kunz wrote: > Do any of your Boost.Python modules use Qt directly? Ah, no. I didn't realize that you were doing this... guess I should have read the rest of the thread more carefully. -greg From mike at bindkey.com Tue Dec 10 22:27:55 2002 From: mike at bindkey.com (Mike Rovner) Date: Tue, 10 Dec 2002 13:27:55 -0800 Subject: [C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python References:

Message-ID: "Dirk Gerrits" wrote in message news:at59bp$skj$1 at main.gmane.org... > Furthermore, there should be a way to set/query the currently active > interpreter. Member functions like this: > > bool is_current() const; > void make_current(); > > were the first things that came to mind. How about being consistent with scope() interface? Creating new interpreter changes current, but one can create objects to keep and use another. Just my 2c. From vanandel at atd.ucar.edu Tue Dec 10 23:28:30 2002 From: vanandel at atd.ucar.edu (Joe Van Andel) Date: Tue, 10 Dec 2002 15:28:30 -0700 Subject: [C++-sig] CVS version of Boost-Python - test/Jamfile patch Message-ID: <3DF66A8E.9040607@atd.ucar.edu> Today, I tried to build all of Boost from CVS. Apparently the test_exec_monitor support library has been renamed to boost_test_exec_monitor. To compile the tests found in lib/python/test, I had to modify lib/python/test/Jamfile. I've attached a context diff. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel at ucar dot edu "There are only 10 kinds of people in the world -- Those who understand binary, and those who don't." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jam.diff URL: From dave at boost-consulting.com Tue Dec 10 23:37:11 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 17:37:11 -0500 Subject: [C++-sig] Re: CVS version of Boost-Python - test/Jamfile patch In-Reply-To: <3DF66A8E.9040607@atd.ucar.edu> (Joe Van Andel's message of "Tue, 10 Dec 2002 15:28:30 -0700") References: <3DF66A8E.9040607@atd.ucar.edu> Message-ID: Joe Van Andel writes: > Today, I tried to build all of Boost from CVS. > > Apparently the test_exec_monitor support library has been renamed to > boost_test_exec_monitor. To compile the tests found in > lib/python/test, I had to modify lib/python/test/Jamfile. Thanks, we know about this problem. I think we're still a bit undecided about who's supposed to fix it ;-/ -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Tue Dec 10 23:59:29 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 17:59:29 -0500 Subject: [C++-sig] Why Python for C++ programmers In-Reply-To: <20021206052908.26603.qmail@web20202.mail.yahoo.com> ("Ralf W. Grosse-Kunstleve"'s message of "Thu, 5 Dec 2002 21:29:08 -0800 (PST)") References: <20021206052908.26603.qmail@web20202.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: > > I also find that debugging/testing my C++ algorithms is a lot faster if I > expose the new classes to Python from where they can easily be exercised with > different inputs. Almost all regression tests for my C++ algorithms are written > in Python. Why is it easier to excercise your C++ from Python than from C++? Surely the Python binding layer hides some of the variations on possible C++ inputs (e.g. const vs. non-const), making it impossible to fully-exercise some C++ interfaces? Even discounting this issue, it's not obvious to me why it would be easier to write a Python binding layer just to test your C++ code. Thanks for your patience, Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From langston at SLAC.Stanford.EDU Wed Dec 11 00:09:32 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Tue, 10 Dec 2002 15:09:32 -0800 Subject: [C++-sig] how to wrap getter returning shared_ptr Message-ID: Hi Dave, The register_shared_ptr() idea sounds intriguing. If I understood your post in message 1456023, then in my "Foo Bar" example I would change this: class_< Bar, shared_ptr < Bar > > ( "Bar" ).add_property ("message", &Bar::get_Message ); to this class_< Bar > ( "Bar" ).add_property ( "message", &Bar::get_Message ); register_shared_ptr < Bar > (); Is that right? I was surprised that Boost.Python originally allowed me to wrap a "member function returning shared_ptr" (e.g. my Foo example compiled and linked fine), but I received a run-time error message when I tried to call that member function from python. Would forgetting to specify register_shared_ptr < Bar > (); have given me a compile or link time error (where forgetting to specify the second template argument in "class_< Bar, shared_ptr < Bar > >" did not)? -Matt -----Original Message----- From: David Abrahams [mailto:dave at boost-consulting.com] Sent: Monday, December 09, 2002 7:53 PM To: c++-sig at python.org Subject: Re: [C++-sig] how to wrap getter returning shared_ptr "Langston, Matthew David" writes: > I answered my own question through trial-and-error experimentation. If > I want to have Boost.Python return a "shared_ptr < Bar >", then I must > export Bar to python using the second template argument to class_ as > follows: > > class_< Bar, shared_ptr < Bar > > ( "Bar" ).add_property ("message", > &Bar::get_Message); > > Matt > I naively expected Boost.Python to just "do the right thing" w.r.t. a > member function returning a boost::shared_ptr. What am I doing wrong? > > Warmest regards, Matt Matt, Please see http://aspn.activestate.com/ASPN/Mail/Message/1456023 (especially the non-quoted section at the bottom). I've been waiting for more feedback about the issues discussed there. So far I'm leaning fairly strongly away from the "just do the right thing" approach and toward the register_shared_ptr() approach on the "don't pay for what you don't use" theory. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From langston at SLAC.Stanford.EDU Wed Dec 11 00:18:56 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Tue, 10 Dec 2002 15:18:56 -0800 Subject: [C++-sig] multiply defined to_python_converter Message-ID: I just ran into a problem where my Boost.Python module is conflicting with a third-party library's Boost.Python module. I get a run-time error when I import both modules into python because they both provide a to_python_converter that converts a std::vector to a python tuple of strings. The methods are named differently at the source-level (i.e. both modules gave their to_python_converter a unique name), so it appears to be a "run-time type matching" problem. How do I work around this problem of "multiply defined to_python_converter"? -Matt -- Matthew D. Langston SLD, Stanford Linear Accelerator Center langston at SLAC.Stanford.EDU From rwgk at yahoo.com Wed Dec 11 01:27:49 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 10 Dec 2002 16:27:49 -0800 (PST) Subject: [C++-sig] Why Python for C++ programmers In-Reply-To: Message-ID: <20021211002749.35401.qmail@web20206.mail.yahoo.com> --- David Abrahams wrote: > "Ralf W. Grosse-Kunstleve" writes: > > > --- David Abrahams wrote: > > > > I also find that debugging/testing my C++ algorithms is a lot faster if I ^^^^^^^^^^ > > expose the new classes to Python from where they can easily be exercised > with > > different inputs. Almost all regression tests for my C++ algorithms are > written > > in Python. > > Surely the Python binding layer hides some of the variations on > possible C++ inputs (e.g. const vs. non-const), making it impossible > to fully-exercise some C++ interfaces? ^^^^^^^^^^ I find it easier to debug my /algorithms/ from Python. This is very different from exercising interfaces. - Most of my algorithms require very complex inputs. It would take a lot of time to write C++ code for generating these inputs. - If things go wrong it is easy to insert print statements in Python to narrow down the problem. This is much more time-consuming in C++ because of the compilation/linking overhead. - From Python I can easily try different inputs without inventing file formats or recompiling. Being able to quickly change inputs or to systematically try a range of inputs often is the key to finding out which of the many parts of a complex algorithm is not functioning properly. > Even discounting this issue, it's not obvious to me why it would be > easier to write a Python binding layer just to test your C++ code. Agreed. But of course I want the Python bindings anyway because this is the most efficient way of putting together a large system. -- I realize my arguments are a bit circular. Maybe it just comes down to: since I have a hybrid system anyway I am free to choose how I implement the regression tests. In practice I find it almost always more efficient to use Python for this purpose. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From rwgk at yahoo.com Wed Dec 11 01:46:27 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 10 Dec 2002 16:46:27 -0800 (PST) Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: Message-ID: <20021211004627.74298.qmail@web20204.mail.yahoo.com> --- "Langston, Matthew David" wrote: > How do I work around this problem of "multiply defined to_python_converter"? If your converter is doing exactly the same work as the other one simply don't register it. If they are doing different things you have a problem because Boost.Python's type conversion registry is global. This is an essential feature. Otherwise bindings established by module A could not be used in module B and vice versa (this is actually how early versions of Boost.Python used to work). Hm, I guess the situation is similar to, say, assigning IP addresses. There has to be some kind of protocol that everybody has to adhere to in order to avoid conflicts. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From dave at boost-consulting.com Wed Dec 11 02:38:06 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 20:38:06 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: ("Langston, Matthew David"'s message of "Tue, 10 Dec 2002 15:18:56 -0800") References: Message-ID: "Langston, Matthew David" writes: > I just ran into a problem where my Boost.Python module is conflicting > with a third-party library's Boost.Python module. I get a run-time > error when I import both modules into python because they both provide > a to_python_converter that converts a std::vector to a > python tuple of strings. > > The methods are named differently at the source-level (i.e. both > modules gave their to_python_converter a unique name), so it appears > to be a "run-time type matching" problem. > > How do I work around this problem of "multiply defined > to_python_converter"? Hmm. I'm not sure what the best answer is. Does Python have a warning mechanism? Maybe it would be best to maks such multiple definitions trigger a Python warning instead of a hard error. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Wed Dec 11 02:42:20 2002 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 10 Dec 2002 20:42:20 -0500 Subject: [C++-sig] how to wrap getter returning shared_ptr In-Reply-To: ("Langston, Matthew David"'s message of "Tue, 10 Dec 2002 15:09:32 -0800") References: Message-ID: "Langston, Matthew David" writes: > Hi Dave, > > The register_shared_ptr() idea sounds intriguing. If I understood > your post in message 1456023, then in my "Foo Bar" example I would > change this: > > > class_< Bar, shared_ptr < Bar > > ( "Bar" ).add_property ("message", > &Bar::get_Message ); > > > to this > > > class_< Bar > ( "Bar" ).add_property ( "message", &Bar::get_Message ); > register_shared_ptr < Bar > (); > > > Is that right? Yes. > I was surprised that Boost.Python originally allowed me to wrap a > "member function returning shared_ptr" (e.g. my Foo example compiled > and linked fine), but I received a run-time error message when I tried > to call that member function from python. This is a difference between Boost.Python v1 and Boost.Python v2. In v1, there was some compile-time checking of conversion validity (unfortunately, it relied on non-standard C++). In v2, all conversions are only checked at runtime. > Would forgetting to specify > > register_shared_ptr < Bar > (); > > have given me a compile or link time error (where forgetting to > specify the second template argument in "class_< Bar, shared_ptr < Bar >> >" did not)? No, and there's pretty much no reasonable way to cause such an error to occur, AFAICT. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From mrussell8081 at pacbell.net Wed Dec 11 02:46:30 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Tue, 10 Dec 2002 17:46:30 -0800 Subject: [C++-sig] Can't convert to unsigned int Message-ID: I am wrapping a library that makes extensive use of flags (in varying guises) that are unsigned longs. I have put together a simplified example below--when I try to use this module I get an overflow error. Is there a way to make this type of conversion? Thanks in advance. --Mark struct bigint { unsigned long flag; }; #include using namespace boost::python; BOOST_PYTHON_MODULE(ul) { class_("bigint") .def_readwrite("flag", &bigint::flag); } C:\developer\Python D3D8\dword>python Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ul import * >>> b = bigint() >>> b.flag = 0x80000000l Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> From rwgk at yahoo.com Wed Dec 11 03:05:04 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 10 Dec 2002 18:05:04 -0800 (PST) Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: Message-ID: <20021211020504.82093.qmail@web20210.mail.yahoo.com> --- David Abrahams wrote: > > How do I work around this problem of "multiply defined > > to_python_converter"? > > Hmm. I'm not sure what the best answer is. Does Python have a > warning mechanism? http://www.python.org/doc/current/lib/module-warnings.html > Maybe it would be best to maks such multiple > definitions trigger a Python warning instead of a hard error. I am not sure if this is a viable solution. For example there are two plausible alternatives for std::vector<> to_python conversions: - to a Python list or tuple - implied by class_ > I am using both alternatives, depending on the value type. Others will have different requirements and make different choices. This will lead to incompatibilities. Ways out? Boost.Python could simply occupy the most prominent ecological niches by default, then everybody has to adhere to that. Conflicts will be the exception. Unfortunately a fully fledged std::vector<> wrapper is fairly heavy-weight. But there is a similar wrapper in the scitbx (flex_wrapper.h; see Boost.Python FAQ) if someone wants to take on this chore. Another idea would be a conversion registry with "context" or "namespaces". Any function could be defined in a certain context with associated conversions. But I am afraid David will need a BIG grant to implement such a beast. Ralf From Paul_Kunz at SLAC.Stanford.EDU Wed Dec 11 05:29:18 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Tue, 10 Dec 2002 20:29:18 -0800 Subject: [C++-sig] Why Python for C++ programmers In-Reply-To: References: <20021206052908.26603.qmail@web20202.mail.yahoo.com> Message-ID: <200212110429.gBB4TID01473@libra3.slac.stanford.edu> >>>>> On Tue, 10 Dec 2002 17:59:29 -0500, David Abrahams said: > "Ralf W. Grosse-Kunstleve" writes: >> --- David Abrahams wrote: >> >> I also find that debugging/testing my C++ algorithms is a lot >> faster if I expose the new classes to Python from where they can >> easily be exercised with different inputs. Almost all regression >> tests for my C++ algorithms are written in Python. > Why is it easier to excercise your C++ from Python than from C++? Ralf answered quite completely. Let me say, if he hadn't I would have said more or less the same sort of things. From dirk at gerrits.homeip.net Wed Dec 11 09:23:04 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Wed, 11 Dec 2002 09:23:04 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python In-Reply-To: References:

Message-ID: Mike Rovner wrote: > "Dirk Gerrits" wrote in message > news:at59bp$skj$1 at main.gmane.org... > >>Furthermore, there should be a way to set/query the currently active >>interpreter. Member functions like this: >> >> bool is_current() const; >> void make_current(); >> >>were the first things that came to mind. > > > How about being consistent with scope() interface? > Creating new interpreter changes current, but one can create > objects to keep and use another. > > Just my 2c. I like the idea of making the new instance the current interpeter. I'm just not so sure what the destructor of the current interpreter should do. Perhaps the most current interpreter still in scope should be looked up in an interpreter registry? Or would it make sense to have no current interpreter at all? I just don't know enough about creating and using sub-interpreters at this point. Dirk Gerrits From Mark.Charsley at radioscape.com Wed Dec 11 11:59:51 2002 From: Mark.Charsley at radioscape.com (Charsley, Mark) Date: Wed, 11 Dec 2002 10:59:51 -0000 Subject: [C++-sig] Re: Presenting a Python embedding tutorial Message-ID: <3190BC9FA8F6D3119508009027E5B33EBA5403@MORSE> > A pseudo-implementation of the constructor and destructor > could look like: > > interpreter() > { > // Create the main interpreter > if (interpreter_count == 0) > { > Py_Initialize(); > ... > } > // Create a sub-interpreter > else > { > ... > } > interpreter_count++; > } > ~interpreter() > { > // Release the main interpreter > if (interpreter_count == 1) > { > Py_Finalize(); > ... > } > // Release a sub-interpreter > else > { > ... > } > interpreter_count--; > } That contains a dangerous flaw - it supposes that PyInitialize hasn't been called by anyone else, using code other than boost::python. Which means that code running in a boost::python extension can't create a sub-interpreter using boost::python. I strongly advise using Py_IsInitialized() instead of a static count in a C++ class. Mark ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at radioscape.com. This footnote also confirms that this email message has been scanned for the presence of computer viruses known at the time of sending. www.radioscape.com ********************************************************************** From dirk at gerrits.homeip.net Wed Dec 11 12:45:58 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Wed, 11 Dec 2002 12:45:58 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial In-Reply-To: <3190BC9FA8F6D3119508009027E5B33EBA5403@MORSE> References: <3190BC9FA8F6D3119508009027E5B33EBA5403@MORSE> Message-ID: Charsley, Mark wrote: >>A pseudo-implementation of the constructor and destructor >>could look like: >> >> interpreter() >> { >> // Create the main interpreter >> if (interpreter_count == 0) >> { >> Py_Initialize(); >> ... >> } >> // Create a sub-interpreter >> else >> { >> ... >> } >> interpreter_count++; >> } >> ~interpreter() >> { >> // Release the main interpreter >> if (interpreter_count == 1) >> { >> Py_Finalize(); >> ... >> } >> // Release a sub-interpreter >> else >> { >> ... >> } >> interpreter_count--; >> } > > > > That contains a dangerous flaw - it supposes that PyInitialize hasn't been > called by anyone else, using code other than boost::python. Which means that > code running in a boost::python extension can't create a sub-interpreter > using boost::python. I strongly advise using Py_IsInitialized() instead of a > static count in a C++ class. Right. Good point. But how do you propose to fix the destructor? Regards from pseudo-code-land, Dirk Gerrits From dave at boost-consulting.com Wed Dec 11 14:15:55 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 08:15:55 -0500 Subject: [C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python In-Reply-To: (Dirk Gerrits's message of "Wed, 11 Dec 2002 09:23:04 +0100") References:

Message-ID: Dirk Gerrits writes: > Mike Rovner wrote: >> "Dirk Gerrits" wrote in message >> news:at59bp$skj$1 at main.gmane.org... >> >>>Furthermore, there should be a way to set/query the currently active >>>interpreter. Member functions like this: >>> >>> bool is_current() const; >>> void make_current(); >>> >>>were the first things that came to mind. >> How about being consistent with scope() interface? >> Creating new interpreter changes current, but one can create >> objects to keep and use another. >> Just my 2c. > > I like the idea of making the new instance the current interpeter. I'm > just not so sure what the destructor of the current interpreter should > do. Perhaps the most current interpreter still in scope should be > looked up in an interpreter registry? Or would it make sense to have > no current interpreter at all? > > I just don't know enough about creating and using sub-interpreters at > this point. I'd like to help make this decision, but I'm having trouble imagining what the consequences or usefulness of having multiple interpreters is. I didn't read that whole article I pointed you at ;-/. Can you give me the quick skinny on this? Thanks, Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Wed Dec 11 14:19:57 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 08:19:57 -0500 Subject: [C++-sig] Why Python for C++ programmers In-Reply-To: <20021211002749.35401.qmail@web20206.mail.yahoo.com> ("Ralf W. Grosse-Kunstleve"'s message of "Tue, 10 Dec 2002 16:27:49 -0800 (PST)") References: <20021211002749.35401.qmail@web20206.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> "Ralf W. Grosse-Kunstleve" writes: >> >> > --- David Abrahams wrote: >> > >> > I also find that debugging/testing my C++ algorithms is a lot faster if I > ^^^^^^^^^^ >> > expose the new classes to Python from where they can easily be exercised >> with >> > different inputs. Almost all regression tests for my C++ algorithms are >> written >> > in Python. >> >> Surely the Python binding layer hides some of the variations on >> possible C++ inputs (e.g. const vs. non-const), making it impossible >> to fully-exercise some C++ interfaces? > ^^^^^^^^^^ > > I find it easier to debug my /algorithms/ from Python. This is very different > from exercising interfaces. > > - Most of my algorithms require very complex inputs. It would take a lot of > time to write C++ code for generating these inputs. > > - If things go wrong it is easy to insert print statements in Python to narrow > down the problem. This is much more time-consuming in C++ because of the > compilation/linking overhead. > > - From Python I can easily try different inputs without inventing file formats > or recompiling. Being able to quickly change inputs or to systematically try a > range of inputs often is the key to finding out which of the many parts of a > complex algorithm is not functioning properly. Does this all come down to the fact that Python has extremely powerful literal expressions which allow you to easily build up new composite objects, and you don't have to recompile it to build new ones? -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Wed Dec 11 14:22:06 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 08:22:06 -0500 Subject: [C++-sig] Re: C++/Boost vs. Python object memory footprint In-Reply-To: (David Abrahams's message of "Tue, 10 Dec 2002 05:17:04 -0500") References: <1039509266.15013.10.camel@localhost> Message-ID: Stephen, Was my answer helpful? David Abrahams writes: > Stephen Davies writes: > >> Hi Dave, >> >> I was wondering what the memory usage of Synopsis would be if I >> converted the in-memory AST to be C++ objects with Boost.Python >> wrappers. >> >> I had 350MB of AST in memory yesterday and my system didn't cope too >> well. I figure each object has at least one dictionary which can't be >> cheap memory wise. The question is, will I still have proxy objects >> floating around if I use Boost.Python, or will the python code directly >> use the C++ objects without creating the instance dictionary et.al.? > > All the code for implementing C++ object wrappers is in > libs/python/src/object/class.cpp. Instance dictionaries are created > only "on demand", the first time the instance's __dict__ attribute is > accessed (see instance_get_dict), but I have no idea whether that > tends to happen almost always or almost never. > > In general, a wrapped C++ object with a corresponding Python object is > the size of a new-style class (derived from 'object' in Python) > instance plus the extra size required to allow variable-length data in > the instance, plus the size of the C++ object, plus the size of a > vtable pointer, plus a pointer to the C++ object's instanceholder, > plus zero or more bytes of padding required to ensure that the > instanceholder is properly aligned. > > You can see this in boost/python/object/instance.hpp. Most Python > objects are represented by instance >, for some C++ > class T. > > I'm not sure what you mean by your question "will I still have proxy > objects floating around...?" > > If your C++ data structure contains pointers or smart pointers, you > can arrange for Python objects to be created which only embed those > pointers (instance >). These Python objects will > be in existence only as long as your Python code holds a reference to > them. So, for example, it should be possible for Python code to do a > walk over your C++ AST, with only O(log(N)) Python objects in > existence corresponding to those N C++ objects at any given time. > >> A related question is what the speed is like calling the C++ objects vs. >> normal Python objects. I can't imagine it would be slower. > > I haven't done any tests, but it certainly could be slower if used > poorly. There is some overhead at the Python/C++ boundary associated > with looking for eligible type converters, overloading, etc. However, > I imagine that ends up being negligible in most cases. The best use > of a Boost.Python C++ binding puts a large amount of computation on > the C++ side of the language boundary. One way I could imagine > slowing down a Python program would be to translate a very large > number of trivial functions to C++. C++ function wrappers will > certainly occupy more memory than the corresponding Python code would, > and this could eventually affect cache locality. > >> The pickling/unpickling speed is also of some concern >> currently. Would this be affected? > > Probably, one way or the other ;-) I think that if you treat your tree > as one monolithic Python object from the standpoint of pickling, you > could probably achieve much better speed than you currently have by > writing some C++ serialization/deserialization code and pickling it as > one long string. Whether or not that's practical for you, of course, > I can't say. > >> Perhaps you can add these to the Boost.Python FAQ :) > > If you'll help me edit them into a suitable form, I'd be most happy > to! > > -- > David Abrahams > dave at boost-consulting.com * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From Mark.Charsley at radioscape.com Wed Dec 11 14:37:24 2002 From: Mark.Charsley at radioscape.com (Charsley, Mark) Date: Wed, 11 Dec 2002 13:37:24 -0000 Subject: [C++-sig] Re: Presenting a Python embedding tutorial Message-ID: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> > > That contains a dangerous flaw - it supposes that > PyInitialize hasn't been > > called by anyone else, using code other than boost::python. > Which means that > > code running in a boost::python extension can't create a > sub-interpreter > > using boost::python. I strongly advise using > Py_IsInitialized() instead of a > > static count in a C++ class. > > Right. Good point. But how do you propose to fix the destructor? A variation on this (a minimal Embedding class we developed here before boost::python v2)? ScriptEngine::ScriptEngine() { if(Py_IsInitialized()) { m_weControlPython = false; } else { Py_Initialize(); m_weControlPython = true; } } ScriptEngine::~ScriptEngine() { if (m_weControlPython) { Py_Finalize(); } } Mark ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at radioscape.com. This footnote also confirms that this email message has been scanned for the presence of computer viruses known at the time of sending. www.radioscape.com ********************************************************************** From dirk at gerrits.homeip.net Wed Dec 11 16:53:51 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Wed, 11 Dec 2002 16:53:51 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial In-Reply-To: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> References: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> Message-ID: Charsley, Mark wrote: >>>That contains a dangerous flaw - it supposes that >> >>PyInitialize hasn't been >> >>>called by anyone else, using code other than boost::python. >> >>Which means that >> >>>code running in a boost::python extension can't create a >> >>sub-interpreter >> >>>using boost::python. I strongly advise using >> >>Py_IsInitialized() instead of a >> >>>static count in a C++ class. >> >>Right. Good point. But how do you propose to fix the destructor? > > > A variation on this (a minimal Embedding class we developed here before > boost::python v2)? > > ScriptEngine::ScriptEngine() > { > if(Py_IsInitialized()) > { > m_weControlPython = false; > } > else > { > Py_Initialize(); > m_weControlPython = true; > } > } > > ScriptEngine::~ScriptEngine() > { > if (m_weControlPython) > { > Py_Finalize(); > } > } Yes very nice. But I still think the static counter is needed for the sub-interpreters. How about this: interpreter() { // Create the main interpreter if (interpreter_count == 0) { if (Py_IsInitialized()) { we_control_python = false; } else { Py_Initialize(); we_control_python = true; } ... } // Create a sub-interpreter else { ... } interpreter_count++; } ~interpreter() { // Release the main interpreter if (interpreter_count == 1) { if (we_control_python) Py_Finalize(); ... } // Release a sub-interpreter else { ... } interpreter_count--; } ?? Dirk Gerrits From dirk at gerrits.homeip.net Wed Dec 11 17:13:09 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Wed, 11 Dec 2002 17:13:09 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial for Boost.Python In-Reply-To: References:

Message-ID: David Abrahams wrote: > Dirk Gerrits writes: > > >>Mike Rovner wrote: >> >>>"Dirk Gerrits" wrote in message >>>news:at59bp$skj$1 at main.gmane.org... >>> >>> >>>>Furthermore, there should be a way to set/query the currently active >>>>interpreter. Member functions like this: >>>> >>>> bool is_current() const; >>>> void make_current(); >>>> >>>>were the first things that came to mind. >>> >>>How about being consistent with scope() interface? >>>Creating new interpreter changes current, but one can create >>>objects to keep and use another. >>>Just my 2c. >> >>I like the idea of making the new instance the current interpeter. I'm >>just not so sure what the destructor of the current interpreter should >>do. Perhaps the most current interpreter still in scope should be >>looked up in an interpreter registry? Or would it make sense to have >>no current interpreter at all? >> >>I just don't know enough about creating and using sub-interpreters at >>this point. > > > I'd like to help make this decision, but I'm having trouble imagining > what the consequences or usefulness of having multiple interpreters > is. I didn't read that whole article I pointed you at ;-/. Can you > give me the quick skinny on this? > > Thanks, > Dave > http://www.modpython.org/live/mod_python-2.7/doc/pyapi-interps.html: (near the top) "Subinterpreters are very useful to make sure that separate programs running under the same Apache server do not interfere with one another." http://www.mcmillan-inc.com/embed2.html (near the bottom) says that you need to have multiple interpreters if you are calling Python from multiple threads and those threads were not created by Python. (Ie Win32 threads, Boost threads, etc.) And perhaps there are more reasons that I missed? Neither of these applies to me at the moment though. And I don't think they will in the (near) future. For me, a python::interpreter which can only have one instance which represents the main interpreter would be just fine. I have however read one message (not on this list) of someone who switched to Lua exactly for the reason that making multiple non-Python threads work with Python was so hard and error-prone. I don't feel I can decide on the matter of supporting multiple interpreters or not. Either would suit me. - Dirk From dave at boost-consulting.com Wed Dec 11 18:34:24 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 12:34:24 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: <20021211020504.82093.qmail@web20210.mail.yahoo.com> ("Ralf W. Grosse-Kunstleve"'s message of "Tue, 10 Dec 2002 18:05:04 -0800 (PST)") References: <20021211020504.82093.qmail@web20210.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> > How do I work around this problem of "multiply defined >> > to_python_converter"? >> >> Hmm. I'm not sure what the best answer is. Does Python have a >> warning mechanism? > > http://www.python.org/doc/current/lib/module-warnings.html > >> Maybe it would be best to maks such multiple >> definitions trigger a Python warning instead of a hard error. > > I am not sure if this is a viable solution. For example there are two plausible > alternatives for std::vector<> to_python conversions: > > - to a Python list or tuple > > - implied by class_ > > > I am using both alternatives, depending on the value type. Others will have > different requirements and make different choices. This will lead to > incompatibilities. > > Ways out? > > Boost.Python could simply occupy the most prominent ecological niches by > default, then everybody has to adhere to that. Conflicts will be the exception. > Unfortunately a fully fledged std::vector<> wrapper is fairly heavy-weight. But > there is a similar wrapper in the scitbx (flex_wrapper.h; see Boost.Python FAQ) > if someone wants to take on this chore. > > Another idea would be a conversion registry with "context" or "namespaces". Any > function could be defined in a certain context with associated conversions. But > I am afraid David will need a BIG grant to implement such a beast. Let's think about what the design should be before we worry about actually getting it done. ;-) In Boost.Python v1, all conversions were "aggressively local". The only way to export them was through a relatively cumbersome explcit construct in both the exporting and importing modules (No offense, Ralf)! One thing I worry about a little is that we might have gone too far in the direction of automatically publishing all conversions for v2: 1. Boost.Python extensions (and the Boost.Python library) compiled with different compilers *cannot* be used together unless the compilers' ABIs match in many respects: type_info (or on some platforms, type_info::name) must have the same format. Object and vtable layout of any types used across modules must match exactly. 2. Since shipping Boost.Python v2, we've discovered problems with some EDG front-ends (used in lots of compilers) on those platforms which use type_info::name comparison, which even prevent modules compiled with the same compiler from interoperating properly unless a cumbersome hack is used. The problem is that the compiler will choose different representations of a given type_info::name() depending on how the type is instantiated. It's not clear to me how important the ABI issue is, but I can imagine that it might be quite important. For example, most Windows compilers are capable of generating compatible object and vtable layouts in the single-inheritance case (which covers an important subset of all C++ applications) even though they may have incompatible type_info formats. I'm not really aware of how similar or different different compiler ABIs are on other platforms, though I think the new ABI developed by a consortium for IA64 may mean we're evolving towards a common ABI for many platforms -- making the issue of incompatibility moot. However, we're surely not there yet. Another approach we could have taken for conversions would be to have all conversions registered in a "local registry" with each module, and use an explicit import. Something like: // Just sketching, here: import import_Y("Foo.Bar.Y"); // Absolute package path import import_X("../Foo/Bar.X"); // Relative package path I realize this is in some sense a step backwards, but I think it's important to convince ourselves we really have the right solution by weighing the pros and cons. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From rwgk at yahoo.com Wed Dec 11 18:41:02 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 11 Dec 2002 09:41:02 -0800 (PST) Subject: [C++-sig] Why Python for C++ programmers In-Reply-To: Message-ID: <20021211174102.45060.qmail@web20210.mail.yahoo.com> --- David Abrahams wrote: > Does this all come down to the fact that Python has extremely powerful > literal expressions which allow you to easily build up new composite > objects, and you don't have to recompile it to build new ones? Maybe. But Python is more than the sum of the pieces. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From achim.domma at syynx.de Wed Dec 11 18:49:15 2002 From: achim.domma at syynx.de (Achim Domma) Date: Wed, 11 Dec 2002 18:49:15 +0100 Subject: [C++-sig] 'unidentifiable C++ exception' / arg_from_python.hpp Message-ID: Hi, using code that worked fine 2-3 days before, I get an 'unidentifiable C++ exception'. If I attach a debugger and let him stop at the first exception, it stops in arg_from_python.hpp in line 319: template inline typename arg_rvalue_from_python::result_type arg_rvalue_from_python::operator()(PyObject* p) { if (m_data.stage1.construct != 0) m_data.stage1.construct(p, &m_data.stage1); <--- Break return python::detail::void_ptr_to_reference(m_data.stage1.convertible, (result_type(*)())0); } The call stack is attached below. Could somebody give me a hint, what's going on? Does this happen in my code, in boost.python or in the CORE_RL_magick_.dll? It must be something stupid, but I have no idea in which direction to search. regards, Achim CORE_RL_magick_.dll!008df35d() > _PythonMagick.pyd!boost::python::converter::arg_rvalue_from_python::operator()(_object * p=0x0079fec0) Line 319 + 0xe C++ _PythonMagick.pyd!boost::python::detail::nullary >::operator()() Line 52 + 0x16 C++ _PythonMagick.pyd!boost::python::detail::invoke(boost::python::detail::fn_ta g __formal={...}, boost::python::detail::fn_tag __formal={...}, void (_object *, const Magick::Geometry &, const Magick::Color &)* & f=0x1000cc10, boost::python::detail::nullary > & ac0={...}, boost::python::detail::nullary > & ac1={...}, boost::python::detail::nullary > & ac2={...}) Line 86 + 0x8 C++ _PythonMagick.pyd!boost::python::detail::caller_arity<3>::impl >::operator()(_object * args_=0x00767350, _object * __formal=0x00000000) Line 162 + 0x20 C++ _PythonMagick.pyd!boost::detail::function::function_obj_invoker2 >,_object *,_object *,_object *>::invoke(boost::detail::function::any_pointer function_obj_ptr={...}, _object * a0=0x00767350, _object * a1=0x00000000) Line 118 C++ boost_python.dll!00b41e75() boost_python.dll!00b4141d() boost_python.dll!00b42c60() boost_python.dll!00b42c12() boost_python.dll!00b554f1() boost_python.dll!00b5522d() boost_python.dll!00b42489() boost_python.dll!00b4198a() python22.dll!1e006d0c() boost_python.dll!00b6c2a0() From dave at boost-consulting.com Wed Dec 11 18:49:47 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 12:49:47 -0500 Subject: [C++-sig] Can't convert to unsigned int In-Reply-To: (Mark Russell's message of "Tue, 10 Dec 2002 17:46:30 -0800") References: Message-ID: Mark Russell writes: > I am wrapping a library that makes extensive use of flags (in varying > guises) that are unsigned longs. I have put together a simplified example > below--when I try to use this module I get an overflow error. Is there a > way to make this type of conversion? Thanks in advance. --Mark > > > struct bigint { > unsigned long flag; > }; > > #include > using namespace boost::python; > > BOOST_PYTHON_MODULE(ul) { > class_("bigint") > .def_readwrite("flag", &bigint::flag); > } > > C:\developer\Python D3D8\dword>python > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> from ul import * >>>> b = bigint() >>>> b.flag = 0x80000000l > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: long int too large to convert to int Well, that's an interesting question. A C++ unsigned long actually has values that can't be represented as a Python INT. Should Boost.Python use Python LONGs to represent these? Even if we did something to make the assignment above work, what would you expect type(b.flag) to be? This very issue has caused a lot of contention on Python-dev. I'm honestly unsure of what the best approach is, and would value a discussion. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From mrussell8081 at pacbell.net Wed Dec 11 19:08:21 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Wed, 11 Dec 2002 10:08:21 -0800 Subject: [C++-sig] Can't convert to unsigned int In-Reply-To: Message-ID: David, Thanks for your reply--the approach I have taken to work around this case is to create a python extension object called flag. This object simply stores the long value I want to set. On the boost side I use an lvalue_from_ptype converter to retrieve the value. This works just fine so I will continue to use this approach. --Mark -----Original Message----- From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On Behalf Of David Abrahams Sent: Wednesday, December 11, 2002 9:50 AM To: c++-sig at python.org Subject: Re: [C++-sig] Can't convert to unsigned int Mark Russell writes: > I am wrapping a library that makes extensive use of flags (in varying > guises) that are unsigned longs. I have put together a simplified example > below--when I try to use this module I get an overflow error. Is there a > way to make this type of conversion? Thanks in advance. --Mark > > > struct bigint { > unsigned long flag; > }; > > #include > using namespace boost::python; > > BOOST_PYTHON_MODULE(ul) { > class_("bigint") > .def_readwrite("flag", &bigint::flag); > } > > C:\developer\Python D3D8\dword>python > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>> from ul import * >>>> b = bigint() >>>> b.flag = 0x80000000l > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: long int too large to convert to int Well, that's an interesting question. A C++ unsigned long actually has values that can't be represented as a Python INT. Should Boost.Python use Python LONGs to represent these? Even if we did something to make the assignment above work, what would you expect type(b.flag) to be? This very issue has caused a lot of contention on Python-dev. I'm honestly unsure of what the best approach is, and would value a discussion. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Wed Dec 11 19:12:07 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 13:12:07 -0500 Subject: [C++-sig] 'unidentifiable C++ exception' / arg_from_python.hpp In-Reply-To: ("Achim Domma"'s message of "Wed, 11 Dec 2002 18:49:15 +0100") References: Message-ID: "Achim Domma" writes: > Hi, > > using code that worked fine 2-3 days before, I get an 'unidentifiable C++ > exception'. If I attach a debugger and let him stop at the first exception, > it stops in arg_from_python.hpp in line 319: > > template > inline typename arg_rvalue_from_python::result_type > arg_rvalue_from_python::operator()(PyObject* p) > { > if (m_data.stage1.construct != 0) > m_data.stage1.construct(p, &m_data.stage1); <--- Break > > return python::detail::void_ptr_to_reference(m_data.stage1.convertible, > (result_type(*)())0); > } > > The call stack is attached below. Could somebody give me a hint, what's > going on? Does this happen in my code, in boost.python or in the > CORE_RL_magick_.dll? It's happening in Boost.Python template code which is instantiated in your extension module. > It must be something stupid, but I have no idea in > which direction to search. It's probably a crash. I have no idea why. I suggest setting your debugger to stop on Win32 exceptions. Adding #include "module_tail.cpp" to the end of your extension module. You can find the .cpp file in libs/python/test. This will cause (JIT) debugging to be invoked at the point of the crash, instead of translating it into a C++ exception. It might be useful to inspect *this at the point of the crash (if the crash does in fact happen at the same place you're seeing the exception above). Sorry I can't be more helpful. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From rwgk at yahoo.com Wed Dec 11 19:11:43 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 11 Dec 2002 10:11:43 -0800 (PST) Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: Message-ID: <20021211181143.25860.qmail@web20209.mail.yahoo.com> --- David Abrahams wrote: > In Boost.Python v1, all conversions were "aggressively local". The > only way to export them was through a relatively cumbersome explcit > construct in both the exporting and importing modules (No offense, > Ralf)! "Explicit is better than implicit." > One thing I worry about a little is that we might have gone > too far in the direction of automatically publishing all conversions > for v2: I think we definitely did go too far. The more I think about it the more I am surprised that we missed this important point until now. Your import<> idea looks interesting. Here is another wild idea: Tie the conversions to scope(). If a function is def'ed in scope a.b.c look for conversions in c first, then b, then a. It's not clear to me what to do about cross-package conversions. Maybe one could use a special module-level variable, like import other_module_1 import other_module_2 __boost_python_conversion_path__=[other_module_1, other_module_2] To support this the registry would have to keep track in what scope each conversion was registered. However, the current C++ interface could maybe left untouched. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From dave at boost-consulting.com Wed Dec 11 19:15:16 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 13:15:16 -0500 Subject: [C++-sig] Can't convert to unsigned int In-Reply-To: (Mark Russell's message of "Wed, 11 Dec 2002 10:08:21 -0800") References: Message-ID: Mark Russell writes: > David, > > Thanks for your reply--the approach I have taken to work around this case is > to create a python extension object called flag. This object simply stores > the long value I want to set. On the boost side I use an lvalue_from_ptype > converter to retrieve the value. This works just fine so I will continue to > use this approach. --Mark I guess I don't see how that helps. Don't you eventually need a Python integer type somewhere? -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From langston at SLAC.Stanford.EDU Wed Dec 11 19:26:07 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Wed, 11 Dec 2002 10:26:07 -0800 Subject: [C++-sig] Can't convert to unsigned int Message-ID: I just ran into this same problem last night. In High Energy Physics we are always using unsigned longs as event bit masks. It would be nice if Python had a bit-vector type for this purpose, but since it doesn't (does it?) a Python long seems like the next best thing. Is there a way to do this on a case-by-case basis (i.e. convert this unsigned long to a Python long for this member function, but not that one). Barring that, I couldn't figure out a way to even register a global to_python_converter to convert all unsigned longs to Python longs. Is this even possible? -Matt -----Original Message----- From: David Abrahams [mailto:dave at boost-consulting.com] Sent: Wednesday, December 11, 2002 9:50 AM To: c++-sig at python.org Subject: Re: [C++-sig] Can't convert to unsigned int Mark Russell writes: > I am wrapping a library that makes extensive use of flags (in varying > guises) that are unsigned longs. I have put together a simplified > example below--when I try to use this module I get an overflow error. > Is there a way to make this type of conversion? Thanks in advance. > --Mark > > > struct bigint { > unsigned long flag; > }; > > #include > using namespace boost::python; > > BOOST_PYTHON_MODULE(ul) { > class_("bigint") > .def_readwrite("flag", &bigint::flag); > } > > C:\developer\Python D3D8\dword>python > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on > win32 Type "help", "copyright", "credits" or "license" for more > information. >>>> from ul import * >>>> b = bigint() >>>> b.flag = 0x80000000l > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: long int too large to convert to int Well, that's an interesting question. A C++ unsigned long actually has values that can't be represented as a Python INT. Should Boost.Python use Python LONGs to represent these? Even if we did something to make the assignment above work, what would you expect type(b.flag) to be? This very issue has caused a lot of contention on Python-dev. I'm honestly unsure of what the best approach is, and would value a discussion. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From mrussell8081 at pacbell.net Wed Dec 11 19:30:23 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Wed, 11 Dec 2002 10:30:23 -0800 Subject: [C++-sig] Can't convert to unsigned int In-Reply-To: Message-ID: In my case I need to set the flag in python, it is used in the wrapped c++ api. So for example if I set the flag as follows in python: >> someflag = flag(0x80000000L) I can then use it to make my wrapped api call >> apicall(someflag) My converter then extracts the value of flag for use in the api all. --Mark -----Original Message----- From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On Behalf Of David Abrahams Sent: Wednesday, December 11, 2002 10:15 AM To: c++-sig at python.org Subject: Re: [C++-sig] Can't convert to unsigned int Mark Russell writes: > David, > > Thanks for your reply--the approach I have taken to work around this case is > to create a python extension object called flag. This object simply stores > the long value I want to set. On the boost side I use an lvalue_from_ptype > converter to retrieve the value. This works just fine so I will continue to > use this approach. --Mark I guess I don't see how that helps. Don't you eventually need a Python integer type somewhere? -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From Paul_Kunz at SLAC.Stanford.EDU Wed Dec 11 19:31:01 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Wed, 11 Dec 2002 10:31:01 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212101328.58246.phil@river-bank.demon.co.uk> References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> <200212101328.58246.phil@river-bank.demon.co.uk> Message-ID: <200212111831.gBBIV1P04269@libra3.slac.stanford.edu> Me again, one final time on this topic. I built a Python extension module for my C++ CanvasWindow class using SIP. Now the following works... [pfkeb at Kunz-pbdsl1 sip]$ python Python 2.2.2 (#1, Oct 15 2002, 07:42:56) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> from qt import * >>> app = QApplication ( sys.argv) >>> from sihippo import * >>> cw = CanvasWindow() >>> cw.show() >>> app.exec_loop() So it appears that SIP and Boost.Python modules can not work together if they are both interfacing to Qt. From langston at SLAC.Stanford.EDU Wed Dec 11 20:00:18 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Wed, 11 Dec 2002 11:00:18 -0800 Subject: [C++-sig] multiply defined to_python_converter Message-ID: If every Boost.Python module had their own registry (as opposed to a global registry), wouldn't this solve the problem? It would just mean that type conversions for any type other than the Python built-ins might be duplicated from time to time. But this might not be a bad thing, since there are potentially an infinite number of ways to convert these more complex types. For example, I thought it was obvious that a std::vector should just convert to a Python tuple. It never even occurred to me that someone might actually want a class_ > instead. My current problem with the global registry was simply solved by commenting out my C++ to_python_converter and recompiling since, in this particular instance, I could rely on the third-party library to supply the conversion functionality that I needed. However, this forces an implicit dependency of my module on the third-party module. There is no way for me to distribute my module standalone. The "explicit is better than implicit" argument would seem to apply here. It would be more work for the Boost.Python module writer, but they would have full control over their conversions and their modules wouldn't have any implicit dependencies on other modules. -Matt -----Original Message----- From: David Abrahams [mailto:dave at boost-consulting.com] Sent: Wednesday, December 11, 2002 9:34 AM To: c++-sig at python.org Subject: Re: [C++-sig] multiply defined to_python_converter "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> > How do I work around this problem of "multiply defined >> > to_python_converter"? >> >> Hmm. I'm not sure what the best answer is. Does Python have a >> warning mechanism? > > http://www.python.org/doc/current/lib/module-warnings.html > >> Maybe it would be best to maks such multiple >> definitions trigger a Python warning instead of a hard error. > > I am not sure if this is a viable solution. For example there are two > plausible alternatives for std::vector<> to_python conversions: > > - to a Python list or tuple > > - implied by class_ > > > I am using both alternatives, depending on the value type. Others will > have different requirements and make different choices. This will lead > to incompatibilities. > > Ways out? > > Boost.Python could simply occupy the most prominent ecological niches > by default, then everybody has to adhere to that. Conflicts will be > the exception. Unfortunately a fully fledged std::vector<> wrapper is > fairly heavy-weight. But there is a similar wrapper in the scitbx > (flex_wrapper.h; see Boost.Python FAQ) if someone wants to take on > this chore. > > Another idea would be a conversion registry with "context" or > "namespaces". Any function could be defined in a certain context with > associated conversions. But I am afraid David will need a BIG grant to > implement such a beast. Let's think about what the design should be before we worry about actually getting it done. ;-) In Boost.Python v1, all conversions were "aggressively local". The only way to export them was through a relatively cumbersome explcit construct in both the exporting and importing modules (No offense, Ralf)! One thing I worry about a little is that we might have gone too far in the direction of automatically publishing all conversions for v2: 1. Boost.Python extensions (and the Boost.Python library) compiled with different compilers *cannot* be used together unless the compilers' ABIs match in many respects: type_info (or on some platforms, type_info::name) must have the same format. Object and vtable layout of any types used across modules must match exactly. 2. Since shipping Boost.Python v2, we've discovered problems with some EDG front-ends (used in lots of compilers) on those platforms which use type_info::name comparison, which even prevent modules compiled with the same compiler from interoperating properly unless a cumbersome hack is used. The problem is that the compiler will choose different representations of a given type_info::name() depending on how the type is instantiated. It's not clear to me how important the ABI issue is, but I can imagine that it might be quite important. For example, most Windows compilers are capable of generating compatible object and vtable layouts in the single-inheritance case (which covers an important subset of all C++ applications) even though they may have incompatible type_info formats. I'm not really aware of how similar or different different compiler ABIs are on other platforms, though I think the new ABI developed by a consortium for IA64 may mean we're evolving towards a common ABI for many platforms -- making the issue of incompatibility moot. However, we're surely not there yet. Another approach we could have taken for conversions would be to have all conversions registered in a "local registry" with each module, and use an explicit import. Something like: // Just sketching, here: import import_Y("Foo.Bar.Y"); // Absolute package path import import_X("../Foo/Bar.X"); // Relative package path I realize this is in some sense a step backwards, but I think it's important to convince ourselves we really have the right solution by weighing the pros and cons. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From dave at boost-consulting.com Wed Dec 11 20:10:02 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 14:10:02 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: ("Langston, Matthew David"'s message of "Wed, 11 Dec 2002 11:00:18 -0800") References: Message-ID: "Langston, Matthew David" writes: > If every Boost.Python module had their own registry (as opposed to a > global registry), wouldn't this solve the problem? It would just mean > that type conversions for any type other than the Python built-ins > might be duplicated from time to time. That would be a problem for class types exposed by users. In general, those have to be exposed in one place and there needs to be a single identifier for the type which can be somehow deduced from its typeid. Otherwise, a [pointer or reference to] C++ type exposed in one module could not be passed to a function exposed in another module. > But this might not be a bad thing, since there are potentially an > infinite number of ways to convert these more complex types. For > example, I thought it was obvious that a std::vector should just > convert to a Python tuple. It never even occurred to me that someone > might actually want a class_ > instead. > > My current problem with the global registry was simply solved by > commenting out my C++ to_python_converter and recompiling since, in > this particular instance, I could rely on the third-party library to > supply the conversion functionality that I needed. However, this > forces an implicit dependency of my module on the third-party module. > There is no way for me to distribute my module standalone. Yep, that's a problem. > The "explicit is better than implicit" argument would seem to apply > here. It would be more work for the Boost.Python module writer, but > they would have full control over their conversions and their > modules wouldn't have any implicit dependencies on other modules. Well, for your particular case I tend to support the idea of warning when two modules define the same converters, and overwriting (or not) the older converter. However, I think there are still good arguments for explicit imports. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Wed Dec 11 20:12:24 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 14:12:24 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: <20021211181143.25860.qmail@web20209.mail.yahoo.com> ("Ralf W. Grosse-Kunstleve"'s message of "Wed, 11 Dec 2002 10:11:43 -0800 (PST)") References: <20021211181143.25860.qmail@web20209.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- David Abrahams wrote: >> One thing I worry about a little is that we might have gone >> too far in the direction of automatically publishing all conversions >> for v2: > > I think we definitely did go too far. Ouch! I was really hoping you'd disagree! > The more I think about it the more I am surprised that we missed > this important point until now. Ouch, ouch, ouch! > Your import<> idea looks interesting. Here is another wild idea: > > Tie the conversions to scope(). If a function is def'ed in scope a.b.c look for > conversions in c first, then b, then a. It's not clear to me what to do about > cross-package conversions. Maybe one could use a special module-level variable, > like > > import other_module_1 > import other_module_2 > __boost_python_conversion_path__=[other_module_1, other_module_2] > > To support this the registry would have to keep track in what scope each > conversion was registered. However, the current C++ interface could maybe left > untouched. That wouldn't handle the issue of ABI/type_info compatibility. Ralf, can you give me a call about this? -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Wed Dec 11 20:15:17 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 14:15:17 -0500 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: <200212111831.gBBIV1P04269@libra3.slac.stanford.edu> ("Paul F. Kunz"'s message of "Wed, 11 Dec 2002 10:31:01 -0800") References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> <200212101328.58246.phil@river-bank.demon.co.uk> <200212111831.gBBIV1P04269@libra3.slac.stanford.edu> Message-ID: "Paul F. Kunz" writes: > Me again, one final time on this topic. > > I built a Python extension module for my C++ CanvasWindow class using > SIP. Now the following works... > > [pfkeb at Kunz-pbdsl1 sip]$ python > Python 2.2.2 (#1, Oct 15 2002, 07:42:56) > [GCC 2.95.3 20010315 (release)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> from qt import * >>>> app = QApplication ( sys.argv) >>>> from sihippo import * >>>> cw = CanvasWindow() >>>> cw.show() >>>> app.exec_loop() > > So it appears that SIP and Boost.Python modules can not work > together if they are both interfacing to Qt. I don't think that's really the right conclusion... or at least, it masks something much deeper. I would very much appreciate it if someone could get me a simple test case I where can easily reproduce this problem (preferably, but not neccessarily on a Windows machine). Thanks, Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From rwgk at yahoo.com Wed Dec 11 20:35:33 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 11 Dec 2002 11:35:33 -0800 (PST) Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: Message-ID: <20021211193533.71997.qmail@web20210.mail.yahoo.com> --- "Langston, Matthew David" wrote: > But this might not be a bad thing, since there are potentially an > infinite number of ways to convert these more complex types. For > example, I thought it was obvious that a std::vector should > just convert to a Python tuple. It never even occurred to me that > someone might actually want a class_ > instead. That's much more useful if - your vectors are huge - you need NumPy-type algebra > My current problem with the global registry was simply solved by > commenting out my C++ to_python_converter and recompiling since, in > this particular instance, I could rely on the third-party library to > supply the conversion functionality that I needed. However, this > forces an implicit dependency of my module on the third-party module. > There is no way for me to distribute my module standalone. Wrap your to_python converter registration in a small function that you expose to Python, then: import your_module try: import third_party_module except: your_module.register_your_converter() > The "explicit is better than implicit" argument would seem to apply > here. It would be more work for the Boost.Python module writer, but > they would have full control over their conversions and their modules > wouldn't have any implicit dependencies on other modules. If you have a large package with elaborate class_<> statements the implicit dependencies are essential. This feature definitely has to stay. But clearly we need something better than the current "everything is global" approach. Boost.Python V2 was released only two months ago and people are already stepping on each other's toes. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From Paul_Kunz at SLAC.Stanford.EDU Wed Dec 11 21:04:13 2002 From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz) Date: Wed, 11 Dec 2002 12:04:13 -0800 Subject: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used together? In-Reply-To: References: <200212100121.gBA1Lst21553@libra3.slac.stanford.edu> <200212100953.53131.phil@river-bank.demon.co.uk> <200212101328.58246.phil@river-bank.demon.co.uk> <200212111831.gBBIV1P04269@libra3.slac.stanford.edu> Message-ID: <200212112004.gBBK4D004611@libra3.slac.stanford.edu> >>>>> On Wed, 11 Dec 2002 14:15:17 -0500, David Abrahams said: > I don't think that's really the right conclusion... or at least, it > masks something much deeper. I would very much appreciate it if > someone could get me a simple test case I where can easily reproduce > this problem (preferably, but not neccessarily on a Windows > machine). I'd like to help, but this problem has delayed me a week. After I get the other half of my group going with a minimal interface using SIP, I'll come back and work up a simple example for you. From mike at bindkey.com Wed Dec 11 21:12:16 2002 From: mike at bindkey.com (Mike Rovner) Date: Wed, 11 Dec 2002 12:12:16 -0800 Subject: [C++-sig] Re: Can't convert to unsigned int References:

Message-ID: "David Abrahams" wrote in message news:uy96wwimc.fsf at boost-consulting.com... > Well, that's an interesting question. A C++ unsigned long actually > has values that can't be represented as a Python INT. Should > Boost.Python use Python LONGs to represent these? ... > This very issue has caused a lot of contention on Python-dev. I'm > honestly unsure of what the best approach is, and would value a > discussion. 2.3+ is going to treat numbers outside int diapason as long. So should BPL IMHO. From mike at bindkey.com Wed Dec 11 21:17:42 2002 From: mike at bindkey.com (Mike Rovner) Date: Wed, 11 Dec 2002 12:17:42 -0800 Subject: [C++-sig] Re: Can't convert to unsigned int References: Message-ID: "Langston, Matthew David" wrote in message > In High Energy Physics we are always using unsigned longs as event bit > masks. It would be nice if Python had a bit-vector type for this > purpose, but since it doesn't (does it?) a Python long seems like the > next best thing. Isn't a std::bitset<> more clear approach? On partial specialization supported platforms it shall be as efficient as ulong. From dave at boost-consulting.com Wed Dec 11 22:47:24 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 16:47:24 -0500 Subject: [C++-sig] Re: Can't convert to unsigned int In-Reply-To: ("Mike Rovner"'s message of "Wed, 11 Dec 2002 12:12:16 -0800") References:

Message-ID: "Mike Rovner" writes: > "David Abrahams" wrote in message > news:uy96wwimc.fsf at boost-consulting.com... > >> Well, that's an interesting question. A C++ unsigned long actually >> has values that can't be represented as a Python INT. Should >> Boost.Python use Python LONGs to represent these? > ... >> This very issue has caused a lot of contention on Python-dev. I'm >> honestly unsure of what the best approach is, and would value a >> discussion. > > 2.3+ is going to treat numbers outside int diapason as long. ^^^^^^^^ What a beautiful word to apply for numeric ranges! > So should BPL IMHO. Believe it or not, those guys on python-dev know what's happening for 2.3+ ;-) Int/Long unification (meaning, having a single type for both) is slated to happen "sometime in the future", IIRC. By 2.2.1, we already had: >>> 32768*65536 2147483648L ...so it's not clear to me what your statement meant. Certainly PyInt_FromLong() is still going to take a signed long int parameter, which will not represent numbers as great as the your constant on a 32-bit platform. The real question is, how do we represent an unsigned integer constant which requires exactly 32-bits? We have 3 choices: 1. We don't (current approach, probably not acceptable) 2. PyInt_FromLong(x) 3. A Python Long representing the actual value. It's not so easy to write down the correct expression for this one ;-) -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From achim at procoders.net Wed Dec 11 22:53:33 2002 From: achim at procoders.net (Achim Domma) Date: Wed, 11 Dec 2002 22:53:33 +0100 Subject: [C++-sig] 'unidentifiable C++ exception' / arg_from_python.hpp In-Reply-To: Message-ID: > -----Original Message----- > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On > Behalf Of David Abrahams > It's probably a crash. I have no idea why. I suggest setting your > debugger to stop on Win32 exceptions. Adding [...] > Sorry I can't be more helpful. Thanks, once again it was my fault: A combination of different runtime libraries, which causes very unpredictable behavior. Sorry for the noise. Achim From wtrenker at hotmail.com Wed Dec 11 22:57:03 2002 From: wtrenker at hotmail.com (William Trenker) Date: Wed, 11 Dec 2002 13:57:03 -0800 Subject: [C++-sig] Wrapping #define's and anonymous enum's Message-ID: Many C/C++ libraries contain one or more .h/.hpp files that define various constants used by that library's API. What is the prescribed method for wrapping #defines that are used to represent constants? Also, how do I wrap anonymous enums? For example, I have a project with an Constants.h file containing: #define MSG_A 23 #define MSG_B 25 enum {Red, White, Blue = 40 }; What would the boost wrapper code for the above look like? Thanks, Bill _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From wtrenker at hotmail.com Wed Dec 11 23:27:03 2002 From: wtrenker at hotmail.com (William Trenker) Date: Wed, 11 Dec 2002 14:27:03 -0800 Subject: [C++-sig] Minimum CVS update for Boost.Python Message-ID: I've got a wonderful 33.6K modem connection to the Internet (aren't I lucky). I've downloaded the entire boost CVS tree but, for now, want to just keep the Python parts current. Boost.Python seems to be located in 2 subdirectories: the guts are in boost/libs/python, and the includes are in boost/boost/python. Are those the only directories I have to update? Thanks, Bill _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From djowel at gmx.co.uk Wed Dec 11 23:40:36 2002 From: djowel at gmx.co.uk (Joel de Guzman) Date: Thu, 12 Dec 2002 06:40:36 +0800 Subject: [C++-sig] Minimum CVS update for Boost.Python References: Message-ID: <010101c2a166$67eda980$94564eca@kim> ----- Original Message ----- From: "William Trenker" > I've got a wonderful 33.6K modem connection to the Internet (aren't I > lucky). I've downloaded the entire boost CVS tree but, for now, want to > just keep the Python parts current. Boost.Python seems to be located in 2 > subdirectories: the guts are in boost/libs/python, and the includes are in > boost/boost/python. Are those the only directories I have to update? There's also a one-stop-shop "python.hpp" in boost/boost that includes everything that you need. Cheers, Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com From nicodemus at globalite.com.br Thu Dec 12 00:45:08 2002 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 11 Dec 2002 20:45:08 -0300 Subject: [C++-sig] Re: Can't convert to unsigned int In-Reply-To: References:

Message-ID: <3DF7CE04.4050209@globalite.com.br> David Abrahams wrote: >The real question is, how do we represent an unsigned integer >constant which requires exactly 32-bits? We have 3 choices: > > 1. We don't (current approach, probably not acceptable) > > 2. PyInt_FromLong(x) > > 3. A Python Long representing the actual value. It's not so easy > to write down the correct expression for this one ;-) > You said that 2) couldn't represent a unsigned long correctly, because it takes as an argument a signed long (or am I missing something?)... I don't see another way to solve this issue, but to implement unsigned longs as PyLongs. Dave, you said that you wasn't sure about the best approach to this problem... what would be the disadvantages of a PyLong approach? Nicodemus. From nicodemus at globalite.com.br Thu Dec 12 00:50:41 2002 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 11 Dec 2002 20:50:41 -0300 Subject: [C++-sig] Re: Presenting a Python embedding tutorial In-Reply-To: References: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> Message-ID: <3DF7CF51.5000203@globalite.com.br> Dirk Gerrits wrote: >> A variation on this (a minimal Embedding class we developed here before >> boost::python v2)? >> >> ScriptEngine::ScriptEngine() >> { >> if(Py_IsInitialized()) >> { >> m_weControlPython = false; >> } >> else >> { >> Py_Initialize(); >> m_weControlPython = true; >> } >> } >> >> ScriptEngine::~ScriptEngine() >> { >> if (m_weControlPython) >> { >> Py_Finalize(); >> } >> } > > > Yes very nice. But I still think the static counter is needed for the > sub-interpreters. How about this: > > interpreter() > { > // Create the main interpreter > if (interpreter_count == 0) > { > if (Py_IsInitialized()) > { > we_control_python = false; > } > else > { > Py_Initialize(); > we_control_python = true; > } > ... > } > // Create a sub-interpreter > else > { > ... > } > interpreter_count++; > } > ~interpreter() > { > // Release the main interpreter > if (interpreter_count == 1) > { > if (we_control_python) > Py_Finalize(); > ... > } > // Release a sub-interpreter > else > { > ... > } > interpreter_count--; > } > > ?? > > Dirk Gerrits > > > Wouldn't be more productive if we first focus in the requirements of a python interpreter, instead of focusing on the implementation itself? 8) In my opinion, a python::interpreter class should be able to (from the top of my head): - Run python code (PyRun_* friends). - Register extension modules. - Run in multiple instances. Nicodemus. From wtrenker at hotmail.com Thu Dec 12 00:05:14 2002 From: wtrenker at hotmail.com (William Trenker) Date: Wed, 11 Dec 2002 15:05:14 -0800 Subject: [C++-sig] FLTK Message-ID: I'm seriously considering doing a Boost.Python extension for the FLTK cross-platform GUI (fltk.org). This is a big job but I'm able to devote the time. My qualifications are a very good working knowledge of Python, a hand-coded Python extension of the SQLite database-engine library (sqlite.org), and a crude but working Boost.Python impementation of SQLite as well. FLTK is implemented in C++ and has a well-documented C++ API. I got a basic FLTK window up and running in Python with Boost.Python in only a day's work (95% of that time learning Boost.Python). I'm doing this work on the FLTK V2.0 CVS tree. Just a few days ago the FLTK folks restructured the FLTK 2.0 source code to use C++ namespaces -- they are really taking C++ seriously. So it seems that a Boost.Python extension of FLTK is a "natural" fit. (I say "seems" because any project like this will have lots of forests with many hidden trees.) I know I'm going to need some help with this. So I would appreciate feedback: are my invevitable Boost / Python questions appropriate for this mailing list? [To the FLTK guru's: I may have a question or 2 for you as well; is that appropriate on the FLTK development newsgroup?] Regards, Bill Trenker Kelowna, BC, Canada (This message has been CC'd to the FLTK development newsgroup @ http://fltk.org/newsgroups.php?gfltk.development) _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From nicodemus at globalite.com.br Thu Dec 12 01:16:08 2002 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 11 Dec 2002 21:16:08 -0300 Subject: [C++-sig] FLTK In-Reply-To: References: Message-ID: <3DF7D548.5060805@globalite.com.br> William Trenker wrote: > I know I'm going to need some help with this. So I would appreciate > feedback: are my invevitable Boost / Python questions appropriate for > this mailing list? [To the FLTK guru's: I may have a question or 2 > for you as well; is that appropriate on the FLTK development newsgroup?] Certainly this is the place to ask. There's always people willing to help, most of all David and Ralf, whose tireless efforts help lots of users every day. About FLTK-specific questions, I think you will get more useful answers from a mailing list devoted to the library. Nicodemus. From dave at boost-consulting.com Thu Dec 12 00:25:50 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 18:25:50 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: <20021211181143.25860.qmail@web20209.mail.yahoo.com> ("Ralf W. Grosse-Kunstleve"'s message of "Wed, 11 Dec 2002 10:11:43 -0800 (PST)") References: <20021211181143.25860.qmail@web20209.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > I think we definitely did go too far. The more I think about it the more I am > surprised that we missed this important point until now. > > Your import<> idea looks interesting. Here is another wild idea: > > Tie the conversions to scope(). If a function is def'ed in scope > a.b.c look for conversions in c first, then b, then a. It's not > clear to me what to do about cross-package conversions. Maybe one > could use a special module-level variable, like I think Ralf and I are now agreeing on a scheme something like the one he suggests above. I don't think we can use scope() exactly, but the following should be possible: * Conversions registered in by the current extension module will always be used in preference to those registered by any other extension module [but see note below] * If no conversion is found in the current extension module, the fallback is to search converters associated with its parent in the package path, and so on, until the package path is empty. * If at this point no eligible conversion is found, the global conversion registry is searched. This would allow some nice conversion scoping without requiring any explicit imports. Of course, some ability to explicitly "hoist" conversions out of a deeper package and into one of its parents or grandparents would be useful. Note: "separation" of extension modules is actually determined by "link units". Modules linked statically into a single executable (e.g. for embedding Python) would all share a big converter registry pool. Under any OS where symbol exports are not explicitly specified (e.g. most Unices), any modules which were directly dynamically linked to one-another would also share a converter registry. Finally, I am not certain whether the fact that all extension modules are dynamically linked to libboost_python will affect this or not. That will take some experimentation on various platforms to determine. The key question is whether two extension modules can end up with separate copies of the same static member of a class template: template struct test { static int x; }; template int test::x; Now when you change test::x in one extension module, does another extension module see the same value? We want the answer to be NO in order to allow some conversion scoping. How does this sound to everyone? -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Thu Dec 12 00:53:06 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 18:53:06 -0500 Subject: [C++-sig] Minimum CVS update for Boost.Python In-Reply-To: ("William Trenker"'s message of "Wed, 11 Dec 2002 14:27:03 -0800") References: Message-ID: "William Trenker" writes: > I've got a wonderful 33.6K modem connection to the Internet (aren't > I lucky). I've downloaded the entire boost CVS tree but, for now, > want to just keep the Python parts current. Boost.Python seems to > be located in 2 subdirectories: the guts are in boost/libs/python, > and the includes are in boost/boost/python. Are those the only > directories I have to update? I wouldn't count on it. Boost.Python is being updated concurrently with other parts of Boost, and I do plan to use new features of other library components. I'm afraid I can't easily give you a limited summary of all the other directories that Boost.Python might need, but I can say that a recursive update in boost/boost and boost/libs/python is likely to be enough. Using the -z9 option to enable full compression during CVS operations could also have a significant positive impact. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Thu Dec 12 01:03:12 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 19:03:12 -0500 Subject: [C++-sig] Re: Can't convert to unsigned int In-Reply-To: <3DF7CE04.4050209@globalite.com.br> (Nicodemus's message of "Wed, 11 Dec 2002 20:45:08 -0300") References:

<3DF7CE04.4050209@globalite.com.br> Message-ID: Nicodemus writes: > David Abrahams wrote: > >>The real question is, how do we represent an unsigned integer >>constant which requires exactly 32-bits? We have 3 choices: >> >> 1. We don't (current approach, probably not acceptable) >> >> 2. PyInt_FromLong(x) >> >> 3. A Python Long representing the actual value. It's not so easy >> to write down the correct expression for this one ;-) >> > > You said that 2) couldn't represent a unsigned long correctly, because > it takes as an argument a signed long (or am I missing > something?)... Right. It would do whatever the platform does when converting an unsigned long to a signed long (which is usually to keep the same bit representation). > I don't see another way to solve this issue, but to implement unsigned > longs as PyLongs. > > Dave, you said that you wasn't sure about the best approach to this > problem... what would be the disadvantages of a PyLong approach? AFAIK, some extension modules (e.g. the Python Win32 API) expect to receive Python Int objects where 32-bit integer constants are passed to them, and will raise an exception if passed a Python Long object. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From nicodemus at globalite.com.br Thu Dec 12 02:44:33 2002 From: nicodemus at globalite.com.br (Nicodemus) Date: Wed, 11 Dec 2002 22:44:33 -0300 Subject: [C++-sig] Re: Can't convert to unsigned int In-Reply-To: References:

<3DF7CE04.4050209@globalite.com.br> Message-ID: <3DF7EA01.2030401@globalite.com.br> David Abrahams wrote: >AFAIK, some extension modules (e.g. the Python Win32 API) expect to >receive Python Int objects where 32-bit integer constants are passed >to them, and will raise an exception if passed a Python Long object. > Hmm, I see. This could be very annoying indeed. But even this drawback is small compared to the current behavior, which is no support at all. I think that if no better solution is proposed, this behavior could be acceptable. Nicodemus. From mrussell8081 at pacbell.net Thu Dec 12 01:47:04 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Wed, 11 Dec 2002 16:47:04 -0800 Subject: [C++-sig] question on object section of bpl tutorial Message-ID: Hi Dave, A quick question from the basic interface page of the object portion of the bpl tutorial. On this page you show the following code snippet. What types are x & y? --Mark def f(x, y): if (y == 'foo'): x[3:7] = 'bar' else: x.items += y(3, x) return x From greglandrum at earthlink.net Thu Dec 12 02:10:22 2002 From: greglandrum at earthlink.net (Greg Landrum) Date: Wed, 11 Dec 2002 17:10:22 -0800 Subject: [C++-sig] passing Numeric arrays as arguments Message-ID: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net> [Boost 1.29, python 2.2.2, g++ 3.2, RH8.0] I've been trying to get a Numeric array object passed in as an argument to a function I've defined in a BPLv2 module, without much success. At the moment I'm happy to get the object in as a PyArrayObject *, because I've got a bunch of code that is expecting those pointers. Since I can't figure out how to extract a PyArrayObject * from a python::numeric::array (if that's even possible), I've attempted to define the following simple function: PyObject *MatFunc(PyArrayObject *arg){ PyObject *res = PyTuple_New(2); return res; } (eventually this will do more, I'm starting small) but whenever I call this Python with a Numeric array as an argument, I get the dreaded catch-all "TypeError: bad argument type for built-in operation". Am I wrong to be even attempting this? Should I just give up and do a normal extension module? -greg ---- greg Landrum (greglandrum at earthlink.net) Software Carpenter/Computational Chemist From dave at boost-consulting.com Thu Dec 12 02:17:29 2002 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 11 Dec 2002 20:17:29 -0500 Subject: [C++-sig] question on object section of bpl tutorial In-Reply-To: (Mark Russell's message of "Wed, 11 Dec 2002 16:47:04 -0800") References: Message-ID: Mark Russell writes: > Hi Dave, > > A quick question from the basic interface page of the object portion of the > bpl tutorial. On this page you show the following code snippet. What types > are x & y? --Mark > > def f(x, y): > if (y == 'foo'): > x[3:7] = 'bar' > else: > x.items += y(3, x) > return x What types would you like them to be? This is Python, remember? Seriously, though: I realize that it's you're unlikely to find types in common usage for which that code makes much sense. Clarifying patches welcome. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From mike at bindkey.com Thu Dec 12 02:38:56 2002 From: mike at bindkey.com (Mike Rovner) Date: Wed, 11 Dec 2002 17:38:56 -0800 Subject: [C++-sig] Re: Wrapping #define's and anonymous enum's References: Message-ID: "William Trenker" wrote in message news:F62JMYRF7luM8gbvdBR000026c2 at hotmail.com... > Many C/C++ libraries contain one or more .h/.hpp files that define various > constants used by that library's API. > > What is the prescribed method for wrapping #defines that are used to > represent constants? > > Also, how do I wrap anonymous enums? > > For example, I have a project with an Constants.h file containing: > > #define MSG_A 23 > #define MSG_B 25 > enum {Red, White, Blue = 40 }; > > What would the boost wrapper code for the above look like? > #include BOOST_PYTHON_MODULE(my_module) { scope().attr("MSG_A") = 23; scope().attr("MSG_B") = 25; scope().attr("Red") = 0; ... } But you really DON'T WANT to do this. Think twice about your code. From greglandrum at mindspring.com Thu Dec 12 02:49:32 2002 From: greglandrum at mindspring.com (greg Landrum) Date: Wed, 11 Dec 2002 17:49:32 -0800 Subject: [C++-sig] passing Numeric arrays as arguments In-Reply-To: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net> Message-ID: <5.1.0.14.2.20021211174833.03bf2140@mail.mindspring.com> Sorry about that dumb question. I was experiencing a major brainlock. using python::numeric::array and the ptr() method appears to solve my problems. -greg From mrussell8081 at pacbell.net Thu Dec 12 05:43:37 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Wed, 11 Dec 2002 20:43:37 -0800 Subject: [C++-sig] question on object section of bpl tutorial In-Reply-To: Message-ID: Dave, I am building a short example for this case--hopefully it will be useful in the tutorial. I have run into a problem however, I am using msvc 6.5 and cannot get the following code from the tutorial to compile: #include using namespace boost::python; void f(str name) { object n2 = name.attr("upper")(); // NAME = name.upper() str NAME = name.upper(); // better object msg = "%s is bigger than %s" % make_tuple(NAME,name); } The compiler cannot resolve the str ambiguity--I did some research on this and I guess my compiler is one of the broken ones that can't do this automatically :{ I have made several tries at explicitly specifying the name but no joy--how do I do this? --Mark -----Original Message----- From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On Behalf Of David Abrahams Sent: Wednesday, December 11, 2002 5:17 PM To: c++-sig at python.org Subject: Re: [C++-sig] question on object section of bpl tutorial Mark Russell writes: > Hi Dave, > > A quick question from the basic interface page of the object portion of the > bpl tutorial. On this page you show the following code snippet. What types > are x & y? --Mark > > def f(x, y): > if (y == 'foo'): > x[3:7] = 'bar' > else: > x.items += y(3, x) > return x What types would you like them to be? This is Python, remember? Seriously, though: I realize that it's you're unlikely to find types in common usage for which that code makes much sense. Clarifying patches welcome. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From rwgk at yahoo.com Thu Dec 12 07:16:20 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 11 Dec 2002 22:16:20 -0800 (PST) Subject: [C++-sig] Do SWIP, SIP have a "cross-module" feature? Message-ID: <20021212061620.82745.qmail@web20202.mail.yahoo.com> The recent discussion about a scoped type conversion registry for Boost.Python made me wonder if and how "cross-module" type conversions are handled by other packages. By "cross-module" I mean that a module A defines a type conversion which can be used by, e.g. a wrapped function in another module B. For example in Boost.Python terms: In module A: class_(...) In module B: your_type foo(your_type const& x); def("foo", foo); For this to work the only requirement in Boost.Python is that module A is somehow imported (either from Python or through the C-API from C++) before foo() is used. Is this also possible with SIP or SWIG? Thanks, Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From dirk at gerrits.homeip.net Thu Dec 12 08:34:42 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Thu, 12 Dec 2002 08:34:42 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial In-Reply-To: <3DF7CF51.5000203@globalite.com.br> References: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> <3DF7CF51.5000203@globalite.com.br> Message-ID: Nicodemus wrote: > Wouldn't be more productive if we first focus in the requirements of a > python interpreter, instead of focusing on the implementation itself? 8) Yes, sounds like a good idea. And since I'm Dutch the one obvious implementation should follow naturally. ;P Dirk Gerrits From niki at vintech.bg Thu Dec 12 10:11:09 2002 From: niki at vintech.bg (Niki Spahiev) Date: Thu, 12 Dec 2002 11:11:09 +0200 Subject: [C++-sig] Do SWIP, SIP have a "cross-module" feature? In-Reply-To: <20021212061620.82745.qmail@web20202.mail.yahoo.com> References: <20021212061620.82745.qmail@web20202.mail.yahoo.com> Message-ID: <3DF852AD.60206@vintech.bg> Ralf W. Grosse-Kunstleve wrote: > The recent discussion about a scoped type conversion registry for Boost.Python > made me wonder if and how "cross-module" type conversions are handled by other > packages. > > By "cross-module" I mean that a module A defines a type conversion which can be > used by, e.g. a wrapped function in another module B. For example in > Boost.Python terms: > > In module A: > > class_(...) > > In module B: > > your_type foo(your_type const& x); > > def("foo", foo); > > For this to work the only requirement in Boost.Python is that module A is > somehow imported (either from Python or through the C-API from C++) before > foo() is used. Is this also possible with SIP or SWIG? AFAIK yes. SIP user SIP.DLL to hold global register. SWIG also can be configured to use global SWIG runtime. SWIG by default uses local. wxPython (SWIG) has similar (C-API import) solution for multiple modules and no extra global runtime. Niki Spahiev From niki at vintech.bg Thu Dec 12 10:39:10 2002 From: niki at vintech.bg (Niki Spahiev) Date: Thu, 12 Dec 2002 11:39:10 +0200 Subject: [C++-sig] FLTK In-Reply-To: References: Message-ID: <3DF8593E.7020406@vintech.bg> William Trenker wrote: > I'm seriously considering doing a Boost.Python extension for the FLTK > cross-platform GUI (fltk.org). This is a big job but I'm able to devote > the time. My qualifications are a very good working knowledge of > Python, a hand-coded Python extension of the SQLite database-engine > library (sqlite.org), and a crude but working Boost.Python impementation > of SQLite as well. > > FLTK is implemented in C++ and has a well-documented C++ API. I got a > basic FLTK window up and running in Python with Boost.Python in only a > day's work (95% of that time learning Boost.Python). > > I'm doing this work on the FLTK V2.0 CVS tree. Just a few days ago the > FLTK folks restructured the FLTK 2.0 source code to use C++ namespaces > -- they are really taking C++ seriously. So it seems that a > Boost.Python extension of FLTK is a "natural" fit. (I say "seems" > because any project like this will have lots of forests with many hidden > trees.) > > I know I'm going to need some help with this. So I would appreciate > feedback: are my invevitable Boost / Python questions appropriate for > this mailing list? [To the FLTK guru's: I may have a question or 2 for > you as well; is that appropriate on the FLTK development newsgroup?] How can i test this? From FLTK CVS? regards, Niki Spahiev From nicodemus at globalite.com.br Thu Dec 12 12:46:36 2002 From: nicodemus at globalite.com.br (Nicodemus) Date: Thu, 12 Dec 2002 08:46:36 -0300 Subject: [C++-sig] question on object section of bpl tutorial In-Reply-To: References: Message-ID: <3DF8771C.1090606@globalite.com.br> Mark Russell wrote: >The compiler cannot resolve the str ambiguity--I did some research on this >and I guess my compiler is one of the broken ones that can't do this >automatically :{ I have made several tries at explicitly specifying the >name but no joy--how do I do this? --Mark > Hi Mark, I have the same problem, unfortunately (Intel C++ 6.0). I assume that you're doing a 'using namespace boost::python' at the top of the module. So, there's two cases where you can use str: 1) When you are dealing with a PyString: str x( "Hello" ); To solve this, simply preppend 'boost::python::': boost::python::str x( "Hello" ); 2) When you're exporting the __str__ method: ... .def( str(self) ) ... To solve the ambiguity, preppend 'boost::python::self_ns::' (or just 'self_ns::'): .def( boost::python::self_ns::str(self) ) or .def( self_ns::str(self) ) Hope this helps. Nicodemus. From dave at boost-consulting.com Thu Dec 12 15:32:20 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 09:32:20 -0500 Subject: [C++-sig] passing Numeric arrays as arguments In-Reply-To: <5.1.0.14.2.20021211174833.03bf2140@mail.mindspring.com> (greg Landrum's message of "Wed, 11 Dec 2002 17:49:32 -0800") References: <5.1.0.14.2.20021211174833.03bf2140@mail.mindspring.com> Message-ID: greg Landrum writes: > Sorry about that dumb question. I was experiencing a major brainlock. > > using python::numeric::array and the ptr() method appears to solve my problems. Great! When you're done, if you'd like to contribute an example for the tutorial or examples folder, that'd be super. -Dave -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Thu Dec 12 17:54:08 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 11:54:08 -0500 Subject: [C++-sig] Re: C++/Boost vs. Python object memory footprint In-Reply-To: <1039667730.4437.86.camel@localhost> (Stephen Davies's message of "12 Dec 2002 15:35:31 +1100") References: <1039509266.15013.10.camel@localhost>

<1039667730.4437.86.camel@localhost> Message-ID: Stephen Davies writes: > On Thu, 2002-12-12 at 00:22, David Abrahams wrote: >> Stephen, >> >> Was my answer helpful? > > Kind of. You gave lots of useful info, but no clear answer (to my maybe > not so clear) questions: will the memory usage decrease? and will the > speed increase? I guess there is no clear answer, since it depends on > how it's used. Right. >> David Abrahams writes: >> >> > Stephen Davies writes: >> > >> >> I had 350MB of AST in memory yesterday and my system didn't cope too >> >> well. I figure each object has at least one dictionary which can't be >> >> cheap memory wise. The question is, will I still have proxy objects >> >> floating around if I use Boost.Python, or will the python code directly >> >> use the C++ objects without creating the instance dictionary et.al.? >> > >> > All the code for implementing C++ object wrappers is in >> > libs/python/src/object/class.cpp. Instance dictionaries are created >> > only "on demand", the first time the instance's __dict__ attribute is >> > accessed (see instance_get_dict), but I have no idea whether that >> > tends to happen almost always or almost never. > > Hmm, it would be useful to investigate what causes this, eg: all > accesses to member variables/calls, getattr calls, or just > "foo.__dict__" statements. > > Hmm I've just been reading through Python sources and boost's class.cpp > for the last hour, Ouch, that's the hard way. Probably much easier to use a debugger. > and here's what I've got: > > Python/ceval.c: Attribute access of an object uses PyObject_GetAttr. > > Objects/Object.c: GetAttr uses the tp_getattro/tp_getattr methods in the > Type object. Boost does not set these, so the default is used. > PyObject_GenericGetAttr or type_getattro (not sure which) uses some kind > of Descriptor Object, and if that fails, the dictionary. The descriptor > stuff confused me, but class.cpp has 0 in the slots for > tp_descr_get/set. That doesn't mean anything. This instance type is derived from Python's "object" type, so lots of slots get filled in automatically by the system during PyType_Ready. No, the internals of Python's new type system are not really documented anywhere :( > So, it seems that the dict would be used after all, for every method > call. I wouldn't count on it. Remember also that the class' dict and the instance dict are two separate beasts. FWIW, I have had it in the back of my mind to allow classes to be wrapped with no instance dict at all for quite a while, but it hasn't been a priority. > I'm not sure how I got to 350MB, but I suspect that the dict is a > large part of it, since there are a lot of (simple: get/set and > visitor accept) methods, of which only the accept (and destructor of > course) would be virtual in C++. I don't know either how memory > efficient the Python data structures are (PyList, PyTuple, even just > pointers), but there's a large chance that there is a *lot* of small > chunks of memory being allocated - iirc each chunk has some > overhead. I'm sure C++ could store this more efficiently. Probably. In Pure Python, tuples are better than lists, though. If you have your choice, use tuples. > If you're interested in looking at the AST and Type heirarchies, there > is both a Python version in Synopsis/Core/{AST,Type}.py and a mostly > corresponding C++ version in Synopsis/Parser/C++/syn/{ast,type}.hh. Maybe after I dig myself out of this backlog... remind me again if you feel it would be helpful, and I'll try. >> > In general, a wrapped C++ object with a corresponding Python object is >> > the size of a new-style class (derived from 'object' in Python) >> > instance plus the extra size required to allow variable-length data in >> > the instance, plus the size of the C++ object, plus the size of a >> > vtable pointer, plus a pointer to the C++ object's instanceholder, >> > plus zero or more bytes of padding required to ensure that the >> > instanceholder is properly aligned. > > This sounds like a lot, but without the dict of every method and > variable it may still be smaller. I think you're confusing classes with instances. Methods get stored once per class, so they're relatively cheap, and wrapped Boost.Python methods take up about as much as Python methods do. Attributes get stored once per instance, and are relatively expensive. Boost.Python exposes C++ data members using "property" descriptors, so there's the cost of one or two methods in the class, plus just the raw storage for the corresponding C++ object in the instance. Usually, this will cost less than a Python attribute in an instance dictionary. >> > I'm not sure what you mean by your question "will I still have proxy >> > objects floating around...?" > > Some API wrappers create proxy objects with methods corresponding to the > API like: > class GTK_Widget (something): > def get_child(self): > return _gtkmodule.do_get_child(self._obj) > > I've since realised that Boost doesn't resort to such trickery. Nope. The new type system makes all that unneccessary. >> > If your C++ data structure contains pointers or smart pointers, you >> > can arrange for Python objects to be created which only embed those >> > pointers (instance >). These Python objects will >> > be in existence only as long as your Python code holds a reference to >> > them. So, for example, it should be possible for Python code to do a >> > walk over your C++ AST, with only O(log(N)) Python objects in >> > existence corresponding to those N C++ objects at any given time. > > This sounds good, though I wonder at the overhead of creating and > destroying those pointer_holder instances - the AST can contain 10,000's > of objects, and be walked several times over. It's a trade-off between memory and speed. But if your memory image is pushing things out of the cache, sometimes it's not a trade-off anymore ;-) > Would this work if the nodes had something like > "std::vector declarations" ? Your question's not very precise, but if I understand it, yes. However, for an application like this I think I'd recommend std::vector > >> >> A related question is what the speed is like calling the C++ objects vs. >> >> normal Python objects. I can't imagine it would be slower. >> > >> > I haven't done any tests, but it certainly could be slower if used >> > poorly. There is some overhead at the Python/C++ boundary associated >> > with looking for eligible type converters, overloading, etc. However, >> > I imagine that ends up being negligible in most cases. The best use >> > of a Boost.Python C++ binding puts a large amount of computation on >> > the C++ side of the language boundary. One way I could imagine >> > slowing down a Python program would be to translate a very large >> > number of trivial functions to C++. C++ function wrappers will >> > certainly occupy more memory than the corresponding Python code would, >> > and this could eventually affect cache locality. > > More memory for every object instance? No, more memory in the executable code image. > The methods in the AST are indeed very simple with the exception of > the constructors which do type checking, and the AST class which has > some other stuff. > > It sounds like there wouldn't be much overhead at the boundary: > since the AST was first written in Python, there is no method > overloading. I think you're basically right, but the lack of overloading in the original design doesn't have much impact on it. >> >> Perhaps you can add these to the Boost.Python FAQ :) >> > >> > If you'll help me edit them into a suitable form, I'd be most happy >> > to! > > Sure, but I'm not happy with the answers yet. Let's keep going until you are. > It looks like I'm going to have to actually come up with some test > cases and see what happens. I don't know when I'll have time for > that though. I'll run a quick test now to see when __dict__ gets filled in. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From rwgk at yahoo.com Thu Dec 12 18:00:36 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 12 Dec 2002 09:00:36 -0800 (PST) Subject: [C++-sig] Do SWIP, SIP have a "cross-module" feature? In-Reply-To: <3DF852AD.60206@vintech.bg> Message-ID: <20021212170036.72525.qmail@web20209.mail.yahoo.com> --- Niki Spahiev wrote: > AFAIK yes. SIP user SIP.DLL to hold global register. SWIG also can be > configured to use global SWIG runtime. SWIG by default uses local. > wxPython (SWIG) has similar (C-API import) solution for multiple modules > and no extra global runtime. Thanks for the reply! Based on these hints I finally found the corresponding SWIG documentation ( http://www.swig.org/Doc1.1/HTML/Advanced.html ). I see that linking with the static runtime is a simple way of avoiding any cross-module type conversion conflicts. The more interesting case however is if there are two SWIG-based multi-extension-module packages where all modules are linked against the central shared runtime (libswigpy.so). If package A registers conversions for, say, std::vector, and package B registers different conversions for the same type, how does SWIG resolve the ambiguity? Thanks, Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From dirk at gerrits.homeip.net Thu Dec 12 18:03:23 2002 From: dirk at gerrits.homeip.net (Dirk Gerrits) Date: Thu, 12 Dec 2002 18:03:23 +0100 Subject: [C++-sig] Re: Presenting a Python embedding tutorial In-Reply-To: <3DF7CF51.5000203@globalite.com.br> References: <3190BC9FA8F6D3119508009027E5B33EBA5405@MORSE> <3DF7CF51.5000203@globalite.com.br> Message-ID: Nicodemus wrote: > In my opinion, a python::interpreter class should be able to (from the > top of my head): > - Run python code (PyRun_* friends). [snip] I like this idea of making the PyRun_* wrappers member functions of python::interpreter. It simplifies things for the user (and the implementer too I reckon. ;)) Dirk Gerrits From dave at boost-consulting.com Thu Dec 12 18:52:26 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 12:52:26 -0500 Subject: [C++-sig] Re: C++/Boost vs. Python object memory footprint In-Reply-To: (David Abrahams's message of "Thu, 12 Dec 2002 11:54:08 -0500") References: <1039509266.15013.10.camel@localhost>

<1039667730.4437.86.camel@localhost> Message-ID: David Abrahams writes: > Stephen Davies writes: > > I'll run a quick test now to see when __dict__ gets filled in. Good news. I checked, and instance dicts are only created "on demand" in Boost.Python extension instances. >>> a = A() # some extension class A, no instance dict >>> a.x # Attribute lookup fails, still no instance dict Traceback ... >>> a.y = 1 # y is a C++ data member, still no instance dict >>> a.x = 1 # creates an instance dict >>> z = A() >>> z.__dict__ # also creates an instance dict HTH, -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Thu Dec 12 19:31:53 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 13:31:53 -0500 Subject: [C++-sig] FLTK In-Reply-To: ("William Trenker"'s message of "Wed, 11 Dec 2002 15:05:14 -0800") References: Message-ID: "William Trenker" writes: > I'm seriously considering doing a Boost.Python extension for the FLTK > cross-platform GUI (fltk.org). I love that idea. Incidentally, I used to work with Bill Spitzak many many moons ago. > This is a big job but I'm able to devote the time. My > qualifications are a very good working knowledge of Python, a > hand-coded Python extension of the SQLite database-engine library > (sqlite.org), and a crude but working Boost.Python impementation of > SQLite as well. > > FLTK is implemented in C++ and has a well-documented C++ API. I got > a basic FLTK window up and running in Python with Boost.Python in > only a day's work (95% of that time learning Boost.Python). Cool! > I'm doing this work on the FLTK V2.0 CVS tree. Just a few days ago > the FLTK folks restructured the FLTK 2.0 source code to use C++ > namespaces -- they are really taking C++ seriously. So it seems > that a Boost.Python extension of FLTK is a "natural" fit. (I say > "seems" because any project like this will have lots of forests with > many hidden trees.) Probably. > I know I'm going to need some help with this. Let us know how we can support you. > So I would appreciate feedback: are my invevitable Boost / Python > questions appropriate for this mailing list? Of course. > [To the FLTK guru's: I may have a question or 2 for you as well; is > that appropriate on the FLTK development newsgroup?] > > Regards, > Bill Trenker > Kelowna, BC, Canada I visited Kelowna many years ago; it was gorgeous. Howdy from Somerville, Mass! -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From mrussell8081 at pacbell.net Thu Dec 12 19:56:29 2002 From: mrussell8081 at pacbell.net (Mark Russell) Date: Thu, 12 Dec 2002 10:56:29 -0800 Subject: [C++-sig] question on object section of bpl tutorial In-Reply-To: <3DF8771C.1090606@globalite.com.br> Message-ID: This works just fine. Thanks Mark -----Original Message----- From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On Behalf Of Nicodemus Sent: Thursday, December 12, 2002 3:47 AM To: c++-sig at python.org Subject: Re: [C++-sig] question on object section of bpl tutorial Mark Russell wrote: >The compiler cannot resolve the str ambiguity--I did some research on this >and I guess my compiler is one of the broken ones that can't do this >automatically :{ I have made several tries at explicitly specifying the >name but no joy--how do I do this? --Mark > Hi Mark, I have the same problem, unfortunately (Intel C++ 6.0). I assume that you're doing a 'using namespace boost::python' at the top of the module. So, there's two cases where you can use str: 1) When you are dealing with a PyString: str x( "Hello" ); To solve this, simply preppend 'boost::python::': boost::python::str x( "Hello" ); 2) When you're exporting the __str__ method: ... .def( str(self) ) ... To solve the ambiguity, preppend 'boost::python::self_ns::' (or just 'self_ns::'): .def( boost::python::self_ns::str(self) ) or .def( self_ns::str(self) ) Hope this helps. Nicodemus. _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From langston at SLAC.Stanford.EDU Thu Dec 12 21:54:58 2002 From: langston at SLAC.Stanford.EDU (Langston, Matthew David) Date: Thu, 12 Dec 2002 12:54:58 -0800 Subject: [C++-sig] multiply defined to_python_converter Message-ID: Dave Abrahams wrote: > I think Ralf and I are now agreeing on a scheme something like the one he > suggests above. I don't think we can use scope() exactly, but the > following should be possible: > > * Conversions registered in by the current extension module will > always be used in preference to those registered by any other > extension module [but see note below] > > * If no conversion is found in the current extension module, the > fallback is to search converters associated with its parent in the > package path, and so on, until the package path is empty. > > * If at this point no eligible conversion is found, the global > conversion registry is searched. > > [snip] > > The key question is whether two extension modules can end up with separate > copies of the same static member of a class template: > > template > struct test { static int x; }; > template int test::x; > > Now when you change test::x in one extension module, does another > extension module see the same value? We want the answer to be NO in order > to allow some conversion scoping. > > How does this sound to everyone? I'm not sure I understood the case for why two extension modules need separate copies of a static member of a class template. Is this an intenal Boost.Python implementation issue that is required to implement your three-point plan above? Or, does it relate to user-written to_python_converters? Based on my use-case, the solution you and Ralf came up with completely solves my problem. So, how does it sound? Sounds perfect to me. -Matt From temas at box5.net Thu Dec 12 22:06:40 2002 From: temas at box5.net (Thomas Muldowney) Date: Thu, 12 Dec 2002 15:06:40 -0600 Subject: [C++-sig] Function taking Virtual Base Pointer Message-ID: <20021212210640.GA19686@box5.net> I'm trying to implement an event listener class from my C++ library so that python scripts can override it and get the events delivered to them in the script. After reading the docs it all seemed possible and easy to do. In my real library I pass a pointer to the constructor of the event dispatcher, but I always ended up getting a TypeError from that. Thinking it might be something with constructors I tried it in a regular function that just took a pointer to the virtual base, still no luck. Next I tried it as a reference. Still nada. So I whipped up this simple test setup and it does the exact same thing: testMOD implementation: #include using namespace boost::python; struct A { virtual void onCommand() = 0; }; struct A_cb : A { A_cb(PyObject* self) : _self(self) { } void onCommand() { return call_method(_self, "onCommand"); } PyObject* _self; }; void test_Aptr(A* cmd) { cmd->onCommand(); } BOOST_PYTHON_MODULE(testMOD) { class_ >("A", no_init); def("test_Aptr", test_Aptr); } Python test script: from testMOD import * class MyA(A): ## Don't get yelled at because we pass off to the non existant internal ## constructor def __init__(self): pass def onCommand(self): print "We got a command" a = MyA() test_Aptr(a) Output running it: $ python test_ptr.py Traceback (most recent call last): File "test_ptr.py", line 12, in ? test_Aptr(a) TypeError: bad argument type for built-in operation I really do love everything, this has just been giving me a headache =) --temas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dave at boost-consulting.com Thu Dec 12 22:15:56 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 16:15:56 -0500 Subject: [C++-sig] Re: Wrapping #define's and anonymous enum's In-Reply-To: ("Mike Rovner"'s message of "Wed, 11 Dec 2002 17:38:56 -0800") References: Message-ID: "Mike Rovner" writes: > "William Trenker" wrote in message > news:F62JMYRF7luM8gbvdBR000026c2 at hotmail.com... >> Many C/C++ libraries contain one or more .h/.hpp files that define various >> constants used by that library's API. >> >> What is the prescribed method for wrapping #defines that are used to >> represent constants? >> >> Also, how do I wrap anonymous enums? >> >> For example, I have a project with an Constants.h file containing: >> >> #define MSG_A 23 >> #define MSG_B 25 >> enum {Red, White, Blue = 40 }; >> >> What would the boost wrapper code for the above look like? >> > > #include > > BOOST_PYTHON_MODULE(my_module) > { > scope().attr("MSG_A") = 23; > scope().attr("MSG_B") = 25; > scope().attr("Red") = 0; > ... > } > > But you really DON'T WANT to do this. > Think twice about your code. Why not, Mike? FYI, there's also: enum_("my_enum") .value("Red", Red) .value("White", White) .value("Blue", Blue) ; But of course, you have to have a name for the enum type to do that. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From wtrenker at hotmail.com Thu Dec 12 22:47:16 2002 From: wtrenker at hotmail.com (William Trenker) Date: Thu, 12 Dec 2002 13:47:16 -0800 Subject: [C++-sig] Searchable Mirror Message-ID: Is there a searchable mirror of this list? _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From temas at box5.net Thu Dec 12 22:56:06 2002 From: temas at box5.net (Thomas Muldowney) Date: Thu, 12 Dec 2002 15:56:06 -0600 Subject: [C++-sig] Searchable Mirror In-Reply-To: References: Message-ID: <20021212215606.GA19809@box5.net> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/C++-sig --temas On Thu, Dec 12, 2002 at 01:47:16PM -0800, William Trenker wrote: > Is there a searchable mirror of this list? > > > > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dave at boost-consulting.com Thu Dec 12 23:22:44 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 17:22:44 -0500 Subject: [C++-sig] Searchable Mirror In-Reply-To: <20021212215606.GA19809@box5.net> (Thomas Muldowney's message of "Thu, 12 Dec 2002 15:56:06 -0600") References: <20021212215606.GA19809@box5.net> Message-ID: Thomas Muldowney writes: > http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/C++-sig > Also see: http://news.gmane.org/thread.php?group=gmane.comp.python.c%2B%2B -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From dave at boost-consulting.com Fri Dec 13 00:10:18 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 18:10:18 -0500 Subject: [C++-sig] Function taking Virtual Base Pointer In-Reply-To: <20021212210640.GA19686@box5.net> (Thomas Muldowney's message of "Thu, 12 Dec 2002 15:06:40 -0600") References: <20021212210640.GA19686@box5.net> Message-ID: Thomas Muldowney writes: > I'm trying to implement an event listener class from my C++ library so > that python scripts can override it and get the events delivered to them > in the script. After reading the docs it all seemed possible and easy > to do. > BOOST_PYTHON_MODULE(testMOD) > { > class_ boost::shared_ptr >("A", no_init); strike no_init here------------------^^^^^^^ You don't really need shared_ptr; but it's OK. > def("test_Aptr", test_Aptr); > } > > > Python test script: > from testMOD import * > > class MyA(A): > ## Don't get yelled at because we pass off to the non existant internal > ## constructor > def __init__(self): You need to call the base class __init__ here to create the C++ instance. Or you can do it the easy way; just remove the __init__ function here. > pass > def onCommand(self): > print "We got a command" > > a = MyA() > test_Aptr(a) > > Output running it: > $ python test_ptr.py > Traceback (most recent call last): > File "test_ptr.py", line 12, in ? > test_Aptr(a) > TypeError: bad argument type for built-in operation > > > I really do love everything, this has just been giving me a headache =) I love everything too! -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From mike at bindkey.com Fri Dec 13 00:31:48 2002 From: mike at bindkey.com (Mike Rovner) Date: Thu, 12 Dec 2002 15:31:48 -0800 Subject: [C++-sig] Re: Re: Wrapping #define's and anonymous enum's References:

Message-ID: "David Abrahams" wrote in message news:u1y4nndkj.fsf at boost-consulting.com... > >> #define MSG_A 23 > >> #define MSG_B 25 > >> enum {Red, White, Blue = 40 }; > >> > >> What would the boost wrapper code for the above look like? > > > > #include > > > > BOOST_PYTHON_MODULE(my_module) > > { > > scope().attr("MSG_A") = 23; > > scope().attr("MSG_B") = 25; > > scope().attr("Red") = 0; > > ... > > } > > > > But you really DON'T WANT to do this. > > Think twice about your code. > > Why not, Mike? IMHO anonimous enums and especialy #define's are marks of a design style I personaly tend to avoid ;) Clattering (global) namespace and unusable at debug time names are definitely not Good Things. So I usualy write a tiny C++ wrapper around a library I can't change to avoid and enlight such things. Just to make my future life easyer. :) > But of course, you have to have a name for the enum type to do that. Exactly. From temas at box5.net Fri Dec 13 00:41:33 2002 From: temas at box5.net (Thomas Muldowney) Date: Thu, 12 Dec 2002 17:41:33 -0600 Subject: [C++-sig] Function taking Virtual Base Pointer In-Reply-To: References: <20021212210640.GA19686@box5.net> Message-ID: <20021212234133.GB20190@box5.net> If I take out the no_init I can no longer compile because of the abstract member function. Perhaps I need to be using a CVS copy of boost? Here is the complete error: /opt/boost-gcc-3.2/include/boost/python/class.hpp: In constructor `boost::python::detail::assert_default_constructible::assert_default_constructible() [with T = A]': /opt/boost-gcc-3.2/include/boost/python/class.hpp:433: instantiated from `boost::python::class_::class_(const char*, const char*) [with T = A, X1 = boost::noncopyable, X2 = boost::shared_ptr, X3 = boost::python::detail::not_specified]' testMOD.cpp:25: instantiated from here /opt/boost-gcc-3.2/include/boost/python/class.hpp:101: cannot allocate an object of type `A' /opt/boost-gcc-3.2/include/boost/python/class.hpp:101: because the following virtual functions are abstract: testMOD.cpp:7: virtual void A::onCommand() --temas On Thu, Dec 12, 2002 at 06:10:18PM -0500, David Abrahams wrote: > Thomas Muldowney writes: > > > I'm trying to implement an event listener class from my C++ library so > > that python scripts can override it and get the events delivered to them > > in the script. After reading the docs it all seemed possible and easy > > to do. > > > > > BOOST_PYTHON_MODULE(testMOD) > > { > > class_ > boost::shared_ptr >("A", no_init); > strike no_init here------------------^^^^^^^ > You don't really need shared_ptr; but it's OK. > > > def("test_Aptr", test_Aptr); > > } > > > > > > Python test script: > > from testMOD import * > > > > class MyA(A): > > ## Don't get yelled at because we pass off to the non existant internal > > ## constructor > > def __init__(self): > > You need to call the base class __init__ here to create the C++ > instance. Or you can do it the easy way; just remove the __init__ > function here. > > > pass > > > def onCommand(self): > > print "We got a command" > > > > a = MyA() > > test_Aptr(a) > > > > Output running it: > > $ python test_ptr.py > > Traceback (most recent call last): > > File "test_ptr.py", line 12, in ? > > test_Aptr(a) > > TypeError: bad argument type for built-in operation > > > > > > I really do love everything, this has just been giving me a headache =) > > I love everything too! > > -- > David Abrahams > dave at boost-consulting.com * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dave at boost-consulting.com Fri Dec 13 00:45:51 2002 From: dave at boost-consulting.com (David Abrahams) Date: Thu, 12 Dec 2002 18:45:51 -0500 Subject: [C++-sig] multiply defined to_python_converter In-Reply-To: ("Langston, Matthew David"'s message of "Thu, 12 Dec 2002 12:54:58 -0800") References: Message-ID: "Langston, Matthew David" writes: > I'm not sure I understood the case for why two extension modules > need separate copies of a static member of a class template. Is this > an intenal Boost.Python implementation issue that is required to > implement your three-point plan above? Yes. > Or, does it relate to user-written to_python_converters? Not really. > Based on my use-case, the solution you and Ralf came up with > completely solves my problem. So, how does it sound? Sounds perfect > to me. Good to know. FWIW, it doesn't solve the compiler interoperability problem. I'm not sure what the best answer for that would be. -- David Abrahams dave at boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution From beazley at cs.uchicago.edu Fri Dec 13 03:18:47 2002 From: beazley at cs.uchicago.edu (David Beazley) Date: Thu, 12 Dec 2002 20:18:47 -0600 (CST) Subject: [C++-sig] Re: Do SWIP, SIP have a "cross-module" feature? (Ralf W. Grosse-Kunstleve) In-Reply-To: <20021212234300.18336.64819.Mailman@mail.python.org> References: <20021212234300.18336.64819.Mailman@mail.python.org> Message-ID: <15865.17287.703256.977636@gargoyle.cs.uchicago.edu> > > Thanks for the reply! Based on these hints I finally found the corresponding > SWIG documentation ( http://www.swig.org/Doc1.1/HTML/Advanced.html ). > > I see that linking with the static runtime is a simple way of avoiding any > cross-module type conversion conflicts. The more interesting case however is if > there are two SWIG-based multi-extension-module packages where all modules are > linked against the central shared runtime (libswigpy.so). If package A > registers conversions for, say, std::vector, and package B registers > different conversions for the same type, how does SWIG resolve the ambiguity? > Modules don't register "conversions" in SWIG so I'm not entirely sure what you're talking about here. The shared runtime is only used to manage cross-module type names (typedef, inheritance across modules, etc.). There's a big difference between a typename (a string) and a conversion (code). If two modules have different conversions for the same type, that's no big deal for SWIG. Of course, the end result might be confusing for the user (types in one module might produce conversion errors in the other module). However, that's a programmer problem, not a SWIG problem. Cheers, Dave From wtrenker at hotmail.com Fri Dec 13 07:12:26 2002 From: wtrenker at hotmail.com (William Trenker) Date: Thu, 12 Dec 2002 22:12:26 -0800 Subject: [C++-sig] Possible overload<> template for class members Message-ID: I've been getting familiar with wrapping overloaded C++ class methods for Python using this syntax: using namespace fltk; using namespace boost::python; BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(show_noArgs, show, 0, 0) BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(show_pWindow, show, 1, 1) BOOST_PYTHON_MODULE(byFLTK) { class_("Window", init()) .def("show", (void(Window::*)())0, show_noArgs()) .def("show", (void(Window::*)(const Window*))0, show_pWindow()) ; } (Like most GUI's FLTK has many overloaded methods such as window->show() or window->show(parent).) It took me a lot of digging to get BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS() and the function casts in the .def's figured out. But it works just fine. I don't know b::p well enough yet to submit proposed changes, but I was wondering if it would be possible to have a template, possibly called "overload", that works for overloded class members like the init<> template does for overloaded constructors? Maybe something like this: using namespace fltk; BOOST_PYTHON_MODULE(byFLTK) { class_("Window", init()) .def("show", overload(), &Window::show) .def("show", overload(), &Window.show) ; } Of course, unlike constructors, a return type has to be provided for member functions; so I've just thrown that in as the first parameter in overload<>. Is something like this even possible? Cheers, Bill _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From rwgk at yahoo.com Fri Dec 13 07:47:15 2002 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 12 Dec 2002 22:47:15 -0800 (PST) Subject: [C++-sig] Possible overload<> template for class members In-Reply-To: Message-ID: <20021213064715.29207.qmail@web20209.mail.yahoo.com> --- William Trenker wrote: > .def("show", overload(), &Window::show) > .def("show", overload(), &Window.show) That looks just like my old "plan A" :-) > Is something like this even possible? David kept claiming the answer is no, because in C++ you cannot take the "address" of a family over overloaded functions. If Window.show has overloads the compiler has no way of knowing which one you mean if you just type &Window.show. You have to have an associated cast, our you have to go through a thin wrapper. This limitation forced us to come up with "plan B": the BOOST_PYTHON_FUNCTION_OVERLOADS and BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macros. Ralf __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From agurtovoy at meta-comm.com Fri Dec 13 09:44:44 2002 From: agurtovoy at meta-comm.com (Aleksey Gurtovoy) Date: Fri, 13 Dec 2002 02:44:44 -0600 Subject: [C++-sig] Possible overload<> template for class members Message-ID: Ralf W. Grosse-Kunstleve wrote: > --- William Trenker wrote: > > .def("show", overload

Building Using the Microsoft Visual C++ IDE

Using the IDE for you own projects