From divinekid at gmail.com Sun Aug 2 07:45:11 2009 From: divinekid at gmail.com (Haoyu Bai) Date: Sun, 2 Aug 2009 13:45:11 +0800 Subject: [C++-sig] boost::python::str and Python's str and unicode types In-Reply-To: <446E8416AAF61D47B271B4E2FAE19BE66B5A63@svgw2k15.roxardomain.roxar.com> References: <446E8416AAF61D47B271B4E2FAE19BE66B5A33@svgw2k15.roxardomain.roxar.com> <4A688025.3000007@sympatico.ca> <446E8416AAF61D47B271B4E2FAE19BE66B5A63@svgw2k15.roxardomain.roxar.com> Message-ID: <3eb99a590908012245x12ece038xebc6e702750f6f05@mail.gmail.com> On Tue, Jul 28, 2009 at 10:11 PM, Robert Smallshire wrote: > >> On 07/23/2009 10:17 AM, Robert Smallshire wrote: >> > Hello, >> > >> > I'm looking for some confirmation that my understanding of what >> > boost.python is doing is correct. >> > >> > > From what I understand boost::python::str represents the str >> > (PyStringObject) type in Python. ?Unless I'm missing >> something, here >> > doesn't seem to be anything like boost::python::unicode >> representing >> > the unicode type (PyUnicodeObject). >> > >> > Boost.Python does have a built-in conversion from std::wstring to >> > object, but this creates a str in Python, so presumably >> there is some >> > (lossy?) decoding going on here. >> > >> > It seems that to directly create a PyUnicodeObject from C++ I will >> > need to do one or more of the following: >> > >> > 1) Directly use the Python C API to create and manipulate >> > PyUnicodeObject. >> > 2) Create my own subclass of boost::python::object called >> for example >> > 'unicode', which would be similar to the str class provided >> out of the >> > box, but would use PyUnicodeObject underneath and deal with wchar_t >> > rather than char. > > I have modified my local build of boost.python to include a > boost::python::unicode class, together with appropriate conversions from > wchar, const wchar_t* and std::wstring, together with additional tests > in the boost.python test suite. ?As you would expect, the code is > closely derived from the existing boost::python::str code but uses the > Python C API for PyUnicode_Type rather than PyString_Type. There are no > breaking changes to the existing boost.python API. > > I'd like to contribute these changes back to boost.python so they can be > hopefully integrated into future official Boost releases. ?What is the > procedure for this? ?Where do I start? > > Cheers, > > Robert Smallshire > > DISCLAIMER: > This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > Hi, Sorry for the delayed reply because I was busy on some other stuff last week. Currently the unicode support I implemented for Python 3 contains some converters for PyUnicode and C++ string types, and a boost::python::str class that conditionally call PyUnicode API in Python 3 or PyString API in Python 2. So a boost::python::unicode type would be very useful for Python 2. And for Python 3, we might need to rename the new "unicode" class to "str", and the old "str" class to "bytes", in order to reflect the change of Python. I'd happy to help to integrate and test it if send your code to the boost trac. Thank you! -- Haoyu Bai School of Computing, National University of Singapore. From divinekid at gmail.com Sun Aug 2 17:44:22 2009 From: divinekid at gmail.com (Haoyu Bai) Date: Sun, 2 Aug 2009 23:44:22 +0800 Subject: [C++-sig] Details of Boost.Python Py_Finalize issue? Message-ID: <3eb99a590908020844i1e775d80v28ce94546486d952@mail.gmail.com> Hello, As suggested by Stefan, I'm looking into the Boost.Python Py_Finalize issue. According to Boost.Python manual, the issue is: "Currently Boost.Python has several global (or function-static) objects whose existence keeps reference counts from dropping to zero until the Boost.Python shared object is unloaded. This can cause a crash because when the reference counts do go to zero, there's no interpreter. In order to make it safe to call PyFinalize() we must register an atexit routine which destroys these objects and releases all Python reference counts so that Python can clean them up while there's still an interpreter." However, until now I can't reproduce the problem. I tried to modify the exec.cpp in BPL test suite to call Py_Initialize and Py_Finalize many times in a loop ( http://pastebin.com/f77279354 ), and also tried examples provided in some report like this: http://d.hatena.ne.jp/floth/20090525/1243247990 . But neither of them can cause a crash or observable memory leak on my machine (Arch Linux with gcc 4.4, Python 2.6 and Boost 1.39). I also checked BPL source code, but can't spot out any suspicious code that may cause problems. So could anyone share your experience with this issue, provide some test case or anymore information about this issue? I will try to solve it. Thank you! -- Haoyu Bai School of Computing, National University of Singapore. From Robert.Smallshire at roxar.com Mon Aug 3 10:27:38 2009 From: Robert.Smallshire at roxar.com (Robert Smallshire) Date: Mon, 3 Aug 2009 10:27:38 +0200 Subject: [C++-sig] boost::python::str and Python's str and unicode types References: <446E8416AAF61D47B271B4E2FAE19BE66B5A33@svgw2k15.roxardomain.roxar.com><4A688025.3000007@sympatico.ca><446E8416AAF61D47B271B4E2FAE19BE66B5A63@svgw2k15.roxardomain.roxar.com> <3eb99a590908012245x12ece038xebc6e702750f6f05@mail.gmail.com> Message-ID: <446E8416AAF61D47B271B4E2FAE19BE65E6DD2@svgw2k15.roxardomain.roxar.com> ________________________________ From: cplusplus-sig-bounces+robert.smallshire=roxar.com at python.org on behalf of Haoyu Bai Sent: Sun 8/2/2009 07:45 To: Development of Python/C++ integration Subject: Re: [C++-sig] boost::python::str and Python's str and unicode types On Tue, Jul 28, 2009 at 10:11 PM, Robert Smallshire wrote: > >> On 07/23/2009 10:17 AM, Robert Smallshire wrote: >> > Hello, >> > >> > I'm looking for some confirmation that my understanding of what >> > boost.python is doing is correct. >> > >> > > From what I understand boost::python::str represents the str >> > (PyStringObject) type in Python. Unless I'm missing >> something, here >> > doesn't seem to be anything like boost::python::unicode >> representing >> > the unicode type (PyUnicodeObject). >> > >> > Boost.Python does have a built-in conversion from std::wstring to >> > object, but this creates a str in Python, so presumably >> there is some >> > (lossy?) decoding going on here. >> > >> > It seems that to directly create a PyUnicodeObject from C++ I will >> > need to do one or more of the following: >> > >> > 1) Directly use the Python C API to create and manipulate >> > PyUnicodeObject. >> > 2) Create my own subclass of boost::python::object called >> for example >> > 'unicode', which would be similar to the str class provided >> out of the >> > box, but would use PyUnicodeObject underneath and deal with wchar_t >> > rather than char. > > I have modified my local build of boost.python to include a > boost::python::unicode class, together with appropriate conversions from > wchar, const wchar_t* and std::wstring, together with additional tests > in the boost.python test suite. As you would expect, the code is > closely derived from the existing boost::python::str code but uses the > Python C API for PyUnicode_Type rather than PyString_Type. There are no > breaking changes to the existing boost.python API. > > I'd like to contribute these changes back to boost.python so they can be > hopefully integrated into future official Boost releases. What is the > procedure for this? Where do I start? > > Cheers, > > Robert Smallshire > > DISCLAIMER: > This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > Hi, Sorry for the delayed reply because I was busy on some other stuff last week. Currently the unicode support I implemented for Python 3 contains some converters for PyUnicode and C++ string types, and a boost::python::str class that conditionally call PyUnicode API in Python 3 or PyString API in Python 2. So a boost::python::unicode type would be very useful for Python 2. And for Python 3, we might need to rename the new "unicode" class to "str", and the old "str" class to "bytes", in order to reflect the change of Python. I'd happy to help to integrate and test it if send your code to the boost trac. Thank you! -- Haoyu Bai School of Computing, National University of Singapore. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig Hi Bayou, I should be able to get around to adding the boost::python::unicode patches to Trac this week. I have also added converters to/from std::wstring and const wchar_t*. Its getting some testing in a commercial development project this week, so hopefully most of the bugs will have been squashed by the time I submit the patches. Cheers! Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 7240 bytes Desc: not available URL: From Robert.Smallshire at roxar.com Tue Aug 4 10:37:28 2009 From: Robert.Smallshire at roxar.com (Robert Smallshire) Date: Tue, 4 Aug 2009 10:37:28 +0200 Subject: [C++-sig] boost::python::str and Python's str and unicode types In-Reply-To: <446E8416AAF61D47B271B4E2FAE19BE65E6DD2@svgw2k15.roxardomain.roxar.com> References: <446E8416AAF61D47B271B4E2FAE19BE66B5A33@svgw2k15.roxardomain.roxar.com><4A688025.3000007@sympatico.ca><446E8416AAF61D47B271B4E2FAE19BE66B5A63@svgw2k15.roxardomain.roxar.com> <3eb99a590908012245x12ece038xebc6e702750f6f05@mail.gmail.com> <446E8416AAF61D47B271B4E2FAE19BE65E6DD2@svgw2k15.roxardomain.roxar.com> Message-ID: <446E8416AAF61D47B271B4E2FAE19BE66B5A8C@svgw2k15.roxardomain.roxar.com> On Tue, Jul 28, 2009 at 10:11 PM, Robert Smallshire wrote: > I have modified my local build of boost.python to include a > boost::python::unicode class, together with appropriate conversions from > wchar_t, const wchar_t* and std::wstring... During testing we have encountered issues with the difference in size of wchar_t and Py_UNICODE. Windows : sizeof(wchar_t) == sizeof(Py_UNICODE) == 2 Linux : sizeof(wchar_t) == 4 != sizeof(Py_UNICODE) == 2 assuming a UCS-2 build of Python which is the default. If Python is built with UCS-4 support then I believe Py_UNICODE and wchar_t will become compatible on Linux, but I'm not sure what the implications are for compatibility of Unicode string pickles, for example, between UCS-2 and UCS-4 builds of Python. Unfortunately, extract seems to be problematic to implement in a portable manner because of these size differences. I have identified the following options: 1) Don't support extract at all. There are no portability problems, but we have reduced functionality and break the symmetry between boost::python::str and boost::python::unicode behaviour. 2) Only support extract on platforms where sizeof(wchar_t) == sizeof(Py_UNICODE) where the PyUnicode_AsUnicode function can be used to return a pointer to Python's internal buffer. This has the API usability advantage of being symmetrical with how extract works in boost.python today on platforms that support it. However, this makes writing portable code for clients awkward. This is what my current implementation does, and its broken on Linux. 3) Implement extract such that it always copies the data from the Py_UNICODE buffer into a new wchar_t buffer using PyUnicode_AsWideChar under the hood. The caller is then responsible for managing the lifetime of the buffer using delete [] or boost::shared_array. This is how the extract is implemented which works without difficulty. However, this breaks the symmetry with extract is a non-obvious way that would need to be prominently documented. I suggest this approach would be likely to lead to quite leaky usage of the API by unwary clients, especially when porting code to Unicode strings. 4) #ifdef between (2) and (3) above depending on whether sizeof(wchar_t) == sizeof(Py_UNICODE). Combines all the bad characteristics of the above. There may, of course, be other options. If the data needs to be copied into a new buffer of wchar_t, the lifetime of which needs to be managed by the client, that pretty much describes the raison d'?tre of std::wstring, so my current preference is for option (1). If we did this, we'd still be able to construct boost::python::unicode instances from const wchar_t*, but would only be able to extract them as std::wstring. I'm open to persuasion about the right way forward... Thanks in advance for any comments or suggestions, and also to the people who have expressed interest in these patches off list. Regards, Rob Smallshire Roxar Software Solutions DISCLAIMER: This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. From jvansanten at gmail.com Tue Aug 4 15:23:06 2009 From: jvansanten at gmail.com (Jakob van Santen) Date: Tue, 4 Aug 2009 15:23:06 +0200 Subject: [C++-sig] Keyed properties? Message-ID: <27912999-599F-49F9-BDB5-4E515F534B20@gmail.com> Hello, I'm in the process of hiding the unnecessarily verbose parts of a C++ interface behind Python properties, and I've run in to a slight problem. We have a bunch of classes that expose private std::vectors via Get(int index) and Set(int index, value_type& val) methods. Ideally, I'd like to replace thingy.GetATWDGain(1) thingy.SetATWDGain(1, 254.5) with thingy.atwd_gain[1] thingy.atwd_gain[1] = 254.5 I know how I would solve this in pure Python (something similar to this: http://code.activestate.com/recipes/440514/), but I'm wondering if there's a clever way to do this in Boost.Python without messing around with the library itself. If anyone has done this already, I'd be curious to know how. Cheers, Jakob van Santen From Matthew.Scouten at tradingtechnologies.com Tue Aug 4 15:44:12 2009 From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT)) Date: Tue, 4 Aug 2009 08:44:12 -0500 Subject: [C++-sig] Keyed properties? In-Reply-To: <27912999-599F-49F9-BDB5-4E515F534B20@gmail.com> References: <27912999-599F-49F9-BDB5-4E515F534B20@gmail.com> Message-ID: <32490DFF7774554A85D65D23A9F0F9380B1C34A0@chiex01> You can solve it pretty much the same way. Expose a function __*etitem__. It would look something like this: void set(thingy_t thingy&, int index, value_type& val){...} value_type get(const thingy_t thingy&, int index ){...} And then you export them in the class_ exposer: class_< thingy_t >("thingy_t") .def("__getstate__", &get) .def("__setstate__", &set) One wrinkle to watch out for: remember not to name the c++ functions starting with '__' Initial double underscores are reserved for the compiler. -----Original Message----- From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at py thon.org] On Behalf Of Jakob van Santen Sent: Tuesday, August 04, 2009 8:23 AM To: cplusplus-sig at python.org Subject: [C++-sig] Keyed properties? Hello, I'm in the process of hiding the unnecessarily verbose parts of a C++ interface behind Python properties, and I've run in to a slight problem. We have a bunch of classes that expose private std::vectors via Get(int index) and Set(int index, value_type& val) methods. Ideally, I'd like to replace thingy.GetATWDGain(1) thingy.SetATWDGain(1, 254.5) with thingy.atwd_gain[1] thingy.atwd_gain[1] = 254.5 I know how I would solve this in pure Python (something similar to this: http://code.activestate.com/recipes/440514/), but I'm wondering if there's a clever way to do this in Boost.Python without messing around with the library itself. If anyone has done this already, I'd be curious to know how. Cheers, Jakob van Santen _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig From divinekid at gmail.com Tue Aug 4 17:23:55 2009 From: divinekid at gmail.com (Haoyu Bai) Date: Tue, 4 Aug 2009 23:23:55 +0800 Subject: [C++-sig] boost::python::str and Python's str and unicode types In-Reply-To: <446E8416AAF61D47B271B4E2FAE19BE66B5A8C@svgw2k15.roxardomain.roxar.com> References: <446E8416AAF61D47B271B4E2FAE19BE66B5A33@svgw2k15.roxardomain.roxar.com> <4A688025.3000007@sympatico.ca> <446E8416AAF61D47B271B4E2FAE19BE66B5A63@svgw2k15.roxardomain.roxar.com> <3eb99a590908012245x12ece038xebc6e702750f6f05@mail.gmail.com> <446E8416AAF61D47B271B4E2FAE19BE65E6DD2@svgw2k15.roxardomain.roxar.com> <446E8416AAF61D47B271B4E2FAE19BE66B5A8C@svgw2k15.roxardomain.roxar.com> Message-ID: <3eb99a590908040823n245b6f47gaf6f8d4cf37851b0@mail.gmail.com> On Tue, Aug 4, 2009 at 4:37 PM, Robert Smallshire wrote: > > > On Tue, Jul 28, 2009 at 10:11 PM, Robert > Smallshire wrote: > >> I have modified my local build of boost.python to include a >> boost::python::unicode class, together with appropriate conversions from >> wchar_t, const wchar_t* and std::wstring... > > During testing we have encountered issues with the difference in size of wchar_t and Py_UNICODE. > > Windows : sizeof(wchar_t) == sizeof(Py_UNICODE) == 2 > Linux ? : sizeof(wchar_t) == 4 != sizeof(Py_UNICODE) == 2 > > assuming a UCS-2 build of Python which is the default. If Python is built with UCS-4 support then I believe Py_UNICODE and wchar_t will become compatible on Linux, but I'm not sure what the implications are for compatibility of Unicode string pickles, for example, between UCS-2 and UCS-4 builds of Python. > > Unfortunately, extract seems to be problematic to implement in a portable manner because of these size differences. ?I have identified the following options: > > 1) Don't support extract at all. There are no portability problems, but we have reduced functionality and break the symmetry between boost::python::str and boost::python::unicode behaviour. > > 2) Only support extract on platforms where sizeof(wchar_t) == sizeof(Py_UNICODE) where the PyUnicode_AsUnicode function can be used to return a pointer to Python's internal buffer. ?This has the API usability advantage of being symmetrical with how extract works in boost.python today on platforms that support it. However, this makes writing portable code for clients awkward. This is what my current implementation does, and its broken on Linux. > > 3) Implement extract such that it always copies the data from the Py_UNICODE buffer into a new wchar_t buffer using PyUnicode_AsWideChar under the hood. ?The caller is then responsible for managing the lifetime of the buffer using delete [] or boost::shared_array. ?This is how the extract is implemented which works without difficulty. ?However, this breaks the symmetry with extract is a non-obvious way that would need to be prominently documented. ?I suggest this approach would be likely to lead to quite leaky usage of the API by unwary clients, especially when porting code to Unicode strings. > > 4) #ifdef between (2) and (3) above depending on whether sizeof(wchar_t) == sizeof(Py_UNICODE). ?Combines all the bad characteristics of the above. > > There may, of course, be other options. > > If the data needs to be copied into a new buffer of wchar_t, the lifetime of which needs to be managed by the client, that pretty much describes the raison d'?tre of std::wstring, so my current preference is for option (1). If we did this, we'd still be able to construct boost::python::unicode instances from const wchar_t*, but would only be able to extract them as std::wstring. ? I'm open to persuasion about the right way forward... > > Thanks in advance for any comments or suggestions, and also to the people who have expressed interest in these patches off list. > > Regards, > > Rob Smallshire > Roxar Software Solutions > > > > DISCLAIMER: > This message contains information that may be privileged or confidential and is the property of the Roxar Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > There could be an option similar to your 3) but still keep the memory managed at the Python side. The trick is, there is a "PyObject *defenc" field in the PyUnicodeObject struct, which can be seen as an internal object attached to and managed by PyUnicode. This field is being used as an object of cached UTF-8 encoded PyString of the PyUnicode object, by some Python API. For example, by PyUnicode_AsString (_PyUnicode_AsString in Python 3, it changed to a internal API). Thus, this object is managed by the PyUnicode object and will be destroyed when the PyUnicode destroyed. So we may hack this field to inject an object which storing a wchar_t* and meanwhile managed by Python. This can be implemented by inherit PyString with an additional field. But, eh, this sounds a bit crazy. :p Anyway, for pointers like const wchar_t *, boost::python requires a "lvalue converter", but when we create new object in the converter, it no longer actually a lvalue converter. That would be a bit strange. So I think at now just have a unicode implementation without const wchar_t * converter is ok, as your option 1). We may have it implemented in future. Just some my thoughts. Regards, Haoyu Bai School of Computing, National University of Singapore. From lists_ravi at lavabit.com Wed Aug 5 04:33:39 2009 From: lists_ravi at lavabit.com (Ravi) Date: Tue, 4 Aug 2009 22:33:39 -0400 Subject: [C++-sig] Details of Boost.Python Py_Finalize issue? In-Reply-To: <3eb99a590908020844i1e775d80v28ce94546486d952@mail.gmail.com> References: <3eb99a590908020844i1e775d80v28ce94546486d952@mail.gmail.com> Message-ID: <200908042233.39582.lists_ravi@lavabit.com> On Sunday 02 August 2009 11:44:22 Haoyu Bai wrote: > So could anyone share your experience with this issue, provide some > test case or anymore information about this issue? I will try to solve > it. I haven't been able to spend any time on this. But the general approach I wanted to check is as follows: Test 1 (to check registry operation): 1. Use an example which embeds (not extends) python. 2. Register a type X to be converted to C++ type XC. 3. Perform some operations to verify that step 2 works. 4. Call PyFinalize. 5. Restart python vising PyInit... 6. Check that X does not convert to XC. Test 2 (to check object cleanup): 1. Hold weak pointers to some shared_ptr objects exposed to python. 2. Call PyFinalize. 3. Ensure that all the weak_ptrs point to deleted objects. Let me think about this some more. Please try pinging Dave A directly to make sure he has no tests for you to try. Regards, Ravi From daniel_james at fmail.co.uk Wed Aug 5 20:47:58 2009 From: daniel_james at fmail.co.uk (Daniel James) Date: Wed, 5 Aug 2009 19:47:58 +0100 Subject: [C++-sig] Documentation bug Message-ID: Hi, Trac ticket 1890, 'Missing parameters in example code' looks like a pretty trivial fix, if someone can confirm that it's correct, I'll make the change if no one else can. https://svn.boost.org/trac/boost/ticket/1890 > On the page: > > http://www.boost.org/doc/libs/1_35_0/libs/python/doc/tutorial/doc/html/python/embedding.html > > object ignored = exec("hello = file('hello.txt', 'w')\n" > > "hello.write('Hello world!')\n" > "hello.close()", main_namespace); > > should be: > > object ignored = exec("hello = file('hello.txt', 'w')\n" > > "hello.write('Hello world!')\n" > "hello.close()", main_namespace, main_namespace); thanks, Daniel From divinekid at gmail.com Fri Aug 7 04:16:59 2009 From: divinekid at gmail.com (Haoyu Bai) Date: Fri, 7 Aug 2009 10:16:59 +0800 Subject: [C++-sig] Details of Boost.Python Py_Finalize issue? In-Reply-To: <200908042233.39582.lists_ravi@lavabit.com> References: <3eb99a590908020844i1e775d80v28ce94546486d952@mail.gmail.com> <200908042233.39582.lists_ravi@lavabit.com> Message-ID: <3eb99a590908061916w6af8ffecj47f4503262e57f1@mail.gmail.com> On Wed, Aug 5, 2009 at 10:33 AM, Ravi wrote: > On Sunday 02 August 2009 11:44:22 Haoyu Bai wrote: >> So could anyone share your experience with this issue, provide some >> test case or anymore information about this issue? I will try to solve >> it. > > I haven't been able to spend any time on this. But the general approach I > wanted to check is as follows: > > Test 1 (to check registry operation): > 1. Use an example which embeds (not extends) python. > 2. Register a type X to be converted to C++ type XC. > 3. Perform some operations to verify that step 2 works. > 4. Call PyFinalize. > 5. Restart python vising PyInit... > 6. Check that X does not convert to XC. > > Test 2 (to check object cleanup): > 1. Hold weak pointers to some shared_ptr objects exposed to python. > 2. Call PyFinalize. > 3. Ensure that all the weak_ptrs point to deleted objects. > > Let me think about this some more. Please try pinging Dave A directly to make > sure he has no tests for you to try. > > Regards, > Ravi > Hi, I have the attached file to check the two test cases you mentioned, or see it at here: http://pastebin.org/7108 The test #1 failed. Registered converters are not cleaned up during Py_Finalize. But test #2 not fail, shared_ptr object is properly destroyed. I think the registration issue is not hard to fix. But is the "crash" mentioned in BPL manual still valid? We still can't produce any crash. I'll check with Dave. Thanks! -- Haoyu Bai School of Computing, National University of Singapore. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_finalize.cpp Type: text/x-c++src Size: 1851 bytes Desc: not available URL: From lists_ravi at lavabit.com Fri Aug 7 05:16:13 2009 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 6 Aug 2009 23:16:13 -0400 Subject: [C++-sig] Details of Boost.Python Py_Finalize issue? In-Reply-To: <3eb99a590908061916w6af8ffecj47f4503262e57f1@mail.gmail.com> References: <3eb99a590908020844i1e775d80v28ce94546486d952@mail.gmail.com> <200908042233.39582.lists_ravi@lavabit.com> <3eb99a590908061916w6af8ffecj47f4503262e57f1@mail.gmail.com> Message-ID: <200908062316.13586.lists_ravi@lavabit.com> On Thursday 06 August 2009 22:16:59 Haoyu Bai wrote: > > Test 1 (to check registry operation): > > 1. Use an example which embeds (not extends) python. > > 2. Register a type X to be converted to C++ type XC. > > 3. Perform some operations to verify that step 2 works. > > 4. Call PyFinalize. > > 5. Restart python vising PyInit... > > 6. Check that X does not convert to XC. > > > > Test 2 (to check object cleanup): > > 1. Hold weak pointers to some shared_ptr objects exposed to python. > > 2. Call PyFinalize. > > 3. Ensure that all the weak_ptrs point to deleted objects. > > > I have the attached file to check the two test cases you mentioned, or > see it at here: http://pastebin.org/7108 > > The test #1 failed. Registered converters are not cleaned up during > Py_Finalize. But test #2 not fail, shared_ptr object is properly > destroyed. You rock. There are more cases where data ought to be cleaned up, but I forget now. Let me look at some old custom converter code this weekend before I come up with more tests. > I think the registration issue is not hard to fix. But is the "crash" > mentioned in BPL manual still valid? We still can't produce any crash. The only way I can think of for this to happen is if boost.python holds some reference to an object held by the python interpreter before PyFinalize was called. The only candidate I could find is the fundamental PyTypeObject used by boost.python but nothing popped out on a cursory look, but then I doubt anyone can find bugs in Dave's code upon cursory examination :-) I am not sure that I can spend enough time on this prior to the end of your GSOC period. Apologies. Regards, Ravi From razvan_76 at ymail.com Fri Aug 7 11:27:49 2009 From: razvan_76 at ymail.com (Razvan Yorik) Date: Fri, 7 Aug 2009 09:27:49 +0000 (GMT) Subject: [C++-sig] [Py++] RuntimeError: `Py++` is going to write different content to the same file Message-ID: <290163.20082.qm@web24612.mail.ird.yahoo.com> Hello, I have a problem wrapping the following header file using Py++. The class "Derived" defines a local typedef "Helper" which has different meanings for each template parameter "T". Wrapped header: ---------- test.h ---------- #ifndef TEST_H #define TEST_H template class Base{ public: }; template class Derived: public Base{ public: typedef Base Helper; }; #ifdef __GCCXML__ void instantiate(){ sizeof(Base); sizeof(Base); sizeof(Derived); sizeof(Derived); } #endif #endif ---------- end of test.h ---------- This leads to the error (full output log at the end of this email): RuntimeError: `Py++` is going to write different content to the same file(split/Helper.pypp.hpp). The following is a short list of possible explanations for this behaviour: * `Py++` bug, in this case, please report it * module_builder_t contains two or more classes with the same alias * module_builder_t contains two or more classes with the same wrapper alias Please carefully review `Py++` warning messages. It should contain an additional information. I tried to rename or exclude the "Helper" class from the wrapper, but the problem is, that it is not even in mb.classes(): >print [c.name for c in mb.classes()] ['Derived', 'Derived', 'Base', 'Base'] Is there a possibility to - rename the different Helpers to "HelperInt" and "HelperFloat" in the code generator or - apply minor changes to the header only for GCCXML, but without changing the classes (they are simplified from a bigger project!) - or to exclude the Helper class? I hope someone can suggest a solution or a workaround. Thank you Razvan Code generator: ---------- generate_code.py ---------- import os from pyplusplus import module_builder from pyplusplus.decl_wrappers import call_policies from pygccxml.declarations.matchers import access_type_matcher_t from pyplusplus import function_transformers as FT files=['test.H'] mb = module_builder.module_builder_t( files=files, define_symbols=[], include_paths=[] ) mb.build_code_creator( module_name='pytest' ) mb.code_creator.user_defined_directories.append( os.path.abspath('.') ) mb.split_module("split") mb.write_module( os.path.join( os.path.abspath('.'), 'generated.cpp' ) ) ---------- end of generate_code.py ---------- ---------- complete ouput ---------- $ python generate_code.py INFO Parsing source file "test.H" ... INFO gccxml cmd: /usr/local/bin/gccxml -I"." "test.H" -fxml="/tmp/tmpM2O_z-.xml" INFO GCCXML version - 0.9( 1.128 ) WARNING: Base [class] > warning W1047: There are two or more classes that use same alias("Helper"). Duplicated aliases causes few problems, but the main one is that some > of the classes will not be exposed to Python.Other classes : Base [class] WARNING: Base [class] > warning W1047: There are two or more classes that use same alias("Helper"). Duplicated aliases causes few problems, but the main one is that some > of the classes will not be exposed to Python.Other classes : Base [class] Traceback (most recent call last): File "generate_code.py", line 20, in mb.split_module("split") File "/usr/lib/python2.5/site-packages/pyplusplus/module_builder/boost_python_builder.py", line 373, in split_module , encoding=self.encoding) File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/__init__.py", line 37, in write_multiple_files mfs.write() File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/multiple_files.py", line 406, in write self.split_classes() File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/multiple_files.py", line 307, in split_classes map( self.split_class, class_creators ) File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/multiple_files.py", line 294, in split_class self.split_class_impl( class_creator ) File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/multiple_files.py", line 268, in split_class_impl , self.create_function_code( function_name ) ) ) File "/usr/lib/python2.5/site-packages/pyplusplus/file_writers/multiple_files.py", line 58, in write_file raise RuntimeError( os.linesep.join(msg) ) RuntimeError: `Py++` is going to write different content to the same file(split/Helper.pypp.hpp). The following is a short list of possible explanations for this behaviour: * `Py++` bug, in this case, please report it * module_builder_t contains two or more classes with the same alias * module_builder_t contains two or more classes with the same wrapper alias Please carefully review `Py++` warning messages. It should contain an additional information. ---------- end of output---------- From roman.yakovenko at gmail.com Fri Aug 7 20:05:16 2009 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Fri, 7 Aug 2009 21:05:16 +0300 Subject: [C++-sig] [Py++] RuntimeError: `Py++` is going to write different content to the same file In-Reply-To: <290163.20082.qm@web24612.mail.ird.yahoo.com> References: <290163.20082.qm@web24612.mail.ird.yahoo.com> Message-ID: <7465b6170908071105l5569e4dfo28a35fdc9ebd0b7f@mail.gmail.com> On Fri, Aug 7, 2009 at 12:27 PM, Razvan Yorik wrote: > > Hello, > I have a problem wrapping the following header file using Py++. The class "Derived" defines a local typedef "Helper" which has different meanings for each template parameter "T". > > Wrapped header: > ---------- test.h ---------- > #ifndef TEST_H > #define TEST_H > > template class Base{ > public: > }; > > template class Derived: public Base{ > public: > ? ?typedef Base Helper; > }; > > This leads to the error (full output log at the end of this email): > > RuntimeError: `Py++` is going to write different content to the same file(split/Helper.pypp.hpp). > The following is a short list of possible explanations for this behaviour: > * `Py++` bug, in this case, please report it > * module_builder_t contains two or more classes with the same alias > * module_builder_t contains two or more classes with the same wrapper alias > Please carefully review `Py++` warning messages. It should contain an additional information. > > I tried to rename or exclude the "Helper" class from the wrapper, but the problem is, that it is not even in mb.classes(): > This is because "Helper" is an alias. "Base" is illegal Python identifier, so Py++ has to build a legal one for you class. In this case it found that you call your class "Helper" and choose it as the alias >>print [c.name for c in mb.classes()] > ['Derived', 'Derived', 'Base', 'Base'] for cls in mb.classes(): print "full name: %s, alias: %s" % ( cls.decl_string, cls.alias ) > Is there a possibility to > - rename the different Helpers to "HelperInt" and "HelperFloat" in the code generator for cls in mb.classes(): cls.alias = 'helper_' + cls.split( '<' )[1].split('>' )[0] or > - apply minor changes to the header only for GCCXML, but without changing the classes (they are simplified from a bigger project!) > - or to exclude the Helper class? I suggest you to take a look on Py++ example. You will find the very useful. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From gelvaos at gmail.com Fri Aug 7 20:54:46 2009 From: gelvaos at gmail.com (Nodir GULYAMOV) Date: Fri, 07 Aug 2009 20:54:46 +0200 Subject: [C++-sig] How to correctly expose back shared_ptr-ed Python object to C++ Message-ID: <87ocqrxxjj.fsf@gmail.com> Hello All, I am trying to implement plug-ins system using BOOST Python but a little stuck. I've read documentation a couple of times and have feeling that missed something pretty simple. Below simplified version what I am trying to do: // abstract Base interface class class IBasePlugins { public: virtual ~IBasePlugins() {}; virtual bool canHandle(int type) = 0; virtual void handle() = 0; }; //some C++ internal plugin (no need to expose to python) class IntrPlugin : public IBasePlugins { public: IntrPlugin() : handle_type(1) {} bool canHandle(int type) { return type == handle_type; } void handle() { std::cout << "handle() from internal plugin" << std::endl; } private: int handle_type; }; // class to manage plug-ins typedef boost::shared_ptr PluginsPtrType; typedef vector VPluginsType; class PluginsMgr { public: static void register(PluginsPtrType plugin) { vplugins.puch_back(plugin); } static void run(int type) { VPluginsType::iterator it; for(it = vplugins.begin(); it != vplugins.end(); it++) if( (*it)->canHandle(type) ) (*it)->handle(); } private: VPluginsType vplugins; }; // export to python struct IBasePluginsWrap : public IBasePlugins { IBasePluginsWrap(PyObject* self_): self(self_) {} bool canHandle(int type) { return call_method< bool >(self, "canHandle", type); } void handle() { call_method< void >(self, "handle"); } PyObject* self; }; BOOST_PYTHON_MODULE(pyPlugins) { class_< IBasePlugins, IBasePluginsWrap, boost::noncopyable >("IBasePlugins") .def("canHandle", pure_virtual(&IBasePlugins::canHandle)) .def("handle", pure_virtual(&IBasePlugins::handle)) ; class_< PluginsMgr >("PluginsMgr") .def("registerPlugin", &PlgMgr::registerPlugin) .staticmethod("registerPlugin") .def("run", &PlgMgr::run) .staticmethod("run") ; register_ptr_to_python(); } Then I am using it from python as follows: from pyPlugins import * class PyTestPlugin(IBasePlugins): def __init__(self): self.handle_type = 2 def canHandle(self, type): return type == handle_type def handle(self): print "handle() from python plugin" pm = PluginsMgr() testplg = PyTestPlugin() pm.registerPlugin(testplg) And have error that C++ signature mismatch. Thank you in advance. I will really appreciate any help. Kind regards, Nodir From renatox at gmail.com Sat Aug 8 22:43:08 2009 From: renatox at gmail.com (Renato Araujo) Date: Sat, 8 Aug 2009 17:43:08 -0300 Subject: [C++-sig] How to correctly expose back shared_ptr-ed Python object to C++ In-Reply-To: <87ocqrxxjj.fsf@gmail.com> References: <87ocqrxxjj.fsf@gmail.com> Message-ID: <95291a80908081343x272925e1rb66def3ff242a95a@mail.gmail.com> Hi Nodir, I saw a problem in your exemple. But I did not know if is this your problem, but try call the base constructor in your "PyTestPlugin" constructor, like that: > class PyTestPlugin(IBasePlugins): > def __init__(self): IBasePlugins.__init__(self) <<<<<<<<<<<<<<< here this need be called explicitly > self.handle_type = 2 > def canHandle(self, type): > return type == handle_type > def handle(self): > print "handle() from python plugin" BR Renato Araujo Oliveira Filho On Fri, Aug 7, 2009 at 3:54 PM, Nodir GULYAMOV wrote: > Hello All, > I am trying to implement plug-ins system using BOOST Python but a little > stuck. I've read documentation a couple of times and have feeling that > missed something pretty simple. > Below simplified version what I am trying to do: > > // abstract Base interface class > class IBasePlugins > { > public: > ? ?virtual ~IBasePlugins() {}; > ? ?virtual bool canHandle(int type) = 0; > ? ?virtual void handle() = 0; > }; > > //some C++ internal plugin (no need to expose to python) > class IntrPlugin : public IBasePlugins > { > public: > ? ?IntrPlugin() : handle_type(1) {} > ? ?bool canHandle(int type) { > ? ? ? ? return type == handle_type; > ? ?} > ? ?void handle() { > ? ? ? ? std::cout << "handle() from internal plugin" << std::endl; > ? ?} > private: > ? ?int handle_type; > }; > > > // class to manage plug-ins > > typedef boost::shared_ptr PluginsPtrType; > typedef vector VPluginsType; > > class PluginsMgr > { > public: > ? ?static void register(PluginsPtrType plugin) { > ? ? ? ?vplugins.puch_back(plugin); > ? ?} > ? ?static void run(int type) { > ? ? ? VPluginsType::iterator it; > ? ? ? for(it = vplugins.begin(); it != vplugins.end(); it++) > ? ? ? ? ? if( (*it)->canHandle(type) ) (*it)->handle(); > ? ?} > private: > ? VPluginsType vplugins; > }; > > // export to python > struct IBasePluginsWrap : public IBasePlugins { > ? ? ? ?IBasePluginsWrap(PyObject* self_): self(self_) {} > ? ? ? ?bool canHandle(int type) { > ? ? ? ? ? ?return call_method< bool >(self, "canHandle", type); > ? ? ? ?} > ? ? ? ?void handle() { > ? ? ? ? ? ?call_method< void >(self, "handle"); > ? ? ? ?} > > ? ? ? ?PyObject* self; > }; > > BOOST_PYTHON_MODULE(pyPlugins) > { > ? ?class_< IBasePlugins, IBasePluginsWrap, boost::noncopyable >("IBasePlugins") > ? ? ? ?.def("canHandle", pure_virtual(&IBasePlugins::canHandle)) > ? ? ? ?.def("handle", pure_virtual(&IBasePlugins::handle)) > ? ? ? ?; > > ? ?class_< PluginsMgr >("PluginsMgr") > ? ? ? ?.def("registerPlugin", &PlgMgr::registerPlugin) > ? ? ? ?.staticmethod("registerPlugin") > ? ? ? ?.def("run", &PlgMgr::run) > ? ? ? ?.staticmethod("run") > ? ? ? ?; > > ? ?register_ptr_to_python(); > } > > > Then I am using it from python as follows: > > from pyPlugins import * > > class PyTestPlugin(IBasePlugins): > ? ? ?def __init__(self): > ? ? ? ? ?self.handle_type = 2 > ? ? ?def canHandle(self, type): > ? ? ? ? ?return type == handle_type > ? ? ?def handle(self): > ? ? ? ? ?print "handle() from python plugin" > > > pm = PluginsMgr() > testplg = PyTestPlugin() > pm.registerPlugin(testplg) > > And have error that C++ signature mismatch. > > Thank you in advance. I will really appreciate any help. > > Kind regards, > Nodir > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > From gelvaos at gmail.com Mon Aug 10 21:43:57 2009 From: gelvaos at gmail.com (Nodir GULYAMOV) Date: Mon, 10 Aug 2009 21:43:57 +0200 Subject: [C++-sig] How to correctly expose back shared_ptr-ed Python object to C++ In-Reply-To: <95291a80908081343x272925e1rb66def3ff242a95a@mail.gmail.com> (Renato Araujo's message of "Sat, 8 Aug 2009 17:43:08 -0300") References: <87ocqrxxjj.fsf@gmail.com> <95291a80908081343x272925e1rb66def3ff242a95a@mail.gmail.com> Message-ID: <8763cv4fpe.fsf@gmail.com> Hi Renato, I've really appreciated your answer. It's solved my issue. I will never find that I need to call base constructor explicitly. Thank you, Nodir Renato Araujo writes: > Hi Nodir, > > > I saw a problem in your exemple. But I did not know if is this your > problem, but try call the base constructor in your "PyTestPlugin" > constructor, like that: > >> class PyTestPlugin(IBasePlugins): >> def __init__(self): > IBasePlugins.__init__(self) <<<<<<<<<<<<<<< here this need > be called explicitly >> self.handle_type = 2 >> def canHandle(self, type): >> return type == handle_type >> def handle(self): >> print "handle() from python plugin" > > BR > Renato Araujo Oliveira Filho > > > > > On Fri, Aug 7, 2009 at 3:54 PM, Nodir GULYAMOV wrote: >> Hello All, >> I am trying to implement plug-ins system using BOOST Python but a little >> stuck. I've read documentation a couple of times and have feeling that >> missed something pretty simple. >> Below simplified version what I am trying to do: >> >> // abstract Base interface class >> class IBasePlugins >> { >> public: >> ? ?virtual ~IBasePlugins() {}; >> ? ?virtual bool canHandle(int type) = 0; >> ? ?virtual void handle() = 0; >> }; >> >> //some C++ internal plugin (no need to expose to python) >> class IntrPlugin : public IBasePlugins >> { >> public: >> ? ?IntrPlugin() : handle_type(1) {} >> ? ?bool canHandle(int type) { >> ? ? ? ? return type == handle_type; >> ? ?} >> ? ?void handle() { >> ? ? ? ? std::cout << "handle() from internal plugin" << std::endl; >> ? ?} >> private: >> ? ?int handle_type; >> }; >> >> >> // class to manage plug-ins >> >> typedef boost::shared_ptr PluginsPtrType; >> typedef vector VPluginsType; >> >> class PluginsMgr >> { >> public: >> ? ?static void register(PluginsPtrType plugin) { >> ? ? ? ?vplugins.puch_back(plugin); >> ? ?} >> ? ?static void run(int type) { >> ? ? ? VPluginsType::iterator it; >> ? ? ? for(it = vplugins.begin(); it != vplugins.end(); it++) >> ? ? ? ? ? if( (*it)->canHandle(type) ) (*it)->handle(); >> ? ?} >> private: >> ? VPluginsType vplugins; >> }; >> >> // export to python >> struct IBasePluginsWrap : public IBasePlugins { >> ? ? ? ?IBasePluginsWrap(PyObject* self_): self(self_) {} >> ? ? ? ?bool canHandle(int type) { >> ? ? ? ? ? ?return call_method< bool >(self, "canHandle", type); >> ? ? ? ?} >> ? ? ? ?void handle() { >> ? ? ? ? ? ?call_method< void >(self, "handle"); >> ? ? ? ?} >> >> ? ? ? ?PyObject* self; >> }; >> >> BOOST_PYTHON_MODULE(pyPlugins) >> { >> ? ?class_< IBasePlugins, IBasePluginsWrap, boost::noncopyable >("IBasePlugins") >> ? ? ? ?.def("canHandle", pure_virtual(&IBasePlugins::canHandle)) >> ? ? ? ?.def("handle", pure_virtual(&IBasePlugins::handle)) >> ? ? ? ?; >> >> ? ?class_< PluginsMgr >("PluginsMgr") >> ? ? ? ?.def("registerPlugin", &PlgMgr::registerPlugin) >> ? ? ? ?.staticmethod("registerPlugin") >> ? ? ? ?.def("run", &PlgMgr::run) >> ? ? ? ?.staticmethod("run") >> ? ? ? ?; >> >> ? ?register_ptr_to_python(); >> } >> >> >> Then I am using it from python as follows: >> >> from pyPlugins import * >> >> class PyTestPlugin(IBasePlugins): >> ? ? ?def __init__(self): >> ? ? ? ? ?self.handle_type = 2 >> ? ? ?def canHandle(self, type): >> ? ? ? ? ?return type == handle_type >> ? ? ?def handle(self): >> ? ? ? ? ?print "handle() from python plugin" >> >> >> pm = PluginsMgr() >> testplg = PyTestPlugin() >> pm.registerPlugin(testplg) >> >> And have error that C++ signature mismatch. >> >> Thank you in advance. I will really appreciate any help. >> >> Kind regards, >> Nodir >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> http://mail.python.org/mailman/listinfo/cplusplus-sig >> > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig From rwgk at yahoo.com Tue Aug 18 02:57:46 2009 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Mon, 17 Aug 2009 17:57:46 -0700 (PDT) Subject: [C++-sig] Documentation bug In-Reply-To: References: Message-ID: <458825.37771.qm@web111413.mail.gq1.yahoo.com> I verified that the example is fine and went ahead closing the ticket. Ralf ----- Original Message ---- From: Daniel James To: cplusplus-sig at python.org Sent: Wednesday, August 5, 2009 11:47:58 AM Subject: [C++-sig] Documentation bug Hi, Trac ticket 1890, 'Missing parameters in example code' looks like a pretty trivial fix, if someone can confirm that it's correct, I'll make the change if no one else can. https://svn.boost.org/trac/boost/ticket/1890 > On the page: > > http://www.boost.org/doc/libs/1_35_0/libs/python/doc/tutorial/doc/html/python/embedding.html > > object ignored = exec("hello = file('hello.txt', 'w')\n" > > "hello.write('Hello world!')\n" > "hello.close()", main_namespace); > > should be: > > object ignored = exec("hello = file('hello.txt', 'w')\n" > > "hello.write('Hello world!')\n" > "hello.close()", main_namespace, main_namespace); thanks, Daniel _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig From renatox at gmail.com Tue Aug 18 15:37:46 2009 From: renatox at gmail.com (Renato Araujo) Date: Tue, 18 Aug 2009 10:37:46 -0300 Subject: [C++-sig] PySide has been released Message-ID: <95291a80908180637m437d6ae4je6fb0d1e45977eb7@mail.gmail.com> Hi, The PySide team is pleased to announce the first public release of PySide: Python for Qt! PySide, its documentation, and developer resources are available at the project website, http://www.pyside.org . What is it? ----------- PySide is a project providing an LGPL'd set of Python bindings for the Qt framework. PySide already provides a full set of Qt bindings as well as automated binding generation tools. Since the whole toolset has been made available, the team expects PySide to be valuable not only to Qt software developers, but to people willing to create Python bindings to any Qt-based library, or to any C++ library in general. Although based on a different technical approach, PySide will initially be API-compatible with existing Python bindings for Qt. PySide is still a work in progress, and some work is still required to stabilize the codebase. This being said, the team believes it is already in a usable state, especially if an occasional rough edge and unpainted surface can be tolerated. Due to practical reasons, the initial development efforts have been focused on Linux, but the team hopes people to join in porting the code to other platforms and to further develop the bindings and tools. Regards and thanks for your support guys PySide team From bfitzpatrick at vtiinstruments.com Wed Aug 19 19:28:24 2009 From: bfitzpatrick at vtiinstruments.com (Ben Fitzpatrick) Date: Wed, 19 Aug 2009 12:28:24 -0500 Subject: [C++-sig] Pybindgen/pygccxml integration In-Reply-To: References: <4A40F01E.3030803@vtiinstruments.com> <4A41064B.7090300@vtiinstruments.com> <4A412895.90206@vtiinstruments.com> Message-ID: <27AD07BD25612C40AF5C78CB49D09B4967ADBC774C@34093-MBX-C08.mex07a.mlsrvr.com> Hi everyone, The messages below are from quite a bit ago. I didn?t respond then because the unit tests weren?t passing for me, and I wanted to try and make them pass?. But then I got pulled off on another project. I?ve recently had some time to work on this again, and I got all the tests involving annotations to work (there?s still a couple tests that don?t pass, involving get_simple_map, but they don?t look super-vital). I finally got my pure virtual class wrapped and compiled, and it is instantiatable and seems to work, but one of my functions is missing. Here?s the code: class pure_virtual_class { public: // -#- @foobaz(transfer_ownership=true, direction=out) -#- virtual int get_value(int* foobaz) = 0; virtual int set_value(int foobaz); // -#- @return(caller_owns_return=true) -#- static pure_virtual_class* Create(); virtual ~pure_virtual_class() {}; } class non_virtual_class : public pure_virtual_class { public: non_virtual_class(); ~non_virtual_class(); // -#- @foobaz(transfer_ownership=true, direction=out) -#- int get_value(int* foobaz); int set_value(int foobaz); private: int internal_state; int utility_function(int foobaz); } And the Create method does this: pure_virtual_class* pure_virtual_class::Create() { return static_cast(new non_virtual_class()); } So, I got rid of all the gccxml warnings on the code (except for the one indicating that the class pure_virtual_class was pure virtual?), and it compiles just fine, and the Create function even works? but the get_value function doesn?t appear when I dir the class. Set_value appears and seems to work, so why not get? Any ideas? I?m on a clean Debian Etch install (virtual machine), using GCC 4.3.2, Python 2.5.2, gccxml 0.9. Thanks, Ben Fitzpatrick From: cplusplus-sig-bounces+bfitzpatrick=vtiinstruments.com at python.org [mailto:cplusplus-sig-bounces+bfitzpatrick=vtiinstruments.com at python.org] On Behalf Of Gustavo Carneiro Sent: Tuesday, June 23, 2009 6:52 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Pybindgen/pygccxml integration 2009/6/23 Ben Fitzpatrick > Gustavo Carneiro wrote: 2009/6/23 Ben Fitzpatrick >> Thanks for the suggestions! I tried the first one, just as a test. I'd like to do the second programatically if I can, but I just wanted to make sure annotations were going to fix this. It still seems to be giving me the same error: (...)/pure_virtual.h:5: WrapperWarning: Parameter 'int * value' error (used in int pure_virtual_class::get_value(int * value) [member function]): virtual int get_value(int* value) = 0; Here is what I changed my code to: // -#- @value(transfer_ownership=true) -#- virtual int get_value(int* value)=0; Apart from the blank line, seems OK. Do you get a "unused annotation" warning? That's odd, there wasn't a blank line in my original email. There certainly isn't one in the file. I do not get an unused annotation warning, or anything to suggest it noticed my annotation in the slightest. I am using Python2.4 on Debian Etch, with Pygccxml 0.9.5. The Python's a bit old, but everything else has been compiled or installed manually. Well, with Python 2.5 it prints TypeConfigurationError('some message'), which is rather more helpful. You are not seeing the full error message, just the (vague) exception type. And did you run the unit tests (./waf check) ? If the unit tests pass, annotations supposedly are working... _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From eudoxos at arcig.cz Thu Aug 20 11:14:16 2009 From: eudoxos at arcig.cz (Vaclav Smilauer) Date: Thu, 20 Aug 2009 09:14:16 +0000 (UTC) Subject: [C++-sig] =?utf-8?q?please_add_python=3A=3Araw=5Fconstructor?= Message-ID: Hi, I am successfully using raw_constructor implementation found at http://markmail.org/message/s4ksg6nfspw2wxwd (in the attachment). Wouldn't it warrant consideration for inclusion into the official boost::python, to complement raw_function? Cheers, Vaclav From eudoxos at arcig.cz Thu Aug 20 11:10:57 2009 From: eudoxos at arcig.cz (Vaclav Smilauer) Date: Thu, 20 Aug 2009 09:10:57 +0000 (UTC) Subject: [C++-sig] =?utf-8?q?=5Bpy++=5D_AttributeError=3A_=27Boost=2EPytho?= =?utf-8?q?n=2EStaticProperty=27_object_attribute_=27=5F=5Fdoc=5F?= =?utf-8?q?=5F=27_is_read-only?= Message-ID: Hi everybody, I have a small wrapper for a few geometry classes generated; it works on boost 1.34--1.37. I tried to compile and run on boost 1.39 (Boost::python doesn't seem to be mentioned in changelogs for 1.38 or 1.39 though) and I am getting this error: Traceback (most recent call last): File "debian/yade-bzr1703-dbg/usr/lib/yade-bzr1703-dbg/gui/PythonUI_rc.py", line 11, in from miniWm3Wrap import * AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only I only googled the same error at http://de.pastebin.ca/1535109 (which concerns pySide), but no solution. What am I doing wrong? Thanks, Vaclav From gjcarneiro at gmail.com Thu Aug 20 13:01:28 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Thu, 20 Aug 2009 12:01:28 +0100 Subject: [C++-sig] Pybindgen/pygccxml integration In-Reply-To: <27AD07BD25612C40AF5C78CB49D09B4967ADBC774C@34093-MBX-C08.mex07a.mlsrvr.com> References: <4A40F01E.3030803@vtiinstruments.com> <4A41064B.7090300@vtiinstruments.com> <4A412895.90206@vtiinstruments.com> <27AD07BD25612C40AF5C78CB49D09B4967ADBC774C@34093-MBX-C08.mex07a.mlsrvr.com> Message-ID: I added your problem as unit test to pybindgen, but it just works as expected: http://bazaar.launchpad.net/~gjc/pybindgen/trunk/revision/681 2009/8/19 Ben Fitzpatrick > Hi everyone, > > > > The messages below are from quite a bit ago. I didn?t respond then because > the unit tests weren?t passing for me, and I wanted to try and make them > pass?. But then I got pulled off on another project. I?ve recently had some > time to work on this again, and I got all the tests involving annotations to > work (there?s still a couple tests that don?t pass, involving > get_simple_map, but they don?t look super-vital). > > > > I finally got my pure virtual class wrapped and compiled, and it is > instantiatable and seems to work, but one of my functions is missing. Here?s > the code: > > > > class pure_virtual_class > > { > > public: > > // -#- @foobaz(transfer_ownership=true, direction=out) -#- > > virtual int get_value(int* foobaz) = 0; > > virtual int set_value(int foobaz); > > > > // -#- @return(caller_owns_return=true) -#- > > static pure_virtual_class* Create(); > > virtual ~pure_virtual_class() {}; > > } > > > > class non_virtual_class : public pure_virtual_class > > { > > public: > > non_virtual_class(); > > ~non_virtual_class(); > > // -#- @foobaz(transfer_ownership=true, direction=out) -#- > > int get_value(int* foobaz); > > int set_value(int foobaz); > > > > private: > > int internal_state; > > int utility_function(int foobaz); > > } > > > > And the Create method does this: > > pure_virtual_class* pure_virtual_class::Create() > > { > > return static_cast(new non_virtual_class()); > > } > > > > So, I got rid of all the gccxml warnings on the code (except for the one > indicating that the class pure_virtual_class was pure virtual?), and it > compiles just fine, and the Create function even works? but the get_value > function doesn?t appear when I dir the class. Set_value appears and seems to > work, so why not get? Any ideas? > > > > I?m on a clean Debian Etch install (virtual machine), using GCC 4.3.2, > Python 2.5.2, gccxml 0.9. > > > > Thanks, > > Ben Fitzpatrick > > > > > > > > *From:* cplusplus-sig-bounces+bfitzpatrick=vtiinstruments.com at python.org[mailto: > cplusplus-sig-bounces+bfitzpatrick = > vtiinstruments.com at python.org] *On Behalf Of *Gustavo Carneiro > *Sent:* Tuesday, June 23, 2009 6:52 PM > *To:* Development of Python/C++ integration > *Subject:* Re: [C++-sig] Pybindgen/pygccxml integration > > > > > > 2009/6/23 Ben Fitzpatrick > > Gustavo Carneiro wrote: > > > > 2009/6/23 Ben Fitzpatrick bfitzpatrick at vtiinstruments.com>> > > Thanks for the suggestions! > > I tried the first one, just as a test. I'd like to do the second > programatically if I can, but I just wanted to make sure > annotations were going to fix this. It still seems to be giving me > the same error: > (...)/pure_virtual.h:5: WrapperWarning: Parameter 'int * value' > error (used in int pure_virtual_class::get_value(int * value) > [member function]): > 0xb780326c> > > virtual int get_value(int* value) = 0; > > Here is what I changed my code to: > > // -#- @value(transfer_ownership=true) -#- > > virtual int get_value(int* value)=0; > > > Apart from the blank line, seems OK. Do you get a "unused annotation" > warning? > > > That's odd, there wasn't a blank line in my original email. There certainly > isn't one in the file. > I do not get an unused annotation warning, or anything to suggest it > noticed my annotation in the slightest. I am using Python2.4 on Debian Etch, > with Pygccxml 0.9.5. The Python's a bit old, but everything else has been > compiled or installed manually. > > > Well, with Python 2.5 it prints TypeConfigurationError('some message'), > which is rather more helpful. You are not seeing the full error message, > just the (vague) exception type. > > And did you run the unit tests (./waf check) ? If the unit tests pass, > annotations supposedly are working... > > > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > > > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwgk at yahoo.com Fri Aug 21 06:00:08 2009 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Thu, 20 Aug 2009 21:00:08 -0700 (PDT) Subject: [C++-sig] please add python::raw_constructor In-Reply-To: References: Message-ID: <253430.12195.qm@web111415.mail.gq1.yahoo.com> If someone develops this into a complete patch including unit test, Jamfile and updated documentation I'll test and add it to the svn. Ralf ----- Original Message ---- From: Vaclav Smilauer To: cplusplus-sig at python.org Sent: Thursday, August 20, 2009 2:14:16 AM Subject: [C++-sig] please add python::raw_constructor Hi, I am successfully using raw_constructor implementation found at http://markmail.org/message/s4ksg6nfspw2wxwd (in the attachment). Wouldn't it warrant consideration for inclusion into the official boost::python, to complement raw_function? Cheers, Vaclav From anderson.lizardo at openbossa.org Fri Aug 21 14:08:59 2009 From: anderson.lizardo at openbossa.org (Anderson Lizardo) Date: Fri, 21 Aug 2009 08:08:59 -0400 Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) Message-ID: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> I think it was not clear in the announcement, but PySide uses Boost.Python. And for it to work properly, we need a few patches that are already in Boost SVN trunk, but in none of the release branches. Therefore, is it possible to get these patches merged into the 1.40 release branch before the final release? That would make life a lot easier for other distros to try PySide without requiring to apply patches separately. The relevant commits are listed in http://www.pyside.org/downloads/, they are: Add generic call operator support. https://svn.boost.org/trac/boost/changeset/47846 Support C++ enums which have the same value. https://svn.boost.org/trac/boost/changeset/53660 Fix unsigned integer converters. https://svn.boost.org/trac/boost/changeset/54919 Fix unsigned integer converters (update). https://svn.boost.org/trac/boost/changeset/54923 IMHO these patches fix important bugs in Boost.Python, and the first two were in trunk even before the 1.39 release, but were never merged... Thanks in advance, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil From seefeld at sympatico.ca Fri Aug 21 14:54:05 2009 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 21 Aug 2009 08:54:05 -0400 Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> Message-ID: <4A8E98ED.5040202@sympatico.ca> Anderson, let me forward that mail to the main boost list, and ping Beman (release manager) and David (boost.python maintainer). Beman, David, if it's not too late, I may help merge trunk to the release branch. Let me know... Stefan On 08/21/2009 08:08 AM, Anderson Lizardo wrote: > I think it was not clear in the announcement, but PySide uses Boost.Python. > > And for it to work properly, we need a few patches that are already in > Boost SVN trunk, but in none of the release branches. > > Therefore, is it possible to get these patches merged into the 1.40 > release branch before the final release? That would make life a lot > easier for other distros to try PySide without requiring to apply > patches separately. > > The relevant commits are listed in http://www.pyside.org/downloads/, they are: > > Add generic call operator support. > https://svn.boost.org/trac/boost/changeset/47846 > Support C++ enums which have the same value. > https://svn.boost.org/trac/boost/changeset/53660 > Fix unsigned integer converters. > https://svn.boost.org/trac/boost/changeset/54919 > Fix unsigned integer converters (update). > https://svn.boost.org/trac/boost/changeset/54923 > > IMHO these patches fix important bugs in Boost.Python, and the first > two were in trunk even before the 1.39 release, but were never > merged... > > Thanks in advance, > -- ...ich hab' noch einen Koffer in Berlin... From rwgk at yahoo.com Fri Aug 21 23:44:37 2009 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 21 Aug 2009 14:44:37 -0700 (PDT) Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> Message-ID: <963038.51319.qm@web111416.mail.gq1.yahoo.com> Hi Anderson, All changes from the trunk were merged Mon Aug 17 this week. I just checked, currently the boost/python and libs/python directories are identical in the trunk and the release branch. I'm pretty sure all updates will be included in the final 1.40 release. Ralf ----- Original Message ---- From: Anderson Lizardo To: Development of Python/C++ integration Sent: Friday, August 21, 2009 5:08:59 AM Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) I think it was not clear in the announcement, but PySide uses Boost.Python. And for it to work properly, we need a few patches that are already in Boost SVN trunk, but in none of the release branches. Therefore, is it possible to get these patches merged into the 1.40 release branch before the final release? That would make life a lot easier for other distros to try PySide without requiring to apply patches separately. The relevant commits are listed in http://www.pyside.org/downloads/, they are: Add generic call operator support. https://svn.boost.org/trac/boost/changeset/47846 Support C++ enums which have the same value. https://svn.boost.org/trac/boost/changeset/53660 Fix unsigned integer converters. https://svn.boost.org/trac/boost/changeset/54919 Fix unsigned integer converters (update). https://svn.boost.org/trac/boost/changeset/54923 IMHO these patches fix important bugs in Boost.Python, and the first two were in trunk even before the 1.39 release, but were never merged... Thanks in advance, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil From rwgk at yahoo.com Fri Aug 21 23:49:30 2009 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 21 Aug 2009 14:49:30 -0700 (PDT) Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <4A8E98ED.5040202@sympatico.ca> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> <4A8E98ED.5040202@sympatico.ca> Message-ID: <355632.65502.qm@web111408.mail.gq1.yahoo.com> Hi Stefan, I merged everything Mon Aug 17. Ralf ----- Original Message ---- From: Stefan Seefeld To: Development of Python/C++ integration ; Boost mailing list ; David Abrahams ; Beman Dawes Sent: Friday, August 21, 2009 5:54:05 AM Subject: Re: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) Anderson, let me forward that mail to the main boost list, and ping Beman (release manager) and David (boost.python maintainer). Beman, David, if it's not too late, I may help merge trunk to the release branch. Let me know... Stefan On 08/21/2009 08:08 AM, Anderson Lizardo wrote: > I think it was not clear in the announcement, but PySide uses Boost.Python. > > And for it to work properly, we need a few patches that are already in > Boost SVN trunk, but in none of the release branches. > > Therefore, is it possible to get these patches merged into the 1.40 > release branch before the final release? That would make life a lot > easier for other distros to try PySide without requiring to apply > patches separately. > > The relevant commits are listed in http://www.pyside.org/downloads/, they are: > > Add generic call operator support. > https://svn.boost.org/trac/boost/changeset/47846 > Support C++ enums which have the same value. > https://svn.boost.org/trac/boost/changeset/53660 > Fix unsigned integer converters. > https://svn.boost.org/trac/boost/changeset/54919 > Fix unsigned integer converters (update). > https://svn.boost.org/trac/boost/changeset/54923 > > IMHO these patches fix important bugs in Boost.Python, and the first > two were in trunk even before the 1.39 release, but were never > merged... > > Thanks in advance, > -- ...ich hab' noch einen Koffer in Berlin... _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig From seefeld at sympatico.ca Fri Aug 21 23:59:34 2009 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 21 Aug 2009 17:59:34 -0400 Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <355632.65502.qm@web111408.mail.gq1.yahoo.com> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> <4A8E98ED.5040202@sympatico.ca> <355632.65502.qm@web111408.mail.gq1.yahoo.com> Message-ID: <4A8F18C6.1080302@sympatico.ca> On 08/21/2009 05:49 PM, Ralf W. Grosse-Kunstleve wrote: > Hi Stefan, > I merged everything Mon Aug 17. > Oh, great ! Since you are around, could you please review https://svn.boost.org/trac/boost/ticket/3356 ? I was working on a numpy.ndarray extension, and got hit by this bug when Python would throw an exception at me at seemingly random places, just because boost.python failed to raise the issue right where it was. May be this is serious enough (and the patch simple enough) to still make it into 1.40 ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... From anderson.lizardo at openbossa.org Sat Aug 22 01:13:50 2009 From: anderson.lizardo at openbossa.org (Anderson Lizardo) Date: Fri, 21 Aug 2009 19:13:50 -0400 Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <963038.51319.qm@web111416.mail.gq1.yahoo.com> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> <963038.51319.qm@web111416.mail.gq1.yahoo.com> Message-ID: <55b616790908211613o22446745re4a93faa1436a65a@mail.gmail.com> On Fri, Aug 21, 2009 at 5:44 PM, Ralf W. Grosse-Kunstleve wrote: > Hi Anderson, > All changes from the trunk were merged Mon Aug 17 this week. I just checked, currently > the boost/python and libs/python directories are identical in the trunk and the release > branch. I'm pretty sure all updates will be included in the final 1.40 release. Ok, I must confess I only checked the beta package in http://sourceforge.net/projects/boost/files/boost/1.40.0.beta.1/boost_1_40_0_beta1.tar.gz/download and noticed it wasn't there, so I assumed it wasn't in the release branch. But now I see that this package was uploaded on Aug 10th, so that's why it didn't have the changes. Thanks! Just hoping to get the final 1.40 release soon :) -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil From dave at boostpro.com Sun Aug 23 19:15:39 2009 From: dave at boostpro.com (David Abrahams) Date: Sun, 23 Aug 2009 09:15:39 -0800 Subject: [C++-sig] [Boost.Python] Request to merge some patches from trunk into 1.40 branch (was: Re: PySide has been released) In-Reply-To: <4A8E98ED.5040202@sympatico.ca> References: <55b616790908210508hf8f1a9fxad93fb6c33be52d5@mail.gmail.com> <4A8E98ED.5040202@sympatico.ca> Message-ID: It's fine as far as I'm concerned. On vacation right now so can't give it more attention. Sent from my iPhone On Aug 21, 2009, at 4:54 AM, Stefan Seefeld wrote: > Anderson, > > let me forward that mail to the main boost list, and ping Beman > (release manager) and David (boost.python maintainer). > > Beman, David, if it's not too late, I may help merge trunk to the > release branch. Let me know... > > Stefan > > > On 08/21/2009 08:08 AM, Anderson Lizardo wrote: >> I think it was not clear in the announcement, but PySide uses >> Boost.Python. >> >> And for it to work properly, we need a few patches that are already >> in >> Boost SVN trunk, but in none of the release branches. >> >> Therefore, is it possible to get these patches merged into the 1.40 >> release branch before the final release? That would make life a lot >> easier for other distros to try PySide without requiring to apply >> patches separately. >> >> The relevant commits are listed in http://www.pyside.org/ >> downloads/, they are: >> >> Add generic call operator support. >> https://svn.boost.org/trac/boost/changeset/47846 >> Support C++ enums which have the same value. >> https://svn.boost.org/trac/boost/changeset/53660 >> Fix unsigned integer converters. >> https://svn.boost.org/trac/boost/changeset/54919 >> Fix unsigned integer converters (update). >> https://svn.boost.org/trac/boost/changeset/54923 >> >> IMHO these patches fix important bugs in Boost.Python, and the first >> two were in trunk even before the 1.39 release, but were never >> merged... >> >> Thanks in advance, >> > > > -- > > ...ich hab' noch einen Koffer in Berlin... > From anderson.lizardo at openbossa.org Mon Aug 24 20:02:35 2009 From: anderson.lizardo at openbossa.org (Anderson Lizardo) Date: Mon, 24 Aug 2009 14:02:35 -0400 Subject: [C++-sig] [py++] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only In-Reply-To: References: Message-ID: <55b616790908241102w6266d42fhf3066da91ac6c4f0@mail.gmail.com> On Thu, Aug 20, 2009 at 5:10 AM, Vaclav Smilauer wrote: > Hi everybody, > > I have a small wrapper for a few geometry classes generated; it works on boost > 1.34--1.37. I tried to compile and run on boost 1.39 (Boost::python doesn't > seem to be mentioned in changelogs for 1.38 or 1.39 though) and I am getting > this error: > > Traceback (most recent call last): > ?File "debian/yade-bzr1703-dbg/usr/lib/yade-bzr1703-dbg/gui/PythonUI_rc.py", > line 11, in > ? ?from miniWm3Wrap import * > AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is > read-only > > I only googled the same error at http://de.pastebin.ca/1535109 (which concerns > pySide), but no solution. What am I doing wrong? Are you using Ubuntu 9.10 (karmic)? We are trying to fix the very same issue on PySide, and so far the problem seems only to happen on Karmic. On Ubuntu 9.04 (jaunty) the same binary package works fine. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil From trhaynes at gmail.com Mon Aug 24 23:27:56 2009 From: trhaynes at gmail.com (Tom Haynes) Date: Mon, 24 Aug 2009 17:27:56 -0400 Subject: [C++-sig] why am I getting a Boost.Python.ArgumentError? Message-ID: <904f086b0908241427p58141b34h83a5b06751cc265@mail.gmail.com> When trying to called a wrapped method (getName) from python, I get the following error: return self.geometry.getName() Boost.Python.ArgumentError: Python argument types in Geometry.getName(Geometry) did not match C++ signature: getName(gfx::Geometry {lvalue}) I don't understand why these don't match, though. It seems to say that the C++ signature is Geometry::getName() (which is true) ... and that's how I'm calling it from python. If I "print self.geometry" I get that it is a gfx.Geometry object. Thanks for your help. -tom From trhaynes at gmail.com Tue Aug 25 16:42:15 2009 From: trhaynes at gmail.com (Tom Haynes) Date: Tue, 25 Aug 2009 10:42:15 -0400 Subject: [C++-sig] why am I getting a Boost.Python.ArgumentError? In-Reply-To: <904f086b0908241427p58141b34h83a5b06751cc265@mail.gmail.com> References: <904f086b0908241427p58141b34h83a5b06751cc265@mail.gmail.com> Message-ID: <904f086b0908250742u50c8a97fqb4a188ff08419207@mail.gmail.com> Fixed it. The self.geometry came from a list of Geometrys, which in C++ was a std::vector. I had used the vector_indexing_suite to wrap this list, but forgot to include the "true" as the NoProxy template parameter (since they're boost::shared_ptrs). -tom On Mon, Aug 24, 2009 at 5:27 PM, Tom Haynes wrote: > When trying to called a wrapped method (getName) from python, I get > the following error: > > ? ?return self.geometry.getName() > Boost.Python.ArgumentError: Python argument types in > ? ?Geometry.getName(Geometry) > did not match C++ signature: > ? ?getName(gfx::Geometry {lvalue}) > > I don't understand why these don't match, though. ?It seems to say > that the C++ signature is Geometry::getName() (which is true) ... and > that's how I'm calling it from python. ?If I "print self.geometry" I > get that it is a gfx.Geometry object. > > Thanks for your help. > > -tom > From sanduleac.dan at gmail.com Tue Aug 25 23:48:02 2009 From: sanduleac.dan at gmail.com (Dan Sanduleac) Date: Wed, 26 Aug 2009 00:48:02 +0300 Subject: [C++-sig] Trouble optimizing Boost.python integration Message-ID: <4A945C12.2020406@gmail.com> Hi, I'm trying to compare different python-C wrapping techniques to see which would be faster and also more suited to game development. I'm using Stackless Python 2.6.2 and boost 1.39.0. I implemented a simple Vec3 (3D vector) class in C++ and wrapped it with boost:python. All it does is multiplications and additions, so it implements just two operators. The thing is, it proves to be kind of slow compared to Cython/Pyrex code that does the same. I think it should run faster than Cython code. (Note: Cython is not an abbreviation for C/Python API) I compiled the python library from boost, in release mode, and then linked the vec3 module, provided below, to the compiled boost_python library. (I used -O2 when compiling the vec3 module) The testing goes like this: each "tick", 10000 objects update their position, according to their velocity and timedelta since last "tick", and I'm measuring the average time a tick takes to complete. On my machine doing this with Cython takes ~0.026 sec/tick, while doing it with boost.python takes like 0.052 sec/tick (The overhead introduced by python's iterating through the list of objects each tick is about 0.01 sec) During one tick, for each object, python runs this: "self.position += self.velocity * time_delta", where position and velocity are instances of Vec3. I was hoping for results better than with Cython, by using Boost. Am I doing something wrong? Source code: vec3.cpp ========== #include using namespace boost::python; class Vec3 { float x, y, z; public: Vec3(float x, float y, float z); Vec3 &operator*=(float scalar); Vec3 operator*(float scalar) const; Vec3 &operator+=(const Vec3 &who); // that `const Vec3` is REALLY needed, unless you want error monsoon to come down }; // === boost:python wrapper === // publish just += and * to python BOOST_PYTHON_MODULE(vec3) { class_("Vec3", init()) .def(self += self) .def(self * float()) ; } // === implementation === Vec3::Vec3(float x, float y, float z) { this->x = x; this->y = y; this->z = z; } Vec3 & Vec3::operator*=(float scalar) { this->x *= scalar; this->y *= scalar; thiz->z *= scalar;a } Vec3 Vec3::operator*(float scalar) const { return Vec3(*this) *= scalar; } Vec3 & Vec3::operator+=(const Vec3 &who) { this->x += who.x; this->y += who.y; this->z += who.z; return *this; } From renatox at gmail.com Fri Aug 28 23:32:25 2009 From: renatox at gmail.com (Renato Araujo) Date: Fri, 28 Aug 2009 18:32:25 -0300 Subject: [C++-sig] use of hash to map c++ pointers with python objects Message-ID: <95291a80908281432x55cc071evb7c66525fba39600@mail.gmail.com> Hi all, I'm working on PySide[1] and we have a problem with map between c++ pointers and PyObject. In this section of FAQ: http://www.boost.org/doc/libs/1_40_0/libs/python/doc/v2/faq.html#xref, they give some examples on how to handle this kind of problem. But the point is: dynamic_cast does not work between shared libraries. My wrapper class is not visible to another library then the dynamic_cast fails. Then I tried implement a hash table to map c++ pointers and python objects, but in some point of the code I received the pointer in another class representation and this moves the pointer address to another region of memory, causing a mess in my hash. I would like to know if someone has any idea about how to solve this problem. How can I map a c++ pointer to a PyObject between libraries without use dynamic_cast. I have attached a small use case for this case. Renato Araujo Oliveira Filho [1] PySide = http://pyside.org -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 1696 bytes Desc: not available URL: From eudoxos at arcig.cz Sat Aug 29 23:52:16 2009 From: eudoxos at arcig.cz (=?utf-8?b?VsOhY2xhdg==?= =?utf-8?b?xaBtaWxhdWVy?=) Date: Sat, 29 Aug 2009 21:52:16 +0000 (UTC) Subject: [C++-sig] =?utf-8?q?=5Bpy++=5D_AttributeError=3A_=27Boost=2EPytho?= =?utf-8?q?n=2EStaticProperty=27_object_attribute_=27=5F=5Fdoc=5F?= =?utf-8?q?=5F=27_is_read-only?= References: <55b616790908241102w6266d42fhf3066da91ac6c4f0@mail.gmail.com> Message-ID: > Are you using Ubuntu 9.10 (karmic)? > > We are trying to fix the very same issue on PySide, and so far the > problem seems only to happen on Karmic. On Ubuntu 9.04 (jaunty) the > same binary package works fine. Hi, yes, I am at ubuntu karmic. (It was me discussing that with you on IRC a few days back). By bisecting the (quite small) py++-generated wrapper that I use I found out that the problem is caused by def_readonly. If I comment them out, everything works fine. Isolating the offensive code (by hand): BOOST_PYTHON_MODULE(miniWm3Wrap){ typedef bp::class_< Wm3::Quaternion< double > > Quaternion_exposer_t; Quaternion_exposer_t Quaternion_exposer = Quaternion_exposer_t( "Quaternion", bp::init< >() ); // ... Quaternion_exposer.def_readonly( "IDENTITY", Wm3::Quaternion< double >::IDENTITY ); } the last line will cause the trouble. The decl&definition of Quaternion::IDENTITY: // template in the header static const Quaternion IDENTITY; // in the .cpp template<> const Quaternion Quaternion::IDENTITY(1.0,0.0,0.0,0.0); If I have time, I will try to make minimum example exhibiting the bug. That should make it easier to find out what's gouing wrong. As an information for other people: this bug was consistently present at the mentioned ubuntu version (the future 9.10) regardless of complier/boost version, python 2.6.2. I wasn't able to reproduce it on debian/other ubuntu versions either. Hope we will be able to sort it out soon. Cheers, Vaclav From eudoxos at arcig.cz Sun Aug 30 09:40:15 2009 From: eudoxos at arcig.cz (=?utf-8?b?VsOhY2xhdg==?= =?utf-8?b?xaBtaWxhdWVy?=) Date: Sun, 30 Aug 2009 07:40:15 +0000 (UTC) Subject: [C++-sig] =?utf-8?q?AttributeError=3A_=27Boost=2EPython=2EStaticP?= =?utf-8?q?roperty=27_object_attribute_=27=5F=5Fdoc=5F=5F=27_is_rea?= =?utf-8?q?d-only?= References: <55b616790908241102w6266d42fhf3066da91ac6c4f0@mail.gmail.com> Message-ID: Such is the shortest example I am able to isolate (nothing py++ specific). Should I report that as bug? Against boost::python? I hope some expert will be able to comment on that. ---- $ cat foo.cc #include struct Foo{ static int bar; }; int Foo::bar=3; BOOST_PYTHON_MODULE(foo){ boost::python::class_("Foo",boost::python::init<>()) .def_readonly("bar",Foo::bar); } $ g++ -o foo.so -I/usr/include/python2.6 -fPIC -shared -lboost_python-mt foo.cc $ PYTHONPATH=. python -c 'import foo' Traceback (most recent call last): File "", line 1, in AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only From admin at lodle.net Mon Aug 31 13:51:04 2009 From: admin at lodle.net (Mark Chandler) Date: Mon, 31 Aug 2009 19:51:04 +0800 Subject: [C++-sig] python extended object to native c++ pointer Message-ID: <4A9BB928.6000603@lodle.net> Im toying around with the idea to use python as an embedded scripting language for a project im working on and have got most things working. However i cant seem to be able to convert a python extended object back into a native c++ pointer. So this is my class: class CGEGameModeBase { public: virtual void FunctionCall()=0; virtual const char* StringReturn()=0; }; class CGEPYGameMode : public CGEGameModeBase, public boost::python::wrapper { public: virtual void FunctionCall() { if (override f = this->get_override("FunctionCall")) f(); } virtual const char* StringReturn() { if (override f = this->get_override("StringReturn")) return f(); return "FAILED TO CALL"; } }; Boost wrapping: BOOST_PYTHON_MODULE(GEGameMode) { class_("CGEGameModeBase", no_init); class_ >("CGEPYGameMode", no_init) .def("FunctionCall", &CGEPYGameMode::FunctionCall) .def("StringReturn", &CGEPYGameMode::StringReturn); } and the python code: import GEGameMode def Ident(): return "Alpha" def NewGamePlay(): return "NewAlpha" def NewAlpha(): import GEGameMode import GEUtil class Alpha(GEGameMode.CGEPYGameMode): def __init__(self): print "Made new Alpha!" def FunctionCall(self): GEUtil.Msg("This is function test Alpha!") def StringReturn(self): return "This is return test Alpha!" return Alpha() Now i can call the first to functions fine by doing this: const char* ident = extract< const char* >( GetLocalDict()["Ident"]() ); const char* newgameplay = extract< const char* >( GetLocalDict()["NewGamePlay"]() ); printf("Loading Script: %s\n", ident); CGEPYGameMode* m_pGameMode = extract< CGEPYGameMode* >( GetLocalDict()[newgameplay]() ); However when i try and convert the Alpha class back to its base class (last line above) i get an boost error: TypeError: No registered converter was able to extract a C++ pointer to type class CGEPYGameMode from this Python object of type Alpha I have done alot of searching on the net but cant work out how to convert the Alpha object into its base class pointer. I could leave it as an object but rather have it as a pointer so some non python aware code can use it. Any ideas? Better Formatted version: http://stackoverflow.com/questions/1355187/python-object-to-native-c-pointer From seefeld at sympatico.ca Mon Aug 31 14:34:38 2009 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon, 31 Aug 2009 08:34:38 -0400 Subject: [C++-sig] python extended object to native c++ pointer In-Reply-To: <4A9BB928.6000603@lodle.net> References: <4A9BB928.6000603@lodle.net> Message-ID: <4A9BC35E.8030908@sympatico.ca> On 08/31/2009 07:51 AM, Mark Chandler wrote: > Im toying around with the idea to use python as an embedded scripting > language for a project im working on and have got most things working. > However i cant seem to be able to convert a python extended object > back into a native c++ pointer. > [...] > import GEGameMode > def Ident(): > return "Alpha" > def NewGamePlay(): > return "NewAlpha" > def NewAlpha(): > import GEGameMode > import GEUtil > class Alpha(GEGameMode.CGEPYGameMode): > def __init__(self): > print "Made new Alpha!" super(Alpha, self).__init__() is missing here. > > def FunctionCall(self): > GEUtil.Msg("This is function test Alpha!") > def StringReturn(self): > return "This is return test Alpha!" > return Alpha() Without explicit initialization of the base class, your Alpha instance is in fact not a CGEPYGameMode instance. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From admin at lodle.net Mon Aug 31 14:57:48 2009 From: admin at lodle.net (Mark Chandler) Date: Mon, 31 Aug 2009 20:57:48 +0800 Subject: [C++-sig] python extended object to native c++ pointer In-Reply-To: <4A9BC35E.8030908@sympatico.ca> References: <4A9BB928.6000603@lodle.net> <4A9BC35E.8030908@sympatico.ca> Message-ID: <4A9BC8CC.50003@lodle.net> Stefan i spent sooooo long on this thank you! I got another quick question, how do i define the class in the global namespace but still refer to it in functions? I want to do something like this but keep getting compile errors. ////////////////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////// import GEUtil import GEGameMode charlieTemp = 0 class Charlie(GEGameMode.CGEPYGameMode): def __init__(self): super(Alpha, self).__init__() def FunctionCall(self): GEUtil.Msg("This is function test Charlie!") def StringReturn(self): return "This is return test Charlie!" def Ident(): return "Charlie" def NewGamePlay(): return "NewCharlie" def NewCharlie(): global charlieTemp charlieTemp = Charlie() return charlieTemp ////////////////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////////////////// Loading Script: Charlie Traceback (most recent call last): File "test_c.py", line 25, in NewCharlie charlieTemp = Charlie() NameError: global name 'Charlie' is not defined Stefan Seefeld wrote: > On 08/31/2009 07:51 AM, Mark Chandler wrote: >> Im toying around with the idea to use python as an embedded scripting >> language for a project im working on and have got most things >> working. However i cant seem to be able to convert a python extended >> object back into a native c++ pointer. >> > > [...] > >> import GEGameMode >> def Ident(): >> return "Alpha" >> def NewGamePlay(): >> return "NewAlpha" >> def NewAlpha(): >> import GEGameMode >> import GEUtil >> class Alpha(GEGameMode.CGEPYGameMode): >> def __init__(self): >> print "Made new Alpha!" > > super(Alpha, self).__init__() > > is missing here. > > >> >> def FunctionCall(self): >> GEUtil.Msg("This is function test Alpha!") >> def StringReturn(self): >> return "This is return test Alpha!" >> return Alpha() > > Without explicit initialization of the base class, your Alpha instance > is in fact not a CGEPYGameMode instance. > > HTH, > Stefan > From renatox at gmail.com Mon Aug 31 15:00:38 2009 From: renatox at gmail.com (Renato Araujo) Date: Mon, 31 Aug 2009 10:00:38 -0300 Subject: [C++-sig] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only In-Reply-To: References: <55b616790908241102w6266d42fhf3066da91ac6c4f0@mail.gmail.com> Message-ID: <95291a80908310600p15fa6358k3df0911a0b4bc955@mail.gmail.com> Hi guys, Searching in karmic patch for python 2.6, I found this one which touch in __doc__ attributes of python objects. (http://pastebin.com/m4d8008fa). I did not test if removing this boost will works fine. For fix this I did a little change removing the use of def_readonly("bar",Foo::bar) to add_property("bar", setter_property_bar). I will try find the problem in boost source but for now this change can solve the problem. BR Renato Araujo Oliveira Filho On Sun, Aug 30, 2009 at 4:40 AM, V?clav?milauer wrote: > Such is the shortest example I am able to isolate (nothing py++ specific). > Should I report that as bug? Against boost::python? > > I hope some expert will be able to comment on that. > > ---- > > $ cat foo.cc > #include > struct Foo{ > ? ? ? ?static int bar; > }; > int Foo::bar=3; > > BOOST_PYTHON_MODULE(foo){ > ? ? ? ?boost::python::class_("Foo",boost::python::init<>()) > ? ? ? ? ? ? ? ?.def_readonly("bar",Foo::bar); > } > > $ g++ -o foo.so -I/usr/include/python2.6 -fPIC -shared -lboost_python-mt foo.cc > $ PYTHONPATH=. python -c 'import foo' > Traceback (most recent call last): > ?File "", line 1, in > AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' > is read-only > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > From seefeld at sympatico.ca Mon Aug 31 15:09:18 2009 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon, 31 Aug 2009 09:09:18 -0400 Subject: [C++-sig] python extended object to native c++ pointer In-Reply-To: <4A9BC8CC.50003@lodle.net> References: <4A9BB928.6000603@lodle.net> <4A9BC35E.8030908@sympatico.ca> <4A9BC8CC.50003@lodle.net> Message-ID: <4A9BCB7E.10802@sympatico.ca> On 08/31/2009 08:57 AM, Mark Chandler wrote: > Stefan i spent sooooo long on this thank you! > > I got another quick question, how do i define the class in the global > namespace but still refer to it in functions? I want to do something > like this but keep getting compile errors. The script itself looks fine (apart from some indentation quirks, which may stem from your use of tabs). I seem to remember some issues with global and local namespaces in boost::python::exec(), which may relate to this. What version of boost are you using ? How do you call exec() from C++ ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From admin at lodle.net Mon Aug 31 15:12:07 2009 From: admin at lodle.net (Mark Chandler) Date: Mon, 31 Aug 2009 21:12:07 +0800 Subject: [C++-sig] python extended object to native c++ pointer In-Reply-To: <4A9BCB7E.10802@sympatico.ca> References: <4A9BB928.6000603@lodle.net> <4A9BC35E.8030908@sympatico.ca> <4A9BC8CC.50003@lodle.net> <4A9BCB7E.10802@sympatico.ca> Message-ID: <4A9BCC27.6020807@lodle.net> im using boost 1_36_0 as the latest has compile issues. im loading it via the boost call: return boost::python::exec_file(file, GetGloablDict(), GetLocalDict()); where GetGloablDict is the main dict and GetLocalDict is a copy for this instant Stefan Seefeld wrote: > On 08/31/2009 08:57 AM, Mark Chandler wrote: >> Stefan i spent sooooo long on this thank you! >> >> I got another quick question, how do i define the class in the global >> namespace but still refer to it in functions? I want to do something >> like this but keep getting compile errors. > > The script itself looks fine (apart from some indentation quirks, > which may stem from your use of tabs). > I seem to remember some issues with global and local namespaces in > boost::python::exec(), which may relate to this. What version of boost > are you using ? How do you call exec() from C++ ? > > Regards, > Stefan > >