From mpe501@chello.se Sat Feb 1 19:56:12 2003 From: mpe501@chello.se (mpe501@chello.se) Date: Sat, 1 Feb 2003 20:56:12 +0100 Subject: [Idle-dev] Non 7bit ascii characters in IDLE Message-ID: <20030201195612.RRZP14460.amsfep13-int.chello.nl@localhost> If i do something like: a = "ä" IDLE will barf and say something along the lines of "Unicode Error: Ordinal error". If i use idlefork i get a bunch of errors the moment i type a non 7bit ascii character: Exception in Tkinter callback Traceback (most recent call last): File "E:\Program\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "E:\Program\Python22\lib\lib-tk\Tkinter.py", line 436, in callit apply(func, args) File "E:\PROGRAM\PYTHON22\Tools\idle\ColorDelegator.py", line 144, in recolorize self.recolorize_main() File "E:\PROGRAM\PYTHON22\Tools\idle\PyShell.py", line 121, in recolorize_main ColorDelegator.recolorize_main(self) File "E:\PROGRAM\PYTHON22\Tools\idle\ColorDelegator.py", line 196, in recolorize_main if value in ("def", "class"): UnicodeError: UTF-16 decoding error: truncated data This may be because of my configuration but the people at #python haven't been able to help me so maybe it's a bug.... Please CC any replies to me since i'm not subscribed to the list. /David From jsteve17@tampabay.rr.com Tue Feb 4 04:12:49 2003 From: jsteve17@tampabay.rr.com (Jeffrey Stephens) Date: Mon, 3 Feb 2003 23:12:49 -0500 Subject: [Idle-dev] Bug in Idlefork 0.9a2 Message-ID: <200302032312.49918.jsteve17@tampabay.rr.com> Executing the following code in the Python Shell window - >>> print \ "Snake Ey\ es" produces output Snake Ey es Six spaces are inserted between the 'y' and 'e' in eyes. This works fine in a terminal window. Regards, Jeff Stephens=20 From kbk@shore.net Tue Feb 4 18:46:20 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 04 Feb 2003 13:46:20 -0500 Subject: [Idle-dev] Bug in Idlefork 0.9a2 In-Reply-To: <200302032312.49918.jsteve17@tampabay.rr.com> (Jeffrey Stephens's message of "Mon, 3 Feb 2003 23:12:49 -0500") References: <200302032312.49918.jsteve17@tampabay.rr.com> Message-ID: Jeffrey Stephens writes: > Executing the following code in the Python Shell window - > >>>> print \ > "Snake Ey\ > es" > > produces output > > Snake Ey es > > Six spaces are inserted between the 'y' and 'e' in eyes. > > This works fine in a terminal window. Actually, it doesn't, if you insert the tab that IDLE inserts for you: >>> print\ ... 'abc\ ... def' abc def So don't do that :) Seriously, this is also a 'problem' in Python IDLE all these years. However, if you use >>> print 'abc\ def\ ghi' abcdefghi it works ok. So does >>> print\ 'abc'\ 'def' abcdef And if you backspace the tab that IDLE inserts before you enter your first line, subsequent lines will line up and you get: >>> print\ 'abc\ def\ ghi' abcdefghi We'd be happy to receive a patch :) -- KBK From kbk@shore.net Tue Feb 4 19:37:07 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 04 Feb 2003 14:37:07 -0500 Subject: [Idle-dev] Non 7bit ascii characters in IDLE In-Reply-To: <20030201195612.RRZP14460.amsfep13-int.chello.nl@localhost> ('s message of "Sat, 1 Feb 2003 20:56:12 +0100") References: <20030201195612.RRZP14460.amsfep13-int.chello.nl@localhost> Message-ID: writes: > If i do something like: > a =3D "=E4" > IDLE will barf and say something along the lines of "Unicode Error: Ordin= al error". If i use idlefork i get a bunch of errors the moment i type a no= n 7bit ascii character: > Exception in Tkinter callback > Traceback (most recent call last): > File "E:\Program\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ > return apply(self.func, args) > File "E:\Program\Python22\lib\lib-tk\Tkinter.py", line 436, in callit > apply(func, args) > File "E:\PROGRAM\PYTHON22\Tools\idle\ColorDelegator.py", line 144, in r= ecolorize > self.recolorize_main() > File "E:\PROGRAM\PYTHON22\Tools\idle\PyShell.py", line 121, in recolori= ze_main > ColorDelegator.recolorize_main(self) > File "E:\PROGRAM\PYTHON22\Tools\idle\ColorDelegator.py", line 196, in r= ecolorize_main > if value in ("def", "class"): > UnicodeError: UTF-16 decoding error: truncated data > > > This may be because of my configuration but the people at #python haven't= been able to help me so maybe it's a bug.... > > Please CC any replies to me since i'm not subscribed to the list. Using IDLEfork0.9a2 and Python2.2.1 if I enter=20 a =3D u"\u00e4" print a I get an 'a' with an umlaut on my W2K box, and \u00e4 on my Linux box, which isn't set up with international fonts. You might try going to Python 2.3 and applying IDLEfork patch 615312. -- KBK From noreply@sourceforge.net Thu Feb 6 23:23:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Feb 2003 15:23:35 -0800 Subject: [Idle-dev] [ idlefork-Patches-681992 ] Better indentation after first line of string continuation Message-ID: Patches item #681992, was opened at 2003-02-07 01:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=681992&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Better indentation after first line of string continuation Initial Comment: This is a fix for Jeffrey Stephens' bug report: -------------------- From: Jeffrey Stephens Organization: Home User To: idle-dev@python.org Date: Mon, 3 Feb 2003 23:12:49 -0500 Subject: [Idle-dev] Bug in Idlefork 0.9a2 Executing the following code in the Python Shell window - >>> print \ "Snake Ey\ es" produces output Snake Ey es Six spaces are inserted between the 'y' and 'e' in eyes. This works fine in a terminal window. Regards, Jeff Stephens=20 ----------------------- The problem is that when IDLE detects string continuation, it indents the new line in the same way as the previous one. This makes sense if you are in the middle of a string, so the indentation of the previous line is a part of the string, but if the string starts at the current line, the indentation of the line is meaningless. The patch fixes that; if the string was started at the current line, no indentation at all is applied. I hope this helps a little, Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=681992&group_id=9579 From noreply@sourceforge.net Fri Feb 7 14:47:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 06:47:48 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From noreply@sourceforge.net Fri Feb 7 14:55:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 06:55:01 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-07 09:55 Message: Logged In: YES user_id=6380 Why would you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From noreply@sourceforge.net Fri Feb 7 15:35:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Feb 2003 07:35:04 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- >Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-07 15:35 Message: Logged In: YES user_id=36553 Two reasons. 1. The following script does not work correctly in IDLE: # -*- encoding: koi8-r -*- name = raw_input("What's your name?") print "Hi %s!" % name I use russian phrases here, of course. And if I enter my name using cyrillic letters, I get UnicodeError. This is because I mixed a Unicode string with with an 8-bit string. I know that I can use unicode literals, but I don't think that my students should know anything about Unicode, 6 cyrrilic encodings, etc, especially when they are writing their first program. Note that this program is absolutely correct and run perfectly from console. So I think that it should work in IDLE too. 2. I believe that raw_input() and stdin.readline() must always return either Unicode strings or 8-bit strings, but do not mix them. P.S. I think that -*- encoding -*- comments are very unfriendly for newbies too, but that's another story. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-07 14:55 Message: Logged In: YES user_id=6380 Why would you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From noreply@sourceforge.net Sat Feb 8 22:54:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 14:54:20 -0800 Subject: [Idle-dev] [ idlefork-Bugs-683123 ] An extension's event binding doesn't work Message-ID: Bugs item #683123, was opened at 2003-02-09 00:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=683123&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: An extension's event binding doesn't work Initial Comment: in config-extensions.def, is binded to CallTips' calltip-cancel event. It doesn't work - open a shell window, and type 'dir('. A yellow tip is displayed, but it you press the Escape button, it doesn't go away. It does go away if you click the shell window with the mouse, which is, I think, because the event is also binded to calltip-cancel. I'm using Debian woody, Python 2.2.1 with IDLEfork from the CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=683123&group_id=9579 From noreply@sourceforge.net Sat Feb 8 23:51:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Feb 2003 15:51:58 -0800 Subject: [Idle-dev] [ idlefork-Patches-673428 ] An extension to add command-wise navigation to the shell Message-ID: Patches item #673428, was opened at 2003-01-24 00:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=673428&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: An extension to add command-wise navigation to the shell Initial Comment: This extension enables navigating in the shell window according to Python commands, using the Alt key. Alt+Home goes to the beginning of the current command. Alt+End goes to the end of the current command. Alt+Up goes the the previous command. Alt+Down goes to the next command. This is, from my experience, useful for two things: 1. Many times, you want to recall a previous command. I think it is easier to do so in the context of its output and other commands, so instead of pressing alt+p, which brings all commands but leaves them out of context, you do alt+up to move quickly to the place where you used the command, and then you click enter. 2. if you want to delete the entire command you typed, especially if it contains multiple lines, you can now type alt+shift+home, to move to the beginning of the command while selecting the area, and press delete. I don't know of an easy way to do this previously. I wrote this as an extension, but I think the four events should go directly to the PyShell class. I think doing that is quite easy. I don't see a way to attach two files, and I don't want to bother you with another update, so you should add the attached file to the directory of IDLEfork, and add the following to config-extensions.def: [CommandNavigator] enable=1 [CommandNavigator_bindings] beg_of_command= end_of_command= prev_command= next_command= ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2003-02-09 01:51 Message: Logged In: YES user_id=679426 I add context diff files for integrating the command-wise navigation into PyShell, instead of being an extension. I deleted the event beginning-of-line, which caused the cursor to go to after the >>> instead of to the real beginning of line, since now Alt-Home has the same behaviour, so a special behaviour for the home key on the first line of the command edited is unneccesary. Also, there was a bug with this event - it didn't work when the Num Lock key was on. It is fixed in the new Alt-Home event. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2003-01-24 00:35 Message: Logged In: YES user_id=679426 I'm sorry, from some reason the file wasn't uploaded ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=673428&group_id=9579 From noreply@sourceforge.net Mon Feb 10 01:58:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Feb 2003 17:58:22 -0800 Subject: [Idle-dev] [ idlefork-Bugs-683701 ] RESTART should re-run startup.py Message-ID: Bugs item #683701, was opened at 2003-02-09 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=683701&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: RESTART should re-run startup.py Initial Comment: IDLEfork restarts the editor when a program is run. This undoes any setup done by startup.py. There should be at least an option to have startup.py run upon restart. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=683701&group_id=9579 From master@89894.com Tue Feb 11 04:34:13 2003 From: master@89894.com (½Å¿ë ö) Date: Tue, 11 Feb 2003 13:34:13 +0900 Subject: [Idle-dev] (no subject) Message-ID: <21110-22003221143413343@89894.com>

