Eric Smith e...@trueblade.com added the comment:
The current patch (protect_tk_loading.diff) looks reasonable to me, and
it solves my problem with the tests hanging. So I'd suggest you commit
the patch, insofar it improves on the current situation.
I'm not an expert in tk, however. So if you're
Guilherme Polo ggp...@gmail.com added the comment:
Thanks Eric, committed in r69473.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
Guilherme Polo ggp...@gmail.com added the comment:
A bit cleaner patch.
Added file: http://bugs.python.org/file12971/protect_tk_loading.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
Changes by Guilherme Polo ggp...@gmail.com:
Removed file:
http://bugs.python.org/file12960/checking_for_failed_tk_load-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
Changes by Guilherme Polo ggp...@gmail.com:
Removed file: http://bugs.python.org/file12958/checking_for_failed_tk_load.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
Eric Smith e...@trueblade.com added the comment:
protect_tk_loading.diff works for me.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
___
Guilherme Polo ggp...@gmail.com added the comment:
Eric, I noticed you said Fedora 6, so I checked which tcl/tk it
includes and apparently it is 8.4.13, is that correct ?
I tried using tcl/tk 8.4.13 and I managed to hang it too :)
Try running test_tcl followed by test_ttk_guionly with regrtest.
Eric Smith e...@trueblade.com added the comment:
Yes, I have these installed:
tcl-8.4.13-3.fc6
tcl-devel-8.4.13-3.fc6
tk-8.4.13-3.fc6
tk-devel-8.4.13-3.fc6
When I run ./python Lib/test/regrtest.py test_tcl test_ttk_guionly, it
hangs.
___
Python tracker
Guilherme Polo ggp...@gmail.com added the comment:
When I run ./python Lib/test/regrtest.py test_tcl test_ttk_guionly, it
hangs.
I have isolated it now:
Traceback (most recent call last):
File stdin, line 1, in module
File /home/gpolo/python-dev/python-trunk/Lib/lib-tk/Tkinter.py,
line
Guilherme Polo ggp...@gmail.com added the comment:
After I have isolated it now:, there should be this interactive
session (but gmail ate it apparently):
import os
del os.environ['DISPLAY']
import Tkinter
t = Tkinter.Tcl()
t.loadtk()
Traceback (most recent call last):
File stdin, line 1,
Guilherme Polo ggp...@gmail.com added the comment:
Ok, I've found the cause of the problem and the patch attached should
solve it but shouldn't be applied! This was just a quick fix I did to
confirm what I expected, I will add something more correct later.
_tkinter is aware of this deadlock
Eric Smith e...@trueblade.com added the comment:
The patch does solve the problem for me. It no longer hangs when running
either:
./python Lib/test/regrtest.py test_tcl test_ttk_guionly
or:
./python Lib/test/regrtest.py
-
...
test_traceback
test_transformer
test_ttk_guionly
Guilherme Polo ggp...@gmail.com added the comment:
Here is a better patch, for some definition of better.
It syncs the failed attempt to load tk that may occur in
_tkinter.Tkapp_TkInit, _tkinter.Tcl_AppInit and tkappinit.Tcl_AppInit.
And that is done only for tk 8.4.14 now.
Said that, I'm a
Guilherme Polo ggp...@gmail.com added the comment:
Any chance you can look at the proposed patch, Martin ? I found out that
it was you who reported this deadlock back then, so you might want to
review the patch.
--
nosy: +loewis
___
Python tracker
Eric Smith e...@trueblade.com added the comment:
The second patch (checking_for_failed_tk_load.diff) also works for me.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5122
___
Guilherme Polo ggp...@gmail.com added the comment:
Found a place still out of sync, it is fixed on this new patch. To
reproduce the problem with the previous patch try this:
import os
del os.environ['DISPLAY']
import Tkinter
Tkinter.Tk()
Tkinter.Tcl().loadtk() # should hang now (with a proper
Eric Smith e...@trueblade.com added the comment:
With the second patch installed, your code snippet does indeed hang for me.
With the third patch installed, I get:
[trunk]$ ./python
Python 2.7a0 (trunk:69369M, Feb 6 2009, 14:59:32)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type help,
Guilherme Polo ggp...@gmail.com added the comment:
Eric Smith added the comment:
.
.
Which I assume is the expected behavior.
Yes it is expected.
Also with the third patch installed, the regrtest's all pass.
Very nice.
And Eric, thanks for the patience and for testing them all.
New submission from Guilherme Polo ggp...@gmail.com:
Recently I've added this test named test_ttk_guionly, and I noticed some
buildslaves went red, like amd64 gentoo trunk and x86 FreeBSD trunk (I
though there were others for the reason I'm going to say next, but
didn't found on a quick look).
19 matches
Mail list logo
