From mike at pcblokes.com Fri Dec 3 18:56:39 2004 From: mike at pcblokes.com (Michael Foord) Date: Fri Dec 3 18:56:30 2004 Subject: [Idle-dev] IDLE Development and Suggestions Message-ID: <41B0A8D7.8040309@pcblokes.com> Is their still progress on the development of IDLE ? (This group is very quiet !). I generally find IDLE a very nice editor. It has a few minor flaws that make it a bit more annoying to use than it should be though : Under windows subprocess crashes IDLE if it has more than one interactive shell open - editing modules without a subprocess is very frustrating ! A lack of horizontal scrollbar No cut and past in the context menu (selected text disappears when you right click because you've forgotten IDLE doesn't have cut and paste like everything else - doh !) In windows it is normal to leave the contents of the clipboard when closing an application. Loads of times I've opened IDLE, copied some code I need and closed IDLE again. Gone to paste it into another application *damn* it's vanished from the clipboard.... I've also been having fun trying to bundle IDLE using py2exe. I'll send a separate email about that. Best Regards, Michael Foord http://www.voidspace.org.uk/atlantibots/pythonutils.html From mike at pcblokes.com Fri Dec 3 19:07:44 2004 From: mike at pcblokes.com (Michael Foord) Date: Fri Dec 3 19:07:46 2004 Subject: [Idle-dev] Bundling IDLE with py2exe Message-ID: <41B0AB70.3040505@pcblokes.com> I'm attempting to bundle IDLE with py2exe (at one of my jobs I don't have admin rights.. so can't install anything - but I can run stuff that doesn't need installing). I've overcome the first couple of problems (py2exe files don't have a __file__ attribute, IDLE uses __import__ so I need to manually add some modules etc). However - what I have got so far doesn't work, unsurprisingly. What it does do is rather surprising and I'd appreciate a bit of help knowing where to look. When I launch my current idle.exe it launches literally hundreds of subprocesses. I then have to reboot ! Any clues as to where in the code this would be happening from ? Regards, Fuzzy http://www.voidspace.org.uk/atlantibots/pythonutils.html From cyber_rebate at cox.net Thu Dec 16 09:10:46 2004 From: cyber_rebate at cox.net (cyber_rebate) Date: Thu Dec 16 09:05:04 2004 Subject: [Idle-dev] coloring letters in output idle window Message-ID: <002a01c4e346$bf613050$6401a8c0@C3> Hello, Is there a way to specify the text color using Python 2.3.4 or Idle 1.0.3 ? I'm using python 2.3.4 with idle 1.0.3 to write some encryption programs and want to print the plaintext in one color and the ciphertext in a different color. Also it would be nice when using regular expressions to color matches a different color than the text that doesn't match. Can different colors be sent to the Idle output window? Thanks, Dillweed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20041216/d3ebfef1/attachment.html From gvanrossum at gmail.com Thu Dec 16 17:32:46 2004 From: gvanrossum at gmail.com (Guido van Rossum) Date: Thu Dec 16 17:32:49 2004 Subject: [Idle-dev] coloring letters in output idle window In-Reply-To: <002a01c4e346$bf613050$6401a8c0@C3> References: <002a01c4e346$bf613050$6401a8c0@C3> Message-ID: > Is there a way to specify the text color using Python 2.3.4 or Idle 1.0.3 > ? > > I'm using python 2.3.4 with idle 1.0.3 to write some encryption programs and > want to print the plaintext in one color and the ciphertext in a different > color. Python itself doesn't have this option. In IDLE, a hack would be to switch between writing to sys.stdout and sys.stderr -- these are displayed in different colors. But this only works in IDLE, and your program would print everything in the same boring color on all other platforms (plus, the interspersing of stdout and stderr depends on the buffering options for both files unless you use flush() a lot). > Also it would be nice when using regular expressions to color matches a > different color than the text that doesn't match. Can different colors be > sent to the Idle output window? In general, when you find this need, you should consider building a real GUI using Tkinter (the same toolkit used to create IDLE) or wxPython, but those have serious learning curves. I find Fredrik Lundh's tutorials and examples on effbot.org very helpful; there's also a book, Python and Tkinter Programming by John E. Grayson, which you may find second-hand on the web. If you're on Unix (including Linux), the curses module will let you do this; it also has a bit of a learning curve but not quite as much as the typical GUI toolkit. Most terminal emulators (but not IDLE) also support using escape sequences for specifying colors (this is how curses works). Googling for ANSI escapes should get you the basic idea (ESC is "\033" in Python). This should work on Windows in CMD windows and on Unix in most terminal programs (e.g. xterm). I think support in remote terminal programs (e.g. putty on Windows) is spotty; you might end up with only being able to choose between regular and bold. Good luck! -- --Guido van Rossum (home page: http://www.python.org/~guido/) From john.zelle at wartburg.edu Thu Dec 16 18:25:23 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Thu Dec 16 18:28:06 2004 Subject: [Idle-dev] Leaving subprocesses hanging Message-ID: <41C1C503.6040300@wartburg.edu> Hello all, I'm new to the idle-dev list, but felt I needed to post here for some assistance. I am in communication with a number of college faculty using Python to teach introductory programming courses. There has been growing frustration that newer versions of IDLE seem to be less stable. In particular, especially under Windows XP, there are times when IDLE becomes unresponsive (hangs). This seems to be related to losing proper communication with its subprocess. The only way to get things cleaned up again is to go into the process manager and kill the stray pythonw processes. Unfortunately, the behavior is sporadic and hard to pin down. I did a little poking around in the idle-dev archives and did not see anything about this problem, so I did a bit of experimenting on my own. One simple case that causes IDLE to hang is to simply close the shell while the program that it is executing is waiting for input. After IDLE asks if it should kill the program, it usually hangs. If it doesn't do this the first time, a couple of -close sequences will produce it. I modified PyShell.py in IDLE 1.03 by adding a call to cancel_callback() before closing the shell window. This seems to solve the problem (perhaps in an inelegant way). I do not know yet if fixing this "special" case solves the larger instability problems. I'm hoping some of the reader of edu-sig are trying it out and will let me know. In the mean time, I'd appreciate hearing if this is a known problem that is being worked on in IDLE. My preliminary test of IDLE 1.1 shows that it still suffers from the specific hang that I've identified. --John From mike at pcblokes.com Fri Dec 17 13:25:53 2004 From: mike at pcblokes.com (Michael Foord) Date: Fri Dec 17 13:25:58 2004 Subject: [Idle-dev] Infinite Subprocesses and IDLE Message-ID: <41C2D051.7000308@pcblokes.com> A couple of weeks ago (? - approx !) I posted a question to this group. I was trying to build IDLE with py2exe and was getting an infinite number of subprocesses launched. I didn't get a response - but in the process of experimenting with 'testenv' (experimental 'Python runtime' that is becoming 'movable python') I discovered the problem. In the spawn_subprocess function in PyShell.py it uses sys.executable to launch the subprocess. When I was freezing IDLE with py2exe - the program pointed to by sys.executable was idle.exe... which launched idle.exe... which launched idle.exe ! With testenv I hacked PyShell so that it launched a genuine subprocess and got it a lot closer to working. It didn't look like the two processes were 'talking to each other' properly though. In fact SPE with wxpython works without amendment - and I'm getting assistance from Stani on the 'movable python' project - so I probably *won't* continue to try and get IDLE working. I thought I would send this for the sake of completeness though. Regards, Fuzzyman http://www.voidspace.org.uk/atlantibots/pythonutils.html From kbk at shore.net Sat Dec 18 08:05:11 2004 From: kbk at shore.net (Kurt B. Kaiser) Date: Sat Dec 18 08:05:35 2004 Subject: [Idle-dev] Leaving subprocesses hanging In-Reply-To: <41C1C503.6040300@wartburg.edu> (John Zelle's message of "Thu, 16 Dec 2004 11:25:23 -0600") References: <41C1C503.6040300@wartburg.edu> Message-ID: <87brcsqe6w.fsf@hydra.bayview.thirdcreek.com> John Zelle writes: > I'm new to the idle-dev list, but felt I needed to post here for some > assistance. I am in communication with a number of college faculty > using Python to teach introductory programming courses. There has been > growing frustration that newer versions of IDLE seem to be less > stable. In particular, especially under Windows XP, there are times > when IDLE becomes unresponsive (hangs). This seems to be related to > losing proper communication with its subprocess. The only way to get > things cleaned up again is to go into the process manager and kill the > stray pythonw processes. Unfortunately, the behavior is sporadic and > hard to pin down. This is the major difficulty with using subprocess execution on Windows. I spent quite a bit of time on the 'hanging subprocess' bug a year and a half ago. The bug was so persistent I've named it 'Freddy'. My priority with IDLE is to choose stability over bells/whistles. IDLE is intended to be used for introductory programming as well as by advanced programmers, but beginners take precedence in my view. At one time (May '03), I was interrupting the subprocess before restarting it but the resulting traceback was slowing down the restart considerably. So I redesigned the subprocess so that a loss of socket connection to the GUI would invoke an interrupt of the main thread (which is executing the user's code). The GUI causes the subprocess to restart by simply closing the socket. On Unix, a TERM signal is also sent to the subprocess, but that's not available on Windows. > I did a little poking around in the idle-dev archives and did not >see anything about this problem, so I did a bit of experimenting on >my own. One simple case that causes IDLE to hang is to simply close >the shell while the program that it is executing is waiting for >input. After IDLE asks if it should kill the program, it usually >hangs. If it doesn't do this the first time, a couple of -close >sequences will produce it. OK, so I assume you are using something like .>>> a = raw_input('prompt: ') and then either clicking the shell window close widget or using F5. That's actually two different scenarios. I'll go off and duplicate them. > I modified PyShell.py in IDLE 1.03 by adding a call to > cancel_callback() before closing the shell window. This seems to > solve the problem (perhaps in an inelegant way). Where, exactly, did you put this code? Did it fix the problem you mentioned with -close sequences? > I do not know yet if fixing this "special" case solves the larger > instability problems. Shutting down the subprocess on Windows involves having it detect the loss of connection and then successfully shut down the main thread, the socket thread, and any threads associated with GUI communication. It's complicated, and 'fixes' tend to regress older issues. > I'm hoping some of the reader of edu-sig are trying it out and will > let me know. > > In the mean time, I'd appreciate hearing if this is a known problem > that is being worked on in IDLE. My preliminary test of IDLE 1.1 shows > that it still suffers from the specific hang that I've identified. It's an old problem which I thought was fixed since it hasn't been reported recently. I hope that edu-sig and c.l.p will bring stability issues to this list if they can't enter them on the Python Bug tracker. I'm also interested in discussing IDLE usability issues, especially in an educational context. That's appropriate for this list. -- KBK From john.zelle at wartburg.edu Sat Dec 18 17:03:52 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Sat Dec 18 17:06:35 2004 Subject: [Idle-dev] Leaving subprocesses hanging In-Reply-To: <87brcsqe6w.fsf@hydra.bayview.thirdcreek.com> References: <41C1C503.6040300@wartburg.edu> <87brcsqe6w.fsf@hydra.bayview.thirdcreek.com> Message-ID: <41C454E8.4040305@wartburg.edu> Kurt, Thanks for the reply on this. Very helpful info. Kurt B. Kaiser wrote: >John Zelle writes: > > > >>I'm new to the idle-dev list, but felt I needed to post here for some >>assistance. I am in communication with a number of college faculty >>using Python to teach introductory programming courses. There has been >>growing frustration that newer versions of IDLE seem to be less >>stable. In particular, especially under Windows XP, there are times >>when IDLE becomes unresponsive (hangs). This seems to be related to >>losing proper communication with its subprocess. The only way to get >>things cleaned up again is to go into the process manager and kill the >>stray pythonw processes. Unfortunately, the behavior is sporadic and >>hard to pin down. >> >> > >This is the major difficulty with using subprocess execution on >Windows. > >I spent quite a bit of time on the 'hanging subprocess' bug a year and >a half ago. The bug was so persistent I've named it 'Freddy'. > >My priority with IDLE is to choose stability over bells/whistles. >IDLE is intended to be used for introductory programming as well as by >advanced programmers, but beginners take precedence in my view. > >At one time (May '03), I was interrupting the subprocess before >restarting it but the resulting traceback was slowing down the restart >considerably. So I redesigned the subprocess so that a loss of socket >connection to the GUI would invoke an interrupt of the main thread >(which is executing the user's code). The GUI causes the subprocess to >restart by simply closing the socket. On Unix, a TERM signal is also >sent to the subprocess, but that's not available on Windows. > > > Stability would also be my first choice in IDLE. It's just so crucial for new programmers to have an evironment that responds the way that they expect it to. I'm glad to hear that someone has been working on 'Freddy.' >>I did a little poking around in the idle-dev archives and did not >>see anything about this problem, so I did a bit of experimenting on >>my own. One simple case that causes IDLE to hang is to simply close >>the shell while the program that it is executing is waiting for >>input. After IDLE asks if it should kill the program, it usually >>hangs. If it doesn't do this the first time, a couple of -close >>sequences will produce it. >> >> > >OK, so I assume you are using something like > >.>>> a = raw_input('prompt: ') > >and then either clicking the shell window close widget or using F5. >That's actually two different scenarios. I'll go off and duplicate >them. > > > This is basically it. I actually put this line in a script, load the script and it. When the shell is waiting for input, closing the shell window either by clicking on the window's close box or by selecting close from the file menu will produce the error. From what I saw in the code, these are equivalent actions. I think as of version 1.04, rather than a pure hang what happens is that the next time is done, IDLE pops up the message window about the socket being in use. If the shell window is waiting for user input and you do in the script window, the shell does do a clean restart, although it seems as if one needs to hit in the shell window before the prompt will display again. >>I modified PyShell.py in IDLE 1.03 by adding a call to >>cancel_callback() before closing the shell window. This seems to >>solve the problem (perhaps in an inelegant way). >> >> > >Where, exactly, did you put this code? Did it fix the problem >you mentioned with -close sequences? > > > I modified the PyShell close method: def close(self): "Extend EditorWindow.close()" if self.executing: response = tkMessageBox.askokcancel( "Kill?", "The program is still running!\n Do you want to kill it?", default="ok", parent=self.text) if response == False: return "cancel" self.cancel_callback() # This line inserted by JMZ self.closing = True # Wait for poll_subprocess() rescheduling to stop self.text.after(2 * self.pollinterval, self.close2) This fix does solve the problem that I describe. I noticed that sending a keyboard interrupt before closing the shell seemed to take care of the problem, so I just inserted the cancel_callback() into the close sequence. It seemed the safest way to go (without understanding the intricacies of the subprocess code). It does have the drawback of producing a bit of "chatter" in the shell window just before it goes away. By the way, this same bug appears under Linux as well, so It's not just the Windows subprocess issues in this case. This seems to work fine on IDLE 1.03-1.04. I've been working with it for a couple days and have not noticed any problems. Unfortunately, last night I tried the same fix on IDLE 1.1, and I ran into some problems. Has the subprocess code undergone significant revision from 1.04 to 1.1? >>I do not know yet if fixing this "special" case solves the larger >>instability problems. >> >> > >Shutting down the subprocess on Windows involves having it detect the >loss of connection and then successfully shut down the main thread, >the socket thread, and any threads associated with GUI communication. >It's complicated, and 'fixes' tend to regress older issues. > > > Yes, this does seem to be a particularly ticklish issue. That's why I used a Band-Aid approach. Anecdotally, the general instability problem seems to have gotten a bit worse from version 1.0 to 1.03. We run 1.0 in our labs and have had only occasional problems, most of which I think are linked to quitting the shell when the subprocess is expecting input. I've heard from other schools that their problems have been so severe and frustrating (versions 1.03 and 1.04) that they are looking at alternatives. >>I'm hoping some of the reader of edu-sig are trying it out and will >>let me know. >> >>In the mean time, I'd appreciate hearing if this is a known problem >>that is being worked on in IDLE. My preliminary test of IDLE 1.1 shows >>that it still suffers from the specific hang that I've identified. >> >> > >It's an old problem which I thought was fixed since it hasn't been >reported recently. > >I hope that edu-sig and c.l.p will bring stability issues to this list >if they can't enter them on the Python Bug tracker. > > > OK, could you enlighten me a bit. Where should I have been looking to find what you've been working on, and where should we be reporting such issues. Obviously, I finally decided to post here because of the questions that I've been getting from colleagues at other schools. As I said, our problems have not been so serious. To be honest, I haven't even been able to track down who's even actively developing IDLE at this point. The python.org/idle page is not really that informative. >I'm also interested in discussing IDLE usability issues, especially >in an educational context. That's appropriate for this list. > > > Great, then perhaps I've found another "home." Thanks for all the work you and others already done on IDLE. It's been a great IDE for us. It's nice to be able to point people to Python and say that everything you need, IDE and all, is in the bundle. --John From ajsiegel at optonline.net Sun Dec 19 15:09:23 2004 From: ajsiegel at optonline.net (Arthur) Date: Sun Dec 19 15:09:41 2004 Subject: [Idle-dev] re: Leaving subprocesses hanging Message-ID: <0I8Z0048G3BT3Q@mta9.srv.hcvlny.cv.net> John writes - >This seems to work fine on IDLE 1.03-1.04. I've been working with it for >a couple days and have not noticed any problems. Unfortunately, last >night I tried the same fix on IDLE 1.1, and I ran into some problems. >Has the subprocess code undergone significant revision from 1.04 to 1.1? Is there a possibility that the issue is differences in the versions of tcl/tk against which it is running, rather than in changes in Idle . It is known that threading related code that worked against 8.3 breaks under 8.4 as tcl seems to have changed its own threading model. There is some writing out there by Martin v. L?wis about this change in tcl's model and the changes it necessitated in Python's tkinter code. Unfortunately I can't seem to trace my steps back to it right now. Is it reasonable to suspect there is relationship here somewhere with Freddy? Not that knowing that gets us anywhere in particular, but it might contain a clue. Are you running IDLE 1.03 against the same tcl/tk versions as you are running IDLE 1.1? Art From jschull at softlock.com Sun Dec 19 00:52:57 2004 From: jschull at softlock.com (Jon Schull) Date: Sun Dec 19 15:21:38 2004 Subject: [Idle-dev] can't run idle. ImportError: cannot import name print_exc Message-ID: Greetings. I've lost the ability to run idle. Perhaps the information below will help? 208-186-56-189:~ jis$ idle -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied 208-186-56-189:~ jis$ sudo idle Password: Traceback (most recent call last): File "/sw/bin/idle", line 3, in ? from idlelib.PyShell import main File "/sw/src/root-python23-2.3.4-2/sw/lib/python2.3/idlelib/PyShell.py", line 11, in ? File "/sw/lib/python2.3/threading.py", line 13, in ? from traceback import print_exc as _print_exc ImportError: cannot import name print_exc 208-186-56-189:~ jis$ find idle find: idle: No such file or directory 208-186-56-189:~ jis$ /sw/bin/python -v # installing zipimport hook import zipimport # builtin # installed zipimport hook # /sw/lib/python2.3/site.pyc matches /sw/lib/python2.3/site.py import site # precompiled from /sw/lib/python2.3/site.pyc # /sw/lib/python2.3/os.pyc matches /sw/lib/python2.3/os.py import os # precompiled from /sw/lib/python2.3/os.pyc import posix # builtin # /sw/lib/python2.3/posixpath.pyc matches /sw/lib/python2.3/posixpath.py import posixpath # precompiled from /sw/lib/python2.3/posixpath.pyc # /sw/lib/python2.3/stat.pyc matches /sw/lib/python2.3/stat.py import stat # precompiled from /sw/lib/python2.3/stat.pyc # /sw/lib/python2.3/UserDict.pyc matches /sw/lib/python2.3/UserDict.py import UserDict # precompiled from /sw/lib/python2.3/UserDict.pyc # /sw/lib/python2.3/copy_reg.pyc matches /sw/lib/python2.3/copy_reg.py import copy_reg # precompiled from /sw/lib/python2.3/copy_reg.pyc # /sw/lib/python2.3/types.pyc matches /sw/lib/python2.3/types.py import types # precompiled from /sw/lib/python2.3/types.pyc # /sw/lib/python2.3/warnings.pyc matches /sw/lib/python2.3/warnings.py import warnings # precompiled from /sw/lib/python2.3/warnings.pyc # /sw/lib/python2.3/linecache.pyc matches /sw/lib/python2.3/linecache.py import linecache # precompiled from /sw/lib/python2.3/linecache.pyc import encodings # directory /sw/lib/python2.3/encodings # /sw/lib/python2.3/encodings/__init__.pyc matches /sw/lib/python2.3/encodings/__init__.py import encodings # precompiled from /sw/lib/python2.3/encodings/__init__.pyc # /sw/lib/python2.3/codecs.pyc matches /sw/lib/python2.3/codecs.py import codecs # precompiled from /sw/lib/python2.3/codecs.pyc import _codecs # builtin # /sw/lib/python2.3/encodings/aliases.pyc matches /sw/lib/python2.3/encodings/aliases.py import encodings.aliases # precompiled from /sw/lib/python2.3/encodings/aliases.pyc # /sw/lib/python2.3/encodings/ascii.pyc matches /sw/lib/python2.3/encodings/ascii.py import encodings.ascii # precompiled from /sw/lib/python2.3/encodings/ascii.pyc Python 2.3.4 (#1, Nov 7 2004, 14:21:14) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. import readline # dynamically loaded from /sw/lib/python2.3/lib-dynload/readline.so >>> ^c # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] site # cleanup[1] encodings # cleanup[1] _codecs # cleanup[1] zipimport # cleanup[1] warnings # cleanup[1] encodings.ascii # cleanup[1] codecs # cleanup[1] readline # cleanup[1] types # cleanup[1] signal # cleanup[1] linecache # cleanup[1] posix # cleanup[1] encodings.aliases # cleanup[1] exceptions # cleanup[2] copy_reg # cleanup[2] posixpath # cleanup[2] os.path # cleanup[2] stat # cleanup[2] UserDict # cleanup[2] os # cleanup sys # cleanup __builtin__ # cleanup ints: 4 unfreed ints in 1 out of 2 blocks # cleanup floats 208-186-56-189:~ jis$ idle -bash: /sw/lib/python2.3/idlelib/idle.py: Permission denied 208-186-56-189:~ jis$ /sw/bin/python /sw/lib/python2.3/idlelib/idle.py Traceback (most recent call last): File "", line 1, in ? File "/sw/lib/python2.3/idlelib/run.py", line 7, in ? import threading File "/sw/lib/python2.3/threading.py", line 13, in ? from traceback import print_exc as _print_exc ImportError: cannot import name print_exc ^CTraceback (most recent call last): File "/sw/lib/python2.3/idlelib/idle.py", line 21, in ? PyShell.main() File "/sw/lib/python2.3/idlelib/PyShell.py", line 1287, in main flist.pyshell = PyShell(flist) File "/sw/lib/python2.3/idlelib/PyShell.py", line 769, in __init__ self.interp.start_subprocess() File "/sw/lib/python2.3/idlelib/PyShell.py", line 362, in start_subprocess self.rpcclt.accept() File "/sw/lib/python2.3/idlelib/rpc.py", line 526, in accept working_sock, address = self.listening_sock.accept() File "/sw/lib/python2.3/socket.py", line 167, in accept sock, addr = self._sock.accept() KeyboardInterrupt 208-186-56-189:~ jis$ sudo /sw/bin/python /sw/lib/python2.3/idlelib/idle.py Password: Traceback (most recent call last): File "", line 1, in ? File "/sw/lib/python2.3/idlelib/run.py", line 7, in ? import threading File "/sw/lib/python2.3/threading.py", line 13, in ? from traceback import print_exc as _print_exc ImportError: cannot import name print_exc =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5785 bytes Desc: not available Url : http://mail.python.org/pipermail/idle-dev/attachments/20041218/11a9acf6/attachment.bin From john.zelle at wartburg.edu Sun Dec 19 21:03:23 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Sun Dec 19 21:06:09 2004 Subject: [Idle-dev] re: Leaving subprocesses hanging In-Reply-To: <0I8Z0048G3BT3Q@mta9.srv.hcvlny.cv.net> References: <0I8Z0048G3BT3Q@mta9.srv.hcvlny.cv.net> Message-ID: <41C5DE8B.2000804@wartburg.edu> I did some more checking on this. My fix _does_ seem to work on IDLE 1.1. I'm not sure what I was doing wrong before. It may be that I was accidently mixing my 2.3 and 2.4 libraries. Or maybe I'm just suffering from too much end-of-term grading :-). --John Arthur wrote: >John writes - > > > >>This seems to work fine on IDLE 1.03-1.04. I've been working with it for >>a couple days and have not noticed any problems. Unfortunately, last >>night I tried the same fix on IDLE 1.1, and I ran into some problems. >>Has the subprocess code undergone significant revision from 1.04 to 1.1? >> >> > >Is there a possibility that the issue is differences in the versions of >tcl/tk against which it is running, rather than in changes in Idle . > >It is known that threading related code that worked against 8.3 breaks under >8.4 as tcl seems to have changed its own threading model. There is some >writing out there by Martin v. L?wis about this change in tcl's model and >the changes it necessitated in Python's tkinter code. Unfortunately I can't >seem to trace my steps back to it right now. > >Is it reasonable to suspect there is relationship here somewhere with >Freddy? > >Not that knowing that gets us anywhere in particular, but it might contain a >clue. > >Are you running IDLE 1.03 against the same tcl/tk versions as you are >running IDLE 1.1? > >Art > > >_______________________________________________ >IDLE-dev mailing list >IDLE-dev@python.org >http://mail.python.org/mailman/listinfo/idle-dev > > > > From kbk at shore.net Thu Dec 23 07:08:17 2004 From: kbk at shore.net (Kurt B. Kaiser) Date: Thu Dec 23 07:08:45 2004 Subject: [Idle-dev] Leaving subprocesses hanging References: <41C1C503.6040300@wartburg.edu> <87brcsqe6w.fsf@hydra.bayview.thirdcreek.com> <41C454E8.4040305@wartburg.edu> Message-ID: <87hdmdmtri.fsf@hydra.bayview.thirdcreek.com> John Zelle writes: > By the way, this same bug appears under Linux as well, so It's not >just the Windows subprocess issues in this case. Yes. Actually this bug is caused by the readline() mainloop not being exited when the keyboard interrupt is serviced. It's not a subprocess issue, though the symptoms are slightly different when IDLE is run without its subprocess (-n switch). > This seems to work fine on IDLE 1.03-1.04. I've been working with it >for a couple days and have not noticed any problems. Unfortunately, >last night I tried the same fix on IDLE 1.1, and I ran into some >problems. Has the subprocess code undergone significant revision from >1.04 to 1.1? OK, I understand it's now working again for you. No, no really significant changes from 1.0.4 to 1.1, but see below. I've checked in a patch (see below) which I believe fixes the problem. It's of long standing, dating back to PyShell.py Rev 1.56 17Feb03 (before the release of IDLE 1.0, and before IDLEfork was merged into Python), and it's my error. It's amazing that no one complained before. I'm adding it to my list of monkey tests. >>>I do not know yet if fixing this "special" case solves the larger >>> instability problems. >>> >> >>Shutting down the subprocess on Windows involves having it detect the >>loss of connection and then successfully shut down the main thread, >>the socket thread, and any threads associated with GUI communication. >>It's complicated, and 'fixes' tend to regress older issues. >> >> >> > Yes, this does seem to be a particularly ticklish issue. That's why I > used a Band-Aid approach. Anecdotally, the general instability > problem seems to have gotten a bit worse from version 1.0 to 1.03. We > run 1.0 in our labs and have had only occasional problems, most of > which I think are linked to quitting the shell when the subprocess is > expecting input. I've heard from other schools that their problems > have been so severe and frustrating (versions 1.03 and 1.04) that they > are looking at alternatives. This is certainly not what we want to hear! In my view it's gotten better, but I did recently add Tk dialogs which pop up when the GUI and the subprocess are having communication problems. That would make formerly silent errors (unless you are running from a command window) more apparent and might add to an impression of instability. The major remaining problem is that on Windows it's possible to (partially) start more than one copy of IDLE by binding multiple copies to the same port. This seems to be a deficiency in the Windows socket implementation. Unfortunately, it's not easy to fix because there is an additional problem: Windows doesn't remove abandoned socket connections from its kernel table, which has a limit of only five pending connections. Therefore until I can fix this, it's important not to start more than one copy of IDLE! >>>I'm hoping some of the reader of edu-sig are trying it out and will >>>let me know. >>> >>>In the mean time, I'd appreciate hearing if this is a known problem >>>that is being worked on in IDLE. My preliminary test of IDLE 1.1 shows >>>that it still suffers from the specific hang that I've identified. >>> >>It's an old problem which I thought was fixed since it hasn't been >> reported recently. >> >>I hope that edu-sig and c.l.p will bring stability issues to this list >>if they can't enter them on the Python Bug tracker. >> > OK, could you enlighten me a bit. Where should I have been looking to > find what you've been working on, and where should we be reporting > such issues. Obviously, I finally decided to post here because of the > questions that I've been getting from colleagues at other schools. As > I said, our problems have not been so serious. To be honest, I haven't > even been able to track down who's even actively developing IDLE at > this point. The python.org/idle page is not really that informative. This is the list for IDLE development, so any concerned users are more than welcome to discuss any issues regarding features, stability, and future directions. Please direct your colleagues over here. Development is done on Sourceforge: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/idlelib/ The bug tracker is at http://sourceforge.net/tracker/?group_id=5470&atid=105470 Set the "category" field to IDLE, "status" Open, "assignee" and "group" to Any. The patch tracker is at http://sourceforge.net/tracker/?group_id=5470&atid=305470 same settings. One of these days something should be done to update the IDLE home page and the tutorial. >>I'm also interested in discussing IDLE usability issues, especially >>in an educational context. That's appropriate for this list. >> >> > Great, then perhaps I've found another "home." > > Thanks for all the work you and others already done on IDLE. It's been > a great IDE for us. It's nice to be able to point people to Python and > say that everything you need, IDE and all, is in the bundle. That's right, and IDLE is a lot more capable than people may realize. I use Emacs with python-mode about half the time, and IDLE the rest of the time. But I'm using Emacs less and less as I add capability to IDLE. When I'm not developing IDLE itself I rarely use Emacs for Python these days, even though I basically live in Emacs for any other editing or mail/news handling. IDLE is faster with the F5 and autosave. But I agree that it's just /critical/ that IDLE work perfectly out of the box. There is nothing worse than having your exposition to a beginner interrupted because there's a problem with the tool you are using. And beginners can certainly find the bugs.... I hope than anyone who has stability issues with IDLE will either enter a bug on the tracker or post here. I'll be away for a few days over Xmas, but check out the patch and let me know. Thanks for the report. -- KBK Index: PyShell.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/PyShell.py,v retrieving revision 1.93 diff -u -u -r1.93 PyShell.py --- PyShell.py 21 Dec 2004 22:10:32 -0000 1.93 +++ PyShell.py 23 Dec 2004 04:19:10 -0000 @@ -910,6 +910,9 @@ parent=self.text) if response == False: return "cancel" + if self.reading: + self.top.quit() + self.canceled = True self.closing = True # Wait for poll_subprocess() rescheduling to stop self.text.after(2 * self.pollinterval, self.close2) @@ -974,10 +977,12 @@ save = self.reading try: self.reading = 1 - self.top.mainloop() + self.top.mainloop() # nested mainloop() finally: self.reading = save line = self.text.get("iomark", "end-1c") + if len(line) == 0: # may be EOF if we quit our mainloop with Ctrl-C + line = "\n" if isinstance(line, unicode): import IOBinding try: @@ -987,10 +992,11 @@ self.resetoutput() if self.canceled: self.canceled = 0 - raise KeyboardInterrupt + if not use_subprocess: + raise KeyboardInterrupt if self.endoffile: self.endoffile = 0 - return "" + line = "" return line def isatty(self): @@ -1009,13 +1015,13 @@ return "break" self.endoffile = 0 self.canceled = 1 - if self.reading: - self.top.quit() - elif (self.executing and self.interp.rpcclt): + if (self.executing and self.interp.rpcclt): if self.interp.getdebugger(): self.interp.restart_subprocess() else: self.interp.interrupt_subprocess() + if self.reading: + self.top.quit() # exit the nested mainloop() in readline() return "break" def eof_callback(self, event): From john.zelle at wartburg.edu Tue Dec 28 04:21:57 2004 From: john.zelle at wartburg.edu (John Zelle) Date: Tue Dec 28 04:25:18 2004 Subject: [Idle-dev] Leaving subprocesses hanging In-Reply-To: <87hdmdmtri.fsf@hydra.bayview.thirdcreek.com> References: <41C1C503.6040300@wartburg.edu> <87brcsqe6w.fsf@hydra.bayview.thirdcreek.com> <41C454E8.4040305@wartburg.edu> <87hdmdmtri.fsf@hydra.bayview.thirdcreek.com> Message-ID: <41D0D155.8070506@wartburg.edu> Kurt, Thanks for this wonderful response. I've applied that patch, and it seems to be working just dandy. I'm hoping that this along with your tip on avoiding multiple IDLEs under Windows will go a long way toward curing any remaining instabilities. I'll be passing this info along to the edu-sig group. Thanks also for the information IDLE forums, as we uncover any new issues, I'll be sure to keep you informed. --John Kurt B. Kaiser wrote: > > >I'll be away for a few days over Xmas, but check out the patch >and let me know. Thanks for the report. > > >