=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF= =A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD= =C3=B8=E9 = =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4

 

[=B0=FA=C7=D0]  =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6 =B9=AB=C7=D1 =B5=BF= =B7=C2

=B9=AB=C7=D1 =B5=BF=B7=C2=C0=BA =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6=B0=A1 =BE= =C6=B4=D2 =BC=F6 =BE=F8=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E
=C8=AD=BC=AE =BF=AC= =B7=E1=B8=A6 =BB=E7=BF=EB=C7=CF=C1=F6 =BE=CA=B0=ED,
=BF=AC=B7=E1=B0=A1=BE=F8=C0=CC =B5=B9=BE=C6=B0=A1=B4=C2 = =BF=A3=C1=F8=C0=CC =C0=D6=B4=D9=B8=E9 =BF=A1=B3=CA=C1=F6=BF=A1=20 =B4=EB=C7=D1 =B9=AE=C1=A6=B4=C2 =B8=F0=B5=CE =C7=D8=B0=E1=B5=C9 =BC=F6 =C0= =D6=B0=DA=C1=F6=BF=E4=2E
=C0=DA=B5=BF=C2=F7=B0=A1 =B1=E2=B8=A7=C0=CC =BE= =F8=C0=CC =B4=DE=B8=B1 =BC=F6=C0=D6=B4=D9=B8=E9=2E=2E=2E=2E=2E?
=BF=AC=B7=E1=B8=A6 =BE=B2=C1=F6= =BE=CA=B0=ED =B9=DF=C0=FC=B1=E2=BF=A1=BC=AD =B9=AB=C7=D1=C1=A4 =C0=FC=B1=E2= =B0=A1=20 =B9=DF=BB=FD=B5=C8=B4=D9=B8=E9 =B1=D7 =BE=EE=B5=F0=BF=A1=BC=AD=B5=E7=C1=F6= =C0=CE=B0=A3=C0=C7 =BB=EE=C0=BA =C7=B3=BF=E4=B7=CE=BF=EF=B0=CD=C0=CC=B8=E7= ,
=C8=AD=BC=AE =BF=AC=B7=E1=C0=C7 =B8=C5=BF=AC =B0=F8=C7=D8=B9=AE=C1=A6=B4=C2 =B4=F5 =C0=CC=BB=F3=C0=C7 =BF=AC=B1=B8 =B4=EB= =BB=F3=C0=CC =B5=C9 =BC=F6 =BE=F8=C0=B8=B8=E7=2E=2E=2E=2E=2E

=B1=D7=B7=AF=B3=AA =BE=D6=BC=AE =C7=CF=B0=D4=B5=B5 =BE=C6=C1=F7 =BF=EC=B8= =AE =C0=CE=B7=F9=B4=C2  =C0=CC =B9=AB=C7=D1 =B5=BF=B7=C2=C0=BB =B0=B3= =B9=DF=C0=BB =BC=BA=B0=F8 =C7=CF=C1=F6 =B8=F8=C7=DF=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E=2E

=B8=B9=C0=BA =BB=E7=B6=F7=C0=CC =BF=A9=B1=E2=BF=A1 =B5=B5=C0=FC=C0=BB =C7= =CF=B0=ED =C0=D6=C0=B8=B8=E7 =BC=BA=B0=F8=C0=C7 =B1=D7 =BC=F8=B0=A3  = =C0=CE=B7=F9=C0=C7 =C7=E0=BA=B9=C0=CF=B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E=2E
=C0=CE=B0=A3=C0=BA= =C0=FA =B9=AB=C7=D1=C0=C7 =B0=F8=B0=A3=20
=BF=EC=C1=D6=B7=CE  =BF=EC=C1=D6=B7=CE =B0=C5=C4=A7=BE=F8=C0=CC =B9= =DF=C0=FC=C7=D8 =B3=AA=B0=A5 =B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E

=C0=CC=B4=C2 =B0=F8=B0=A3 =C1=A6=C7=D1=C0=BB =B9=E7=C1=F6=BE=CA=B0=ED =BF= =A1=B3=CA=C1=F6=B8=A6 =B9=AB=C7=D1=BB=FD=BB=EA=C7=D2 =BC=F6 =C0=D6=B4=C2 =B9= =AB=C7=D1 =B5=BF=B7=C2=C0=CC =C0=D6=C0=BB =B0=E6=BF=EC=BF=A1=B8=B8 =B0=A1=B4=C9=C7=D1 =C0=CF=C0=D4=B4=CF=B4=D9=2E=2E= =2E

=BF=A9=B1=E2=BF=A1 =B0=ED=C1=A4 =BF=A1=B3=CA=C1=F6=B8=A6 =C0=CC=BF=EB=C7= =D1 =BF=A3=C1=F8=C0=BB 16=B3=E2=B0=A3=BF=A1=B0=C9=C3=C4 =B2=D9=C1=D8=C8=F7= =B0=B3=B9=DF=C7=CF=B0=ED=C0=D6=C0=B8=B8=E7 =C3=D6=B1=D9 5=B3=E2=BF=A9=B5=BF=BE=C8 6=C8=B8=BF=A1=B0=C9=C3=C4 =BA=CE=BA= =D0 =BA=CE=BA=D0=C0=BB =C1=A6=C0=DB=C7=CF=BF=A9 =B0=CB=C1=F5=C0=BB =C7=D8=BF= =C2=B9=D9=20 =C1=F6=B1=DD=C0=BA =BC=B3=B0=E8=B0=A1 =B8=B6=B9=AB=B8=AE=B5=C7=BE=EE =C1=BE= =C7=D5 =C0=FB=C0=CE =C1=A6=C0=DB =B0=FA=C1=A4=BF=A1 =BF=CD=C0=D6=C0=B8=B8=E7= ,

