Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote: On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila akaba...@pcug.org.au wrote: On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote: On 22/06/11 20:49, David Townshend wrote: On Wed, Jun 22, 2011 at 2:34 PM, Baz Walterbaz...@ftml.net wrote: according to the qt docs, only one application object should be created at a time, and there is a global qApp pointer which refers to the current instance. this suggests that, in pyqt, something like the following should work: from PyQt4 import QtGui QtGui.qApp = app = QtGui.QApplication([]) app.quit() QtGui.qApp = app = None [snip] I've investigated further and found that its caused by the gtk style which I am using, since I am running gnome. Simply changing the qt style avoids the problem. I recall reading about similar issues before with the gtk-qt style, so I think that this is a know problem. However, I noticed that after changing the style, python still segfaults on exit. gdb indicates that it is something in the QApplication destructor, and it seems that deleting the instance after quitting solves this, e.g.: from PyQt4.QtGui import QApplication for i in range(10): ... app = QApplication([]) ... app.quit() ... del app ... exit() I experimented a bit with setting qApp = None, but it didn't make a difference. my point was simply that you need to make sure you remove all references to the current qpplication instance before creating a new one. in general, setting qApp to the instance of qapplication isn't necessary. but it's worth noting that qApp won't refer to the same *pyqt* object unless it's explicitly over-written. this may become relevant when working with subclasses of qapplication. of course, if you don't use qApp, it won't make any difference, as you say ;-) Baz, This does not explain why the IDLE quits so early in the test, even before CR is pressed... Actually, in python3.2 if one programs in IDLE, one finds that IDLE is useless with PyQt as it quits (just vanishes from the screen...) if one tries to run a script after modifying it. Basically, IDLE works only if it is invoked from scratch each time one wants to run a program. I suggest that because of such misbehaviour it is not useful to look for faults in the test case - there is a fault, either in Python3 IDLE, Python 3, PyQt, Qt itself. As for the PyQt bug tracker - I was not able to find it, though I saw bug reports in several places, though I said earlier that I did see it somewhere. I would write it down to my aging memory OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt Baz - Sorry, I think I misunderstood you slightly, but I reached the same conclusion - to delete all references to the instance. I don't think that omitting this should cause a segfault though, so it does look like a bug, but at least its easy to work around. OldAl - I don't get that behaviour. Is this is linux or windows, have you tried to get a backtrace to see where the problem is? I have to admit I never use IDLE, I much prefer the console interface, so I haven't had much opportunity to see if this happens to me. David No backtrace possible - it's vanishing act of IDLE... It only happens with IDLE for python 3 (3.2). My os is kubuntu 11.04 natty. Sip and PyQt are compiled with python 3.2, but Qt is from debian (ubuntu) binaries. As I could not make use of IDLE, I compiled eric5 from source. It is a really nice IDE! [press ( gives (), press , - adds a space after it - and the code completion is only the beginning!] - free sales pitch. It is free as in beer and OSS. Here are my system details: ak@supremo:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 11.04 Release:11.04 Codename: natty ak@supremo:~$ ak@supremo:~$ python3 Python 3.2 (r32:88445, Mar 25 2011, 19:56:22) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. from PyQt4 import QtCore QtCore.PYQT_VERSION_STR '4.8.4' QtCore.QT_VERSION_STR '4.7.2' The key point is that IDLE is for Python3.2 and sip, PyQt are compiled with Python3.2. I have observed this kind of errant behaviour with PySide too. (PySide does not yet have a Python3 version). OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
If it vanishes, it implies a segfault which you will probably see if you run idle form the command line. You should be able to get a backtrace by running idle through gdb, i.e, from the command line, run gdb idle. Then in gdb type run. Idle should start as usual, so get it to crash. Then within gdb type bt. This will give a backtrace which will hopefully at least point to whether its python, pyqt or qt. David On Thu, Jun 23, 2011 at 8:16 AM, Algis Kabaila akaba...@pcug.org.au wrote: On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote: On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila akaba...@pcug.org.au wrote: On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote: On 22/06/11 20:49, David Townshend wrote: On Wed, Jun 22, 2011 at 2:34 PM, Baz Walterbaz...@ftml.net wrote: according to the qt docs, only one application object should be created at a time, and there is a global qApp pointer which refers to the current instance. this suggests that, in pyqt, something like the following should work: from PyQt4 import QtGui QtGui.qApp = app = QtGui.QApplication([]) app.quit() QtGui.qApp = app = None [snip] I've investigated further and found that its caused by the gtk style which I am using, since I am running gnome. Simply changing the qt style avoids the problem. I recall reading about similar issues before with the gtk-qt style, so I think that this is a know problem. However, I noticed that after changing the style, python still segfaults on exit. gdb indicates that it is something in the QApplication destructor, and it seems that deleting the instance after quitting solves this, e.g.: from PyQt4.QtGui import QApplication for i in range(10): ... app = QApplication([]) ... app.quit() ... del app ... exit() I experimented a bit with setting qApp = None, but it didn't make a difference. my point was simply that you need to make sure you remove all references to the current qpplication instance before creating a new one. in general, setting qApp to the instance of qapplication isn't necessary. but it's worth noting that qApp won't refer to the same *pyqt* object unless it's explicitly over-written. this may become relevant when working with subclasses of qapplication. of course, if you don't use qApp, it won't make any difference, as you say ;-) Baz, This does not explain why the IDLE quits so early in the test, even before CR is pressed... Actually, in python3.2 if one programs in IDLE, one finds that IDLE is useless with PyQt as it quits (just vanishes from the screen...) if one tries to run a script after modifying it. Basically, IDLE works only if it is invoked from scratch each time one wants to run a program. I suggest that because of such misbehaviour it is not useful to look for faults in the test case - there is a fault, either in Python3 IDLE, Python 3, PyQt, Qt itself. As for the PyQt bug tracker - I was not able to find it, though I saw bug reports in several places, though I said earlier that I did see it somewhere. I would write it down to my aging memory OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt Baz - Sorry, I think I misunderstood you slightly, but I reached the same conclusion - to delete all references to the instance. I don't think that omitting this should cause a segfault though, so it does look like a bug, but at least its easy to work around. OldAl - I don't get that behaviour. Is this is linux or windows, have you tried to get a backtrace to see where the problem is? I have to admit I never use IDLE, I much prefer the console interface, so I haven't had much opportunity to see if this happens to me. David No backtrace possible - it's vanishing act of IDLE... It only happens with IDLE for python 3 (3.2). My os is kubuntu 11.04 natty. Sip and PyQt are compiled with python 3.2, but Qt is from debian (ubuntu) binaries. As I could not make use of IDLE, I compiled eric5 from source. It is a really nice IDE! [press ( gives (), press , - adds a space after it - and the code completion is only the beginning!] - free sales pitch. It is free as in beer and OSS. Here are my system details: ak@supremo:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 11.04 Release:11.04 Codename: natty ak@supremo:~$ ak@supremo:~$ python3 Python 3.2 (r32:88445, Mar 25 2011, 19:56:22) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. from PyQt4 import QtCore QtCore.PYQT_VERSION_STR '4.8.4'
Re: [PyQt] licensing
On Wed, 22 Jun 2011 10:35:40 +0200, KONTRA, Gergely pihent...@gmail.com wrote: Hi all! Maybe a bit offtopic and theoretical question: Suppose I'd like to write an app in python and Qt. I evaluate the possibilities, and see, that pyqt is more stable now, so I decide to begin coding with it (with the free version). When I make this decision, I already think to wait for a more complete/stable PySide binding and distribute my code which uses PySide (with a less restrictive license). Or I first release it with PyQt, but later on I find PySide, which has a less restrictive license. Is any of the above cases the violation of the License Terms? So is it legal? Is it fair? And consider another case: I begin to write my app with Pyside, and later release a version with pyqt at some point. Can I later release a newer PySide based version with license compatible with PySide (which is not compatible with pyqt's license)? Yet another case: I do a prototype with PyQt, and than hand-convert it to Qt/C++. You haven't said what license you want to use for your code. If you use the GPL version of PyQt then your license must be compatible with the GPL. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] licensing
On Thu, Jun 23, 2011 at 10:33, Phil Thompson p...@riverbankcomputing.com wrote: On Wed, 22 Jun 2011 10:35:40 +0200, KONTRA, Gergely pihent...@gmail.com wrote: Hi all! Maybe a bit offtopic and theoretical question: Suppose I'd like to write an app in python and Qt. I evaluate the possibilities, and see, that pyqt is more stable now, so I decide to begin coding with it (with the free version). When I make this decision, I already think to wait for a more complete/stable PySide binding and distribute my code which uses PySide (with a less restrictive license). Or I first release it with PyQt, but later on I find PySide, which has a less restrictive license. Is any of the above cases the violation of the License Terms? So is it legal? Is it fair? And consider another case: I begin to write my app with Pyside, and later release a version with pyqt at some point. Can I later release a newer PySide based version with license compatible with PySide (which is not compatible with pyqt's license)? Yet another case: I do a prototype with PyQt, and than hand-convert it to Qt/C++. You haven't said what license you want to use for your code. If you use the GPL version of PyQt then your license must be compatible with the GPL. Phil This question is a question, as long as somebody would like to release the PySide version, which conforms to the PySide license, but not compatible with PyQt's license. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
On Thursday 23 June 2011, 08:28:06 David Townshend wrote: If it vanishes, it implies a segfault which you will probably see if you run idle form the command line. You should be able to get a backtrace by running idle through gdb, i.e, from the command line, run gdb idle. Then in gdb type run. Idle should start as usual, so get it to crash. Then within gdb type bt. This will give a backtrace which will hopefully at least point to whether its python, pyqt or qt. Close, but no cigar. after installing assorted .debug packages of python(3), sip, qt, PyQt, and probably glibc, glib, libstdc++, you usually invoke a python script with gdb similar to: gdb python3 -ex set args /usr/bin/idle -ex run Hth, Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Where may I get older Windows builds?
Hi All, Where may I get older Windows builds of pyQt 4.7.x ? The new 4.8.x has regression in SVG rendering, which I can't hunt down yet. -- -Alexey Eromenko Technologov ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote:
On Thursday 23 June 2011, 08:28:06 David Townshend wrote:
If it vanishes, it implies a segfault which you will probably see if
you run idle form the command line. You should be able to get a
backtrace by running idle through gdb, i.e, from the command line,
run gdb idle. Then in gdb type run. Idle should start as usual,
so get it to crash. Then within gdb type bt. This will give a
backtrace which will hopefully at least point to whether its python,
pyqt or qt.
Close, but no cigar.
after installing assorted .debug packages of python(3), sip, qt, PyQt,
and probably glibc, glib, libstdc++, you usually invoke a python script
with gdb similar to:
gdb python3 -ex set args /usr/bin/idle -ex run
Hth,
Pete
Hi Pete, David et al,
I know sweet all about the gdb, so will need to read up on it (at least a
little bit). I put in the CLI your command and attach the listing, warts and
all. It does not tell *me* much, so I list it all below. You will see that
idle could not be found at the location suggested, so I ran it with the
command that IDLE gui had in the properties. So IDLE did start ok and it
failed after the entry of the same commands under (gdb) as has been tried on
idle window earlier (without invoking gdb):
from PyQt4 import QtGui
app = QtGui.QApplication([])
app.quit()
app = QtGui.QApplication([])
app.quit() -- frozen text in IDLE Python Shell.
At this point bt command was entered within the gdb shell. As expected
there are segmentation faults. The following are the grim details:
**
ak@supremo:~$ gdb python3 -ex set args /usr/bin/idle -ex run
Starting program: /usr/bin/python3 /usr/bin/idle
[Thread debugging using libthread_db enabled]
/usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such file or
directory
Program exited with code 02.
(gdb) /usr/bin/idle-python3.2 -n
Undefined command: . Try help.
(gdb) run /usr/bin/idle-python3.2 -n
Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef1cd700 (LWP 1705)]
Program received signal SIGSEGV, Segmentation fault.
0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
(gdb) bt
#0 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
#1 0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
gnu/libX11.so.6
#5 0x70b8a246 in Tk_HandleEvent () from /usr/lib/libtk8.5.so.0
#6 0x70b8a7c0 in ?? () from /usr/lib/libtk8.5.so.0
#7 0x708d564f in Tcl_ServiceEvent () from /usr/lib/libtcl8.5.so.0
#8 0x708d58d5 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
#9 0x711ba2e9 in ?? () from /usr/lib/python3.2/lib-
dynload/_tkinter.cpython-32mu.so
#10 0x00465d28 in call_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3875
#11 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#12 0x004675f2 in PyEval_EvalCodeEx (_co=value optimised out,
globals=value optimised out,
locals=value optimised out, args=value optimised out, argcount=1,
kws=0x12a0d40, kwcount=0,
defs=0xe76b68, defcount=1, kwdefs=0x0, closure=0x0) at
../Python/ceval.c:3311
#13 0x00466784 in fast_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3973
#14 call_function (f=value optimised out, throwflag=value optimised out) at
../Python/ceval.c:3896
#15 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#16 0x00466ae0 in fast_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3963
#17 call_function (f=value optimised out, throwflag=value optimised out) at
../Python/ceval.c:3896
#18 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#19 0x004675f2 in PyEval_EvalCodeEx (_co=value optimised out,
globals=value optimised out,
locals=value optimised out, args=value optimised out, argcount=0,
kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at ../Python/ceval.c:3311
#20 0x0046787b in PyEval_EvalCode (co=value optimised out,
globals=value optimised out,
locals=value optimised out) at ../Python/ceval.c:761
#21 0x0048d00d in run_mod (fp=0xb149b0, filename=value optimised out,
start=value optimised out, globals=
{'QtGui': module at remote 0x1970878, '__builtins__': module at remote
0x77fb2638, '__file__'---Type return to continue, or q return to
quit---
q
Quit
(gdb) quit
A debugging session is active.
Inferior 1 [process 1704]
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
Dear Al, On Thursday 23 June 2011, 13:26:02 Algis Kabaila wrote: On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote: On Thursday 23 June 2011, 08:28:06 David Townshend wrote: If it vanishes, it implies a segfault which you will probably see if you run idle form the command line. You should be able to get a backtrace by running idle through gdb, i.e, from the command line, run gdb idle. Then in gdb type run. Idle should start as usual, so get it to crash. Then within gdb type bt. This will give a backtrace which will hopefully at least point to whether its python, pyqt or qt. Close, but no cigar. after installing assorted .debug packages of python(3), sip, qt, PyQt, and probably glibc, glib, libstdc++, you usually invoke a python script with gdb similar to: gdb python3 -ex set args /usr/bin/idle -ex run Hth, Pete Hi Pete, David et al, I know sweet all about the gdb, so will need to read up on it (at least a little bit). I put in the CLI your command and attach the listing, warts and all. It does not tell *me* much, so I list it all below. You will see that idle could not be found at the location suggested, so I ran it with the command that IDLE gui had in the properties. Sure, that's why I wrote similar to ;-). So IDLE did start ok and it failed after the entry of the same commands under (gdb) as has been tried on idle window earlier (without invoking gdb): from PyQt4 import QtGui app = QtGui.QApplication([]) app.quit() app = QtGui.QApplication([]) app.quit() -- frozen text in IDLE Python Shell. At this point bt command was entered within the gdb shell. As expected there are segmentation faults. The following are the grim details: ** ak@supremo:~$ gdb python3 -ex set args /usr/bin/idle -ex run Starting program: /usr/bin/python3 /usr/bin/idle [Thread debugging using libthread_db enabled] /usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such file or directory Program exited with code 02. (gdb) /usr/bin/idle-python3.2 -n Undefined command: . Try help. (gdb) run /usr/bin/idle-python3.2 -n Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n [Thread debugging using libthread_db enabled] [New Thread 0x7fffef1cd700 (LWP 1705)] Program received signal SIGSEGV, Segmentation fault. 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4 (gdb) bt #0 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4 #1 0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #2 0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3 0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux- gnu/libX11.so.6 That's pretty much useless in this form. That's why I wrote about debug packages. I'm sure, that ubuntu provides them somewhere. In your case, you need to install the libqt4 (or however Ubuntu calls it) debug packages at least to make this backtrace useful. Cheers, Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
On Thu, 23 Jun 2011 10:08:50 PM Hans-Peter Jansen wrote: Dear Al, On Thursday 23 June 2011, 13:26:02 Algis Kabaila wrote: On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote: On Thursday 23 June 2011, 08:28:06 David Townshend wrote: If it vanishes, it implies a segfault which you will probably see if you run idle form the command line. You should be able to get a backtrace by running idle through gdb, i.e, from the command line, run gdb idle. Then in gdb type run. Idle should start as usual, so get it to crash. Then within gdb type bt. This will give a backtrace which will hopefully at least point to whether its python, pyqt or qt. Close, but no cigar. after installing assorted .debug packages of python(3), sip, qt, PyQt, and probably glibc, glib, libstdc++, you usually invoke a python script with gdb similar to: gdb python3 -ex set args /usr/bin/idle -ex run Hth, Pete Hi Pete, David et al, I know sweet all about the gdb, so will need to read up on it (at least a little bit). I put in the CLI your command and attach the listing, warts and all. It does not tell *me* much, so I list it all below. You will see that idle could not be found at the location suggested, so I ran it with the command that IDLE gui had in the properties. Sure, that's why I wrote similar to ;-). So IDLE did start ok and it failed after the entry of the same commands under (gdb) as has been tried on idle window earlier (without invoking gdb): from PyQt4 import QtGui app = QtGui.QApplication([]) app.quit() app = QtGui.QApplication([]) app.quit() -- frozen text in IDLE Python Shell. At this point bt command was entered within the gdb shell. As expected there are segmentation faults. The following are the grim details: ** ak@supremo:~$ gdb python3 -ex set args /usr/bin/idle -ex run Starting program: /usr/bin/python3 /usr/bin/idle [Thread debugging using libthread_db enabled] /usr/bin/python3: can't open file '/usr/bin/idle': [Errno 2] No such file or directory Program exited with code 02. (gdb) /usr/bin/idle-python3.2 -n Undefined command: . Try help. (gdb) run /usr/bin/idle-python3.2 -n Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n [Thread debugging using libthread_db enabled] [New Thread 0x7fffef1cd700 (LWP 1705)] Program received signal SIGSEGV, Segmentation fault. 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4 (gdb) bt #0 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4 #1 0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #2 0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #3 0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux- gnu/libX11.so.6 That's pretty much useless in this form. That's why I wrote about debug packages. I'm sure, that ubuntu provides them somewhere. In your case, you need to install the libqt4 (or however Ubuntu calls it) debug packages at least to make this backtrace useful. Cheers, Pete OK - will do after continuing to sleep. I am on my night walk at the moment. I did gather your note on the location of IDLE in the system, but did not get the note about the debug packages. It was already late in the day... Thanks for your guidance. Al. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] sipConvertFromSliceObject() macro incompatible with Python 3.2
On Mon, 20 Jun 2011 19:13:51 +0200, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2011-06-20 18:45:25 Arfrever Frehtes Taifersar Arahesis napisał(a): sipConvertFromSliceObject() macro is incompatible with Python 3.2. Please see comment #0 in: https://bugs.gentoo.org/show_bug.cgi?id=365549 The patch for SIP: https://365549.bugs.gentoo.org/attachment.cgi?id=271739 It might be appropriate to also update some code in siplib/voidptr.c. I'm attaching updated patch. Thanks, Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyQt application frozen if run in localhost; OK if SSH'd to another host
Consider the following PyQT application (helloworld.py): import sys from PyQt4 import QtGui def main(): app = QtGui.QApplication(sys.argv) win = QtGui.QPushButton(Hello, World!) win.show() return app.exec_() if __name__ == __main__: sys.exit(main()) If I run ($python helloworld.py) this application from a shell in my computer, I see the main container for the button, but the button itself never renders. After a few clicks on the [x] of the main container, I receive a warning window stating: Window with title helloworld.py is not responding. This window belongs to application helloworld.py (PID=2000, hostname=localhost). Do you wish to terminate this application? (All unsaved data in this application will be lost.) [Yes] [No] If I then use the same shell window to SSH to another machine in our network and run the exact same program (we have an NFS file system; I see the same files in every machine) it runs as expected. In fact, even if I SSH back to my original computer I can run the application. This happens with all the PyQt applications I have developed for my group, and it happens on every computer in our network: the applications won't run locally, but run perfectly fine if the user is connected to the terminal via SSH (let me insist, even if SSH'd to your local, physical computer!) Do you have any suggestion for debugging/tracking down this problem? Many thanks. Python 2.6.5 Qt 4.6.2 Red Hat Linux Enterprise Edition (4) -- View this message in context: http://old.nabble.com/PyQt-application-frozen-if-run-in-localhost--OK-if-SSH%27d-to-another-host-tp3195p3195.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] sipConvertFromSliceObject() macro incompatible with Python 3.2
2011-06-23 18:26:05 Phil Thompson napisał(a): On Mon, 20 Jun 2011 19:13:51 +0200, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2011-06-20 18:45:25 Arfrever Frehtes Taifersar Arahesis napisał(a): sipConvertFromSliceObject() macro is incompatible with Python 3.2. Please see comment #0 in: https://bugs.gentoo.org/show_bug.cgi?id=365549 The patch for SIP: https://365549.bugs.gentoo.org/attachment.cgi?id=271739 It might be appropriate to also update some code in siplib/voidptr.c. I'm attaching updated patch. Thanks, Phil When do you plan to release SIP 4.12.4? -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] sipConvertFromSliceObject() macro incompatible with Python 3.2
On Thu, 23 Jun 2011 19:47:17 +0200, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2011-06-23 18:26:05 Phil Thompson napisał(a): On Mon, 20 Jun 2011 19:13:51 +0200, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2011-06-20 18:45:25 Arfrever Frehtes Taifersar Arahesis napisał(a): sipConvertFromSliceObject() macro is incompatible with Python 3.2. Please see comment #0 in: https://bugs.gentoo.org/show_bug.cgi?id=365549 The patch for SIP: https://365549.bugs.gentoo.org/attachment.cgi?id=271739 It might be appropriate to also update some code in siplib/voidptr.c. I'm attaching updated patch. Thanks, Phil When do you plan to release SIP 4.12.4? Probably with the next PyQt release early/mid July. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] bug in latest sip release
On Sat, 18 Jun 2011 16:58:43 +0100, Baz Walter baz...@ftml.net wrote:
after recently upgrading sip, several applications that use treeviews
started producing a lot of errors like this:
TypeError: expected 1 arguments, got 0
this is using: python 2.7.2, qt 4.7.3, sip 4.12.3, pyqt 4.8.4
the following test case demonstrates the problem:
import sys
from PyQt4 import QtCore, QtGui
class Window(QtGui.QTreeWidget):
def __init__(self):
QtGui.QTreeWidget.__init__(self)
for num in range(5):
QtGui.QTreeWidgetItem(
self, QtCore.QStringList('Item(%i)' % num))
self.sortByColumn(0, QtCore.Qt.AscendingOrder)
if __name__ == __main__:
app = QtGui.QApplication(sys.argv)
win = Window()
win.show()
sys.exit(app.exec_())
Fixed in tonight's SIP snapshot.
Thanks,
Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt application frozen if run in localhost; OK if SSH'd to another host
On Thursday 23 June 2011, 18:26:52 Arrieta wrote: Consider the following PyQT application (helloworld.py): import sys from PyQt4 import QtGui def main(): app = QtGui.QApplication(sys.argv) win = QtGui.QPushButton(Hello, World!) win.show() return app.exec_() if __name__ == __main__: sys.exit(main()) If I run ($python helloworld.py) this application from a shell in my ^ It looks, like $python is some unusual shell variable, that we cannot interprete. computer, I see the main container for the button, but the button itself never renders. What happens, if you run python interactively, and paste the above into the python shell? After a few clicks on the [x] of the main container, I receive a warning window stating: Window with title helloworld.py is not responding. This window belongs to application helloworld.py (PID=2000, hostname=localhost). Do you wish to terminate this application? (All unsaved data in this application will be lost.) [Yes] [No] This is the window manager chiming in. For some reason, the communication to the X server seems to be stalled. xauth issues? If I then use the same shell window to SSH to another machine in our network and run the exact same program (we have an NFS file system; I see the same files in every machine) it runs as expected. In fact, even if I SSH back to my original computer I can run the application. Well, ssh -X creates a private communication channel to the X server. This happens with all the PyQt applications I have developed for my group, and it happens on every computer in our network: the applications won't run locally, but run perfectly fine if the user is connected to the terminal via SSH (let me insist, even if SSH'd to your local, physical computer!) I cannot see a single reason, how PyQt could be the culprit here. The whole issue sounds like a major misconfiguration of X, selinux, or some other security feature running wild.. Do you have any suggestion for debugging/tracking down this problem? You might want to recode the script in C++. Due to the nature of PyQt, I expect this to fail in a similar way, or your PyQt build is busted in non trivial ways. Many thanks. Python 2.6.5 Qt 4.6.2 Red Hat Linux Enterprise Edition (4) Since you asked here, you might want to tell us the versions of sip and PyQt you use. Even, if it happens that you discover the reason being something unrelated to sip/PyQt, report this back here, please. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] licensing
On Thursday, June 23, 2011 04:33:20 am Phil Thompson wrote: On Wed, 22 Jun 2011 10:35:40 +0200, KONTRA, Gergely pihent...@gmail.com wrote: Hi all! Maybe a bit offtopic and theoretical question: Suppose I'd like to write an app in python and Qt. I evaluate the possibilities, and see, that pyqt is more stable now, so I decide to begin coding with it (with the free version). When I make this decision, I already think to wait for a more complete/stable PySide binding and distribute my code which uses PySide (with a less restrictive license). Or I first release it with PyQt, but later on I find PySide, which has a less restrictive license. Is any of the above cases the violation of the License Terms? So is it legal? Is it fair? And consider another case: I begin to write my app with Pyside, and later release a version with pyqt at some point. Can I later release a newer PySide based version with license compatible with PySide (which is not compatible with pyqt's license)? Yet another case: I do a prototype with PyQt, and than hand-convert it to Qt/C++. You haven't said what license you want to use for your code. If you use the GPL version of PyQt then your license must be compatible with the GPL. Sure, that's true *while* the application uses PyQt, but what about *after* PyQt is replaced with PySide? I suppose one could argue that there is some ethical commitment due to the history, but I'm not seeing any commitment in a legal technical sense. I think that after all technical reliance from PyQt is replaced by technical reliance on PySide, the project is free to relicense is it wishes in compliance with the reliance on PySide. Or think about it this way: I write a large project using a GPL library. I wish to have more control so I clean-room re-implement the GPL library. I'm now the sole author of the entire relevant software stack and I believe I'm free of the GPL. I don't see how the fact that Nokia (in the case of PySide/PyQt) is the one bank-rolling the clean-room reimplementation changes this. Joel ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] licensing
On Thu Jun 23 21:32:47 BST 2011, Joel B. Mohler wrote: On Thursday, June 23, 2011 04:33:20 am Phil Thompson wrote: You haven't said what license you want to use for your code. If you use the GPL version of PyQt then your license must be compatible with the GPL. Sure, that's true *while* the application uses PyQt, but what about *after* PyQt is replaced with PySide? I suppose one could argue that there is some ethical commitment due to the history, but I'm not seeing any commitment in a legal technical sense. I think that after all technical reliance from PyQt is replaced by technical reliance on PySide, the project is free to relicense is it wishes in compliance with the reliance on PySide. I don't think Phil said anything different to that. Or think about it this way: I write a large project using a GPL library. I wish to have more control so I clean-room re-implement the GPL library. I'm now the sole author of the entire relevant software stack and I believe I'm free of the GPL. I don't see how the fact that Nokia (in the case of PySide/PyQt) is the one bank-rolling the clean-room reimplementation changes this. If the entity funding the effort doesn't have a bearing on the use of the library then why bring them into the argument? David ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt application frozen if run in localhost; OK if SSH'd to another host
The $ in $python helloworld.py is meant to simbolize the command prompt, not an environment variable. Sorry for the confusion. I will verify the X configuration in the machines and get back to you. Thanks! -- View this message in context: http://old.nabble.com/PyQt-application-frozen-if-run-in-localhost--OK-if-SSH%27d-to-another-host-tp3195p31915798.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug report: multiple QApplication instances cause a segfault
On Thu, 23 Jun 2011 10:08:50 PM Hans-Peter Jansen wrote:
Dear Al,
On Thursday 23 June 2011, 13:26:02 Algis Kabaila wrote:
On Thu, 23 Jun 2011 07:06:49 PM Hans-Peter Jansen wrote:
[snip...]
Following Pete's advise, I've installed 23 new packages that appeared to be
dbg related (169 MiB downloaded, 802 MiB additional space of hdd used).
The gdb was then invoked with the command, shown immediately after the
marker. After that in the invoked IDLE Python Shell given were
the following commands:
from PyQt4 import QtGui
app = QtGui.QApplication([])
app.quit()
app = QtGui.QApplication([])
app.quit()
app = QtGui.QApplication([])
At that point the IDLE Shell froze. Typed on the CLI shell was *bt*.
The whole dialog is shown between the markers.
ak@supremo:~$ gdb python3 -ex set args /usr/bin/idle-python3.2 -n -ex run
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/python3...Reading symbols from
/usr/lib/debug/usr/bin/python3.2mu...done.
done.
Starting program: /usr/bin/python3 /usr/bin/idle-python3.2 -n
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef1cd700 (LWP 2347)]
Program received signal SIGSEGV, Segmentation fault.
0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
(gdb) bt
#0 0x7fffec894b1f in ?? () from /usr/lib/libQtGui.so.4
#1 0x7053ad3f in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2 0x70537fb1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3 0x70538aa6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x7052e48d in XQueryTree () from /usr/lib/x86_64-linux-
gnu/libX11.so.6
#5 0x70b8a246 in Tk_HandleEvent () from /usr/lib/libtk8.5.so.0
#6 0x70b8a7c0 in ?? () from /usr/lib/libtk8.5.so.0
#7 0x708d564f in Tcl_ServiceEvent () from /usr/lib/libtcl8.5.so.0
#8 0x708d58d5 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
#9 0x711ba2e9 in ?? () from /usr/lib/python3.2/lib-
dynload/_tkinter.cpython-32mu.so
#10 0x00465d28 in call_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3875
#11 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#12 0x004675f2 in PyEval_EvalCodeEx (_co=value optimised out,
globals=value optimised out,
locals=value optimised out, args=value optimised out, argcount=1,
kws=0x12a0d40, kwcount=0,
defs=0xe76ba8, defcount=1, kwdefs=0x0, closure=0x0) at
../Python/ceval.c:3311
#13 0x00466784 in fast_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3973
#14 call_function (f=value optimised out, throwflag=value optimised out) at
../Python/ceval.c:3896
#15 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#16 0x00466ae0 in fast_function (f=value optimised out,
throwflag=value optimised out)
at ../Python/ceval.c:3963
#17 call_function (f=value optimised out, throwflag=value optimised out) at
../Python/ceval.c:3896
#18 PyEval_EvalFrameEx (f=value optimised out, throwflag=value optimised
out)
at ../Python/ceval.c:2673
#19 0x004675f2 in PyEval_EvalCodeEx (_co=value optimised out,
globals=value optimised out,
locals=value optimised out, args=value optimised out, argcount=0,
kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at ../Python/ceval.c:3311
#20 0x0046787b in PyEval_EvalCode (co=value optimised out,
globals=value optimised out,
locals=value optimised out) at ../Python/ceval.c:761
#21 0x0048d00d in run_mod (fp=0xb149b0, filename=value optimised out,
start=value optimised out, globals=
{'QtGui': module at remote 0x196c6c8, '__builtins__': module at remote
0x77fb1638, '__file__'---Type return to continue, or q return to
quit---
q
Quit
(gdb) quit
A debugging session is active.
Inferior 1 [process 2344] will be killed.
Quit anyway? (y or n) y
ak@supremo:~$
It is clear that there is segmentation fault. I do not know how to read the
dbg output and would appreciate advice whether the output is useful or not.
@ Pete - do you want me to do any more testing? If yes, just let me know.
Thanks again!
OldAl.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
