New submission from John Bollinger :
This is the same as issue 452973, created as a new issue pursuant to the
instruction given when 452973 was closed as "out of date".
In a nutshell, in a program using combining Tkinter with Tcl callbacks written
in C, it is possible for eve
John Bollinger added the comment:
I was already working on a standalone test, and now I have it ready. Using it
I can demonstrate the issue against both the cpython trunk and against my local
v2.6.6 binary distribution, therefore I have added v3.3 as an affected version.
It is reasonable
John Bollinger added the comment:
For what it's worth, I can convert my standalone test into a PyUnit testcase
easily enough (or so it appears). I'm having trouble, however, figuring out
how to get the extension it depends on built and accessible to the test, yet
not installe
John Bollinger added the comment:
I looked at the packaging tests (thanks), but I didn't find anything useful to
me. There were a couple whose names looked promising, but they turned out to
be stubs. As far as I can tell, none of those tests actually invoke the
system's C comp
New submission from John Bollinger :
I encountered this test failure while attempting to verify a patch for a
separate issue, and I found that it occurs with the unmodified source on the
default branch:
LD_LIBRARY_PATH="$PWD" ./python -bb -Wd -m test -r -w -uall -v test_curses
John Bollinger added the comment:
I attach a patch fixing the issue and providing a test and docs.
The fix is substantially as I described earlier: a thread that holds the Tcl
lock is permitted to acquire it logically any number of times, but physically
attempts to acquire it only if it
John Bollinger added the comment:
Yes, I have basically made tkinter's Tcl lock into an Rlock. With respect to
Python3's Rlock implementation, though, are you talking about what I see in
Modules/_threadmodule.c? Even if it would be acceptable to make the tkinter
module depend on
John Bollinger added the comment:
The system on which I encountered the test failure uses ncurses 5.7, so that's
consistent with the theory that the test is tickling an ncurses bug.
I'll have a look at testing with ncurses 5.8, but it is not available from
RedHat or CentOS (and it
John Bollinger added the comment:
Clarification: "so that's not a good solution for most users" ... of
RedHat-family distros, version 6.2 and earlier.
In fact, it looks like RedHat is sticking with its current version of ncurses
for RHEL 6.3, too, so no help is coming from tha
John Bollinger added the comment:
Ok, I confirm that the test passes after the system's ncurses library is
upgraded to ncurses 5.8, and fails again when ncurses is downgraded back to
version 5.7.
--
___
Python tracker
<http://bugs.py
10 matches
Mail list logo