=BA=B8=B4=D9 =B8=B9=C0=BA =C0=CC =B5=E9=B7=CE=BA=CE=C5=CD =C7=D4=B2=B2 = =C7=CF=B0=ED=C0=DA =C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE=B8=A6 =B0=B3=BC=B3=C7=CF= =BF=A9 =B5=BF=C8=A3=C0=CE=C0=C7 =B2=DE=C0=BB =B8=B8=B5=E9=BE=EE =B0=A1=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9=2E=2E=2E

=C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE :  cafe=2Edaum=2Enet/106030 =C0=D4= =B4=CF=B4=D9=2E

=B8=B9=C0=CC =B9=E6=B9=AE=C7=CF=BD=C3=BE=EE =C0=DA=B7=E1 =B0=CB=BB=F6=C7= =CF=BD=C3=B0=ED =B6=C7 =B1=DB=C0=BB =B8=B9=C0=CC =BF=C3=B7=C1 =C1=D6=BC=BC= =BF=E4=2E=2E=2E=2E

  ^^ ** ^^   ^^ ** ^^  

tel : 011-281-1434  =BD=C5  =BF=EB  =C3=B6


From noreply@sourceforge.net Thu Feb 13 22:15:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Feb 2003 14:15:08 -0800 Subject: [Idle-dev] [ idlefork-Patches-686254 ] Run IDLEfork from any directory without set-up Message-ID: Patches item #686254, was opened at 2003-02-14 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Run IDLEfork from any directory without set-up Initial Comment: This patch adds the directory of the PyShell module to the PYTHONPATH environment variable of the spawned subprocess, so that it will find the IDLEfork modules no matter from which directory it was run, no matter where they are, and with no need for changing system configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 From kbk@users.sourceforge.net Mon Feb 17 18:57:19 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 17 Feb 2003 10:57:19 -0800 Subject: [Idle-dev] CVS: idle NEWS.txt,1.10,1.11 PyShell.py,1.55,1.56 ScriptBinding.py,1.17,1.18 rpc.py,1.15,1.16 run.py,1.9,1.10 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv20344 Modified Files: NEWS.txt PyShell.py ScriptBinding.py rpc.py run.py Log Message: M NEWS.txt M PyShell.py M ScriptBinding.py M rpc.py M run.py Clean up the way IDLEfork handles termination of the subprocess, restore ability to interrupt user code in Windows (so long as it's doing terminal I/O). 1. Handle subprocess interrupts in Windows with an RPC message. 2. Run/F5 will restart the subprocess even if user code is running. 3. Restart the subprocess if the link is dropped. 4. Exit IDLE cleanly even during I/O. 4. In rpc.py, remove explicit calls to statelock, let the condition variable handle acquire() and release(). Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** NEWS.txt 27 Jan 2003 02:40:20 -0000 1.10 --- NEWS.txt 17 Feb 2003 18:57:16 -0000 1.11 *************** *** 3,6 **** --- 3,32 ---- +++++++++++++ + What's New in IDLEfork 0.9 Alpha 3? + =================================== + + *Release date: xx-xxx-2003* + + - Exit IDLE cleanly even when doing subprocess I/O + + - Handle subprocess interrupt in Windows with an RPC message. + + - Calling Run will restart the subprocess even if user code is running. + + - Restart the subprocess if it terminates itself. (VPython programs do that) + + - Support subclassing of exceptions, including in the shell, by moving the + exception formatting to the subprocess. + + - Known issues: + + + Can't kill/restart a tight loop in the Windows version: add + I/O to the loop or use the Task Manager to kill the subprocess. + + Typing two Control-C in close succession when the subprocess is busy can + cause IDLE to lose communication with the subprocess. Please type one + only and wait for the exception to complete. + + Printing under some versions of Linux may be problematic. + + What's New in IDLEfork 0.9 Alpha 2? =================================== *************** *** 105,117 **** - Modified idle, idle.py, idle.pyw to improve exception handling. - - - Known issues: - - + Can't kill a tight loop in the Windows version: Insert a - ``print "*",`` in an outer loop or use the Task Manager to kill. - + Typing two Control-C in close succession when the subprocess is busy can - cause IDLE to lose communication with the subprocess. Please type one - only and wait for the exception to complete. - + Printing under some versions of Linux may be problematic. --- 131,134 ---- Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.55 retrieving revision 1.56 diff -C2 -r1.55 -r1.56 *** PyShell.py 31 Jan 2003 05:06:43 -0000 1.55 --- PyShell.py 17 Feb 2003 18:57:16 -0000 1.56 *************** *** 9,12 **** --- 9,13 ---- import socket import time + import threading import traceback import types *************** *** 362,368 **** debug = self.getdebugger() if debug: ! RemoteDebugger.close_subprocess_debugger(self.rpcclt) ! # kill subprocess, spawn a new one, accept connection ! self.rpcclt.close() self.spawn_subprocess() self.rpcclt.accept() --- 363,383 ---- debug = self.getdebugger() if debug: ! try: ! RemoteDebugger.close_subprocess_debugger(self.rpcclt) ! except: ! pass ! # Kill subprocess, spawn a new one, accept connection. ! if hasattr(os, 'kill'): ! # We can interrupt any loop if we can use SIGINT. This doesn't ! # work in Windows, currently we can only interrupt loops doing I/O. ! self.__signal_interrupt() ! # XXX KBK 13Feb03 Don't close the socket until the interrupt thread ! # finishes. ! self.tkconsole.executing = False ! try: ! self.rpcclt.close() ! os.wait() ! except: ! pass self.spawn_subprocess() self.rpcclt.accept() *************** *** 375,379 **** console.text.mark_set("restart", "end-1c") console.text.mark_gravity("restart", "left") ! # restart remote debugger if debug: gui = RemoteDebugger.restart_subprocess_debugger(self.rpcclt) --- 390,394 ---- console.text.mark_set("restart", "end-1c") console.text.mark_gravity("restart", "left") ! # restart subprocess debugger if debug: gui = RemoteDebugger.restart_subprocess_debugger(self.rpcclt) *************** *** 381,384 **** --- 396,417 ---- debug.load_breakpoints() + def __signal_interrupt(self): + try: + from signal import SIGINT + except ImportError: + SIGINT = 2 + os.kill(self.rpcpid, SIGINT) + + def __request_interrupt(self): + self.rpcclt.asynccall("exec", "interrupt_the_server", (), {}) + + def interrupt_subprocess(self): + if hasattr(os, "kill"): + self.__signal_interrupt() + else: + # Windows has no os.kill(), use an RPC message. + # This is async, must be done in a thread. + threading.Thread(target=self.__request_interrupt).start() + def transfer_path(self): self.runcommand("""if 1: *************** *** 394,398 **** if clt is None: return ! response = clt.pollresponse(self.active_seq) # Reschedule myself in 50 ms self.tkconsole.text.after(50, self.poll_subprocess) --- 427,444 ---- if clt is None: return ! try: ! response = clt.pollresponse(self.active_seq) ! except (EOFError, IOError): ! # lost connection: subprocess terminated itself, restart ! if self.tkconsole.closing: ! return ! response = None ! try: ! # stake any zombie before restarting ! os.wait() ! except (AttributeError, OSError): ! pass ! self.restart_subprocess() ! self.tkconsole.endexecuting() # Reschedule myself in 50 ms self.tkconsole.text.after(50, self.poll_subprocess) *************** *** 572,577 **** "Override base class method" if self.tkconsole.executing: ! self.display_executing_dialog() ! return self.checklinecache() if self.save_warnings_filters is not None: --- 618,622 ---- "Override base class method" if self.tkconsole.executing: ! self.interp.restart_subprocess() self.checklinecache() if self.save_warnings_filters is not None: *************** *** 671,678 **** self.interp.start_subprocess() ! reading = 0 ! executing = 0 ! canceled = 0 ! endoffile = 0 def toggle_debugger(self, event=None): --- 716,724 ---- self.interp.start_subprocess() ! reading = False ! executing = False ! canceled = False ! endoffile = False ! closing = False def toggle_debugger(self, event=None): *************** *** 749,763 **** "Extend EditorWindow.close()" if self.executing: ! # XXX Need to ask a question here ! if not tkMessageBox.askokcancel( "Kill?", ! "The program is still running; do you want to kill it?", default="ok", ! master=self.text): return "cancel" ! self.canceled = 1 ! if self.reading: ! self.top.quit() ! return "cancel" return EditorWindow.close(self) --- 795,809 ---- "Extend EditorWindow.close()" if self.executing: ! response = tkMessageBox.askokcancel( "Kill?", ! "The program is still running!\n Do you want to kill it?", default="ok", ! master=self.text) ! if response == False: return "cancel" ! # interrupt the subprocess ! self.closing = True ! self.cancel_callback() ! self.endexecuting() return EditorWindow.close(self) *************** *** 820,824 **** return True ! def cancel_callback(self, event): try: if self.text.compare("sel.first", "!=", "sel.last"): --- 866,870 ---- return True ! def cancel_callback(self, event=None): try: if self.text.compare("sel.first", "!=", "sel.last"): *************** *** 832,847 **** return "break" self.endoffile = 0 if self.reading: - self.canceled = 1 self.top.quit() ! elif (self.executing and self.interp.rpcclt and ! self.interp.rpcpid and hasattr(os, "kill")): ! try: ! from signal import SIGINT ! except ImportError: ! SIGINT = 2 ! os.kill(self.interp.rpcpid, SIGINT) ! else: ! self.canceled = 1 return "break" --- 878,886 ---- return "break" self.endoffile = 0 + self.canceled = 1 if self.reading: self.top.quit() ! elif (self.executing and self.interp.rpcclt): ! self.interp.interrupt_subprocess() return "break" *************** *** 1021,1030 **** def write(self, s, tags=()): ! self.text.mark_gravity("iomark", "right") ! OutputWindow.write(self, s, tags, "iomark") ! self.text.mark_gravity("iomark", "left") if self.canceled: self.canceled = 0 - raise KeyboardInterrupt class PseudoFile: --- 1060,1071 ---- def write(self, s, tags=()): ! try: ! self.text.mark_gravity("iomark", "right") ! OutputWindow.write(self, s, tags, "iomark") ! self.text.mark_gravity("iomark", "left") ! except: ! pass if self.canceled: self.canceled = 0 class PseudoFile: Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** ScriptBinding.py 26 Jan 2003 04:17:16 -0000 1.17 --- ScriptBinding.py 17 Feb 2003 18:57:16 -0000 1.18 *************** *** 125,131 **** shell = flist.open_shell() interp = shell.interp - if interp.tkconsole.executing: - interp.display_executing_dialog() - return interp.restart_subprocess() # XXX Too often this discards arguments the user just set... --- 125,128 ---- Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** rpc.py 31 Jan 2003 05:06:43 -0000 1.15 --- rpc.py 17 Feb 2003 18:57:16 -0000 1.16 *************** *** 87,90 **** --- 87,100 ---- return self.socket, self.server_address + def handle_error(self, request, client_address): + """Override TCPServer method, no error message if exiting""" + try: + raise + except SystemExit: + raise + else: + TCPServer.handle_error(request, client_address) + + objecttable = {} *************** *** 101,107 **** objtable = objecttable self.objtable = objtable ! self.statelock = threading.Lock() self.responses = {} self.cvars = {} def close(self): --- 111,118 ---- objtable = objecttable self.objtable = objtable ! self.cvar = threading.Condition() self.responses = {} self.cvars = {} + self.interrupted = False def close(self): *************** *** 154,164 **** ret = remoteref(ret) return ("OK", ret) except: self.debug("localcall:EXCEPTION") efile = sys.stderr typ, val, tb = info = sys.exc_info() sys.last_type, sys.last_value, sys.last_traceback = info tbe = traceback.extract_tb(tb) ! print >>efile, 'Traceback (most recent call last):' exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") self.cleanup_traceback(tbe, exclude) --- 165,178 ---- ret = remoteref(ret) return ("OK", ret) + except SystemExit: + raise except: self.debug("localcall:EXCEPTION") + if self.debugging: traceback.print_exc(file=sys.__stderr__) efile = sys.stderr typ, val, tb = info = sys.exc_info() sys.last_type, sys.last_value, sys.last_traceback = info tbe = traceback.extract_tb(tb) ! print >>efile, '\nTraceback (most recent call last):' exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") self.cleanup_traceback(tbe, exclude) *************** *** 187,193 **** del tb[-1] if len(tb) == 0: ! # error was in RPC internals, don't prune! tb[:] = orig_tb[:] ! print>>sys.stderr, "** RPC Internal Error: ", tb for i in range(len(tb)): fn, ln, nm, line = tb[i] --- 201,207 ---- del tb[-1] if len(tb) == 0: ! # exception was in RPC internals, don't prune! tb[:] = orig_tb[:] ! print>>sys.stderr, "** IDLE RPC Internal Exception: " for i in range(len(tb)): fn, ln, nm, line = tb[i] *************** *** 200,204 **** def remotecall(self, oid, methodname, args, kwargs): ! self.debug("calling asynccall via remotecall") seq = self.asynccall(oid, methodname, args, kwargs) return self.asyncreturn(seq) --- 214,223 ---- def remotecall(self, oid, methodname, args, kwargs): ! self.debug("remotecall:asynccall: ", oid, methodname) ! # XXX KBK 06Feb03 self.interrupted logic may not be necessary if ! # subprocess is threaded. ! if self.interrupted: ! self.interrupted = False ! raise KeyboardInterrupt seq = self.asynccall(oid, methodname, args, kwargs) return self.asyncreturn(seq) *************** *** 222,226 **** return what if how == "EXCEPTION": ! raise Exception, "RPC SocketIO.decoderesponse exception" if how == "ERROR": self.debug("decoderesponse: Internal ERROR:", what) --- 241,246 ---- return what if how == "EXCEPTION": ! self.debug("decoderesponse: EXCEPTION") ! return None if how == "ERROR": self.debug("decoderesponse: Internal ERROR:", what) *************** *** 267,280 **** else: # Auxiliary thread: wait for notification from main thread ! cvar = threading.Condition(self.statelock) ! self.statelock.acquire() ! self.cvars[myseq] = cvar while not self.responses.has_key(myseq): ! cvar.wait() response = self.responses[myseq] del self.responses[myseq] del self.cvars[myseq] ! self.statelock.release() ! return response # might be None def newseq(self): --- 287,299 ---- else: # Auxiliary thread: wait for notification from main thread ! self.cvar.acquire() ! self.cvars[myseq] = self.cvar while not self.responses.has_key(myseq): ! self.cvar.wait() response = self.responses[myseq] del self.responses[myseq] del self.cvars[myseq] ! self.cvar.release() ! return response def newseq(self): *************** *** 291,296 **** s = struct.pack(" 0: ! n = self.sock.send(s) ! s = s[n:] def ioready(self, wait=0.0): --- 310,320 ---- s = struct.pack(" 0: ! try: ! n = self.sock.send(s) ! except AttributeError: ! # socket was closed ! raise IOError ! else: ! s = s[n:] def ioready(self, wait=0.0): *************** *** 375,384 **** return resq else: ! self.statelock.acquire() ! self.responses[seq] = resq cv = self.cvars.get(seq) if cv is not None: cv.notify() ! self.statelock.release() continue --- 399,410 ---- return resq else: ! self.cvar.acquire() cv = self.cvars.get(seq) + # response involving unknown sequence number is discarded, + # probably intended for prior incarnation if cv is not None: + self.responses[seq] = resq cv.notify() ! self.cvar.release() continue Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** run.py 20 Dec 2002 04:24:43 -0000 1.9 --- run.py 17 Feb 2003 18:57:16 -0000 1.10 *************** *** 72,75 **** --- 72,80 ---- exec code in self.locals + def interrupt_the_server(self): + # XXX KBK 05Feb03 Windows requires this be done with messages and + # threads.... + self.rpchandler.interrupted = True + def start_the_debugger(self, gui_adap_oid): return RemoteDebugger.start_debugger(self.rpchandler, gui_adap_oid) From noreply@sourceforge.net Mon Feb 17 21:30:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 13:30:15 -0800 Subject: [Idle-dev] [ idlefork-Patches-686254 ] Run IDLEfork from any directory without set-up Message-ID: Patches item #686254, was opened at 2003-02-13 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Run IDLEfork from any directory without set-up Initial Comment: This patch adds the directory of the PyShell module to the PYTHONPATH environment variable of the spawned subprocess, so that it will find the IDLEfork modules no matter from which directory it was run, no matter where they are, and with no need for changing system configuration. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 16:30 Message: Logged In: YES user_id=149084 It's not clear to me what problem you are trying to solve with this patch. It's not intended that the user's search path include IDLEfork. If you want that, try e.g. import idleforklib.PyShell. If you are in the IDLEfork directory, just import PyShell will work. Are you having some problem starting IDLEfork? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 From noreply@sourceforge.net Mon Feb 17 22:14:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 14:14:32 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 17:14 Message: Logged In: YES user_id=149084 Does this solve the problem mentioned in http://mail.python.org/pipermail/idle-dev/2003-February/001628.html ---------------------------------------------------------------------- Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-07 10:35 Message: Logged In: YES user_id=36553 Two reasons. 1. The following script does not work correctly in IDLE: # -*- encoding: koi8-r -*- name = raw_input("What's your name?") print "Hi %s!" % name I use russian phrases here, of course. And if I enter my name using cyrillic letters, I get UnicodeError. This is because I mixed a Unicode string with with an 8-bit string. I know that I can use unicode literals, but I don't think that my students should know anything about Unicode, 6 cyrrilic encodings, etc, especially when they are writing their first program. Note that this program is absolutely correct and run perfectly from console. So I think that it should work in IDLE too. 2. I believe that raw_input() and stdin.readline() must always return either Unicode strings or 8-bit strings, but do not mix them. P.S. I think that -*- encoding -*- comments are very unfriendly for newbies too, but that's another story. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-07 09:55 Message: Logged In: YES user_id=6380 Why would you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From noreply@sourceforge.net Mon Feb 17 23:25:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Feb 2003 15:25:11 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- >Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-17 23:25 Message: Logged In: YES user_id=36553 There are no such a problem with Idlefork. The author of the post was using the original IDLE from the 2.2 distribution. Note the line in the traceback: File "[...]\Tools\idle\ColorDelegator.py", line 196, in recolorize_main if value in ("def", "class"): The line 196 of ColorDelegator.py from Idlefork 0.9a2 is different. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 22:14 Message: Logged In: YES user_id=149084 Does this solve the problem mentioned in http://mail.python.org/pipermail/idle-dev/2003-February/001628.html ---------------------------------------------------------------------- Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-07 15:35 Message: Logged In: YES user_id=36553 Two reasons. 1. The following script does not work correctly in IDLE: # -*- encoding: koi8-r -*- name = raw_input("What's your name?") print "Hi %s!" % name I use russian phrases here, of course. And if I enter my name using cyrillic letters, I get UnicodeError. This is because I mixed a Unicode string with with an 8-bit string. I know that I can use unicode literals, but I don't think that my students should know anything about Unicode, 6 cyrrilic encodings, etc, especially when they are writing their first program. Note that this program is absolutely correct and run perfectly from console. So I think that it should work in IDLE too. 2. I believe that raw_input() and stdin.readline() must always return either Unicode strings or 8-bit strings, but do not mix them. P.S. I think that -*- encoding -*- comments are very unfriendly for newbies too, but that's another story. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-07 14:55 Message: Logged In: YES user_id=6380 Why would you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From noreply@sourceforge.net Wed Feb 19 19:39:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 19 Feb 2003 11:39:15 -0800 Subject: [Idle-dev] [ idlefork-Bugs-689543 ] File/Save As Message-ID: Bugs item #689543, was opened at 2003-02-19 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: File/Save As Initial Comment: I installed Python 2.3a1. I start IDLE by 'python idle.py' and the shell window is open in the background. When I want to save an idle session I do not get a file. In the shell window I get this error message: ------------------------------------------------------- Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 273, in save self.save_as(event) File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 282, in save_as filename = self.asksavefile() File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 441, in asksavefile return self.savedialog.show(initialdir=dir, initialfile=base) File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 From noreply@sourceforge.net Fri Feb 21 17:18:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 09:18:03 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661759 ] IDLE should preserve source files' newline conventions Message-ID: Bugs item #661759, was opened at 2003-01-03 18:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 Category: None Group: None Status: Open Resolution: Duplicate Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE should preserve source files' newline conventions Initial Comment: If I move a Unix source file to a Windows system (or vice versa) and use IDLE to edit the file, the changed file acquires the newline convention of its new host. This behavior, though logical, is inconvenient in heterogeneous environments. I would like to suggest that when IDLE opens a source file, it should determine what newline convention the file uses and preserve that convention when it updates the file. ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2003-02-21 17:18 Message: Logged In: YES user_id=418174 I think that what you're describing is Idle's current behavior, and it doesn't work for me. Two use cases: 1) I use rcp to copy a file from my Unix machine to my Windows machine, change it there using Idle, and then rcp it back. The file is now a Windows file on my Unix machine. 2) I use Idle on my Unix machine to edit a file that is actually on a Windows machine, mounted via Samba. The file is now a Windows file on my Unix machine. In both of these cases, it would be more useful if Idle were to remember the file's newline convention and preserve it when writing back changes. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-06 18:18 Message: Logged In: YES user_id=34881 Here's another possibility, one which worked well in the cross- platform cT programming language environment. Have IDLE read any format, but always write in the format of the platform on which you're currently running. This has various nice properties. In addition to allowing seamless editing on all platforms, FTP of a saved file will be done intelligently to a different platform, because the local FTP expects the local file to be in local format. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 17:49 Message: Logged In: YES user_id=418174 The other--and perhaps more useful--alternative would be to have it check for the presence of universal newline support and fall back to present behavior if the support is absent. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-05 22:03 Message: Logged In: YES user_id=149084 Duplicate of 838584 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 19:59 Message: Logged In: YES user_id=149084 ** GvR Idle-dev: Until recently this would have been a pain. As of Python 2.3, it can be done quite conveniently using universal newlines, open(filename,"U"), and the new 'newlines' attribute of resulting file objects. ========== I suppose that since IDLEfork supports 2.2 that this would be deferred until after the merge? KBK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 From noreply@sourceforge.net Fri Feb 21 17:31:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 09:31:24 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661759 ] IDLE should preserve source files' newline conventions Message-ID: Bugs item #661759, was opened at 2003-01-03 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 Category: None Group: None Status: Open Resolution: Duplicate Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE should preserve source files' newline conventions Initial Comment: If I move a Unix source file to a Windows system (or vice versa) and use IDLE to edit the file, the changed file acquires the newline convention of its new host. This behavior, though logical, is inconvenient in heterogeneous environments. I would like to suggest that when IDLE opens a source file, it should determine what newline convention the file uses and preserve that convention when it updates the file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:31 Message: Logged In: YES user_id=6380 I'm with Andrew. Kurt mentioned this is a duplicate of 838584, but I can't find an IDLEfork bug, patch or feature request by that number. We can do this once IDLEfork is integrated into Python 2.3 (which I expect to happen by 2.3b1), or we can do it in IDLEfork right now and code it in such a way that universal newlines will only be used in Python >= 2.3. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-02-21 12:18 Message: Logged In: YES user_id=418174 I think that what you're describing is Idle's current behavior, and it doesn't work for me. Two use cases: 1) I use rcp to copy a file from my Unix machine to my Windows machine, change it there using Idle, and then rcp it back. The file is now a Windows file on my Unix machine. 2) I use Idle on my Unix machine to edit a file that is actually on a Windows machine, mounted via Samba. The file is now a Windows file on my Unix machine. In both of these cases, it would be more useful if Idle were to remember the file's newline convention and preserve it when writing back changes. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=34881 Here's another possibility, one which worked well in the cross- platform cT programming language environment. Have IDLE read any format, but always write in the format of the platform on which you're currently running. This has various nice properties. In addition to allowing seamless editing on all platforms, FTP of a saved file will be done intelligently to a different platform, because the local FTP expects the local file to be in local format. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 12:49 Message: Logged In: YES user_id=418174 The other--and perhaps more useful--alternative would be to have it check for the presence of universal newline support and fall back to present behavior if the support is absent. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-05 17:03 Message: Logged In: YES user_id=149084 Duplicate of 838584 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 14:59 Message: Logged In: YES user_id=149084 ** GvR Idle-dev: Until recently this would have been a pain. As of Python 2.3, it can be done quite conveniently using universal newlines, open(filename,"U"), and the new 'newlines' attribute of resulting file objects. ========== I suppose that since IDLEfork supports 2.2 that this would be deferred until after the merge? KBK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 From noreply@sourceforge.net Fri Feb 21 17:34:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 09:34:21 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661759 ] IDLE should preserve source files' newline conventions Message-ID: Bugs item #661759, was opened at 2003-01-03 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 Category: None Group: None Status: Open Resolution: Duplicate Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE should preserve source files' newline conventions Initial Comment: If I move a Unix source file to a Windows system (or vice versa) and use IDLE to edit the file, the changed file acquires the newline convention of its new host. This behavior, though logical, is inconvenient in heterogeneous environments. I would like to suggest that when IDLE opens a source file, it should determine what newline convention the file uses and preserve that convention when it updates the file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:34 Message: Logged In: YES user_id=6380 Never mind, Kurt meant 538584. I looked at the code, and it's a little trickier. It already understands all types of line endings, but always saves in native mode. I'll see how easy it is to save in the original mode (if unambiguous). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:31 Message: Logged In: YES user_id=6380 I'm with Andrew. Kurt mentioned this is a duplicate of 838584, but I can't find an IDLEfork bug, patch or feature request by that number. We can do this once IDLEfork is integrated into Python 2.3 (which I expect to happen by 2.3b1), or we can do it in IDLEfork right now and code it in such a way that universal newlines will only be used in Python >= 2.3. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-02-21 12:18 Message: Logged In: YES user_id=418174 I think that what you're describing is Idle's current behavior, and it doesn't work for me. Two use cases: 1) I use rcp to copy a file from my Unix machine to my Windows machine, change it there using Idle, and then rcp it back. The file is now a Windows file on my Unix machine. 2) I use Idle on my Unix machine to edit a file that is actually on a Windows machine, mounted via Samba. The file is now a Windows file on my Unix machine. In both of these cases, it would be more useful if Idle were to remember the file's newline convention and preserve it when writing back changes. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=34881 Here's another possibility, one which worked well in the cross- platform cT programming language environment. Have IDLE read any format, but always write in the format of the platform on which you're currently running. This has various nice properties. In addition to allowing seamless editing on all platforms, FTP of a saved file will be done intelligently to a different platform, because the local FTP expects the local file to be in local format. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 12:49 Message: Logged In: YES user_id=418174 The other--and perhaps more useful--alternative would be to have it check for the presence of universal newline support and fall back to present behavior if the support is absent. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-05 17:03 Message: Logged In: YES user_id=149084 Duplicate of 838584 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 14:59 Message: Logged In: YES user_id=149084 ** GvR Idle-dev: Until recently this would have been a pain. As of Python 2.3, it can be done quite conveniently using universal newlines, open(filename,"U"), and the new 'newlines' attribute of resulting file objects. ========== I suppose that since IDLEfork supports 2.2 that this would be deferred until after the merge? KBK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 From noreply@sourceforge.net Fri Feb 21 17:50:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 09:50:39 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661759 ] IDLE should preserve source files' newline conventions Message-ID: Bugs item #661759, was opened at 2003-01-03 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 Category: None Group: None Status: Open Resolution: Duplicate Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE should preserve source files' newline conventions Initial Comment: If I move a Unix source file to a Windows system (or vice versa) and use IDLE to edit the file, the changed file acquires the newline convention of its new host. This behavior, though logical, is inconvenient in heterogeneous environments. I would like to suggest that when IDLE opens a source file, it should determine what newline convention the file uses and preserve that convention when it updates the file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:50 Message: Logged In: YES user_id=6380 Here's a patch for IOBinding.py that does what you want. It assumes the first line of the file is typical, and on output converts all line endings to whatever the first line ending was on input (there's no way to save individual line endings without displaying them, which would be too ugly). Please test this on Windows; I've only tested it on Unix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:34 Message: Logged In: YES user_id=6380 Never mind, Kurt meant 538584. I looked at the code, and it's a little trickier. It already understands all types of line endings, but always saves in native mode. I'll see how easy it is to save in the original mode (if unambiguous). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:31 Message: Logged In: YES user_id=6380 I'm with Andrew. Kurt mentioned this is a duplicate of 838584, but I can't find an IDLEfork bug, patch or feature request by that number. We can do this once IDLEfork is integrated into Python 2.3 (which I expect to happen by 2.3b1), or we can do it in IDLEfork right now and code it in such a way that universal newlines will only be used in Python >= 2.3. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-02-21 12:18 Message: Logged In: YES user_id=418174 I think that what you're describing is Idle's current behavior, and it doesn't work for me. Two use cases: 1) I use rcp to copy a file from my Unix machine to my Windows machine, change it there using Idle, and then rcp it back. The file is now a Windows file on my Unix machine. 2) I use Idle on my Unix machine to edit a file that is actually on a Windows machine, mounted via Samba. The file is now a Windows file on my Unix machine. In both of these cases, it would be more useful if Idle were to remember the file's newline convention and preserve it when writing back changes. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=34881 Here's another possibility, one which worked well in the cross- platform cT programming language environment. Have IDLE read any format, but always write in the format of the platform on which you're currently running. This has various nice properties. In addition to allowing seamless editing on all platforms, FTP of a saved file will be done intelligently to a different platform, because the local FTP expects the local file to be in local format. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 12:49 Message: Logged In: YES user_id=418174 The other--and perhaps more useful--alternative would be to have it check for the presence of universal newline support and fall back to present behavior if the support is absent. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-05 17:03 Message: Logged In: YES user_id=149084 Duplicate of 838584 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 14:59 Message: Logged In: YES user_id=149084 ** GvR Idle-dev: Until recently this would have been a pain. As of Python 2.3, it can be done quite conveniently using universal newlines, open(filename,"U"), and the new 'newlines' attribute of resulting file objects. ========== I suppose that since IDLEfork supports 2.2 that this would be deferred until after the merge? KBK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 From noreply@sourceforge.net Fri Feb 21 17:51:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 21 Feb 2003 09:51:14 -0800 Subject: [Idle-dev] [ idlefork-Bugs-538584 ] IDLE needs to allow control of eol seq Message-ID: Bugs item #538584, was opened at 2002-04-03 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE needs to allow control of eol seq Initial Comment: IDLE tries to respect the end of line sequence of the platform it is running on. However, sometimes this isn't the correct behavior. I want to use IDLE on Windows, but access files on a Samba share. These files are in turn used by Apache, and it's very picky about end-of-line. If the file has CR-LF, it won't execute it. Any time I change a file with IDLE, it resets all the end of line sequences. This also fouls up the ability to diff files, or do CVS merges, because it's a global change. IDLE should either (1) allow an explicit setting for EOL sequence, or (2) figure out what it is for a specific file and then write it out the same way. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:51 Message: Logged In: YES user_id=6380 A patch for this was attached to bug 661759. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 07:00 Message: Logged In: YES user_id=6380 Definitely a feature request. I'm sure both IDLE versions have this issue. It will be possible to fix this in Python 2.3 by using the Universal Newlines feature (see PEP 278) -- that will let IDLE determine the original newline convention. Writing back using that convention is then (relatively) simple, using binary output mode. (But you'll have to get the text from the Text widget a line at a time, or do a global replace of \n with the line ending of choice.) ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:52 Message: Logged In: YES user_id=75867 This item talks about idle rather than idlefork, although I think the behaviour is the same in both cases. Should this be entered as a python idle bug, or perhaps "feature request"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 From noreply@sourceforge.net Sat Feb 22 21:32:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 22 Feb 2003 13:32:32 -0800 Subject: [Idle-dev] [ idlefork-Patches-686254 ] Run IDLEfork from any directory without set-up Message-ID: Patches item #686254, was opened at 2003-02-14 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Run IDLEfork from any directory without set-up Initial Comment: This patch adds the directory of the PyShell module to the PYTHONPATH environment variable of the spawned subprocess, so that it will find the IDLEfork modules no matter from which directory it was run, no matter where they are, and with no need for changing system configuration. ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2003-02-22 23:32 Message: Logged In: YES user_id=679426 I'm trying to solve the problem of using idlefork if it was not installed using distutils. On my machine it seems that I don't have distutils - the command "from distutils.core import setup" raises "ImportError: No module named distutils.core", both as root and as a normal user, both on python 2.1.3 (the default) and on python 2.2.1. I'm using debian woody. I think it may help a large group of users - those without root privileges. It will also help users who just want to experiment - to them, extracting the files to a directory and running, without installing, is the easiest way. In such cases, when idlefork's files just sit in their directory, and you want a Python shell in your current directory (this happens to me a lot of times), you must change to idlefork's directory, run ./idle, and then change back to your original directory both in your system shell and in your Python shell, and still, when you open a file from an idlefork's window, you must manually go to your working directory. I think running, say, ~/idlefork/idle, is much simpler than the process I described above. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 23:30 Message: Logged In: YES user_id=149084 It's not clear to me what problem you are trying to solve with this patch. It's not intended that the user's search path include IDLEfork. If you want that, try e.g. import idleforklib.PyShell. If you are in the IDLEfork directory, just import PyShell will work. Are you having some problem starting IDLEfork? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 From noreply@sourceforge.net Sun Feb 23 01:53:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 22 Feb 2003 17:53:08 -0800 Subject: [Idle-dev] [ idlefork-Patches-686254 ] Run IDLEfork from any directory without set-up Message-ID: Patches item #686254, was opened at 2003-02-13 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Run IDLEfork from any directory without set-up Initial Comment: This patch adds the directory of the PyShell module to the PYTHONPATH environment variable of the spawned subprocess, so that it will find the IDLEfork modules no matter from which directory it was run, no matter where they are, and with no need for changing system configuration. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-22 20:53 Message: Logged In: YES user_id=149084 You could install python2.2-dev, which contains the necessary distutils code. Alternatively, you could add the IDLE directory to your sys.path via a Python startup file referenced by your PYTHONSTARTUP env variable. That would do the same thing as the patch, but specifically for your situation. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2003-02-22 16:32 Message: Logged In: YES user_id=679426 I'm trying to solve the problem of using idlefork if it was not installed using distutils. On my machine it seems that I don't have distutils - the command "from distutils.core import setup" raises "ImportError: No module named distutils.core", both as root and as a normal user, both on python 2.1.3 (the default) and on python 2.2.1. I'm using debian woody. I think it may help a large group of users - those without root privileges. It will also help users who just want to experiment - to them, extracting the files to a directory and running, without installing, is the easiest way. In such cases, when idlefork's files just sit in their directory, and you want a Python shell in your current directory (this happens to me a lot of times), you must change to idlefork's directory, run ./idle, and then change back to your original directory both in your system shell and in your Python shell, and still, when you open a file from an idlefork's window, you must manually go to your working directory. I think running, say, ~/idlefork/idle, is much simpler than the process I described above. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 16:30 Message: Logged In: YES user_id=149084 It's not clear to me what problem you are trying to solve with this patch. It's not intended that the user's search path include IDLEfork. If you want that, try e.g. import idleforklib.PyShell. If you are in the IDLEfork directory, just import PyShell will work. Are you having some problem starting IDLEfork? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 From noreply@sourceforge.net Sun Feb 23 20:21:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 23 Feb 2003 12:21:25 -0800 Subject: [Idle-dev] [ idlefork-Bugs-691827 ] saving required to run script Message-ID: Bugs item #691827, was opened at 2003-02-23 12:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=691827&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: saving required to run script Initial Comment: (I couldn't enter this as a feature request; it seems to be broken.) Whenever one tries to run a one-shot program or test, he/she still must save it as a file. It would be much better if the user had the option to save, or turn off the prompt in Preferences. Dr. Scheme is a good example where this makes things much faster. I suppose this guards against code loss, but not all situations really need this protection, and it could be saved in a backup file anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=691827&group_id=9579 From kbk@shore.net Sun Feb 23 20:36:27 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 23 Feb 2003 15:36:27 -0500 Subject: [Idle-dev] IDLEfork / Windows Message-ID: After cleaning up the termination code, studying the Thread-SIG and Python-dev archives, and experimenting with various threaded approaches, the situation appears to me to be as follows: 1. The Linux implementation is working fine with SIGINT, pass loop code can be interrupted with a KeyboardInterrupt and the remaining environment examined with the shell. 2. Windows subprocesses can't be interrupted using signals in standard Python, as far as I can tell. 3. Therefore, subprocesses in Windows have to be controlled via RPC messages. However, a subprocess which is not doing RPC I/O will not be listening to the socket because the single thread of control is in the user code, and can't be interrupted. If the IDLE GUI process drops the link, the subprocess continues on its merry way and has to be killed manually with the Windows Task Manager. 4. Therefore, it is necessary to thread the subprocess on Windows. However, even after doing this there is no mechanism in Python to interrupt the user thread or even request it to (clean up and) exit, though the interpreter is servicing both threads with no difficulty. 5. If the subprocess is threaded and the user thread is setDaemon(True), it is possible to shut it down by doing a sys.exit() in the main thread. When the GUI detects that the link has been dropped, it will spawn a new subprocess. Though you can no longer examine the remaining environment, you will be able to continue your work, and there will be no errant processes. 6. To maintain fullest possible utility, the subprocess will be threaded under Windows, and not threaded on other platforms. This is the direction in which I'm headed, pending an implementation of PEP 42 / SF221115. Am I missing something? Is this the optimum approach? Any comments would be appreciated. -- KBK From guido@python.org Sun Feb 23 21:26:45 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 23 Feb 2003 16:26:45 -0500 Subject: [Idle-dev] IDLEfork / Windows In-Reply-To: "Your message of Sun, 23 Feb 2003 15:36:27 EST." References: Message-ID: <200302232126.h1NLQjo11329@pcp02138704pcs.reston01.va.comcast.net> Kurt: The only defense I have is that AFAIK the situation is no better in the old IDLE. I'm not very happy with running the program in a thread, since the main thread is somewhat special. I'd be willing to have a separate thread that somehow watches RPC for a ^C equivalent. Maybe we could emulate a signal call at the C level -- the machinery for calling the Python-level signal handler could be reused. --Guido van Rossum (home page: http://www.python.org/~guido/) From teyc@cognoware.com Mon Feb 24 22:45:59 2003 From: teyc@cognoware.com (Chui Tey) Date: Tue, 25 Feb 2003 08:45:59 +1000 Subject: [Idle-dev] Terminating subprocesses Message-ID: <9DB60AFDAB1A5E4093762030DBB3897814FB5C@WEBSERVER.advdata.com.au> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2DCAA.530BABA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Kurt, In the case of windows, we could kill a subprocess using the self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) . . . import win32process win32process.TerminateProcess(self.rpcpid,0) Chui ------=_NextPart_000_0010_01C2DCAA.530BABA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Terminating subprocesses

