[PyQt] KAboutData() broken when using PyQt 4.4
Hello,
I upgraded to PyQt 4.4.2 this morning, and now KAboutData no longer
works for me:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: argument 1 of KAboutData() has an invalid type
Instead of the expected:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: insufficient number of arguments to KAboutData()
This has broken my application, any ideas?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Joaquín Sabina - Como un explorador
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Exception handling crash
Hi I'm still having problems with SIP's exception handling support, using SIP snapshot 20080612). When an exception from my wrapped C++ code is caught, SIP triggers an error in the Python API (PyEval_SaveThread: NULL tstate), The relevant backtrace looks as follows: #3 0xb6854968 in Py_FatalError () from /usr/lib/libpython2.5.so.1.0 #4 0xb682cad5 in PyEval_SaveThread () from /usr/lib/libpython2.5.so.1.0 #5 0xb2627b69 in release_QString (sipCppV=0x825e3c0) at sipQtCorepart1.cpp:16116 #6 0xb279c2db in release (addr=0x825e3c0, td=0xb27813a0, state=1) at siplib.c:5651 #7 0xb279c299 in sip_api_release_instance (cpp=0x825e3c0, type=0x8495354, state=1) at siplib.c:5633 #8 0xb2503186 in meth_BuildProject2_loadProject (sipArgs=0x854f9cc) at sip_wrapperBuildProject2.cpp:669 AFAICT the problem is that outside the try block there is a call to Py_BEGIN_ALLOW_THREADS, which releases the GIL? Then, first thing after the exception is caught, an QString is released (a parameter to the wrapped method). As part of releasing the QString, in release_QString, Py_BEGIN_ALLOW_THREADS is called again, which is not allowed since the GIL is not being held, right? From what I understand there is a simpler alternative to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in the API: PyGILState_Ensure/PyGILState_Release. Could SIP make use of these functions instead? Arve ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] patch to fix segfault on mac
On Thursday 12 June 2008 11:40:09 pm Erick Tryzelaar wrote: On Thu, Jun 12, 2008 at 2:22 PM, Phil Thompson [EMAIL PROTECTED] wrote: On Wednesday 04 June 2008 5:09:25 am Erick Tryzelaar wrote: I tracked down another segfault for me on the mac. I wasn't able to do import PyQt4.QtWebKit using the sip 4.7.4 You can't build PyQt v4.4 with SIP v4.7.4. Oh, I should have been more clear. We still need this patch on the latest sip v4.7.7 snapshot and pyqt4. [snip] I can't reproduce this. Perhaps it's machine dependent? We're running into this both on x86_64 linux machines running fedora core 5, and macbook pros with core2 duos on leopard. If it helps, I've attached the source that sip generated for QtWebKit and QWebView. Are these files what sip generates for you? The important lines for me are sipQtWebKitQWebView-bad.cpp:3800 and sipQtWebKitcmodule.cpp:614-618. What arguments are you passing to PyQt's configure.py? Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Exception handling crash
On Friday 13 June 2008 10:54:47 am Arve Knudsen wrote: Hi I'm still having problems with SIP's exception handling support, using SIP snapshot 20080612). When an exception from my wrapped C++ code is caught, SIP triggers an error in the Python API (PyEval_SaveThread: NULL tstate), The relevant backtrace looks as follows: #3 0xb6854968 in Py_FatalError () from /usr/lib/libpython2.5.so.1.0 #4 0xb682cad5 in PyEval_SaveThread () from /usr/lib/libpython2.5.so.1.0 #5 0xb2627b69 in release_QString (sipCppV=0x825e3c0) at sipQtCorepart1.cpp:16116 #6 0xb279c2db in release (addr=0x825e3c0, td=0xb27813a0, state=1) at siplib.c:5651 #7 0xb279c299 in sip_api_release_instance (cpp=0x825e3c0, type=0x8495354, state=1) at siplib.c:5633 #8 0xb2503186 in meth_BuildProject2_loadProject (sipArgs=0x854f9cc) at sip_wrapperBuildProject2.cpp:669 AFAICT the problem is that outside the try block there is a call to Py_BEGIN_ALLOW_THREADS, which releases the GIL? Then, first thing after the exception is caught, an QString is released (a parameter to the wrapped method). As part of releasing the QString, in release_QString, Py_BEGIN_ALLOW_THREADS is called again, which is not allowed since the GIL is not being held, right? Can you send me the generated code so that I can see the logic. From what I understand there is a simpler alternative to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in the API: PyGILState_Ensure/PyGILState_Release. Could SIP make use of these functions instead? They are not alternatives. One pair frees the GIL for a period, the other acquires the GIL for a period. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Exception handling crash
On 6/13/08, Phil Thompson [EMAIL PROTECTED] wrote: On Friday 13 June 2008 10:54:47 am Arve Knudsen wrote: Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in the API: PyGILState_Ensure/PyGILState_Release. Could SIP make use of these functions instead? They are not alternatives. One pair frees the GIL for a period, the other acquires the GIL for a period. In order to free the GIL, you have to acquire it first no? Therefore, BEGIN_ALLOW/END_ALLOW, should correspond to GILState_Release of a previously Ensure'd GIL state and then a new call to PyGILState_Ensure. Besides, the Python docs (http://docs.python.org/api/threads.html) present the PyGILState_* functions as a simpler alternative to Py_BEGIN_ALLOW_THREADS et al. Arve ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Exception handling crash
On Friday 13 June 2008 1:45:09 pm Arve Knudsen wrote: On 6/13/08, Phil Thompson [EMAIL PROTECTED] wrote: On Friday 13 June 2008 10:54:47 am Arve Knudsen wrote: Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in the API: PyGILState_Ensure/PyGILState_Release. Could SIP make use of these functions instead? They are not alternatives. One pair frees the GIL for a period, the other acquires the GIL for a period. In order to free the GIL, you have to acquire it first no? Therefore, BEGIN_ALLOW/END_ALLOW, should correspond to GILState_Release of a previously Ensure'd GIL state and then a new call to PyGILState_Ensure. Besides, the Python docs (http://docs.python.org/api/threads.html) present the PyGILState_* functions as a simpler alternative to Py_BEGIN_ALLOW_THREADS et al. The documentation is misleading at best. Both pairs are intended to be used in the same scope. Ensure/Release make it easier to use across different scopes and to use Release then Ensure if you want to - but you then have to maintain a separate stack of the GIL states. If you use them the way they are supposed to be used then you use the C stack - see the definition of SIP_BLOCK_THREADS and SIP_UNBLOCK_THREADS. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Python and smartpointers
In our C++ application we typically use smartpointers to manage pointers automatically, but there's the problem of transferring such objects to Python. What I'd like to do is pass smartpointers to Python, so that one plays along with the C++ memory management scheme, but treat these as their managed objects (i.e., not having to worry about the presence of smartpointers). Is there a typical pattern for accomplishing this, or should I go about it completely differently? Thanks, Arve ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Python and smartpointers
On 6/13/2008 3:16 PM, Arve Knudsen wrote: In our C++ application we typically use smartpointers to manage pointers automatically, but there's the problem of transferring such objects to Python. What I'd like to do is pass smartpointers to Python, so that one plays along with the C++ memory management scheme, but treat these as their managed objects (i.e., not having to worry about the presence of smartpointers). Is there a typical pattern for accomplishing this, or should I go about it completely differently? One idea that comes to mind is to increment the smart-pointer counter when the Python wrapper is created and decrement it when the Python wrapper is destroyed. This would allow the Python code to keep the object in life by itself, even though the Python refcount would of course be different from the C++ refcount. I have no idea how to implement this with SIP though; maybe Phil will chime in. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Template - unsupported function return type
I'm trying to wrap a class method which returns a templated type, which I've successfully defined in the SIP specification. SIP doesn't accept the templated type as the function return type however, saying: unsupported function return type - provide %MethodCode and a C++ signature. What's going on here? Thanks, Arve ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
On Friday 13 June 2008 01:23, Adeodato Simó wrote:
Hello,
I upgraded to PyQt 4.4.2 this morning, and now KAboutData no longer
works for me:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: argument 1 of KAboutData() has an invalid type
Instead of the expected:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: insufficient number of arguments to KAboutData()
This has broken my application, any ideas?
PyKDE3 or PyKDE4?
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: Template - unsupported function return type
Looks like I made it work, somehow. Anyway, I refer to the class template in the SIP specification using a typedef. That leads to another problem, however. The generated code refers to the typedef, but lacks its definition. How do I include the header containing the typedef?? For a class I would use %TypeHeaderCode, but can't see anyway of doing the same for typedefs .. Arve On 6/13/08, Arve Knudsen [EMAIL PROTECTED] wrote: I'm trying to wrap a class method which returns a templated type, which I've successfully defined in the SIP specification. SIP doesn't accept the templated type as the function return type however, saying: unsupported function return type - provide %MethodCode and a C++ signature. What's going on here? Thanks, Arve ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
* Jim Bublitz [Fri, 13 Jun 2008 07:50:31 -0700]: PyKDE3 or PyKDE4? Er, PyKDE4 (since I said I was using PyQt 4.4...) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - Y sin embargo ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
Am Freitag, 13. Juni 2008 schrieb Adeodato Simó: * Jim Bublitz [Fri, 13 Jun 2008 07:50:31 -0700]: PyKDE3 or PyKDE4? Er, PyKDE4 (since I said I was using PyQt 4.4...) Dunno if it helps, but I have the same problem. I guess we're using the same version(s) as I'm using the Debian package over here. Chris ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] patch to fix segfault on mac
On Fri, Jun 13, 2008 at 4:24 AM, Phil Thompson [EMAIL PROTECTED] wrote: What arguments are you passing to PyQt's configure.py? The environment is: CFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2' LDFLAGS='-L/opt/local/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install' OBJCFLAGS='-O2' FFLAGS='-O2' CC='/usr/bin/gcc-4.0' And the command: /opt/local/bin/python2.4 configure.py -g -q /opt/local/bin/qmake --confirm-license LFLAGS=-F/opt/local/Library/Frameworks -L/opt/local/lib ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: Template - unsupported function return type
On Friday 13 June 2008 08:04:46 Arve Knudsen wrote: Looks like I made it work, somehow. Anyway, I refer to the class template in the SIP specification using a typedef. That leads to another problem, however. The generated code refers to the typedef, but lacks its definition. How do I include the header containing the typedef?? For a class I would use %TypeHeaderCode, but can't see anyway of doing the same for typedefs .. %ModuleHeaderCode #include myheader.h %End Matt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