Kurt,

In the case of windows, we could kill a subprocess = using the

self.rpcpid =3D os.spawnv(os.P_NOWAIT, args[0], = args)
.
.
.
import win32process
win32process.TerminateProcess(self.rpcpid,0)


Chui
 

------=_NextPart_000_0010_01C2DCAA.530BABA0-- From noreply@sourceforge.net Wed Feb 26 01:15:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 17:15:01 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693333 ] Misleading message Message-ID: Bugs item #693333, was opened at 2003-02-26 01:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading message Initial Comment: If you attempt to use 'exit' as a command, IdleFork responds: 'Use Ctrl-Z plus Return to exit.'. This is apparently a holdover from Idle. Ctrl-Z is now setup by default to perform 'Undo' Either exit should be treated as an unrecognized command or it should respond 'Use Ctrl-Q to exit' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 From noreply@sourceforge.net Wed Feb 26 01:16:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 17:16:39 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693333 ] Misleading message for 'exit' Message-ID: Bugs item #693333, was opened at 2003-02-26 01:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) >Summary: Misleading message for 'exit' Initial Comment: If you attempt to use 'exit' as a command, IdleFork responds: 'Use Ctrl-Z plus Return to exit.'. This is apparently a holdover from Idle. Ctrl-Z is now setup by default to perform 'Undo' Either exit should be treated as an unrecognized command or it should respond 'Use Ctrl-Q to exit' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 From david@rebirthing.co.nz Wed Feb 26 03:11:30 2003 From: david@rebirthing.co.nz (David McNab) Date: 26 Feb 2003 16:11:30 +1300 Subject: [Idle-dev] KeyBindings for Debugger Message-ID: <1046229090.1304.21.camel@rebirth> Hi, I've just started using Idle on Debian. Great IDE, except for one thing. There seems to be no way to create key bindings for the Debugger commands - 'next', 'step', 'continue', 'return'. Result is that it's compulsory-mouse-only operation, which gets extremely painful on the mouse finger. Repetitive mouse-clicks put a lot more stress on the finger than keystrokes. I tried adding bindings, by setting keystroke event handlers in Debugger.py. They work, but every time I do a 'step'/'next' etc, window focus goes to the source editing window, at which point I have to either click back on the debugger window or use a keyboard shortcut. I experimented with a few things, but I don't know tk well enough to know what methods to invoke. Can anyone please help? All I want is the option of pressing keystrokes to step through code, instead of the compulsory mouse-clicks. Thanks muchly in advance David From noreply@sourceforge.net Wed Feb 26 04:45:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 25 Feb 2003 20:45:49 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693418 ] Normal text background color not refreshed Message-ID: Bugs item #693418, was opened at 2003-02-26 04:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Normal text background color not refreshed Initial Comment: IdleFork 0.9a2 / Python 2.2.2 Changing the background color for Normal Text in Custom Highlighting does not change the current window when 'Apply' is selected. The change does not become effective until a new Shell or Editor window is opened. The other text choices (Comments, Keywords, etc.) do refresh their background colors when after 'Apply'. Obviously, this discrepancy does not impact the usefulness of IdleFork, but the inconsistency is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579 From kbk@users.sourceforge.net Thu Feb 27 23:04:23 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 27 Feb 2003 15:04:23 -0800 Subject: [Idle-dev] CVS: idle rpc.py,1.16,1.17 run.py,1.10,1.11 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2438 Modified Files: rpc.py run.py Log Message: M rpc.py M run.py Move exception formatting out of rpc.py. This allows each end of the link to format and print exceptions how and where it sees fit and makes it easier for threads to display their own exceptions. Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -r1.16 -r1.17 *** rpc.py 17 Feb 2003 18:57:16 -0000 1.16 --- rpc.py 27 Feb 2003 23:04:15 -0000 1.17 *************** *** 169,215 **** except: self.debug("localcall:EXCEPTION") ! if self.debugging: traceback.print_exc(file=sys.__stderr__) ! efile = sys.stderr ! typ, val, tb = info = sys.exc_info() ! sys.last_type, sys.last_value, sys.last_traceback = info ! tbe = traceback.extract_tb(tb) ! print >>efile, '\nTraceback (most recent call last):' ! exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") ! self.cleanup_traceback(tbe, exclude) ! traceback.print_list(tbe, file=efile) ! lines = traceback.format_exception_only(typ, val) ! for line in lines: ! print>>efile, line, return ("EXCEPTION", None) - - def cleanup_traceback(self, tb, exclude): - "Remove excluded traces from beginning/end of tb; get cached lines" - orig_tb = tb[:] - while tb: - for rpcfile in exclude: - if tb[0][0].count(rpcfile): - break # found an exclude, break for: and delete tb[0] - else: - break # no excludes, have left RPC code, break while: - del tb[0] - while tb: - for rpcfile in exclude: - if tb[-1][0].count(rpcfile): - break - else: - break - del tb[-1] - if len(tb) == 0: - # exception was in RPC internals, don't prune! - tb[:] = orig_tb[:] - print>>sys.stderr, "** IDLE RPC Internal Exception: " - for i in range(len(tb)): - fn, ln, nm, line = tb[i] - if nm == '?': - nm = "-toplevel-" - if not line and fn.startswith(">efile, '\nTraceback (most recent call last):' ! exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") ! self.cleanup_traceback(tbe, exclude) ! traceback.print_list(tbe, file=efile) ! lines = traceback.format_exception_only(typ, val) ! for line in lines: ! print>>efile, line, ! ! def cleanup_traceback(self, tb, exclude): ! "Remove excluded traces from beginning/end of tb; get cached lines" ! orig_tb = tb[:] ! while tb: ! for rpcfile in exclude: ! if tb[0][0].count(rpcfile): ! break # found an exclude, break for: and delete tb[0] ! else: ! break # no excludes, have left RPC code, break while: ! del tb[0] ! while tb: ! for rpcfile in exclude: ! if tb[-1][0].count(rpcfile): ! break ! else: ! break ! del tb[-1] ! if len(tb) == 0: ! # exception was in IDLE internals, don't prune! ! tb[:] = orig_tb[:] ! print>>sys.stderr, "** IDLE Internal Exception: " ! for i in range(len(tb)): ! fn, ln, nm, line = tb[i] ! if nm == '?': ! nm = "-toplevel-" ! if not line and fn.startswith(" Hi, I just tested the checker under IDLEfork-0.9a2 and was wondering, if there are any plans to use pychecker (additionally, or instead)? (actually, it might be nice if one can set the various options somehow with a graphical interface and store them in a project dependent way. Well, this part would be a lot of work ...) Arnd From baecker@physik.tu-dresden.de Fri Feb 28 13:11:15 2003 From: baecker@physik.tu-dresden.de (baecker@physik.tu-dresden.de) Date: Fri, 28 Feb 2003 14:11:15 +0100 (CET) Subject: [Idle-dev] socket troubles Message-ID: Hi, I have a question (which in the end is related to the socket associated with idle): Is it right that at the moment it is not possible to have two instances of idle running on the same machine by different users (or even the same user ) ? If so, are there any plans/possibility to improve on this ? ((I browsed through the archive of the mailing list and this topic was raised a while ago, but I haven't found a solution on this..) I just did another test on this and the results/"screen-shots" are at the end of this message. Background information: We are planning to use Idle in a course on computational physics. The tutorials will be done in a PC-Pool which is also accessible via the internet. There seems to be another issue arising from this: under certain circumstances we encounter that idle gets killed but not completely. Then the socket is not freed for further use. So the same user will not be able to start idle again. (and in general he will not know which process to kill ...). Now, even worse, it could be that this user just logs out from the machine and goes home. Then another user will not be able to use idle. Now only a root user (well, or the previous user) can solve this problem, or ? I think that this is really a substantial problem for using idle in a multi-user environment. Don't get me wrong, I think idle is really good, in particular for beginners!!! Many thanks, Arnd Illustration of the problem: ============================ On machine test one user runs idle. Now I ssh to this machine and try to start idle. This is what happens: -------------- begin screen-shot -------------------- [test] ~ $ idle . . . Idle socket error: Address already in use, retrying... Idle socket error: Address already in use, retrying... [[At this point I press CTRL-c]] Traceback (most recent call last): File "/home/python/PYTHON/bin//idle", line 11, in ? idlelib.PyShell.main() File "/home/python/PYTHON/lib/python2.2/site-packages/idlelib/PyShell.py", line 1238, in main flist.pyshell = PyShell(flist) File "/home/python/PYTHON/lib/python2.2/site-packages/idlelib/PyShell.py", line 716, in __init__ self.interp.start_subprocess() File "/home/python/PYTHON/lib/python2.2/site-packages/idlelib/PyShell.py", line 338, in start_subprocess time.sleep(i) KeyboardInterrupt [ptpcp4] ~ $ exit -------------- end screen-shot -------------------- Even worse, doing a CTRL-c after realising the problem and tyring to log out, ssh waits. The reason is that a process is still alive - ps fax (from a different terminal) gives: 4768 pts/2 S 0:05 | | \_ /home/python/PYTHON/bin/python /home/python/PYTHON/bin//idle 4836 pts/2 S 0:00 | | \_ /home/python/PYTHON/bin/python -c __import__('idlelib.run').run.main() 8833 4870 ? S 0:00 /home/python/PYTHON/bin/python -c __import__('idlelib.run').run.main() 8833 Killing the last (from a different window) allows ssh to quit the connection. (the first two processes are from the other user ...)