From chris.lyon@spritenote.co.uk Fri May 2 17:06:44 2003 From: chris.lyon@spritenote.co.uk (Chris Lyon) Date: Fri, 02 May 2003 17:06:44 +0100 Subject: [Idle-dev] Clear Debug breakpoints Message-ID: <3EB29794.2010605@spritenote.co.uk> On 5 Mar 2002 Edward K. Ream posted on the com.lang.python list a patch for idle to allow you to clear breakpoints. There is talk of submitting it to this list. I don't know if this has been done, so I bring it to your attension in the hope that it will be implemented. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3C84E2C9.8DC206B4%40tds.net&rnum=1&prev=/groups%3Fq%3Didle%2Bbreakpoint%2Bclear%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D3C84E2C9.8DC206B4%2540tds.net%26rnum%3D1 If the link is too horrendous just search in com.lang.python for "breakpoint clear idle" Hopefully this wont ruffle any feathers or demonstrate any other aspects of my personal limitations... Chris From kbk@shore.net Sat May 3 14:12:39 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 03 May 2003 09:12:39 -0400 Subject: [Idle-dev] Clear Debug breakpoints In-Reply-To: <3EB29794.2010605@spritenote.co.uk> (Chris Lyon's message of "Fri, 02 May 2003 17:06:44 +0100") References: <3EB29794.2010605@spritenote.co.uk> Message-ID: Chris Lyon writes: > On 5 Mar 2002 Edward K. Ream posted on the com.lang.python list a > patch for idle to allow you to clear breakpoints. There is talk of > submitting it to this list. I don't know if this has been done, so I > bring it to your attension in the hope that it will be implemented. Thanks for the link. That request was also posted as an IDLEfork bug last summer (within minutes of my check-in which implemented it :) though in a slightly different way). Please try installing the latest packaged version of IDLEfork (0.9a2), it has the capability you are looking for. Individual breakpoints can be cleared, and breakpoints are saved across IDLE sessions. http://sourceforge.net/projects/idlefork IDLEfork (current CVS version) has been added to the Python CVS on the idlefork-merge-branch. That version is somewhat beyond 0.9a2 in that it uses a threaded subprocess. However, it is not the final threaded version which will be available RSN as IDLEfork 0.9b1 and later in Python 2.3b2, replacing the old IDLE. __ KBK From noreply@sourceforge.net Mon May 5 00:10:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 04 May 2003 16:10:13 -0700 Subject: [Idle-dev] [ idlefork-Patches-732395 ] Not compatible with Blender226 Message-ID: Patches item #732395, was opened at 2003-05-04 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=732395&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Not compatible with Blender226 Initial Comment: Dear, Thanks a lot for this wonderful tool. Due to the poor support of Python editing, I was happy to find out that Idle was the (only) editor which could be run from within Blender it self. Unfortunately debugging wouldn't work (AttributeError:__nonzero__ for Delegator Bugs item #732397, was opened at 2003-05-04 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=732397&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: running/debugging fails from within Blender Initial Comment: Due to the poor support of Python editing, I was happy to find out that Idle was the (only) editor which could be run from within Blender it self. Unfortunately debugging wouldn't work (AttributeError:__nonzero__ for Delegator Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv5992 Modified Files: NEWS.txt PyShell.py rpc.py run.py Log Message: 1. Implement processing of user code in subprocess MainThread. Pass loop is now interruptable on Windows. 2. Tweak signal.signal() wait parameters as called by various methods to improve I/O response, especially on Windows. 3. Debugger is disabled at this check-in pending further development. M NEWS.txt M PyShell.py M rpc.py M run.py Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** NEWS.txt 25 Apr 2003 17:48:08 -0000 1.14 --- NEWS.txt 8 May 2003 20:26:54 -0000 1.15 *************** *** 6,10 **** =================================== ! *Release date: 25-Apr-2003* - Implemented the 'interrupt' extension module, which allows a subthread --- 6,16 ---- =================================== ! *Release date: XX-XXX-2003* ! ! - Improved I/O response by tweaking the wait parameter in various ! calls to signal.signal(). ! ! - Implemented a threaded subprocess which allows interrupting a pass ! loop in user code using the 'interrupt' extension. - Implemented the 'interrupt' extension module, which allows a subthread *************** *** 37,45 **** - 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. --- 43,50 ---- - Known issues: + 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. If you do manage to ! interrupt the interrupt, simply restart the shell. + Printing under some versions of Linux may be problematic. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.59 retrieving revision 1.60 diff -C2 -r1.59 -r1.60 *** PyShell.py 22 Mar 2003 19:40:18 -0000 1.59 --- PyShell.py 8 May 2003 20:26:54 -0000 1.60 *************** *** 36,39 **** --- 36,44 ---- IDENTCHARS = string.ascii_letters + string.digits + "_" + try: + from signal import SIGTERM + except ImportError: + SIGTERM = 15 + # Change warnings module to write to sys.__stderr__ try: *************** *** 368,378 **** pass # Kill subprocess, spawn a new one, accept connection. ! try: ! self.interrupt_subprocess() ! self.shutdown_subprocess() ! self.rpcclt.close() ! os.wait() ! except: ! pass self.tkconsole.executing = False self.spawn_subprocess() --- 373,378 ---- pass # Kill subprocess, spawn a new one, accept connection. ! self.rpcclt.close() ! self.unix_terminate() self.tkconsole.executing = False self.spawn_subprocess() *************** *** 392,431 **** debug.load_breakpoints() - def __signal_interrupt(self): - try: - from signal import SIGINT - except ImportError: - SIGINT = 2 - try: - os.kill(self.rpcpid, SIGINT) - except OSError: # subprocess may have already exited - pass - def __request_interrupt(self): ! try: ! self.rpcclt.asynccall("exec", "interrupt_the_server", (), {}) ! except: ! pass def interrupt_subprocess(self): ! # XXX KBK 22Mar03 Use interrupt message on all platforms for now. ! # XXX if hasattr(os, "kill"): ! if False: ! 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 __request_shutdown(self): ! try: ! self.rpcclt.asynccall("exec", "shutdown_the_server", (), {}) ! except: ! pass ! def shutdown_subprocess(self): ! t = threading.Thread(target=self.__request_shutdown) ! t.start() ! t.join() def transfer_path(self): --- 392,420 ---- debug.load_breakpoints() def __request_interrupt(self): ! self.rpcclt.remotecall("exec", "interrupt_the_server", (), {}) def interrupt_subprocess(self): ! threading.Thread(target=self.__request_interrupt).start() ! def kill_subprocess(self): ! self.rpcclt.close() ! self.unix_terminate() ! self.tkconsole.executing = False ! self.rpcclt = None ! def unix_terminate(self): ! "UNIX: make sure subprocess is terminated and collect status" ! if hasattr(os, 'kill'): ! try: ! os.kill(self.rpcpid, SIGTERM) ! except OSError: ! # process already terminated: ! return ! else: ! try: ! os.waitpid(self.rpcpid, 0) ! except OSError: ! return def transfer_path(self): *************** *** 446,464 **** 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) if response: self.tkconsole.resetoutput() --- 435,447 ---- return try: ! response = clt.pollresponse(self.active_seq, wait=0.05) ! except (EOFError, IOError, KeyboardInterrupt): ! # lost connection or subprocess terminated itself, restart ! # [the KBI is from rpc.SocketIO.handle_EOF()] if self.tkconsole.closing: return response = None self.restart_subprocess() self.tkconsole.endexecuting() if response: self.tkconsole.resetoutput() *************** *** 478,488 **** # we received a response to the currently active seq number: self.tkconsole.endexecuting() ! ! def kill_subprocess(self): ! clt = self.rpcclt ! if clt is not None: ! self.shutdown_subprocess() ! clt.close() ! self.rpcclt = None debugger = None --- 461,466 ---- # we received a response to the currently active seq number: self.tkconsole.endexecuting() ! # Reschedule myself in 50 ms ! self.tkconsole.text.after(50, self.poll_subprocess) debugger = None *************** *** 496,500 **** def remote_stack_viewer(self): import RemoteObjectBrowser ! oid = self.rpcclt.remotecall("exec", "stackviewer", ("flist",), {}) if oid is None: self.tkconsole.root.bell() --- 474,478 ---- def remote_stack_viewer(self): import RemoteObjectBrowser ! oid = self.rpcclt.remotequeue("exec", "stackviewer", ("flist",), {}) if oid is None: self.tkconsole.root.bell() *************** *** 629,633 **** return 0 if self.rpcclt: ! self.rpcclt.remotecall("exec", "runcode", (code,), {}) else: exec code in self.locals --- 607,611 ---- return 0 if self.rpcclt: ! self.rpcclt.remotequeue("exec", "runcode", (code,), {}) else: exec code in self.locals *************** *** 646,650 **** try: if not debugger and self.rpcclt is not None: ! self.active_seq = self.rpcclt.asynccall("exec", "runcode", (code,), {}) elif debugger: --- 624,628 ---- try: if not debugger and self.rpcclt is not None: ! self.active_seq = self.rpcclt.asyncqueue("exec", "runcode", (code,), {}) elif debugger: *************** *** 713,717 **** text.bind("<>", self.eof_callback) text.bind("<>", self.open_stack_viewer) ! text.bind("<>", self.toggle_debugger) text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) --- 691,695 ---- text.bind("<>", self.eof_callback) text.bind("<>", self.open_stack_viewer) ! ##text.bind("<>", self.toggle_debugger) text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) *************** *** 800,810 **** self.resetoutput() self.executing = 1 - ##self._cancel_check = self.cancel_check - ##sys.settrace(self._cancel_check) def endexecuting(self): "Helper for ModifiedInterpreter" - ##sys.settrace(None) - ##self._cancel_check = None self.executing = 0 self.canceled = 0 --- 778,784 ---- *************** *** 823,827 **** # interrupt the subprocess self.closing = True - self.cancel_callback() self.endexecuting() return EditorWindow.close(self) --- 797,800 ---- *************** *** 1017,1037 **** line = line[:i] more = self.interp.runsource(line) - - def cancel_check(self, frame, what, args, - dooneevent=tkinter.dooneevent, - dontwait=tkinter.DONT_WAIT): - # Hack -- use the debugger hooks to be able to handle events - # and interrupt execution at any time. - # This slows execution down quite a bit, so you may want to - # disable this (by not calling settrace() in beginexecuting() and - # endexecuting() for full-bore (uninterruptable) speed.) - # XXX This should become a user option. - if self.canceled: - return - dooneevent(dontwait) - if self.canceled: - self.canceled = 0 - raise KeyboardInterrupt - return self._cancel_check def open_stack_viewer(self, event=None): --- 990,993 ---- Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.22 retrieving revision 1.23 diff -C2 -r1.22 -r1.23 *** rpc.py 22 Mar 2003 20:11:14 -0000 1.22 --- rpc.py 8 May 2003 20:26:54 -0000 1.23 *************** *** 29,32 **** --- 29,33 ---- import sys + import os import socket import select *************** *** 35,38 **** --- 36,40 ---- import cPickle as pickle import threading + import Queue import traceback import copy_reg *************** *** 40,43 **** --- 42,47 ---- import marshal + import interrupt + def unpickle_code(ms): co = marshal.loads(ms) *************** *** 99,104 **** except SystemExit: raise - except EOFError: - pass except: erf = sys.__stderr__ --- 103,106 ---- *************** *** 111,119 **** print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 - import os os._exit(0) objecttable = {} class SocketIO: --- 113,124 ---- print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 os._exit(0) + #----------------- end class RPCServer -------------------- objecttable = {} + request_queue = Queue.Queue(0) + response_queue = Queue.Queue(0) + class SocketIO: *************** *** 122,126 **** def __init__(self, sock, objtable=None, debugging=None): ! self.mainthread = threading.currentThread() if debugging is not None: self.debugging = debugging --- 127,131 ---- def __init__(self, sock, objtable=None, debugging=None): ! self.sockthread = threading.currentThread() if debugging is not None: self.debugging = debugging *************** *** 129,136 **** objtable = objecttable self.objtable = objtable - self.cvar = threading.Condition() self.responses = {} self.cvars = {} - self.interrupted = False def close(self): --- 134,139 ---- *************** *** 140,143 **** --- 143,150 ---- sock.close() + def exithook(self): + "override for specific exit action" + os._exit() + def debug(self, *args): if not self.debugging: *************** *** 157,161 **** pass ! def localcall(self, request): self.debug("localcall:", request) try: --- 164,168 ---- pass ! def localcall(self, seq, request): self.debug("localcall:", request) try: *************** *** 163,167 **** except TypeError: return ("ERROR", "Bad request format") - assert how == "call" if not self.objtable.has_key(oid): return ("ERROR", "Unknown object id: %s" % `oid`) --- 170,173 ---- *************** *** 179,190 **** method = getattr(obj, methodname) try: ! ret = method(*args, **kwargs) ! if isinstance(ret, RemoteObject): ! ret = remoteref(ret) ! return ("OK", ret) except SystemExit: raise except socket.error: ! pass except: self.debug("localcall:EXCEPTION") --- 185,202 ---- method = getattr(obj, methodname) try: ! if how == 'CALL': ! ret = method(*args, **kwargs) ! if isinstance(ret, RemoteObject): ! ret = remoteref(ret) ! return ("OK", ret) ! elif how == 'QUEUE': ! request_queue.put((seq, (method, args, kwargs))) ! return("QUEUED", None) ! else: ! return ("ERROR", "Unsupported message type: %s" % how) except SystemExit: raise except socket.error: ! raise except: self.debug("localcall:EXCEPTION") *************** *** 194,215 **** 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) def asynccall(self, oid, methodname, args, kwargs): ! request = ("call", (oid, methodname, args, kwargs)) seq = self.newseq() self.debug(("asynccall:%d:" % seq), oid, methodname, args, kwargs) self.putmessage((seq, request)) return seq def asyncreturn(self, seq): self.debug("asyncreturn:%d:call getresponse(): " % seq) ! response = self.getresponse(seq, wait=None) self.debug(("asyncreturn:%d:response: " % seq), response) return self.decoderesponse(response) --- 206,240 ---- def remotecall(self, oid, methodname, args, kwargs): self.debug("remotecall:asynccall: ", oid, methodname) seq = self.asynccall(oid, methodname, args, kwargs) return self.asyncreturn(seq) + def remotequeue(self, oid, methodname, args, kwargs): + self.debug("remotequeue:asyncqueue: ", oid, methodname) + seq = self.asyncqueue(oid, methodname, args, kwargs) + return self.asyncreturn(seq) + def asynccall(self, oid, methodname, args, kwargs): ! request = ("CALL", (oid, methodname, args, kwargs)) seq = self.newseq() + if threading.currentThread() != self.sockthread: + cvar = threading.Condition() + self.cvars[seq] = cvar self.debug(("asynccall:%d:" % seq), oid, methodname, args, kwargs) self.putmessage((seq, request)) return seq + def asyncqueue(self, oid, methodname, args, kwargs): + request = ("QUEUE", (oid, methodname, args, kwargs)) + seq = self.newseq() + if threading.currentThread() != self.sockthread: + cvar = threading.Condition() + self.cvars[seq] = cvar + self.debug(("asyncqueue:%d:" % seq), oid, methodname, args, kwargs) + self.putmessage((seq, request)) + return seq + def asyncreturn(self, seq): self.debug("asyncreturn:%d:call getresponse(): " % seq) ! response = self.getresponse(seq, wait=0.05) self.debug(("asyncreturn:%d:response: " % seq), response) return self.decoderesponse(response) *************** *** 219,225 **** --- 244,256 ---- if how == "OK": return what + if how == "QUEUED": + return None if how == "EXCEPTION": self.debug("decoderesponse: EXCEPTION") return None + if how == "EOF": + self.debug("decoderesponse: EOF") + self.decode_interrupthook() + return None if how == "ERROR": self.debug("decoderesponse: Internal ERROR:", what) *************** *** 227,241 **** raise SystemError, (how, what) def mainloop(self): """Listen on socket until I/O not ready or EOF ! Main thread pollresponse() will loop looking for seq number None, which never comes, and exit on EOFError. """ try: ! self.getresponse(myseq=None, wait=None) except EOFError: ! pass def getresponse(self, myseq, wait): --- 258,277 ---- raise SystemError, (how, what) + def decode_interrupthook(self): + "" + raise EOFError + def mainloop(self): """Listen on socket until I/O not ready or EOF ! pollresponse() will loop looking for seq number None, which never comes, and exit on EOFError. """ try: ! self.getresponse(myseq=None, wait=0.05) except EOFError: ! self.debug("mainloop:return") ! return def getresponse(self, myseq, wait): *************** *** 257,263 **** def _getresponse(self, myseq, wait): self.debug("_getresponse:myseq:", myseq) ! if threading.currentThread() is self.mainthread: ! # Main thread: does all reading of requests or responses ! # Loop here, blocking each time until socket is ready. while 1: response = self.pollresponse(myseq, wait) --- 293,298 ---- def _getresponse(self, myseq, wait): self.debug("_getresponse:myseq:", myseq) ! if threading.currentThread() is self.sockthread: ! # this thread does all reading of requests or responses while 1: response = self.pollresponse(myseq, wait) *************** *** 265,277 **** return response 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 --- 300,314 ---- return response else: ! # wait for notification from socket handling thread ! cvar = self.cvars[myseq] ! cvar.acquire() while not self.responses.has_key(myseq): ! cvar.wait() response = self.responses[myseq] + self.debug("_getresponse:%s: thread woke up: response: %s" % + (myseq, response)) del self.responses[myseq] del self.cvars[myseq] ! cvar.release() return response *************** *** 284,288 **** try: s = pickle.dumps(message) ! except: print >>sys.__stderr__, "Cannot pickle:", `message` raise --- 321,325 ---- try: s = pickle.dumps(message) ! except pickle.UnpicklingError: print >>sys.__stderr__, "Cannot pickle:", `message` raise *************** *** 294,301 **** # socket was closed raise IOError else: s = s[n:] ! def ioready(self, wait=0.0): r, w, x = select.select([self.sock.fileno()], [], [], wait) return len(r) --- 331,341 ---- # socket was closed raise IOError + except socket.error: + self.debug("putmessage:socketerror:pid:%s" % os.getpid()) + os._exit(0) else: s = s[n:] ! def ioready(self, wait): r, w, x = select.select([self.sock.fileno()], [], [], wait) return len(r) *************** *** 305,309 **** bufstate = 0 # meaning: 0 => reading count; 1 => reading data ! def pollpacket(self, wait=0.0): self._stage0() if len(self.buffer) < self.bufneed: --- 345,349 ---- bufstate = 0 # meaning: 0 => reading count; 1 => reading data ! def pollpacket(self, wait): self._stage0() if len(self.buffer) < self.bufneed: *************** *** 335,339 **** return packet ! def pollmessage(self, wait=0.0): packet = self.pollpacket(wait) if packet is None: --- 375,379 ---- return packet ! def pollmessage(self, wait): packet = self.pollpacket(wait) if packet is None: *************** *** 349,391 **** return message ! def pollresponse(self, myseq, wait=0.0): """Handle messages received on the socket. ! Some messages received may be asynchronous 'call' commands, and ! some may be responses intended for other threads. ! Loop until message with myseq sequence number is received. Save others ! in self.responses and notify the owning thread, except that 'call' ! commands are handed off to localcall() and the response sent back ! across the link with the appropriate sequence number. """ while 1: ! message = self.pollmessage(wait) ! if message is None: # socket not ready return None - #wait = 0.0 # poll on subsequent passes instead of blocking seq, resq = message self.debug("pollresponse:%d:myseq:%s" % (seq, myseq)) ! if resq[0] == "call": self.debug("pollresponse:%d:localcall:call:" % seq) ! response = self.localcall(resq) self.debug("pollresponse:%d:localcall:response:%s" % (seq, response)) ! self.putmessage((seq, response)) continue elif seq == myseq: 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 #----------------- end class SocketIO -------------------- --- 389,483 ---- return message ! def pollresponse(self, myseq, wait): """Handle messages received on the socket. ! Some messages received may be asynchronous 'call' or 'queue' requests, ! and some may be responses for other threads. ! ! 'call' requests are passed to self.localcall() with the expectation of ! immediate execution, during which time the socket is not serviced. ! 'queue' requests are used for tasks (which may block or hang) to be ! processed in a different thread. These requests are fed into ! request_queue by self.localcall(). Responses to queued requests are ! taken from response_queue and sent across the link with the associated ! sequence numbers. Messages in the queues are (sequence_number, ! request/response) tuples and code using this module removing messages ! from the request_queue is responsible for returning the correct ! sequence number in the response_queue. ! ! pollresponse() will loop until a response message with the myseq ! sequence number is received, and will save other responses in ! self.responses and notify the owning thread. """ while 1: ! # send queued response if there is one available ! try: ! qmsg = response_queue.get(0) ! except Queue.Empty: ! pass ! else: ! seq, response = qmsg ! message = (seq, ('OK', response)) ! self.putmessage(message) ! # poll for message on link ! try: ! message = self.pollmessage(wait) ! if message is None: # socket not ready ! return None ! except EOFError: ! self.handle_EOF() ! return None ! except AttributeError: return None seq, resq = message + how = resq[0] self.debug("pollresponse:%d:myseq:%s" % (seq, myseq)) ! # process or queue a request ! if how in ("CALL", "QUEUE"): self.debug("pollresponse:%d:localcall:call:" % seq) ! response = self.localcall(seq, resq) self.debug("pollresponse:%d:localcall:response:%s" % (seq, response)) ! if how == "CALL": ! self.putmessage((seq, response)) ! elif how == "QUEUE": ! # don't acknowledge the 'queue' request! ! pass continue + # return if completed message transaction elif seq == myseq: return resq + # must be a response for a different thread: else: ! cv = self.cvars.get(seq, None) # response involving unknown sequence number is discarded, ! # probably intended for prior incarnation of server if cv is not None: + cv.acquire() self.responses[seq] = resq cv.notify() ! cv.release() continue + def handle_EOF(self): + "action taken upon link being closed by peer" + self.EOFhook() + self.debug("handle_EOF") + for key in self.cvars: + cv = self.cvars[key] + cv.acquire() + self.responses[key] = ('EOF', None) + cv.notify() + cv.release() + interrupt.interrupt_main() + # call our (possibly overridden) exit function + self.exithook() + + def EOFhook(self): + "Classes using rpc client/server can override to augment EOF action" + pass + #----------------- end class SocketIO -------------------- *************** *** 466,470 **** if not self.__attributes.has_key(name): raise AttributeError, name ! __getattr__.DebuggerStepThrough=1 def __getattributes(self): --- 558,563 ---- if not self.__attributes.has_key(name): raise AttributeError, name ! ! __getattr__.DebuggerStepThrough = 1 def __getattributes(self): Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** run.py 22 Mar 2003 19:40:19 -0000 1.14 --- run.py 8 May 2003 20:26:55 -0000 1.15 *************** *** 1,3 **** --- 1,4 ---- import sys + import os import time import socket *************** *** 21,30 **** # completion and exit flags: - server = None # RPCServer instance - queue = Queue.Queue(0) - execution_finished = False exit_requested = False - def main(): """Start the Python execution server in a subprocess --- 22,27 ---- *************** *** 45,50 **** """ - global queue, execution_finished, exit_requested - port = 8833 if sys.argv[1:]: --- 42,45 ---- *************** *** 59,77 **** try: if exit_requested: ! sys.exit() ! # XXX KBK 22Mar03 eventually check queue here! ! pass ! time.sleep(0.05) except KeyboardInterrupt: - ##execution_finished = True continue def manage_socket(address): - global server, exit_requested - for i in range(6): time.sleep(i) try: ! server = rpc.RPCServer(address, MyHandler) break except socket.error, err: --- 54,74 ---- try: if exit_requested: ! os._exit(0) ! try: ! seq, request = rpc.request_queue.get(0) ! except Queue.Empty: ! time.sleep(0.05) ! continue ! method, args, kwargs = request ! ret = method(*args, **kwargs) ! rpc.response_queue.put((seq, ret)) except KeyboardInterrupt: continue def manage_socket(address): for i in range(6): time.sleep(i) try: ! server = MyRPCServer(address, MyHandler) break except socket.error, err: *************** *** 83,90 **** --- 80,118 ---- else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." + global exit_requested exit_requested = True + return server.handle_request() # A single request only + class MyRPCServer(rpc.RPCServer): + + def handle_error(self, request, client_address): + """Override RPCServer method for IDLE + + Interrupt the MainThread and exit server if link is dropped. + + """ + try: + raise + except SystemExit: + raise + except EOFError: + global exit_requested + exit_requested = True + interrupt.interrupt_main() + except: + erf = sys.__stderr__ + print>>erf, '\n' + '-'*40 + print>>erf, 'Unhandled server exception!' + print>>erf, 'Thread: %s' % threading.currentThread().getName() + print>>erf, 'Client Address: ', client_address + print>>erf, 'Request: ', repr(request) + traceback.print_exc(file=erf) + print>>erf, '\n*** Unrecoverable, server exiting!' + print>>erf, '-'*40 + os._exit(0) + + class MyHandler(rpc.RPCHandler): *************** *** 96,100 **** sys.stdout = self.get_remote_proxy("stdout") sys.stderr = self.get_remote_proxy("stderr") ! rpc.RPCHandler.getresponse(self, myseq=None, wait=0.5) --- 124,141 ---- sys.stdout = self.get_remote_proxy("stdout") sys.stderr = self.get_remote_proxy("stderr") ! rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05) ! ! def exithook(self): ! "override SocketIO method - wait for MainThread to shut us down" ! while 1: pass ! ! def EOFhook(self): ! "Override SocketIO method - terminate wait on callback and exit thread" ! global exit_requested ! exit_requested = True ! ! def decode_interrupthook(self): ! "interrupt awakened thread" ! interrupt.interrupt_main() *************** *** 107,148 **** def runcode(self, code): - global queue, execution_finished - - execution_finished = False - queue.put(code) - # dequeue and run in subthread - self.runcode_from_queue() - while not execution_finished: - time.sleep(0.05) - - def runcode_from_queue(self): - global queue, execution_finished - - # poll until queue has code object, using threads, just block? - while True: - try: - code = queue.get(0) - break - except Queue.Empty: - time.sleep(0.05) try: exec code in self.locals except: ! self.flush_stdout() ! 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) ! traceback.print_list(tbe, file=efile) ! lines = traceback.format_exception_only(typ, val) ! for line in lines: ! print>>efile, line, ! execution_finished = True else: self.flush_stdout() - execution_finished = True def flush_stdout(self): --- 148,175 ---- def runcode(self, code): try: exec code in self.locals except: ! try: ! if exit_requested: ! os._exit(0) ! self.flush_stdout() ! 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", "threading.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, ! except: ! sys.stderr = sys.__stderr__ ! raise else: self.flush_stdout() def flush_stdout(self): *************** *** 185,196 **** def interrupt_the_server(self): - self.rpchandler.interrupted = True - ##print>>sys.__stderr__, "** Interrupt main!" interrupt.interrupt_main() - - def shutdown_the_server(self): - global exit_requested - - exit_requested = True def start_the_debugger(self, gui_adap_oid): --- 212,216 ---- From kbk@shore.net Fri May 9 02:45:19 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Thu, 08 May 2003 21:45:19 -0400 Subject: [Idle-dev] CVS Status Message-ID: Note that the Debugger has been temporarily disabled in the latest check-in because it's tracing through threading.py, and Queue.py. The task is to solve this in a way which allows tracing through user code which imports the threading and/or Queue modules. -- KBK From alain.cadet@insee.fr Fri May 9 08:32:59 2003 From: alain.cadet@insee.fr (Cadet Alain) Date: Fri, 9 May 2003 09:32:59 +0200 Subject: [Idle-dev] Bug report for idle : problems with file save and unicode Message-ID: <71B15EF981A9D311BE5B0000F6C3A7B6DF2A00@S53X01> On windows NT4 with a French installation (cp850), I get sometimes some problems when I try to save a file. I get an error and after : 1) it is impossible to save the file 2) the previous file is lost (file with 0K and nothing inside) I got this several times. I notice nothing special except that the files have special characters in strng values (ascii >128). Here is the error message : Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Exception in Tkinter callback Traceback (most recent call last): File "D:\Python22\lib\lib-tk\Tkinter.py", line 1292, in __call__ return apply(self.func, args) File "D:\Python22\Tools\idle\EditorWindow.py", line 495, in close reply = self.maybesave() File "D:\Python22\Tools\idle\EditorWindow.py", line 490, in maybesave return self.io.maybesave() File "D:\Python22\Tools\idle\IOBinding.py", line 118, in maybesave self.save(None) File "D:\Python22\Tools\idle\IOBinding.py", line 128, in save if self.writefile(self.filename): File "D:\Python22\Tools\idle\IOBinding.py", line 154, in writefile f.write(chars) UnicodeError: ASCII encoding error: ordinal not in range(128) From zhaoqiang@neusoft.com Fri May 9 17:46:11 2003 From: zhaoqiang@neusoft.com (zhaoq) Date: Sat, 10 May 2003 00:46:11 +0800 Subject: [Idle-dev] please del my mail address from list,thanks! Message-ID: <002701c3164a$7f481fd0$0200a8c0@zhaoq> This is a multi-part message in MIME format. --Boundary_(ID_72k1rlEGrkhPzP2dh+Zfpw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT --Boundary_(ID_72k1rlEGrkhPzP2dh+Zfpw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
 
--Boundary_(ID_72k1rlEGrkhPzP2dh+Zfpw)-- From kbk@shore.net Fri May 9 19:20:31 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Fri, 09 May 2003 14:20:31 -0400 Subject: [Idle-dev] please del my mail address from list,thanks! In-Reply-To: <002701c3164a$7f481fd0$0200a8c0@zhaoq> (zhaoq's message of "Sat, 10 May 2003 00:46:11 +0800") References: <002701c3164a$7f481fd0$0200a8c0@zhaoq> Message-ID: Done, see you later.... From kbk@users.sourceforge.net Sat May 10 01:09:54 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 09 May 2003 17:09:54 -0700 Subject: [Idle-dev] CVS: idle Debugger.py,1.20,1.21 PyShell.py,1.60,1.61 rpc.py,1.23,1.24 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv20416 Modified Files: Debugger.py PyShell.py rpc.py Log Message: 1. Update debugger to not trace RPC code even when calling Queue and threading modules. Can debug user code which imports these modules, though. 2. Re-enable debugger in PyShell. 3. Remove old code implementing previous approaches to this issue. M Debugger.py M PyShell.py M rpc.py Index: Debugger.py =================================================================== RCS file: /cvsroot/idlefork/idle/Debugger.py,v retrieving revision 1.20 retrieving revision 1.21 diff -C2 -r1.20 -r1.21 *** Debugger.py 1 Jan 2003 00:26:41 -0000 1.20 --- Debugger.py 10 May 2003 00:09:52 -0000 1.21 *************** *** 14,53 **** def user_line(self, frame): ! ! co_filename = frame.f_code.co_filename ! ## co_name = frame.f_code.co_name ! ! ## print>>sys.__stderr__, "*function: ", frame.f_code.co_name ! ## print>>sys.__stderr__, "*file: ", frame.f_code.co_filename ! ## print>>sys.__stderr__, "*line number: ", frame.f_code.co_firstlineno ! ## print>>sys.__stderr__, "*name: ", co_name ! ## print>>sys.__stderr__, "*function: ", frame.f_locals.get(co_name,None) ! ! ## try: ! ## # XXX 12 Dec 2002 CGT TO DO: Find way to get a reference to the ! ## # XXX currently running function. If the function has an ! ## # attribute called "DebuggerStepThrough", prevent the debugger ! ## # from stepping through Idle code. The following doesn't work ! ## # in instance methods. Hard coded some workarounds. ! ## func = frame.f_locals[co_name] ! ## if getattr(func, "DebuggerStepThrough", 0): ! ## print "XXXX DEBUGGER STEPPING THROUGH" ! ## self.set_step() ! ## return ! ## except: ! ## pass ! ! # workaround for the problem above ! exclude = ('rpc.py', 'threading.py', '') ! for rpcfile in exclude: ! if co_filename.count(rpcfile): ! self.set_step() ! return message = self.__frame2message(frame) self.gui.interaction(message, frame) def user_exception(self, frame, info): message = self.__frame2message(frame) self.gui.interaction(message, frame, info) def __frame2message(self, frame): --- 14,39 ---- def user_line(self, frame): ! if self.in_rpc_code(frame): ! self.set_step() ! return message = self.__frame2message(frame) self.gui.interaction(message, frame) def user_exception(self, frame, info): + if self.in_rpc_code(frame): + self.set_step() + return message = self.__frame2message(frame) self.gui.interaction(message, frame, info) + + def in_rpc_code(self, frame): + if frame.f_code.co_filename.count('rpc.py'): + return True + else: + prev_frame = frame.f_back + if prev_frame.f_code.co_filename.count('Debugger.py'): + # (that test will catch both Debugger.py and RemoteDebugger.py) + return False + return self.in_rpc_code(prev_frame) def __frame2message(self, frame): Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.60 retrieving revision 1.61 diff -C2 -r1.60 -r1.61 *** PyShell.py 8 May 2003 20:26:54 -0000 1.60 --- PyShell.py 10 May 2003 00:09:52 -0000 1.61 *************** *** 691,695 **** text.bind("<>", self.eof_callback) text.bind("<>", self.open_stack_viewer) ! ##text.bind("<>", self.toggle_debugger) text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) --- 691,695 ---- text.bind("<>", self.eof_callback) text.bind("<>", self.open_stack_viewer) ! text.bind("<>", self.toggle_debugger) text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.23 retrieving revision 1.24 diff -C2 -r1.23 -r1.24 *** rpc.py 8 May 2003 20:26:54 -0000 1.23 --- rpc.py 10 May 2003 00:09:52 -0000 1.24 *************** *** 559,564 **** raise AttributeError, name - __getattr__.DebuggerStepThrough = 1 - def __getattributes(self): self.__attributes = self.sockio.remotecall(self.oid, --- 559,562 ---- From kbk@shore.net Sat May 10 01:15:42 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Fri, 09 May 2003 20:15:42 -0400 Subject: [Idle-dev] Debugger Message-ID: OK, Debugger is re-enabled in CVS -- KBK From kbk@users.sourceforge.net Sat May 10 01:49:58 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 09 May 2003 17:49:58 -0700 Subject: [Idle-dev] CVS: idle IOBinding.py,1.14,1.15 config-main.def,1.13,1.14 configDialog.py,1.51,1.52 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2233 Modified Files: IOBinding.py config-main.def configDialog.py Log Message: [ SF 710733 - Martin v. Loewis] Improving source encoding dialog M IOBinding.py M config-main.def M configDialog.py Index: IOBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/IOBinding.py,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** IOBinding.py 25 Apr 2003 18:36:31 -0000 1.14 --- IOBinding.py 10 May 2003 00:49:56 -0000 1.15 *************** *** 14,17 **** --- 14,19 ---- import tkMessageBox import re + from Tkinter import * + from SimpleDialog import SimpleDialog from configHandler import idleConf *************** *** 68,71 **** --- 70,119 ---- coding_re = re.compile("coding[:=]\s*([-\w_.]+)") + class EncodingMessage(SimpleDialog): + "Inform user that an encoding declaration is needed." + def __init__(self, master, enc): + self.should_edit = False + + self.root = top = Toplevel(master) + top.bind("", self.return_event) + top.bind("", self.do_ok) + top.protocol("WM_DELETE_WINDOW", self.wm_delete_window) + top.wm_title("I/O Warning") + top.wm_iconname("I/O Warning") + self.top = top + + l1 = Label(top, + text="Non-ASCII found, yet no encoding declared. Add a line like") + l1.pack(side=TOP, anchor=W) + l2 = Entry(top, font="courier") + l2.insert(0, "# -*- coding: %s -*-" % enc) + # For some reason, the text is not selectable anymore if the + # widget is disabled. + # l2['state'] = DISABLED + l2.pack(side=TOP, anchor = W, fill=X) + l3 = Label(top, text="to your file\n" + "Choose OK to save this file as %s\n" + "Edit your general options to silence this warning" % enc) + l3.pack(side=TOP, anchor = W) + + buttons = Frame(top) + buttons.pack(side=TOP, fill=X) + # Both return and cancel mean the same thing: do nothing + self.default = self.cancel = 0 + b1 = Button(buttons, text="Ok", default="active", + command=self.do_ok) + b1.pack(side=LEFT, fill=BOTH, expand=1) + b2 = Button(buttons, text="Edit my file", + command=self.do_edit) + b2.pack(side=LEFT, fill=BOTH, expand=1) + + self._set_transient(master) + + def do_ok(self): + self.done(0) + + def do_edit(self): + self.done(1) + def coding_spec(str): """Return the encoding declaration according to PEP 263. *************** *** 369,384 **** # Nothing was declared, and we had not determined an encoding # on loading. Recommend an encoding line. ! try: ! chars = chars.encode(encoding) ! enc = encoding ! except UnicodeError: ! chars = BOM_UTF8 + chars.encode("utf-8") ! enc = "utf-8" ! tkMessageBox.showerror( ! "I/O Error", ! "Non-ASCII found, yet no encoding declared. Add a line like\n" ! "# -*- coding: %s -*- \nto your file" % enc, ! master = self.text) ! return chars def fixlastline(self): --- 417,449 ---- # Nothing was declared, and we had not determined an encoding # on loading. Recommend an encoding line. ! config_encoding = idleConf.GetOption("main","EditorWindow", ! "encoding") ! if config_encoding == 'utf-8': ! # User has requested that we save files as UTF-8 ! return BOM_UTF8 + chars.encode("utf-8") ! ask_user = True ! try: ! chars = chars.encode(encoding) ! enc = encoding ! if config_encoding == 'locale': ! ask_user = False ! except UnicodeError: ! chars = BOM_UTF8 + chars.encode("utf-8") ! enc = "utf-8" ! if not ask_user: ! return chars ! dialog = EncodingMessage(self.editwin.top, enc) ! dialog.go() ! if dialog.num == 1: ! # User asked us to edit the file ! encline = "# -*- coding: %s -*-\n" % enc ! firstline = self.text.get("1.0", "2.0") ! if firstline.startswith("#!"): ! # Insert encoding after #! line ! self.text.insert("2.0", encline) ! else: ! self.text.insert("1.0", encline) ! return self.encode(self.text.get("1.0", "end-1c")) ! return chars def fixlastline(self): *************** *** 488,491 **** if __name__ == "__main__": - from Tkinter import * test() --- 553,555 ---- Index: config-main.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-main.def,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** config-main.def 14 Jan 2003 22:03:31 -0000 1.13 --- config-main.def 10 May 2003 00:49:56 -0000 1.14 *************** *** 50,53 **** --- 50,54 ---- font-size= 12 font-bold= 0 + encoding=none [Indent] Index: configDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/configDialog.py,v retrieving revision 1.51 retrieving revision 1.52 diff -C2 -r1.51 -r1.52 *** configDialog.py 14 Jan 2003 22:03:31 -0000 1.51 --- configDialog.py 10 May 2003 00:49:56 -0000 1.52 *************** *** 335,338 **** --- 335,339 ---- self.winHeight=StringVar(self) self.startupEdit=IntVar(self) + self.encoding=StringVar(self) self.userHelpBrowser=BooleanVar(self) self.helpBrowser=StringVar(self) *************** *** 343,346 **** --- 344,348 ---- frameRun=Frame(frame,borderwidth=2,relief=GROOVE) frameWinSize=Frame(frame,borderwidth=2,relief=GROOVE) + frameEncoding=Frame(frame,borderwidth=2,relief=GROOVE) frameHelp=Frame(frame,borderwidth=2,relief=GROOVE) #frameRun *************** *** 360,363 **** --- 362,373 ---- entryWinHeight=Entry(frameWinSize,textvariable=self.winHeight, width=3) + #frameEncoding + labelEncodingTitle=Label(frameEncoding,text="Default Source Encoding") + radioEncLocale=Radiobutton(frameEncoding,variable=self.encoding, + value="locale",text="Locale-defined") + radioEncUTF8=Radiobutton(frameEncoding,variable=self.encoding, + value="utf-8",text="UTF-8") + radioEncNone=Radiobutton(frameEncoding,variable=self.encoding, + value="none",text="None") #frameHelp labelHelpTitle=Label(frameHelp,text='Help Options') *************** *** 388,391 **** --- 398,402 ---- frameRun.pack(side=TOP,padx=5,pady=5,fill=X) frameWinSize.pack(side=TOP,padx=5,pady=5,fill=X) + frameEncoding.pack(side=TOP,padx=5,pady=5,fill=X) frameHelp.pack(side=TOP,padx=5,pady=5,expand=TRUE,fill=BOTH) #frameRun *************** *** 400,403 **** --- 411,419 ---- entryWinWidth.pack(side=RIGHT,anchor=E,padx=10,pady=5) labelWinWidthTitle.pack(side=RIGHT,anchor=E,pady=5) + #frameEncoding + labelEncodingTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) + radioEncNone.pack(side=RIGHT,anchor=E,pady=5) + radioEncUTF8.pack(side=RIGHT,anchor=E,pady=5) + radioEncLocale.pack(side=RIGHT,anchor=E,pady=5) #frameHelp labelHelpTitle.pack(side=TOP,anchor=W,padx=5,pady=5) *************** *** 433,436 **** --- 449,453 ---- self.winHeight.trace_variable('w',self.VarChanged_winHeight) self.startupEdit.trace_variable('w',self.VarChanged_startupEdit) + self.encoding.trace_variable('w',self.VarChanged_encoding) def VarChanged_fontSize(self,*params): *************** *** 526,529 **** --- 543,550 ---- self.AddChangedItem('main','General','editor-on-startup',value) + def VarChanged_encoding(self,*params): + value=self.encoding.get() + self.AddChangedItem('main','EditorWindow','encoding',value) + def ResetChangedItems(self): #When any config item is changed in this dialog, an entry *************** *** 1021,1024 **** --- 1042,1047 ---- self.winWidth.set(idleConf.GetOption('main','EditorWindow','width')) self.winHeight.set(idleConf.GetOption('main','EditorWindow','height')) + # default source encoding + self.encoding.set(idleConf.GetOption('main','EditorWindow','encoding')) # additional help sources self.userHelpList = idleConf.GetAllExtraHelpSourcesList() From noreply@sourceforge.net Sat May 10 01:52:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 17:52:47 -0700 Subject: [Idle-dev] [ idlefork-Patches-710733 ] Improving source encoding dialog Message-ID: Patches item #710733, was opened at 2003-03-27 09:10 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Lwis (loewis) Assigned to: Kurt B. Kaiser (kbk) Summary: Improving source encoding dialog Initial Comment: This patch improves the error message a user gets when saving a file with non-ASCII characters, and no source encoding is specified. It does so by: - adding a dialog EncodingMessage, which contains the line to add in a fixed-font entry widget, and which has a button to add that line to the file automatically. - adding a configuration option EditorWindow/encoding, which has three possible values: none, utf-8, and locale. none is the default; IDLE will show this dialog when non-ASCII characters are encountered. utf-8 means that files with non-ASCII characters are saved as utf-8-with-bom. locale means that files are saved in the locale's encoding; the dialog is only display if the source contains characters outside the locale's charset. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-09 19:52 Message: Logged In: YES user_id=149084 Applied. IOBinding.py 1.15 config-main.def 1.14 configDialog.py 1.52 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 From noreply@sourceforge.net Sat May 10 02:10:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 18:10:57 -0700 Subject: [Idle-dev] [ idlefork-Bugs-678325 ] ParenMatching Missing AutoIndent module Message-ID: Bugs item #678325, was opened at 2003-02-01 06:37 Message generated for change (Comment added) made by fisheggs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=678325&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: ParenMatching Missing AutoIndent module Initial Comment: Three problems: 1. There is no access to ParenMatching from the "Configure Idle" pannel. 2. One need to edit both the global configuration file in idlelib or idleforklib, and the local configuration file (in .idlerc, under linux) in order to enable this option. 3. When ParenMatching is enabled, python complains about missing AutoIndent module. I solved this problem by copying AutoIndent.py from the idle directory. Nadav. ---------------------------------------------------------------------- Comment By: Nigel Rowe (fisheggs) Date: 2003-05-10 11:10 Message: Logged In: YES user_id=756090 Re point 3. ParenMatch should be using EditorWindow, not AutoIndent. See patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=678325&group_id=9579 From noreply@sourceforge.net Sat May 10 02:14:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 18:14:59 -0700 Subject: [Idle-dev] [ idlefork-Patches-735527 ] Re Bug [ 678325 ] ParenMatching Missing AutoIndent module Message-ID: Patches item #735527, was opened at 2003-05-10 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=735527&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nigel Rowe (fisheggs) Assigned to: Nobody/Anonymous (nobody) Summary: Re Bug [ 678325 ] ParenMatching Missing AutoIndent module Initial Comment: Re point of bug 678325. ParenMatch.py should be using EditorWindow, not AutoIndent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=735527&group_id=9579 From noreply@sourceforge.net Sat May 10 04:29:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 09 May 2003 20:29:03 -0700 Subject: [Idle-dev] [ idlefork-Patches-456006 ] open multiple modules at once Message-ID: Patches item #456006, was opened at 2001-08-27 23:11 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Stephen M. Gava (elguavas) >Assigned to: Kurt B. Kaiser (kbk) Summary: open multiple modules at once Initial Comment: Every time I open a project, I open a lot of modules, and this was usually done by double-clicking each module in import myModule1, myModule2, myModule3, myModule4, myModule5, myModule6 and pressing Alt-M to open it. Now I patched EditorWindow.py to extend the ability of open_module to open a list of modules (and ignore the import keyword), so that one can select the whole line and open all modules with one Alt-M. Below is the changed method open_module in EditorWindow.py, which can be substituted to the original to obtain the new behaviour. def open_module(self, event=None): # XXX Shouldn't this be in IOBinding or in FileList? try: name = self.text.get("sel.first", "sel.last") except TclError: name = "" else: name = string.strip(name) if not name: name = tkSimpleDialog.askstring("Module", "Enter the name of a Python module\n" "to search on sys.path and open:", parent=self.text) name = string.replace(name, ",", " ") name = string.replace(name, ";", " ") nameList = string.split(name) # XXX Ought to support package syntax # XXX Ought to insert current file's directory in front of path for name in nameList: if name in ["", "import"]: continue try: (f, file, (suffix, mode, type)) = imp.find_module(name) except (NameError, ImportError), msg: tkMessageBox.showerror("Import error", str(msg), parent=self.text) return if type != imp.PY_SOURCE: tkMessageBox.showerror("Unsupported type", "%s is not a source module" % name, parent=self.text) return if f: f.close() if self.flist: self.flist.open(file) else: self.io.loadfile(file) Daniel Haertle ------------------------------------------------------------------------ Daniel Haertle haertle@iqe.phys.ethz.ch _________________ ___ http://www.nlo.ethz.ch / ____/_ __/ /_/ / ETH Hoenggerberg - Nonlinear Optics Laboratory / __/_ / / / __ / Institute of Quantum Electronics, HPF E18 /______/ /__/ /__/ /__/ 8093 Zuerich - Switzerland Tel +41 1 63 32338 Fax +41 1 63 31056 ------------------------------------------------------------------------ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:54 Message: Logged In: YES user_id=149084 Per GvR Python style guide, PEP 8, multiple module names on one line are discouraged. The sylistically allowable exceptions are rather minor. Downgrade priority pending further discussion whether this is worthwhile. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:59 Message: Logged In: YES user_id=75867 I like this idea in principle. I float implementation detail ideas on idle-dev when I get the chance to eventually come back to this in earnest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 From 377uo43ob@hotmail.com Sun May 11 00:22:23 2003 From: 377uo43ob@hotmail.com (Sophie Grant) Date: Sat, 10 May 03 23:22:23 GMT Subject: [Idle-dev] From Danny oqkttbg bwaqrv Message-ID: This is a multi-part message in MIME format. --0_A7931DF027.9_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
 
 
 

3D""

 
 
 
qrqxkw qzo egv nfr --0_A7931DF027.9_-- From kbk@users.sourceforge.net Mon May 12 03:33:50 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 11 May 2003 19:33:50 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.61,1.62 RemoteDebugger.py,1.9,1.10 run.py,1.15,1.16 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2433 Modified Files: PyShell.py RemoteDebugger.py run.py Log Message: 1. RemoteDebugger now runs user code in subprocess MainThread 2. run.py: move exception printing to toplevel to allow access from main() 3. Clarification in PyShell.py: when the subprocess is restarted, the debugger GUI is reused with a fresh instance of the subprocess debugger. M PyShell.py M RemoteDebugger.py M run.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.61 retrieving revision 1.62 diff -C2 -r1.61 -r1.62 *** PyShell.py 10 May 2003 00:09:52 -0000 1.61 --- PyShell.py 12 May 2003 02:33:47 -0000 1.62 *************** *** 369,372 **** --- 369,373 ---- if debug: try: + # Only close subprocess debugger, don't unregister gui_adap! RemoteDebugger.close_subprocess_debugger(self.rpcclt) except: *************** *** 388,391 **** --- 389,393 ---- # restart subprocess debugger if debug: + # Restarted debugger connects to current instance of debug GUI gui = RemoteDebugger.restart_subprocess_debugger(self.rpcclt) # reload remote debugger breakpoints for all PyShellEditWindows Index: RemoteDebugger.py =================================================================== RCS file: /cvsroot/idlefork/idle/RemoteDebugger.py,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** RemoteDebugger.py 25 Jan 2003 21:33:40 -0000 1.9 --- RemoteDebugger.py 12 May 2003 02:33:47 -0000 1.10 *************** *** 301,305 **** def run(self, cmd, locals): # Ignores locals on purpose! ! seq = self.conn.asynccall(self.oid, "run", (cmd,), {}) self.shell.interp.active_seq = seq --- 301,305 ---- def run(self, cmd, locals): # Ignores locals on purpose! ! seq = self.conn.asyncqueue(self.oid, "run", (cmd,), {}) self.shell.interp.active_seq = seq Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** run.py 8 May 2003 20:26:55 -0000 1.15 --- run.py 12 May 2003 02:33:47 -0000 1.16 *************** *** 63,67 **** ret = method(*args, **kwargs) rpc.response_queue.put((seq, ret)) ! except KeyboardInterrupt: continue --- 63,69 ---- ret = method(*args, **kwargs) rpc.response_queue.put((seq, ret)) ! except: ! print_exception() ! rpc.response_queue.put((seq, None)) continue *************** *** 85,88 **** --- 87,143 ---- server.handle_request() # A single request only + def print_exception(): + flush_stdout() + efile = sys.stderr + typ, val, tb = info = sys.exc_info() + tbe = traceback.extract_tb(tb) + print >>efile, 'Traceback (most recent call last):' + exclude = ("run.py", "rpc.py", "threading.py", "Queue.py", + "RemoteDebugger.py", "bdb.py") + 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(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: " + rpchandler = rpc.objecttable['exec'].rpchandler + for i in range(len(tb)): + fn, ln, nm, line = tb[i] + if nm == '?': + nm = "-toplevel-" + if not line and fn.startswith(">efile, 'Traceback (most recent call last):' ! exclude = ("run.py", "rpc.py", "threading.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, except: sys.stderr = sys.__stderr__ raise else: ! self.flush_stdout() ! ! def flush_stdout(self): ! try: ! if sys.stdout.softspace: ! sys.stdout.softspace = 0 ! sys.stdout.write("\n") ! except (AttributeError, EOFError): ! pass ! ! 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(" Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv12544 Modified Files: NEWS.txt Log Message: Update for SF 71033 and changes to subprocess threading Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** NEWS.txt 8 May 2003 20:26:54 -0000 1.15 --- NEWS.txt 12 May 2003 03:04:59 -0000 1.16 *************** *** 8,16 **** *Release date: XX-XXX-2003* - Improved I/O response by tweaking the wait parameter in various calls to signal.signal(). - Implemented a threaded subprocess which allows interrupting a pass ! loop in user code using the 'interrupt' extension. - Implemented the 'interrupt' extension module, which allows a subthread --- 8,28 ---- *Release date: XX-XXX-2003* + - Improve the error message a user gets when saving a file with non-ASCII + characters and no source encoding is specified. Done by adding a dialog + 'EncodingMessage', which contains the line to add in a fixed-font entry + widget, and which has a button to add that line to the file automatically. + Also, add a configuration option 'EditorWindow/encoding', which has three + possible values: none, utf-8, and locale. None is the default: IDLE will show + this dialog when non-ASCII characters are encountered. utf-8 means that files + with non-ASCII characters are saved as utf-8-with-bom. locale means that + files are saved in the locale's encoding; the dialog is only displayed if the + source contains characters outside the locale's charset. SF 710733 - Loewis + - Improved I/O response by tweaking the wait parameter in various calls to signal.signal(). - Implemented a threaded subprocess which allows interrupting a pass ! loop in user code using the 'interrupt' extension. User code runs ! in MainThread, while the RPCServer is handled by SockThread. - Implemented the 'interrupt' extension module, which allows a subthread From tonylownds@users.sourceforge.net Tue May 13 16:28:23 2003 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Tue, 13 May 2003 08:28:23 -0700 Subject: [Idle-dev] CVS: idle buildapp.py,NONE,1.1 INSTALL.txt,1.6,1.7 PyShell.py,1.62,1.63 macosx_main.py,1.8,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv17129 Modified Files: INSTALL.txt PyShell.py Added Files: buildapp.py Removed Files: macosx_main.py Log Message: 1. The command-line arguments for subprocesses no longer need to be specialized for Mac OS X. 2. buildapp.py - a new file for building an application icon for IDLE on Mac OS X. See INSTALL.txt --- NEW FILE: buildapp.py --- # # After running python setup.py install, run this program from the command # line like so: # # % python2.3 buildapp.py build # # A double-clickable IDLE application will be created in the build/ directory. # from bundlebuilder import buildapp buildapp( name="IDLE", mainprogram="idle.py", argv_emulation=1, ) Index: INSTALL.txt =================================================================== RCS file: /cvsroot/idlefork/idle/INSTALL.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** INSTALL.txt 25 Apr 2003 16:37:31 -0000 1.6 --- INSTALL.txt 13 May 2003 15:28:21 -0000 1.7 *************** *** 42,45 **** --- 42,56 ---- script to read: !# /usr/bin/python2.2 + + On Mac OS X, /usr/bin/python may be pointing at the OS-installed + python, which does not have GUI support. Change the first line of + /usr/bin/idle to read: + #! /usr/bin/env pythonw + + Also, to build an IDLE application that can be used from the Finder + on Mac OS X, run: + pythonw buildapp.py build + open build + You will see an IDLE application. See README.txt for more details on this version of IDLEfork. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.62 retrieving revision 1.63 diff -C2 -r1.62 -r1.63 *** PyShell.py 12 May 2003 02:33:47 -0000 1.62 --- PyShell.py 13 May 2003 15:28:21 -0000 1.63 *************** *** 312,338 **** def build_subprocess_arglist(self): ! if sys.platform == 'darwin' and sys.argv[0].count('.app'): ! # We need to avoid using sys.executable because it fails on some ! # of the applet architectures On Mac OS X. ! # ! # here are the applet architectures tried: ! # ! # framework applet: sys.executable + -p is correct ! # python 2.2 + pure python main applet: ! # sys.executable + -p is correct ! # pythonw idle.py: sys.executable + -c is correct ! # ! # XXX what about warnoptions? ! return [sys.executable, '-p', str(self.port)] else: ! w = ['-W' + s for s in sys.warnoptions] ! # Maybe IDLE is installed and is being accessed via sys.path, ! # or maybe it's not installed and the idle.py script is being ! # run from the IDLE source directory. ! if __name__ == 'idlelib.PyShell': ! command = "__import__('idlelib.run').run.main()" ! else: ! command = "__import__('run').main()" ! return [sys.executable] + w + ["-c", command, str(self.port)] def start_subprocess(self): --- 312,324 ---- def build_subprocess_arglist(self): ! w = ['-W' + s for s in sys.warnoptions] ! # Maybe IDLE is installed and is being accessed via sys.path, ! # or maybe it's not installed and the idle.py script is being ! # run from the IDLE source directory. ! if __name__ == 'idlelib.PyShell': ! command = "__import__('idlelib.run').run.main()" else: ! command = "__import__('run').main()" ! return [sys.executable] + w + ["-c", command, str(self.port)] def start_subprocess(self): --- macosx_main.py DELETED --- From tony@lownds.com Tue May 13 16:50:27 2003 From: tony@lownds.com (Tony Lownds) Date: Tue, 13 May 2003 08:50:27 -0700 Subject: [Idle-dev] IDLE application icon? Message-ID: --============_-1159281432==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi All, I'd like to add an icon for the IDLE application on Mac OS X. What do you think of the attached? Was there ever an IDLE icon for Windows? -Tony --============_-1159281432==_============ Content-Id: Content-Type: application/mac-binhex40; name="IDLE.gif" Content-Disposition: attachment; filename="IDLE.gif" ; modification-date="Mon, 12 May 2003 10:18:12 -0700" (This file must be converted with BinHex 4.0) :#%P%6%8ZCfPQ!!!!!!!!!!!!!!!!!"-!!!!!!*G'4dP'1$PKJ!#!!2Ir!2rrr`J )#"JB'#%K)6Nj18T+5P*58Q0MBfYVDhYlHi5%K)b-M*58P*bFR+@PTDfYVEfp[FE 'aXl'aXDp[B4lHmDeY9T58UfFR*b-M+@8P*5%K)4cFh0MBk@-M*b%K$%T+9T+5LN K)9*#3N)a-6NT+6%K)4J3%#NB'$NK)4!)#$%B'#%3%"J)#!J!!(055XDYT8)T)9T #16NK'-DeVBalFi4cDfYD8Q055NSj-8)a+5NB%#%3#-DPP&T+3[HeP$NT)A0M@XD FK+9lBc%K'+9D-BacBrHeM+eV3U9M1Ca5)HqeM'0+1HHYK-k8Dk9V3N)T'*4D-FC c1EeV-Fjc-E9M+FCV+DeD)D95'+e5%-DPM+f-FrHeK0D8BmD%8V9c3Xk%5XCl3Ve c1D9M-FCc-DeM+HHeM,@-Dkf%BrHpM-kFFqqeK,@%@YDFDrHeHmk8Bkel8XD-@Xk -8XCl1DeV-D9M+EeV+E9M)DfFM*4lBdSj+5%B%0D-5V9V+E@YT9*+3T5%FmDYP+f 8Hjb%DmkYM0DYK-kPHrr'M2qpHqHPBrqeDdT#1HHpM#NK'2HpHrHeDqqYBpkpP-k YK-DPHlfFFl@8DrHeBqqY@XkeP-DYM1qpHrHpDqqeBrI'HqHeDpDP@[HpBhYD+Fk eM1HpHpDYDrI'FqqpDqHeBf0D5Tb%@[I'DqqpBj4c1FDeP,fYM,fPFh0M3Uf8Bk@ -@YDeFjb%8ZHpDkf-5UfPP0DpK-DYFmkYBrI1FmDP@ZHpBmkpP,@PHk@8Bi4c3XD YBl@F8QYD+8Sj#,@YP+fPM)4c1@05'(YV-EfeM+fPHjb8Dib%@T5%-D@FDj5-@U@ FBi4l5RYc3Sb%5Sb%-B4l+AYc)@YM'+fYTE@eVA0cDi5%Hd*#1E@eR+@PM*bFHb% K'&TD+@YV)9TD'&TD#$Nj!%*+#%T5#$%j!+feYFE'cUfY[Cb8Y9)aTBalY9SjTC5 %YAYMV@Y+V8)BR$N)R$%!R)4VVFDpaUfFVDfFTEfYYFDe[Cb%M!!!!-$!`#(j"!% !!2m!,!!!!!#!!)!!3!Mr!2m*(%L`S-'$#"-UA-L`SF1(%#0+G!J"(i4r&KdXf'C KK+)K1NVSd"&#`F@*+&1UA,P`JS4p'IV4i'#KK`JF)dDJS2([*-ZI3&(ZZl#+#KN TBD4)S@+8c*8N'4S`Z!LK`EB3,9UNb'U#4B'JB)&#d2H'cT``D0'#!I0&cKJ`JbU `h1B#KSB%0f"F#-ZA)!4Y6XK336ZR$K@PE,p)UG)&JXqq$G9PZb2TPQ94Q$2ILQ5 jFbK@32F&mK*Q$P-TI-C)L3)'$Kc@6IV)KCabAcTca-Bj%jE,NkP0P654%Uk*H+R MTA59%YAVmFTLDpEifNHE,`4eYmqK`eDYeUlIMK`9rarr5G1R4*r5Tkr%RYDPk[! K3XKQc&LX*S8+GHSN+e1E4T`%5!STKa4ib)!$TU)J+EVS)L##T*5555Dd31*FI#V 0ji!YaM36bc18Z#***)33SSBSLf!@)#GSU*(*LJ'LXD+-!ZV#B)-i3UMJMXJTL&` Q%TC#L#dB%T50,F9-3XNaa*!!Fm`XNa4###l*1!(,*#85`S3D6#M4iKBZEK(M&Q3 #f%JMC(+ba5'F)1J)JSP!'0jjaEdjS#D9P$GHFEbS8NTa%CCb#j&&%U50,G*)di` ik#3M$5@5Z$)-1Sp+)XNXb+##5b&-G-U%,)J`NFNM@dcSb)4YT"UHUSi38XSMajh rkXJSX$j#DbGX[1U**BmJiJNL[3%lbLLK$**0SFJQUba#lYMMl,-%YI2XXr)30-q dcY*$%,Ef`0-3YpiZUe+cf%E,EEA@eS0Y1`0akmkhf)BVlVcdeJZC1JISX8*A+D4 JJJNTK&2!!GXNS-!#$0LV-&MU-+$!$BU-3!)*2m53!2#&#bm-J6G%5)'%&c`md-F q3f@J33dFh####)VJS)J-)Q4F+!4hd&%D@U5a"8FFAl#eKMF60$4"!J)%8%!)*Z" 3!cJb6k41)%J-PPC5BAJ"aKKMa&%"aLa&i"J%AMGG%!4ph((%c@%`98FBB,L4aQY M`0%(2[9LC`ibeMLc5bkQr2pQb5HUU*+H*UP%k#GbY)6bNcC[),@@'fbiS9JA&33 YGN(UQ'11GVVa*U&ijU95bTfP(+lF*[bTFcQ'kQL$6MRB110G-+0d%Q5E%1DHHh' UQ&)+,FDXRY+KaMb6KT5b-0''%8D8fFKrR,c))LFq'-**JEL6XL#-R*MC5)4!)PG ++!iSQmdVi,5b6#5q&"**+,j-`X`XdJ!$UC5%$&+'%[ccli-4r80$QVURTLdB`K" L!P$f)'3Ml@QL&$Z#N!"jdS1F24hZGl6!)+(-CiYC`-)9VN$&-*+"LM58+!dHP&) C)J',qq##%+*3JaV)4+C-b0!rCrT2)c,KL%-NiK#1D)1"rdJ4RL)Q)K&&6+)M0Q' *5McL%CXSKAL3!0-*9R"0H&KF&VQQC5jZHG%Hp@"A3F!&VbpqmA*EK0C!T)8YG+h aA1h#eVXBBXBcST&EAD`MYZBa4Mf@5b"qj*BBXdM)3SBP!9-aT2!5-))"$#!!iIM !#F)aK",mi!FUf-%++XQ)!TK%NF*V3$Ji8)-Fj'!%2i#"(a`$bSa"B"m1d-G-3-# b%H5!"$$JaMqm&S&@*JX#YTJ!2LUhMcjF`!-8S-R+F'*,'rJb2YV3JQ#Q53Bbd)% (qG"("BTj!C24B!-T-q8*K["-X9c!#A-i#p[BYKB`K+%1GC!!!L#iKSm('-!%,4" !1"L4ri)9++#F$rP,)-3`0AEfc#eJN!$%$(BC%3GJj3!*X-%1PS!(J"T%(AG!!K, #X&'eY(--8i$$#bch%h`X`!Bfi)B$VSM&#@JM%%43Ta61JK4fZZ8,a5#T4F0#YM1 FK65'L@FBZZ!'0k`P#,0C&RD)`ChGl+)6TV"Gi(K"L`aQ%$QNN!"&9A["dcZm`3X GP8*3Sc"8SiiK$-@JMXE533adG+ihIDY%i&5a#9836K1"%jmS&-F5EEM6-%SC3a6 L`!Bf[+D3!0V3h(Ed9V[M#+imR"LGk2a%L`(plKDUqdN3MPH)1*c9'bb9Q6VXKJj b@--lL*!!)ZM'Sk#jcR86MPL12RDkNZ[rT)0cTpe&-2EcL$H&4dF++Njk9''*`(9 #&+'PE8'dXD%Rr3)@HaZ&+$U4#Gd"Gd'NH0!8XbS+@4a,Z@2E%#SS-3PFb%*,0Ja L)pl%2HieD%H&Ja'#(NL+m0%L%k#ak!0XB3Y82%-5R1U8$0@!KJ,,k)!dQPk#B95 J!6N)4YqVEbN#e)MM@,B8TT!!4'D,"%a`-%-3cB"&+hcKLeDSEaR,F!8c*N(L5,J i5lFS3aP#)H-B$PJ0CUTZJpVEAZZ5ER5P%amYU-S,m5&)50SS9$DD3@)Pq3)@`d! '1C,a#eIJ,dYEkKm0A86J!JI)HBhi)4((%bG5V*H"L4$1F!J(hm'PB[p2a4%I,iT F#PN8JelCJ!BiA"%*9m5#bT)Ja!UE%!YBQ("r5T!!S4,)e,`Y#(!,Cd)6KFp%a$H GHFhM+5+Fje5*f"jR%iMBcjq+8pPH*0PmGk$',%)N$A3FBlb@QJ8SCS%r@-bL#9S 5aCCQ5--fM+S0kYh#)dDP"L8DfiMKkA3P0X(X68#4LCD`4"4KY3P6Y+*m#pZ3!#! S3BPL11")r&hT2l54M@rV!dQ4B!+@bj!!L8)i3Mm`l-5@E+J')AAh%YIQl`@bm3" Y21$E$XJ!KrKVLfq!1aXE"Ur#9r)1H6Mmi34Kam-R2[&l$2)J&*I(1aU5mBj6r(, ``1-E!rNXE@e,MQAr*,Npl[K(JE"a@Qi8L$`%'FGTcA%Kh++(aafqZM3k+ir8+XM ,J`j)P004j5YR14G($R1"3#!Hp#"Mc8[HMUTErHT6GpE0&HRcT,YFj6(2ZKr&lXH ,,rcXD%qlfXZT!!3BB!3#--%),*!!J!8NI1em%B%!8R!#4[bJ")`)4dKd`)*q"5` %"%#!1R5+pj@S``%)3)!#&,#"!K!J*b6)`3jB%"*'#1#6MDG0"06KKflB!!8P)%% P2l#!j)Bq*IJi`!B@d!0E8J`(&1M*krX5J3ai3'8iQ&J1IQ!$GI4bpd"TJ!2iBE) 0f)"P,61P)LEJHZ5hC"d6'!S'01$mPE8-"cQ!3Im$V$m4EIb"$PTBKclf-B0p0+! $h,H"bQk#!ac!i06NAmKIK'#8Q","#l#d$pU`$lB3%aj`-ME3!iS3!bJ`![QA%'0 ""dU40P4J"8a""QI!64N3F0X`!L93!KjBH#b`!Y@RGK"`!9$!"dK48fM"&(0!"PJ 3#"!`!CN&0[M3!0f!6bB3!#B`"#XJEYDA$@+3!%lXe%jI%!Ga!!C6%$F[`"$U3!! ")!!N%!!"S!-``(KTpaGD3)4U)3GId!9Y)3G8-!PCS&B1i3"&F`!8J!)`m!GrB)* pJ!FaP4D1`aCZ!3HX-!&Bk"$lB!%rF!-83!&@@!0RT`fSN!"1(C8@(b8(66!$*Iq S%!e`!hQ3!!FAB!%Em)M#Je&13!@*U"CId"CMm!89F(aJ-3(+4cHNk%Z["$9T)68 iXaCM)!G)pB!""3l9T%jUicJp8`GbN!!&Q%Kq%!!e2j8fm,3DA3!(B"!&Ak!0HaJ IVC-0hl!-*CB,RC!!3Aj5AlU3!!N00'6F@&9m"4PN-aT5)eC88!G@i`C0F$9I!$6 dBK[RB&VH`6Hr)6LZ96MKBf'T)!YF&4E8CcCH)&2aY"UYi3C48!A,f)c*XJq+e4f e`$I-TKkDX!Q$`cYjp6[l@&,&S!8YU"5&-B&Jd!9a%!9bB!EiYc#Ne6QlN!"DMf8 HE#Bk[[-li(14+U%0Ca!&8N!%92m`"dSK"Df4"QR`"B4N0qA`9SjP9m,a*X6a3-P "#TK"#!r!%[[J"DFK"9lS0Nd3"A&$50Ha1HJ`$)ce#*J@C`N5C-Q43Ea`#b@C%[V J"R$JNfP!N!"5%!5r+#kfX6RBF!fed*!!RI!)He)iSZ0BiK0&D!N8IE!(8l#%Df# '33N"f9%1el!Ee1J)4j3)UI"$2U3JkN&Fl1%)XV""2m&+S-5BYl%GHF-E[Q-RZE- MkV'DUT!!1,6B%iRe1VVK(BdeDTEQBq-"3B!cC0KQIBFb3XIJ9,66#8(NBr"PMpP c(&8P#X8`Pmr%Ap)`#rG"#G*&ADJb)!HL1r!e)!mb(-U*'CjjG[2rd9q`J"q%N!! *SIC%CJBJf48J$hB)$44"0c*ISa-S@d!+Lp#Ei(8Nif8m*E*VTB+D2-BQea1IKG1 HdI-mi'09i3-*iIP-Kf),d@"P@X)%B-)rMlBQKf!p"cBpef-J$F3J"%TK!6)kCa) N5QN+bT!!PPRd&a[5Aq3P*EF!3cBf3#mL)ek'ScA#B!ffB`X8@hm*2N*'#d'3!#b fm'hC8'i%C`Y*fU3[@Jc-8'+Y)!Qi-#)P8JD,)'!h*#CLdL"U`'24-b(DL#0N1TD !L6K9C9A(FBqB8#J2-!dX9Q+q!'!Z0JL$i'+`!'X[9JEkS`3bpUGP)%248d0L%UB VJMd&mMd2GT`lrk+8b2%*iR-F['!+&e3iaf%+qPNGkQ!,c0!+@Z!+P$#RN`!-b)! -bG!-N!"#)KAD*I`$3%TJ"$*N"$)#CJ'5U!1#QN5N1fR@U!L5#ZVaCR$f3*3eCmS C2%@L$Yr3BL5@$1JJ$Y2`#eC+#*23"-&3S@U!S4R+T@5#"Yl6#)F3D3VNB`15CYJ T3AGb9h"@NDA!E+A3#Dh!35Z9$FQ`DP*b+F$`$#Vd+@Q3!$cmFf11CQ!b!Ui&e$h CHDY%&'&69#Gk-QB6&"jaKQ&4&@HY@3LCLLa(!JiIG#R*3!eB8L+8i%'"YMrk)`U YfQJd"'QTFLB#p$hK%@EKi80lSPTjXLHaa4l1r`CUe@BlHd),GMB['8"PV["N`c! -dJ!,8M)*al!+Nd!LK4!,De#Y*J+J0#5Q1,4$U"*%Ur)QFB+eRAC%4G4TiF&XdFB HdJBVXB8kV&#a5TB-X#!0[b!0b%!Tce#P)J3+4PXLe1!%Z+"Vr6SK[0B'[39Xrp% '@q"VT5#i5D3*kh9X6[4%6a4YdIB)[1*XMf!+RN!qpV*I51UfU$#KdN!-b!!0+AD Nf6!,!%B)jj8*RL)U`aBH`pCEVrZkEG!*,M)Kdb8+`j+l6E!,Zq!*Z3!XZF!h[TX ,Si!*aJ#%BP0Z4h)5kX"5%2!!qm9IaA!(2-!$Ph!*N!$3#pGl#FA!!mC3J2cGpJ$ 1qCVN@llQ+caG"h4e0!rXF"$ZNR)N"h)Lph9)eliRCh2`'dMbfh,r-(61!Jm10`p 4abdE*hEbSK!jYh-m*cBKalrqD`pK0m$1SLiq)A8i&bqqe-",4lp04a$a!%G&0bd (R"")jh90Sm&Ua-&%ah3VE-%)M(5VJm)ram,1%REh`#hhB-$j1m+&*--Qr-!a"`( UJLd9M-&(*m)C2,rpkdG$r#`Aabe0l%9NTdGQTc!qV,jka%GpT(*6A%G9E#pA6-2 B8Jrd!!rhS*Mh'lmKV(*II,jZr-C`(-I9%4!!1qeY!!!!: --============_-1159281432==_============-- From michael.williams@st-annes.oxford.ac.uk Tue May 13 17:05:47 2003 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Tue, 13 May 2003 17:05:47 +0100 Subject: [Idle-dev] IDLE application icon? In-Reply-To: Message-ID: On Tuesday, May 13, 2003, at 04:50 PM, Tony Lownds wrote: > I'd like to add an icon for the IDLE application on Mac OS X. What do > you think of the attached? Was there ever an IDLE icon for Windows? I'm not sure how useful the text will be for people who have their icons and dock quite small. I have some very cryptic icons in my dock, that a new user would struggle to guess the function of, so don't worry about spelling out the purpose (literally and figuratively) of an application in its icon. For example, Safari is a compass, and VideoLAN (a movie viewer) is a traffic cone (!). Visual and reflexive memory will allow them to pick it up quickly. Aren't there already some icons using snakes for Windows and X Window? I personally prefer your graphic, but it would be good to keep consistency across platforms, even if the Mac version is be a nice 24 bit 128x128 TIFF version of the same image. -- Michael From kbk@shore.net Tue May 13 20:34:14 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 13 May 2003 15:34:14 -0400 Subject: [Idle-dev] IDLE application icon? In-Reply-To: (Tony Lownds's message of "Tue, 13 May 2003 08:50:27 -0700") References: Message-ID: Tony Lownds writes: > I'd like to add an icon for the IDLE application on Mac OS X. What do > you think of the attached? Was there ever an IDLE icon for Windows? I don't seem to be able to view it. mac-binhex40 encoding? What about .../Icons/python.gif? -- KBK From tony@lownds.com Tue May 13 21:57:20 2003 From: tony@lownds.com (Tony Lownds) Date: Tue, 13 May 2003 13:57:20 -0700 Subject: [Idle-dev] IDLE application icon? In-Reply-To: References: Message-ID: --============_-1159263017==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I'm not sure how useful the text will be for people who have their >icons and dock quite small. I have some very cryptic icons in my >dock, that a new user would struggle to guess the function of, so >don't worry about spelling out the purpose (literally and >figuratively) of an application in its icon. Good point. I wasn't too sure about the text. >For example, Safari is a compass, and VideoLAN (a movie viewer) is a >traffic cone (!). Visual and reflexive memory will allow them to >pick it up quickly. > >Aren't there already some icons using snakes for Windows and X >Window? I personally prefer your graphic, but it would be good to >keep consistency across platforms, even if the Mac version is be a >nice 24 bit 128x128 TIFF version of the same image. Yes, there are PC icons (cute little pythons)\, although I don't think IDLE itself has a special icon. The problem is the resolution -- increasing the resolution of a 32x32 bitmap to 128x128 does not look nice at all. The MacPython IDE icon (attached) re-uses a small "16 ton" icon on a larger image, which is very reminiscent of Apple's Project Builder icon. Perhaps I could put the snake from the PC icon, or the foot, in place of the 16-ton. -Tony --============_-1159263017==_============ Content-Id: Content-Type: image/gif; name="PythonIDE.gif" ; x-mac-type="47494666" ; x-mac-creator="3842494D" Content-Disposition: attachment; filename="PythonIDE.gif" Content-Transfer-Encoding: base64 R0lGODlhgACAAPf/AP///xAQEEpKSmNjY2tra3Nzc4SEhIyMjJSUlKWlpa2trbW1tb29 vcbGxs7OztbW1t7e3ufn5+/v7/f39/fv79bOzr21tbWtrca9vZyUlGtjY869vVpSUpyM jIx7e4Rzc3tra0I5OWNSUlpKSlJCQnNaWkIxMVpCQjEhIUIpKSkYGBAICCEQEBgICGtK Qlo5MYRjWoxza0oxKTkhGK2clKWUjEo5MXNSQsallIRjUjkpIZSEe72EY9a9rXNaSrWM c62Ea71jKd7Gtb2llN69pdalhGNKObV7UqVrQpRaMa1jMb1rMbVjKbWUe9aUY86MWoRa Oc6ESsZ7Qr1zOaVjMbVrMZxaKaVaIaVSEN61lLWMa86cc9aca4xjQr2EUs6MUq1zQsaE SrVzOYRSKcZ7Ob1rKbWchGtaSs6EQrVrKdbOxpSMhN7OvVJKQs6tjL2ce4RrUr2Ua2tS OcaMUq2lnJx7SpR7Uq2UOZyMSqWUQq2cOb2tMca1Kc69KdbGIca9Kd7WGOfeEOfn3ikp ISEhGO/vCPf3AP//AO/v98bGzt7e56Wlrefn9wgAtQgAxhAAtRgArYyErdbO787G562l xpyUtaWU1ikApaWcvbWl3nNatWtSrVIxpWtalIxzxmNKnGNCrVIprUohpUIYpTkQlK2l vb2t3pSEtYRjxloxrUIQpTkInDEAlDEAnKWUxox7rWtCtTkIlK2U1qWMzpyExntjpXNa nEIYjEIQjMa13oRznEohhFIphJyMrc7G1rWtvZSMnIR7jGM5c2NKa/fv987GztbO1ufe 58a9xpyMnDEpMXNKa72ctZRzjHNSa5whe8aMtb2EraVrlJxjjPfe7+/W59a9zsZzra1a lN6tzs6EtZxShMZjpb1anIxCc5Qxc7U5jK0xhKUQc717pb1jnJxCe7VCjJwAY961ztaU vbVznJRSe71SlK0pe+e91qV7lMZzpbVjlKVShNacvc69xr2ttbWlrZSEjHNSY+fW3u/O 3ufG1q2MnHtaYwAAAMDAwCH5BAEAAP8ALAAAAACAAIAAQAj/AP8JHEiwoMGDCBMqXMiw ocOHECNKbKiAgYMHEB48aHDxgYMGHCFEkDABAIAJKFOqXLmywcSXCBU0wDgyZYSMDi5C IFnSpE+UJE+W7HnS5AQJERokSLagQQShLKNGJckTKMoHDGBCdDAUAgMFEEw6kGByAQKZ ZIkiVbpgAoMFDCIc/flxwtgGDJyiNCqVp9+pSRVESPBVAU2/CbTGJDqhQTIGOyEkaJD2 JLFqQilQA0ASwsdkixpAmKCIrE8JGSO0RRYBA0bPBxIkgLBAgdnYdB4wRt2g9mO5fv9S pYrSpeKDC8gilYvSK51E5o5NmNdtb750k7JnzzVq1S1eu1St/9rkqxcmTJV8NUAAt1k8 ktWosUQ0gT4F+il53qewH9F+CBDUIMcNO2AgwXIHHjjBAwto9YBPEBrQQE89SfCAAudA M0E355wkiSatsBLiiK2QaKKIIa5iCn3knINMAttA4wAEeDUlmxojORABfkBRcJSCB2aE AAcamEAIIQGsoOQKKrQhgww2mJDCDIRp1QCEPhFA2UnMnTONbohksgqKIpY5oplonlmi JpMAJU449PknJ0pzHkWnj8QN92OCyzHIAR100PBOB2t88AEIIoxwhg0ooEAIBhIxgCUA CuQ21Em6cCIiL4HoEQsf+LQCSSwh5nHIIXzg0kg/gfxxCSQwAP8iKy6XtLKKLMDleZ+d +SlCYzIeKTXjcEAeqMgbZaTBxBVWMKGEEknskAwCCTS1kQGDhECIChe8NKm1xohi6yWr lGvrKiWWu0os68bCSizwpojuueiSS64tkzWF2hoF0LEAgFUBlSAFBxIsgcERZDGFFGFI IYUYVSRRQDIVzTgSnweqJpACil1pVAEDEDDAAR5wUMABBxhQgMgctMyBAAK8LLPLA4Rc gAHUVlSjArYxUO1OxE0gkgMMGOABYZQlGEEFXJSBhhRTLFEFtBM3JVIEN3llQDL+MpCX SBI4wPFx/ySQscstx4zAIguYxXZtKBuNAAIow9V22wgAs8AiFnX/dDVzGWP1QDJb0yEa VhTHwQTUU0CsBBU5HMA1Aw9QRaNSOCeg0UwXY6xab2QPtADW61E74Y92OtA2R709kFSC QzVHo88eiJaIBMlxlEwCRDOIgBdlfPHFEkww0XgSI3hgwAF0AEM3U6LBftRGDNB9QN/R AxlBVqEPNKEEiixQAO/17YqnnRbytD1TrkugQAJbW1R5UChhHYEbZUQRRtRBLCGGEl04 WkW81jYFUMw2i0hM9xZomPox4ACjQ12x/JOfCHjkLQtIAAJAFrOQKc8AR1hCFLgwPKlN rQl0WKAKVQiX0tSkfg9IoGwUuMIa2vCGE5GJ61LCGYvc5CMgsdhQ/8aGwxr6TCfMOQpO ONI+xkjliVBUyV/m4oAiei92EDAMhFJyud68RSOj+YlI8IKyschlNLGTSlFOgsYosmSK +WkOEW+4gIuMhEGQMUpRRCNGoiVgewtoohSDwsbKqdEoFiKaXXA3GUJCRWyjCQ6vFIQS 7i2QckLhiVgcM6FjEGMC2hDHULhxjpqchAG28MQr7hEMW2yiEniRwBF55gAKqOMcTKkI UiTANbtlcHeESYQiIrArq8QxT+hDZhVXqIC0XMqCCcDQPCbAjg7VjxYhYoU2S4SiM6Ep FG1CCYc+CQ0MFGMpFVkAMkTCGAbZZlp04NtXfBgMEWAgHzFIgQr8sf+CFrBAAHSYEdAG oxii+GRaTyEKBAxwDnVE4BjZmMAkQpGmNHGzRGoSUS16oYZ5cORNKyHOnChJwTwpbYk1 gp8AWHCCDpRgBCcgwQlCYIMUKAMFGXyJQU1CBwQkFCXWOIYCfOGJi54ooxjtJplKJIpc kGQf+aCPBPxDkpLWh1dWLZYEhxMBA5RgCJVKwBAwsAF6WGAAJ/NACDhAgDlGxGMQEoxQ TCGuEfVBD7s4xC0cgYdAXEJEdwAEJCARCDw44haH4MUd/NCKSxTCDn9dhSZKMS2eyWRH adSPwDLyAA0aQAF2nKoEhJA/xi1hCUqIHGisBTakVOstWlEAlhCAs6b/LCI2lCMaxRIA jJSBLGQECC4BCuCBAnDAA3PTYWv5ZCc5HYyqEjTYwTD2gCI4jXEQk5i/ZrJcjGXsK6G7 mCLiVoCV1YxlaENbzNY7s5bVrLzLO0B580WjnSQTdnxCxHQlwIbTOmwKU6gCFVywPNsk QHIGgAzWvLvLBNGGhmSr1gGAobK5UcYqJImAAXmXl71MdQIREJssp7WAA/SmbVyjzAvR t5OiNYEMUphD1KQGrRKgjHmLYM5NOjstA0ymAfG8AFz21DlLdo8BB+rs+E4XNIwAJWd5 UZ0so5mXDKazKUphAOEKQMAIWIAMZPhCGKpQvP9RIQa7RUCaDYMRHiHF/zMYjOf73mdF gVikfuL7V0qkehT+6Dc5QPEMz6pltjoqwkeZhMAGvLCEJzyBDGXwnxKsUAOs2KbOdJTN +xLAtp0lg2QD4MB7l0ctuMzkgoOG8D9+sAUnBJgJUlsDpDBNa4ZsWtW1zrWui8jhgfgM JEbetbAbUi2QGFKJGwkiOy8lFa8Mu4a1QSJQLBhEITrRjU8MGIjd+uyCTIYmQ0GKR3LS xC1imy/YzrYx/cLtGnKXfuIm97IndRIJKIVnu1MwD1HDoCHDxZDmTnccjxnSlBgHh/86 SSDRwqXGQAARW7wJ7vaCEdOYJMQWGt1GHrQXANwEmpqu4w7dWBVtD8UjzP9ZJg7NxiWz cKUo4abMzv5l8R/lpN6EpgNT/g0VgXPpJgt4TG3qyJxMDpInD7AhWGpOI52/PI1CodQB 1BzIMEJldj7LC2QAZBOOOKDUsnlMNDVdai2/jyNJxLDaKdmcBi1wQgDwjFCCLptAAkA+ E6AGZlCSD2tgoI0TkIQpSmEBC1TiF6UASx3h4oClPKAY0bCLU8SmgAtwOpptQxnSvDaW NKJvksnk1VFwrZg8ThvOqrOAIs7hjgnkY5onIWXAIqAKSAzDDjEgRStQ0fhEmAUrbwlG MuIhEmM8YGuc5qznUeIj+8jpfCa9755IEmyy6UZoPcnRZM4xDwCQMiXUsMb/LMY/fleA IhW7AA8vOLEJWrzCE7SYhSlUco1zTLUd4OChFBf0Ea+tpN5h8xZ4UQAkMAMyIAdw8AIz YABW83kHpxhp0UgAkA+6wRmqoQDiYA0bcg4pMQkgYiZHBYIhogq0kAhuUU0V8QzhEG5h owYMMAGEoWUxmAzjMxZcBxQNUAJnMANNwgEhYAIokCT+pAMzMAM6UAIWoHITYXERIhdr FHd0cA7jIAHasIKIMAviUlFJtYUXxQqc0AsLAA/PUGLfUA7y1nOD1CP3FTiqkwDNkzID MAgt0AIiUAIyRVNSkgI6YHk5RG9q5oQ+kQjnIA0QQAyIEAGwMCZIZVGLaCuW/0ANVSUO 7XBVPnIfdYJVPhJ6noM1AOIRLyIAHkADHxADIFACiUICbZCHKaA6EcGEJsEBCFCBPVEO H9AAipAJqrBUjSiCvNgKsDASiJAO0yQncUIVu8ITWYVMQDJ9x7cGF/ALF2AP9gAoNEAD dGAAHNAGMKADWUF6CrFTAEAYaRFGCAAiotIHezAql8AHh9AHJXIJdQAIl0AqrUAqKAIv 89IKqmAKn6RfxmRVfPZ5m2VIxZIxbsAEWMAsVHAEGNCQ9bA8u6MAByAAg8AB7cYQCUBv YQQ+ipAK3XRXuHAIgdApvBAil4AHgPAIkFAIeNAIpJBYd/AHjfAIhVAHf9UKs/+Qdvdx ExgAQT4zGaWRH3oiMBo2Q0BQBmRAZkEQBFZQBV1wMqAhPyPBAAQQAP7gdhLxFFiiF4iQ hfPSD/0ACZdgB3swDJCAIsJwB3iAC48wDHxgk5DgDP1QIjAgDPVYIrRwcVU1FAbjFSCh aRohPdN3IFtABvoDNadVBTBQatw1Ep0jNnb2EpKyRRK5BnOTMoG0HDRiQNSyO4tQeXez ABYgG3SzaUqhQY8BEheDHxjjfASjX9M1mAkDYw7zMFVgBQRAMZTTXdR1kRCRkT9xM3Rj ANdILT1FMuaVXullMzczdVR2ast1FDfRYXuiX5VIEtJ1IBVgXf/VOALWL8rVORj/AyCO 6TXHERZAcQBoZVxrVV7o5TLrBTMw017uFWrDhVt2hDUz8hWa4z6GwXb7lSAV8ARLsD9R IwZIkAMGoDIowx5tUznA5jXieSDgpRiCgRrLk5wtU17uaV7ANVwcWl7MKTLDxaA/hkQT KnrSiRcYsAAXMARICWABJgZU8ALLozlAw2Di5pjehRfeCBET4icsg1YBpRL4sQDAoHOE BhfNdFVZsxLbsxTwk5pD4z4IoGXJcTCC8ARlYKCSRgVyMAC9tTUSmWCCZHM8k0HRBjuq 45sS8aBaNjeBpIaEpERIphOr4zOfdTnLxkU5sQA4805ItgAZEAddKmPEUwU0KgIn/8M7 7+NjMtEAhqFhyTEslJQanbMgbvqmXOEVKQMZazcTAYMaUbo9mjoZPjMxPKMG7iSRu9MU C0AHUhA8c7AEQVAFAWYFJWAAwOBDPNGJlpUAHmBi7ZNJFkQ0tXFrzDQaEZAIJGMBcjEn +2Fw0ZQUKWMbbTMj7EFbMlFAdFA1YQMBQlCgDUM8/nObbaA8mvNCQfIRbRNNwdptEWQh tIVkdDIBBNNn9OEZhRYXEhdSSQFM8YMRW1AGTyBjQQBrEAMFA7AIn0lAfNNtEGGvFtJT L9hc00VV3jUssQM+EOCC/EkyMbAEU+AEXxA1TPA/ViAbEhs6F6s1ycAVUApnBUQ4BP/g XjBDAJCqAIsQTwiwBmOQP1uAqMVTBU1QfS27QmxzXM5paolwGKjReJvGEMhQA03ABD9A A0mba7zjcZYmQ1sbtmI7tmRbtmZLR6JREgzCOSWBO3b2Y0h7tlZUMVYnnRmBFyExEmgI AA8otyokEznBRPYTLILbcWjYFz/qt7YmPzlKuMqmt3okcPtXEkqouAaRreAWaBtBbqaE bpJLcikRt2F7RJkrncESWgalEof7uZJLG0mrQ8VqtzmhE47kuSwBcxByg1E0RXBkTHvR t0XEeGe6Y5wLiFgSJF4kGzzEF6PhOwO0dWnHum8UUokbOg4QufUFuZMCYv2XMpPRuVz/ kmSq0RRF9xNq9Lkm93lkUbk1xHJC01lPdxQl1kuVA4iV8RVnwV2TQhsct7x7cRRSmxfp OxWTSxxQIbrd8yAAcBEVgZ4vaBISkAjzFHQKAI4g1huYdzWMAQAewTOUE2Lau7rntiA0 omY8g0ZYUUSn43GS+nK4+xNY01nYahscByH29hURaUf/K7311okUbGWqO0h8G7wicUHJ cGG4CxIUoAiVY76OQTe8I7MAsDfb5YSSWxUGtKBMoRPhVsCoYycEZUPrmn1fgZ5rZCFG URiRer0wtxvTWWVmzBchViPTEmVahrdIQTSg1SeAo74CQxLs2zGdGzZ0l0BP18ZFkRP0 /2MSnuE6FqCb9nW8EoAzPrkUa5AICEAHXrMUqyNy5SudJScwAgkkCBwp6BkkKQc/oxN1 ElANQ0EN7uB7N+wAvqAIjHDLx8AIikA01cN5wIYBzFABqIEItPUcnHdgcBEXXgGrxdY+ vItMoZfC3dNMnCGzFpIjoOV6QJEPe+EO6bBO9dYAr9AJwWAGF/AKtaA3cPE5jQcX1sAP PlNqMqFBZiOpn/UWDKBzbwEcBKeJoKcgwFt6lOQTfvm97rAZEJUS43AOn7QXiTAm31GS rPAJIDETsCoZEIANpSQScQGrb+EBWBbJsdMf97GMyijKv7qpEvFyEvcaNBJI4bAPE+AO 2v8gFOnQDcdwDBLACBIgCejCC84wDKRCHgqQCKUwG4+RF/ywDQlADPdkSsvHfFeFr/jB Z8QCATSAAZkaNHahQnmEGkYhqckADA1wDhFFSkIBUaaw1mudCaDACem3fqBQC5lwCpHw CrpACWAzAdnADSThDjL9RPQRd9dXVcUUbpJhADfgAzkgBy6AeQqgBuXjHyodEW1BIQRN MWYNABwiFIggC6owCqGtCqKwCqRg2rEgHqMtCqINC4qg0OfgyumQDlzCEfksjhZ0MZwh bnejQexBNG0QAzLAAiogAzrQAihwAK6TqdJMNr3xchn2Znuz2dUkFJLgCfk4IoqYLl3Y CqL/wI/idA71cADeUA5V13H0cREYQDfs8dJP8Ra8o58aIAMzsAb5oAYc4A/bsk8toAIm MAIZ0GJakQAGxUtPgRrhhgGLkCGcbU0RgArd1N1aiCKrQAlT1SKbEQ7mQBJ4cRZPS7kK kKQzYkj++McPQAcjkANG0AL+4A8BEAAs7g8sFQIhYNw6QAfVmxAPjCUMUrtxhyHRgAho LVGwYFS7qCa2QgsGJA/nkAEIIA/j8BVmAVo7sWJx5I8FebfA4KECQAgr4A8tQAIuQAI0 lQJSogMYUNkGMZlYoiVMKDQIcA78IAGvBwAdeVQSjlTcVAuLkAzS0ADGAFKH+3zBUdJ7 8iM7/ybBtSEbBkCR/pA8MDVTP5gClM6Hrbi9CFABBhUBBzCIEEAN+jABdMWFIYjkJPIJ pVAM+XAMESCJzpcSlThSz2XSXMWJGtF/CuABgyACGVCKidIGZC4lKKADOQUR4KgyVndx XgImk6AKRq5UWwjtGNUKmqAInyQBkoive0bVeFIshq5VnoMUvqI6A1ADNLAGHjCKpTgC wF5TyjADFVDKBQGOAnAACSUUXjIWx0AL6KKLeG7qZpIKpuAjxIB/2q7t0wpdBYPlxCJB 03cTNGgPQ3ABgDIohRKKdLAGJ8ACdvMQC0BvS2EaKDEN97AAvjALutiLeZ7ynCAJQOUO FKTts//eZ8Px7YdekErjABpwAfxwAfVQeBdwAcxgD6I2AEliAw0S0AkhW5OCAGF0E/KR AJQAC+/CC7xQJrzQD3ZZIryw9UsFgiKyCrQQAcRwDK6MjDMfmwuvVSjtXYoABFZwBU0w BPawCPaAARVABwQwdcBAADDTMxGhwBCyFPdeEsEACiECCIegB2L5WKSACyHSCChZK6QC CdN+CZiv3ZgwVZmoK1ieif8LRG2zoCaVIGowBWXQLEtgBQjKAxWgAHlTbIugDITAARdQ oQ8Bju6LEsfgCbnICo/wB3h1CHlwB2ZpKzAQCIaQB63gDHqwB3pQB7GQB8uvB3kg0bCQ C1b9fyD/pmUHkAEZpDm7vXYqIQgYgPrEcwXM8iw+MKx0ALgAogBdHgB1JBH0tiVIMQmc QCJ3BRC8Dt1yhCdQK4R5AF2CBCjPpVuHeN3xE+tSITsIW9GKIAECAwcKENBZoECBgwgR AExgKaFlSwkRHDRgsKiAhwQYHoRBE2XKkiVWmCgpcIDOIpAPUkp4QCBAiAX/pE6lWpUq gwkAtG6FIAEAIlisWolt1WcPpGF+DOnZpbHOIT+4SOkp5GfYpT1+WF2sc2nsqlMPILBc OQERBUSGYUoIWdIDggcOHriEGaGHFTJfpJCZUqVKEgPJFCyQDKGjBNQLFv1jwMDqa6sJ tm5lMBiR/yhWq8SSHctwFcLdj4C3euRXrHFIGsfSerBgQe0JHxUkc27AQAMIXVkaRoTa e/eYQp4s0SzFs5UkBxIsaCB4qXePCqRigF1/qoLZAJCVTJAg2RoDGFAJJkEUUYOBBOhA AAGTQMoupQggaMCB9egwxoIHGjDJpMm6Smw7+FwSUQLwwIupgjjIiEKKKaYQowooEFhP svdClEDDfxKwb0cH8kvAAPUUoMMABYqJcKYGEjCpv2QQOOAA6x5LgIADFkSAgAKErM00 ECeQgALUDEMMTBG7Q8xG1NSIYokVWxRDCTlkTKpG+DqKIKod81RpKwQMQGCRBYBBQDQM aqoSSgIGUP90AA4abXQALItKZj0G2nPvuzG385LEMUtErbvDUIuADTTYZNFFJbr408HT 0PSOwjx3ZGArlgogwIAC/CwKAWAO8KAARR3lQABhhYU01wMmfc6BByF44AEGrEumgQY2 ZYkClmRqL8QIhCCDDDR+elGJGJFittUJ7KTJpAZQY0C+WOtTIKusDiCABA4MIICDAayz lV9HiRVgYIGNJSDSXz0ITUnswmQpuxt/TKbS2iRQJEQIvCXj1M6oKAEYBTBwgAH2SF7g AJCotfFOeON9LQERI+jzgAIAPjhRRhsleFidd3ZU0VxlVKBSySSbLoEGTqP3u5XzcQPc zcSQGgoCBBj/oIBVpxPNNJRi8q5VB5xzGTYGYoIASgN+ZVTRg4Mt9u1HF10US4Xp+IVZ 00K0Fr5rEcmOHie+PfXNMTjYd9qGO9rUVa9TI3ns15KO8F+d810QSswvf5LmAooqavOE DwYG6dIg9E5TCU9ewL/WEukhjDLCcPPNJAqY8VLKzIZgZOe6ajyCCZp7F3KrHjBMWGI5 AIaBZyt9NpHQ5Eygz/aKfmC0LbPLe6mZSKYZgZRLClBCC4goY+MWUU2Cgyr7mzAZA/pr MG8QJWQWvtYeJ76qBJDqPFIEVGs72JoATRKRCJr4CSki0pRHGrCAZCSLea0ZTNki0C6H ZesBRVhCGGTn/6I3QYEDuSIAHRKhHS9tqjHJkNRJIAYfCOBpf6+ZzuqqBL7BsORDjAEe YbYzkwRkACRme5cC+kOjDKbEAQ6gA9YueIEwZEYKQKlCCCFlgNGZpCQleWBSJBDBBSQi Q5OpE2oaMMP6LMBZC1iQAgT4kuCtDn7JUEoElLK6/sDMJVrxUkq0Z0QGhY1kHWHAEMiw hCeEIQhMYIKL5EAAnCRgd+vqUwJGFpMUbspZNHnOaU7TMjRSRZJMScCTBATH6BhxXpHp IWEkULaQVIk9lMLAIgooCAiSbEEIakIZ0JDIRVYxVZ0LGnuMp6kIMcBJ8nOj72AySZLp KJRWqdaNEOCBk/+8hDJqbIkcR7OgCYTNiChrwKQeiMVptWYRJIFAk7TAhDA8YYpMWIIY qFAHBukkJdBSUCkRsADBUKYlm4ymKvszTfssAHh3whoDEjMmEsFkAgvwkyyHFk3RaEhD VjrA0JKkAAkkSg1bmMIXZLdIF1mBColCVgJOGNGW2JGTG+rfQRE6NtIAgCl0IIAaAQBR M5noXYxxjoY4FIGh8Q4BWWrAS73UnfF84ZCMTKkPDoAU9yjiAQcqCR1oKs2bIrRs6WqA nwT4JU4dxkwwoRBThiYB0qBwO8IrohqmIIUn/IQJQZCaEnygsEH5hyQlWU1YDcu/B+gU AovwgEI3BaZNdSf/OqQJXitZUqAIGOVPdBAQZRBBBDKEwQlTTEM9q4AEC0hGDSVxzWFd SzYVJssBXgLTmZ6KLW5GZwBOmpjvCoOII5FMAT8owxe4EAag1FMJYHhXa1/7XNg41iOL QBkDvxRUxKRwjwOdiXMUAAx9rS0GYijDE0a7hDJ4hgpmkCF03WuVSumUMQxKrHUbSFDn lLIAAghBCKwGJGAoyAAxSAMauPCEQ1aBCVVQAg3e+2CyqZMOAcZKTDJksunpi1+K8kD7 hoZABClgEXmkwRyi4ATkMtIzdIBwi/NkxATIDUt+Osqy3LPJ1RkRNnR4gxgWLIYf2MPF Q5bV6hggxkuR6cIiJwZrrBhABxYTWcoJFURhIvRAGE9Zy9CtlElGvGUwh1nMYyZzmesT EAA7 --============_-1159263017==_============-- From tony@lownds.com Tue May 13 21:59:54 2003 From: tony@lownds.com (Tony Lownds) Date: Tue, 13 May 2003 13:59:54 -0700 Subject: [Idle-dev] IDLE application icon? In-Reply-To: References: Message-ID: --============_-1159262863==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I don't seem to be able to view it. mac-binhex40 encoding? Sorry bout that. >What about .../Icons/python.gif? It's too small -- the image needs to be 128x128 (Icons/python.gif is 14x15). -Tony --============_-1159262863==_============ Content-Id: Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="IDLE.gif" Content-Disposition: attachment; filename="IDLE.gif" ; modification-date="Mon, 12 May 2003 10:18:12 -0700" AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAADAAAASgAAAAgAAAAJAAAAUgAAACAA AAAIAAAAcgAAABAAAAABAAAAggAAEwBJRExFLmdpZgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABlNvJQZSMWRLbQwABlO3AUdJRjg5YYAAgAD3/wD///8ICAgYGBgh ISE5OTlKSkpSUlJjY2Nra2t7e3uEhISMjIyUlJScnJylpaWtra29vb3GxsbOxsbGvb2E e3vGtbVaUlKtnJycjIyllJSUhISEc3NzY2OljIychIQxKSlaSkopISFSQkJCMTE5KSkx ISEYEBApGBg5ISEQCAgxGBghEBAYCAgIAABzUkrGraVCKSFaQjk5IRjGta2Me3OEc2tr WlJjUkpKOTFCMSkpGBAhEAjGpZRaSkL3tZQ5KSFzY1rGnISle2MxIRilWjGMc2P3tYyt a0KlYzmcUiHvtYxjSjnnrYTOlGula0JCKRiUWjHGczm9azHOczG1YynGaymtWiGlUhit UhDGpYytjHP3tYTWlGPGhFK1c0LOhErGe0K9czmlYzHGczGtYynntYy1jGuthGP3vYzO nHPvtYS1hFrWnGv3tXvOlGOte1LGjFrOjFLGezmtazGlYym9aym1YyGtnIyUe2NKOSkh GBDWjEq1aym1raVSSkKUhHPGrZStlHuchGvOrYzWrYTOpXv/xoz/vXvnpWP/tWtKQjnn vYwpIRj3vXv3tWvvrWPevZTOrYTGpXu9nHO1lGv3tWPvrVrOtZTGrYzvvXv3vWvvtWP3 xnvntWvWpVr3vWN7WinOtYznvXvWrWv3xnPvvWvntWNjWkqchFr3xmvvvWOUcznGtZS9 rYy9pXNzY0KtlGOljFrWtXOchFLnvWutjEqtpZTWvYTGrXPOrWP3znPGpVrnvWPOvZS1 pXullGOEc0LGrWO1nFJrWilKOQi1rZStpYyEczljUhh7azG9tYytpXuclGuMhFqUhDGl nGuUjFqlnGOEe0p7c0KMhEqMhDGEeyl7cyFrYxitraW1ta1zc2uEhHtCQjm1tZylpYyc nHshIRhaWilrayFaWhhaWgg5OQBCSghKUggxOQCttbXGxs6trb2clLVSMaWMe7VaOaWU hLV7Y61rSq1CGJw5CJwxAJyEa63GvcatnK2tnKW9rbXGtb2chIwAAADAwMAh+QQBAAD/ ACwAAAAAgACAAEAI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSnQIAR+EfxYdLNhmYYSiITpK 6NARQsHFiShTqly5cIKEfRn60eBgoYcIHCNGoKDx7yTLn0BR7ruwigoZKWGkSKFilMyV JBkaMLgIocG2EC1apMhqgkWBoGCBQtD3hs6cMGjRggHzRc4YMIMqsNzmAoaGBDdgXAjL lyAEbU7IUEE7pw4VpWy/SKnSBYLPvg3VZbsj6ZZlUZgz34pkuXMoVkD3BfISZg5TKXzG SIkCBg4c1k36yIWccl86c8TGOROWy5OpTZU0kRKuiXip46V0lRLV6/HKYmvW+NpHmy8E dbfPocNWrdau344cFf8f/0nTp0Sf0qevxJ7WperwIULIZsxYrCaFCnXqJCtTm0acBEgK KYcUeMiAA6aiICm66CIggqSUkkkmtEDiXHwqzeeALcY0E8szlLgiSSSEEKKGKItgFiAn aKiRyYoBorGijALqwmCDOEKo4I7IKYhcJhKWQogtGBKUjS3FTELJMcSQc8wskxRCCC7J OAHLJCUSwoQaTCjR4hYubhHjFmQC2EgjZHKyxSGcIOgIgolAGN55xb05oCaVlDdecbyo UkpxEZZyC5FFEqSNLdJI04w46CQjDSWSuDIMOo9KIsksyKCCSyFMdMqELIgwkckjW0zo yIRtpBqeqo4QUsojx53/6sgosD5CaydsvOqJJY8g4gkivQE7yiihDJJNocgmqyxC7tjj 7LMEtfPss/IQNM+0ztJDELb2wNMQt94uq1Kz2EbLbbXW1oNtOwNx68632IYr7rz01guZ OgfosUJXKaRgggkphFPAAdskoMACDNirMFjqMKDADYqMQAIJP8SQ8IULLwyBN0RIgYQX PDzQxz5DZaBBDRzcIIIIiuCgiAwiZFwoBHfQURpapLEFRxxfsLWGNxM0NEECAgRQQAgm 4FADODJPpE4gSAyWVlJheAHGGGPEUQHGLEXgGAReN10QBH3cccTNYTBVRxhguJHGa2PA 0Qc+9WJnDjLWOLNLLqb8/2bJJ6qokp4mqUToJ3K0hPKTNm8gtZYbbLihWBcVBC12QeqY Y452uvEmoXjmpVLKnaUcrtwm/KlzOYbqaINOOdg4410wo3QSZJsQ5p57caqYUgotxqye 0qHGPJOGlLIw0YYRRpTZyH+cvMgiJz4YwkmBuJOyIIycmNlIhEAiV0ooDiibzSvgtLJM JL4UEkkovkzCzCzSAAOplIQMUoYS/PPvgxH9Q0OauqemLRjCEGICUPYgZCPtaaIUO4KQ edKDnD0d7ne0wCChzGeLWcDCFa5AxTCSgYo0lCgNHpRSGSIBi/vgghCiUIMayESmTMjQ P2f6TyMy4YhDJOIQjmiDgf9IEZ4iJiIRRUyiIzZhiUo84hGbKIV4kNMJVnBNeFhcFrmm ZS5uedEe9WBXQcAFry9+8XJbhNZApIUtdK3xXO3C1rsYYsYzopFbXawjtuYxRj2WSyB+ 5JYYs0jIQoYlAVMxpPASMIIBDCAA4fjACcIxhBL84Acq2MEKKsmIAphEkcJrQDg4UIMc 5GAEP4CBHxwDyoxBYB8O0MdMQMCyEeSABDDgxj+8FoFWJgsCtpgAPiq3jz5cwAMUoMnK cGJLG/gyPtrQgmCmSQYy0IEH+dBHBYp5AZPRYAMpM+UJhvBMsVzACXM4C9vYthYwhKEO dZACILiGjwcYwAQtEEA4GJH/ghUooJwP+UsgxDA1dvbMLWCQxAx2GREHYOUACbDBDpaA B4AaRB13QAISwrBRtbRzDFOAwwss9xN8LMAGNuCGA66IxQloIxBEUKcUzoIUdrrlC8Ug qUXDQrYznIU0holnGLrgBjesJQizWRZ2iMGd3eyiE6awXeB4QYsMZhA5pJBFVXvB0zu8 wQsdlUJQozBUo44hDMWgjsbSQQx0dK43fatE4FSxCVUQThOBE58oFMcSbbjTMEoZQxTi wAY2vKaQ2tDcdvRWu+MIrjycGJ3o/ESLAf3uFqr7SRCOV4g4nNUbLJWZOuyGDnJYwzuI kCLoxqOguc51E45Yjj52upLr/6SDc6fdRTD284g3hUdHCipOelRhicB1QhShpW1BtLGh J/0CFnsbhSg6kQndAXdBpHjQFLMqClkcS7lj2xAqKDEJXMhCSzYMYiPexD3uNWhHhYMR gh5IivDRIhOgsegDbGELVDxDEpzqlAzVgIYCy+iANJpegmFUoAE5CEbfq28pAtSI41i2 FKaQRGaLBExwMEMQzYBFK3zhi1aobxnLcAUzJkHiSLg4S7coQxlCIeMYDlgNZqpug9rb XuuSbnSlEx8tqMoL8SFISNooVDaaQWIl+QIWw0AGOZLxC1fgL0tb6h8NXUTgAgfIeY34 IRHHEydSrJeBiRDOcAgH38GlYv9PxREfL4pcClkUg17ZgAY4XBEJV8SCypIgxAqbEAtY mHB/SpChEsjUvC0IcAtnQhOFz0TEN515zeMpIpznVInYHmcTiNjPn4pT2V4k2Xx3oMYs QiQNdBxjvJaaBShmgT9YzKIJWhLFlmZIwzaMqg3q3cIjRqUGJRrbiOHpdCU2wexNQJGJ lrBEFGG1CVO0onwL25AgKEGJYjjgSPxd6T+0kY1v6wNJkWAClsuQiUI4Qj8w7MSWbKgG IXX3Etfm7wWy8QBtPODbDsgAh/hri2+AOxsbBq/CV/IOeTj84QRhx8MnPvF7DPIgFJfH OxqS8Y5T/HLwwOMbA/ksbW1LjmX/JLk97vhHgbBxWm4UiDwEGcdpzXEh3KKHxx2+ujQ6 K4/UKsjLgw5IlNNR5StnORdHDnOBQCAe9CBjzUvejqpb/epTd9bNFenzpLtc5THPuh/F 7seLL/zsaE+72supAAQYYAQCMMEILJCABSR87XwRgQBScAJG/KAEjAhHSHTAgn4FLAQE QIA6dIr3lajDAQhAgAIUsIECECAnJMjBDlgQEkYI4JONp00E1OGHbtgABSUgQSU/sIDk hj4l+DjABhbQA1tSDAcU6Mnr+xKBDHhAZTiYWA5+YAN19HL3QGmAA/hhsg3YgGUtM6Ui JuB65LdkHRMYCgY04PyVtQwHOYBB/wOsPxFt/IEOWliHPvYxg300oAPct4HKboIDHMDg 1ORfyF+EYJSYEsELsLQP2rAPthATHnAyNtADihADKDAC+ZcQY0EHSpE2VGAFTEEGZ8BN GRBw2zACJVACHlh4LLAC1ad2EHABUMAHSFFTaMEUc0AGWBAIEDABmQU2+NAA3YBPJhAA JjAEKyBu1pcNYpBO7NROXxAHcQAGUxA3L8AQ6kAAASAAJBAAAaADMMB4afcXWkCEaiEH X9AFbSEHVDAJWaBWDuEARXMAFIACMPAHf2CCfYAHMZUWjsMWbgEHrDABWOgQ+2ABP3AD FEABVlgDZ6cNqJBOHZUWHyUHTTADJf+oEA1wA3mQBxdgARvwiMKDUU5ABYmoFl/QFmPw BRVwfGAxAcpHN6ToS68ENWkhNTizFmMgB0j1gAEFDtWkTmrjOD1TB3KQBZhIfhAANT+V NvC0Gl0AB2AQBV+gDXsYH62TDd+wDCWWC52QQX5SX7qQCQ00ZNxYVXwFGWQzGlIjVlRQ B1bjBk1wNV8ANPRiG+dgWt7BN78hOK5VOOFjYakgC1wVFtRnNl4gU/G0Gq3hBlFQBcvY jMmyD4rVHbXAN8ymHpqwCYPDO3n1O/tYUsWgBS2oFIUxgWDQBXEQBXJgBvi3MKTVObuQ Wo9lHmwmOr7zO+BzkSqhDWcQBVJABFT/MAdKIQWtkQZp8AWEZDfl8FaOZVfC8SbE8UDJ QQqYQQgPwBL74AWnIQVe6DZNEAVxQ0jXsTnoMAyM9QiYFmcJEmTJkUG8cAslmRL64AZw 4JNpQJBSEAS/KC62sTnYcA210JCd8Ah7Ujii41jiE0VoCRR9sAdTsIRrYIZBCQHZUQ7X sBvU6AhHlAip8EM+pCDqQVzs4QiysEE/wUqgxJi3sR15wxu+Yye5syPqsZqqkDi02BOJ 9Tq64R2NNWqW5mPjAUGAM2TYZn2HMkLH4FS00wlB5GPwZY/ZcxxVJQrFMJfPxF/SMAv3 QQnSRV2oMiAHojvwNSAPMhzKiRmeeXbz/9FfsIAfhJAJofZEZgYg2RUgD3YIDRRBNzJf oxMoW0AKi9Cb4HUk42U8JbJrpYKaPMYm1xOfhdOe0fM84GNV4QMJ4flMh2IL0WBlWsIE YMI/j7Ymh2A9BzY912MgDcQgBEphATI6ZxIkSmkKypCWWfQXG9Jf5CUltwBDNjZALyIj XoajNcJgDbZjCxRbfwk+QkYLQZAstvBt2VBuBGcLSdqkL1oMzFBirSAJuDAiJVIGiyBg NyQmYtIgasBj0TMh2ogjZDqWgIk4VWVVx3GPmFAoDzANLFZivgBgLjYIg+BisABrL1YG +qMEMvanZSBD0VNDYhKmK4I9BfI9D3acO/+ilMjxCeJzHLxgChdUOMdhCvpZHepgC8zQ ClrgCpQwp5MADMiADMnQDJBCIhXaJfwDQEpgBDJkBDICZgGSqAOCmkSkO2nWqAiSCurx ZnD2QJQ1Z8oZPEWiDt/QYiSWDOggDtPwC1ZKCJPQBMFQoWqAoRnKpWSCBt7TCIcQaQrk YwOSZtgpQXdyV3BWkaXAbKXQCa3AQSuVDcmwalJyKcDwDCr0KWmQPPxzY45mYDICrgXU Pdl5q0QUYVNUJ3oyZhMUHnGGYVEVZ61ZCJmKLEcCDh90KclADVhSIpTgQYG2P/ojCq3a aDQEaalyJgL0PeERZuHhQ3uiWnmyJ7HFHs7/BmrVZjt7Qgt2Ni8ZQGWu8GTDMAzSAAtS MgnHsAqTQCKFEAtrUK0mAqA0JKY4tEOoEkSr8iZxgrWddkRF1GnhwWzRxh7SBiuxhTqs ULFKlgywIA2/IA3IQCnPUKUiBApGWyLU4AS4oGv9OiG81ga9BWz/0QZb4GulILhJpAnr dWxO9ERPFG3R9gi84myPYAqeQD72sl9I6raoMKHSQAzIAA0pdqTZMAsARgjnlQmeIirD Fh7D1luv+7pt0AkuMiHTJQrDkrtNsAu74Am5ACy5wDe+mwujgAnGAIRiU25HchLqwFIQ 8AD7xV/FcAc8wAOXcAmQ0AvXewnFwAPGUID83fYAzvma5Fu+5is8XQd0dTQP7HAQ7pJy JAdyIvd1SNe+J2dz8BtI8tty/zB0zgIPDjcPUcctGyd28qIQObdzPCc2Ice//msPYTfA zqIuPiF1OBcvvtTAS0e/TUcQ8QBHRTctB5wQSOd1TaPBasTBRMd0K2zBCIx0q4PCP8fC zhJ298At92DA+TvChSTDJvzAMQcB6oItFYzBRyfCGTy//etHQ/wsF8ctTexFZKdHZqcw Pqy+esRHfaRyU1xHVWwvV0zD2FIP9AAP96CY9xu/IaxyX3y+bvzGcBzH1REQADs= --============_-1159262863==_============-- From noreply@sourceforge.net Wed May 14 02:31:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 18:31:56 -0700 Subject: [Idle-dev] [ idlefork-Bugs-706860 ] sys.path does not contain source file directory Message-ID: Bugs item #706860, was opened at 2003-03-20 07:21 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted >Priority: 6 Submitted By: Dickon Reed (dickon) >Assigned to: Kurt B. Kaiser (kbk) Summary: sys.path does not contain source file directory Initial Comment: With idlefork 0.8.1, when a script was run the current working directory was set to the script location, and the script location was added to sys.path. Therefore, imports of modules in the same directory as the script location worked even if the user had not made an effort to place the script location on the module path. With idlefork 0.9a2, for me it seems neither the current working directory nor sys.path get updated with the script location. Thus imports do not work for modules in the same location as the script (unless the location is in sys.path anyway). My actions were: 1. Install python 2.2.1 from python labs on Win2K in c:\python22 2. Install idlefork 0.9a2. 3. Rename C:\python22\scripts\idlefork to C:\python22\scripts\idlefork.py 4. Launch C:\python22\scripts\idlefork.py 5. Create a script using idlefork 0.9a2: import os, sys print 'cwd', os.getcwd() print 'path', sys.path 6. Save the script as C:\ 7. Run the script from within idlefork. 8. Output is: cwd C:\Python22\Scripts path ['C:\Python22\Scripts', 'C:\Python22\Scripts', 'C:\Python22\DLLs', 'C:\Python22\lib', 'C:\Python22\lib\lib-tk', 'C:\Python22', 'C:\Python22\lib\site-packages'] I'm not sure whether the CWD should be updated or not (I note idlefork 0.8.1 does, but running the script from the path on Linux doesn't). But it shouldn't it the case that one is able to import modules from the same directory as the launched script without having to worry about setting sys.path. I haven't tried this with other platforms or the CVS version. I believe this is the same problem reported on comp.lang.python here: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=3E79728C.AED36CCD%40alcyone.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26group%3Dcomp.lang.python win2k and winxp, python labs python 2.2.1 idlefork 0.9a2 from idlefork.sf.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 From noreply@sourceforge.net Wed May 14 02:37:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 13 May 2003 18:37:24 -0700 Subject: [Idle-dev] [ idlefork-Bugs-689543 ] File/SaveAs Raises Tkinter Callback Error Message-ID: Bugs item #689543, was opened at 2003-02-19 14:39 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 Category: None Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Kurt B. Kaiser (kbk) Summary: File/SaveAs Raises Tkinter Callback Error 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' ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 22:25 Message: Logged In: YES user_id=149084 You appear to be using IDLEfork installed from the tarfile. I can't reproduce this problem on Linux using Python2.2.2, Python2.3a0(14Dec), or Python2.3a2. What version of Tcl/Tk do you have? I did find a different problem where IDLEfork was trying to save the breaks from the shell (there are none), so I fixed that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 From kbk@users.sourceforge.net Wed May 14 19:15:43 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 14 May 2003 11:15:43 -0700 Subject: [Idle-dev] CVS: idle run.py,1.16,1.17 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv26762 Modified Files: run.py Log Message: On Windows the subprocess was not exiting during a restart. This bug, henceforth designated Freddy, was due to the mistaken elimination of the KeyboardInterrupt exception at the previous revision. PyShell's unix_terminate hammer was masking the problem on Linux. On W2K the subprocess MainThread was trying to print the exception after the SockThread had ceased to service the socket. The subprocess would then detach and spin when the GUI created the new subprocess. Modified Files: run.py Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -r1.16 -r1.17 *** run.py 12 May 2003 02:33:47 -0000 1.16 --- run.py 14 May 2003 18:15:40 -0000 1.17 *************** *** 63,66 **** --- 63,68 ---- ret = method(*args, **kwargs) rpc.response_queue.put((seq, ret)) + except KeyboardInterrupt: + continue except: print_exception() From kbk@users.sourceforge.net Thu May 15 04:19:45 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 14 May 2003 20:19:45 -0700 Subject: [Idle-dev] CVS: idle NEWS.txt,1.16,1.17 PyShell.py,1.63,1.64 ScriptBinding.py,1.18,1.19 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv14052 Modified Files: NEWS.txt PyShell.py ScriptBinding.py Log Message: 1. Restore the capability to run and debug without a subprocess. 2. Add an indicator to the shell startup notice when running w/o subprocess. 3. Improve exception reporting when running a command or script from the command line. 4. Clarify the fact that breakpoints set or cleared after a file is saved will revert to the saved state if the file is closed without re-saving. 5. If user tries to exit or restart when user code is running, interrupt the user code. This helps to eliminate occasional hanging subprocesses on Windows (except for Freddy :). M NEWS.txt M PyShell.py M ScriptBinding.py Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -r1.16 -r1.17 *** NEWS.txt 12 May 2003 03:04:59 -0000 1.16 --- NEWS.txt 15 May 2003 03:19:41 -0000 1.17 *************** *** 8,11 **** --- 8,27 ---- *Release date: XX-XXX-2003* + - Interrupt the subprocess if it is running when the user attempts to + restart the shell, run a module, or exit. + + - Improved exception reporting when running commands or scripts from the + command line. + + - Added a comment to the shell startup header to indicate when IDLE is not + using the subprocess. (For now, set PyShell.use_subprocess to False to run + in this mode.) + + - Restore the ability to run without the subprocess. This can be important for + some platforms or configurations. (Running without the subprocess allows the + debugger to trace through parts of IDLE itself, which may or may not be + desirable, depending on your point of view. In addition, the traditional + reload/import tricks must be use if user source code is changed.) + - Improve the error message a user gets when saving a file with non-ASCII characters and no source encoding is specified. Done by adding a dialog Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.63 retrieving revision 1.64 diff -C2 -r1.63 -r1.64 *** PyShell.py 13 May 2003 15:28:21 -0000 1.63 --- PyShell.py 15 May 2003 03:19:42 -0000 1.64 *************** *** 32,35 **** --- 32,36 ---- import rpc + import Debugger import RemoteDebugger *************** *** 161,167 **** # needs to be re-verified, since the breaks at the time the # temp file is created may differ from the breaks at the last ! # permanent save of the file. A break introduced after a save ! # will be effective, but not persistent. This is necessary to ! # keep the saved breaks synched with the saved file. # # Breakpoints are set as tagged ranges in the text. Certain --- 162,169 ---- # needs to be re-verified, since the breaks at the time the # temp file is created may differ from the breaks at the last ! # permanent save of the file. Currently, a break introduced ! # after a save will be effective, but not persistent. ! # This is necessary to keep the saved breaks synched with the ! # saved file. # # Breakpoints are set as tagged ranges in the text. Certain *************** *** 362,371 **** self.rpcclt.close() self.unix_terminate() ! self.tkconsole.executing = False self.spawn_subprocess() self.rpcclt.accept() self.transfer_path() # annotate restart in shell window and mark it - console = self.tkconsole console.text.delete("iomark", "end-1c") halfbar = ((int(console.width) - 16) // 2) * '=' --- 364,373 ---- self.rpcclt.close() self.unix_terminate() ! console = self.tkconsole ! console.executing = False self.spawn_subprocess() self.rpcclt.accept() self.transfer_path() # annotate restart in shell window and mark it console.text.delete("iomark", "end-1c") halfbar = ((int(console.width) - 16) // 2) * '=' *************** *** 373,376 **** --- 375,379 ---- console.text.mark_set("restart", "end-1c") console.text.mark_gravity("restart", "left") + console.showprompt() # restart subprocess debugger if debug: *************** *** 490,495 **** except (OverflowError, SyntaxError): self.tkconsole.resetoutput() ! console = self.tkconsole.console ! print >>console, 'Traceback (most recent call last):' InteractiveInterpreter.showsyntaxerror(self, filename) self.tkconsole.showprompt() --- 493,499 ---- except (OverflowError, SyntaxError): self.tkconsole.resetoutput() ! tkerr = self.tkconsole.stderr ! print>>tkerr, '*** Error in script or command!\n' ! print>>tkerr, 'Traceback (most recent call last):' InteractiveInterpreter.showsyntaxerror(self, filename) self.tkconsole.showprompt() *************** *** 609,636 **** self.save_warnings_filters = None debugger = self.debugger - self.tkconsole.beginexecuting() try: ! if not debugger and self.rpcclt is not None: ! self.active_seq = self.rpcclt.asyncqueue("exec", "runcode", ! (code,), {}) ! elif debugger: ! debugger.run(code, self.locals) ! else: ! exec code in self.locals ! except SystemExit: ! if tkMessageBox.askyesno( ! "Exit?", ! "Do you want to exit altogether?", ! default="yes", ! master=self.tkconsole.text): ! raise ! else: self.showtraceback() ! except: ! self.showtraceback() def write(self, s): "Override base class method" ! self.tkconsole.console.write(s) class PyShell(OutputWindow): --- 613,644 ---- self.save_warnings_filters = None debugger = self.debugger try: ! self.tkconsole.beginexecuting() ! try: ! if not debugger and self.rpcclt is not None: ! self.active_seq = self.rpcclt.asyncqueue("exec", "runcode", ! (code,), {}) ! elif debugger: ! debugger.run(code, self.locals) ! else: ! exec code in self.locals ! except SystemExit: ! if tkMessageBox.askyesno( ! "Exit?", ! "Do you want to exit altogether?", ! default="yes", ! master=self.tkconsole.text): ! raise ! else: ! self.showtraceback() ! except: self.showtraceback() ! finally: ! if not use_subprocess: ! self.tkconsole.endexecuting() def write(self, s): "Override base class method" ! self.tkconsole.stderr.write(s) class PyShell(OutputWindow): *************** *** 742,761 **** def open_debugger(self): - # XXX KBK 13Jun02 An RPC client always exists now? Open remote - # debugger and return...dike the rest of this fcn and combine - # with open_remote_debugger? if self.interp.rpcclt: ! return self.open_remote_debugger() ! import Debugger ! self.interp.setdebugger(Debugger.Debugger(self)) ! sys.ps1 = "[DEBUG ON]\n>>> " ! self.showprompt() ! self.set_debugger_indicator() ! ! def open_remote_debugger(self): ! gui = RemoteDebugger.start_remote_debugger(self.interp.rpcclt, self) ! self.interp.setdebugger(gui) ! # Load all PyShellEditorWindow breakpoints: ! gui.load_breakpoints() sys.ps1 = "[DEBUG ON]\n>>> " self.showprompt() --- 750,760 ---- def open_debugger(self): if self.interp.rpcclt: ! dbg_gui = RemoteDebugger.start_remote_debugger(self.interp.rpcclt, ! self) ! else: ! dbg_gui = Debugger.Debugger(self) ! self.interp.setdebugger(dbg_gui) ! dbg_gui.load_breakpoints() sys.ps1 = "[DEBUG ON]\n>>> " self.showprompt() *************** *** 780,795 **** "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.endexecuting() ! return EditorWindow.close(self) def _close(self): "Extend EditorWindow._close(), shut down debugger and execution server" self.close_debugger() ! self.interp.kill_subprocess() # Restore std streams sys.stdout = self.save_stdout --- 779,798 ---- "The program is still running!\n Do you want to kill it?", default="ok", ! parent=self.text) if response == False: return "cancel" # interrupt the subprocess ! self.canceled = True ! if use_subprocess: ! self.interp.interrupt_subprocess() ! return "cancel" ! else: ! return EditorWindow.close(self) def _close(self): "Extend EditorWindow._close(), shut down debugger and execution server" self.close_debugger() ! if use_subprocess: ! self.interp.kill_subprocess() # Restore std streams sys.stdout = self.save_stdout *************** *** 815,821 **** def begin(self): self.resetoutput() ! self.write("Python %s on %s\n%s\nIDLEfork %s\n" % (sys.version, sys.platform, self.COPYRIGHT, ! idlever.IDLE_VERSION)) self.showprompt() import Tkinter --- 818,828 ---- def begin(self): self.resetoutput() ! if use_subprocess: ! nosub = '' ! else: ! nosub = "==== No Subprocess ====" ! self.write("Python %s on %s\n%s\nIDLEfork %s %s\n" % (sys.version, sys.platform, self.COPYRIGHT, ! idlever.IDLE_VERSION, nosub)) self.showprompt() import Tkinter *************** *** 854,858 **** if not (self.executing or self.reading): self.resetoutput() ! self.write("KeyboardInterrupt\n") self.showprompt() return "break" --- 861,865 ---- if not (self.executing or self.reading): self.resetoutput() ! self.interp.write("KeyboardInterrupt\n") self.showprompt() return "break" *************** *** 998,1003 **** def restart_shell(self, event=None): ! self.interp.restart_subprocess() ! self.showprompt() def showprompt(self): --- 1005,1018 ---- def restart_shell(self, event=None): ! if self.executing: ! self.cancel_callback() ! # Wait for subprocess to interrupt and restart ! # This can be a long time if shell is scrolling on a slow system ! # XXX 14 May 03 KBK This delay (and one in ScriptBinding) could be ! # shorter if we didn't print the KeyboardInterrupt on ! # restarting while user code is running.... ! self.text.after(2000, self.interp.restart_subprocess) ! else: ! self.interp.restart_subprocess() def showprompt(self): *************** *** 1031,1034 **** --- 1046,1051 ---- if self.canceled: self.canceled = 0 + if not use_subprocess: + raise KeyboardInterrupt class PseudoFile: Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.18 retrieving revision 1.19 diff -C2 -r1.18 -r1.19 *** ScriptBinding.py 17 Feb 2003 18:57:16 -0000 1.18 --- ScriptBinding.py 15 May 2003 03:19:42 -0000 1.19 *************** *** 23,26 **** --- 23,27 ---- import tokenize import tkMessageBox + import PyShell IDENTCHARS = string.ascii_letters + string.digits + "_" *************** *** 39,44 **** - # XXX 11Jun02 KBK TBD Implement stop-execution - class ScriptBinding: --- 40,43 ---- *************** *** 125,129 **** shell = flist.open_shell() interp = shell.interp ! interp.restart_subprocess() # XXX Too often this discards arguments the user just set... interp.runcommand("""if 1: --- 124,140 ---- shell = flist.open_shell() interp = shell.interp ! if PyShell.use_subprocess: ! shell.restart_shell() ! if shell.executing: ! delay = 2700 ! else: ! delay = 500 ! # Wait for the interrupt and reset to finish ! shell.text.after(delay, self.run_module_event2, interp, ! filename, code) ! else: ! self.run_module_event2(interp, filename, code) ! ! def run_module_event2(self, interp, filename, code): # XXX Too often this discards arguments the user just set... interp.runcommand("""if 1: From kbk@users.sourceforge.net Thu May 15 04:40:53 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 14 May 2003 20:40:53 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.64,1.65 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv28246 Modified Files: PyShell.py Log Message: 1. Make the startup more robust by not spawning the subprocess if IDLE can't acquire the port to listen on. 2. Shorten the retry and simplify the messages. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.64 retrieving revision 1.65 diff -C2 -r1.64 -r1.65 *** PyShell.py 15 May 2003 03:19:42 -0000 1.64 --- PyShell.py 15 May 2003 03:40:51 -0000 1.65 *************** *** 326,332 **** def start_subprocess(self): addr = ("localhost", self.port) - self.spawn_subprocess() # Idle starts listening for connection on localhost ! for i in range(6): time.sleep(i) try: --- 326,331 ---- def start_subprocess(self): addr = ("localhost", self.port) # Idle starts listening for connection on localhost ! for i in range(3): time.sleep(i) try: *************** *** 334,345 **** break except socket.error, err: ! if i < 3: ! print>>sys.__stderr__, ". ", ! else: ! print>>sys.__stderr__,"\nIdle socket error: " + err[1]\ + ", retrying..." else: display_port_binding_error() sys.exit() # Accept the connection from the Python execution server self.rpcclt.accept() --- 333,342 ---- break except socket.error, err: ! print>>sys.__stderr__,"Idle socket error: " + err[1]\ + ", retrying..." else: display_port_binding_error() sys.exit() + self.spawn_subprocess() # Accept the connection from the Python execution server self.rpcclt.accept() From noreply@sourceforge.net Thu May 15 04:48:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 20:48:33 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open >Resolution: Fixed Priority: 7 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Thu May 15 04:59:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 20:59:50 -0700 Subject: [Idle-dev] [ idlefork-Bugs-720581 ] Restarting Shell (sometimes) causes sub-process to hang Message-ID: Bugs item #720581, was opened at 2003-04-13 05:47 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=720581&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nigel Rowe (fisheggs) Assigned to: Nobody/Anonymous (nobody) Summary: Restarting Shell (sometimes) causes sub-process to hang Initial Comment: When restarting the Shell windows (Using Ctrl+F6), the sub-process intermittantly hangs in rpc.py with an unhandled exception (usually "connection reset by peer" or "Broken pipe") from socket.send() in putmessage(). When PyShell restarts, it interupts and shutsdown the sub-process, then closes the socket before waiting for the subprocess to exit. Proposed solution, reverse the order of self.rpcclt.close() and os.wait() in restart_subprocess(). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:59 Message: Logged In: YES user_id=149084 Then after multiple wait()s we're always one state collection behind. The issue is much more complicated than that! I've beat on this for quite a while; please try the current CVS or wait for the beta. ---------------------------------------------------------------------- Comment By: Nigel Rowe (fisheggs) Date: 2003-04-13 06:17 Message: Logged In: YES user_id=756090 Possibly relevant. This was on a fast, dual cpu machine ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=720581&group_id=9579 From noreply@sourceforge.net Thu May 15 05:05:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 14 May 2003 21:05:19 -0700 Subject: [Idle-dev] [ idlefork-Bugs-732397 ] running/debugging fails from within Blender Message-ID: Bugs item #732397, was opened at 2003-05-04 18:14 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=732397&group_id=9579 Category: None Group: None Status: Open >Resolution: Later >Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: running/debugging fails from within Blender Initial Comment: Due to the poor support of Python editing, I was happy to find out that Idle was the (only) editor which could be run from within Blender it self. Unfortunately debugging wouldn't work (AttributeError:__nonzero__ for DelegatorComment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 23:05 Message: Logged In: YES user_id=149084 As a Blender Foundation member, I suppose I should pay some attention to this. I did fix the problems with running IDLE without the subprocess. Please try again using the current CVS or wait for the beta release. Further work on this will have to wait, I'm afraid. The debugger has not changed much; I'd be interested in hearing your priorities for improvements. If you have some, please enter as Tracker RFE items. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=732397&group_id=9579 From michael.williams@st-annes.oxford.ac.uk Thu May 15 13:46:05 2003 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Thu, 15 May 2003 13:46:05 +0100 Subject: [Idle-dev] IDLE application icon? References: Message-ID: <002d01c31adf$f31c1940$70134381@stannes.ox.ac.uk> Tony Lownds wrote: > Yes, there are PC icons (cute little pythons)\, although I don't > think IDLE itself has a special icon. The problem is the resolution > -- increasing the resolution of a 32x32 bitmap to 128x128 does not > look nice at all. > > The MacPython IDE icon (attached) re-uses a small "16 ton" icon on a > larger image, which is very reminiscent of Apple's Project Builder > icon. Perhaps I could put the snake from the PC icon, or the foot, in > place of the 16-ton. I don't like that at all. What does a 16 ton weight have to do with anything? Sure, it needn't represent the program, but that's so specific it's confusing. I'd go for what you suggested: take the Project Builder icon (which people associate with IDEs), and stick the Python icon on it. If the Monty Python foot looks better, which may be the case when it's scaled, you could use that. I prefer the Python to the Foot as, although experienced (older?!) Python developers will get the reference, they're not IDLEs target audience of beginners. That would certainly do for the time being, and perhaps we can work on something a bit smarter after the (imminent?) release. -- Michael From glyph@twistedmatrix.com Thu May 15 17:50:38 2003 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Thu, 15 May 2003 11:50:38 -0500 Subject: [Idle-dev] IDLE application icon? Message-ID: <7CE6F2BD-86F5-11D7-A5D5-000393C9700E@twistedmatrix.com> --Apple-Mail-4--451632508 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Here's another logo I made several years ago for IDLE - it doesn't really meet anybody's criterea, but I figured I should toss it in as long as people are discussing icons. --Apple-Mail-4--451632508 Content-Disposition: inline; filename=IDLEicon.png Content-Transfer-Encoding: base64 Content-Type: image/png; x-unix-mode=0644; name="IDLEicon.png" iVBORw0KGgoAAAANSUhEUgAAAIAAAAB/CAYAAAAn+soHAAAABmJLR0QA/wD/AP+gvaeTAAAACXBI WXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wUPEC8phHVYdgAAIABJREFUeJztnXl4VFW29n+npiSV eYZACCHMSJR5iCBii6DMg0AEuptrOzHqpaW5ooKfjRN0i4LDvQIikyDQMjXKICDQCAjBEAgYQgIZ CWQqMtS8vz8q56SqkkDCmHT7Ps9+quqcU1Wn6n33Wmuvs/c6Er+hoUEyGo2tNRpNd6CREMIbwG63 SwA2m63cZDLlpaWlnejcuXMKIFW8Tzg9CsB+r0/8N9w+JKPR2EYIcVgIYRFC2GtoFovF8tMPP/zQ BQioaP6AH+ALeAN6wFNz/37Lb6gjJICKnt9dkqQbcacRQnSJiorqAWQ4bZd7vh2wAXbV3Trb33BH Icnt8uXLMYC6Fu9RX7t2LQbwqmieFc0D0FU07W8WoP5DMhgMbfR6fTe73d5YrVb3s1qtN32T1Wql Xbt2DyclJdmLi4uvHThw4Jf/+Z//uYij59sAK2C5y+f+G24TksFgaOvu861Wq53KYK7aZrValZjA ZrNZi4qKfpk9e/YIIBZoB7QEon6zAPUXEiDp9fpu3Nzn8+GHH7q81mg0ktNLtc1m69C7d+8uwBXA LLffYoD6CdnnUweff0OoVCqV1WptDvg4Nf1vFqD+4ZZ8/s1gtVrp0aNHp3/+85/2oqKiq3v37k1a tmzZhd8EUL8gGQyGNr6+vsuA7mq1Wg0ghLjJ22rxwZJEkyZN2jVp0qSd3W639+/f/4LNZlv4mwDq D27L58+cOfOGH15NTNCyX79+sb/FAPUDd9zn3wwqByIbrAUQQoQA7N+/X9+vXz/nXWUVj/qK/QD0 69evbP/+/fqK5+zfv59+/fqVOX+G8zZ5u/xeoEySpDLuPO6Kz68N/P39ddLND6tfqCC+E/A7oElx cbGfXq9XFRYWqgICAsp0Op0wGo22kpISnZ+fn9poNCJJklGr1QpAXVZWprLb7ZJer7cBNr1ebzUa jTqbzaYqLy8Xer3eptfrMRqNlJaWqrRarRBCFPn7+/8E7JUk6fId/DkuPp+Knm+z2dxNdhXU1QW4 w263s3nz5t0NygJUkP8E8PLHH38c27hxY1Vqaqqk0Wjw9vZGr9dz6dIlWrRoQUlJCWVlZQghCA0N pbS0FKPRiJ+fHwBlZWWYTCZatGghMjIyJJVKhZeXF0FBQSI5OVlq0aKFMJvNlJWVSRaLxT5y5Mih gYGBW5KSkj554IEHEu/Az7mrPr82sFqtDScVLIQIsdlsA1Uq1V8WLVrU/s9//rOk0WjQaDR4eXlh NBpRqVSUlpbi6ekJgF6vx2q1UlZWhtVqxcfHB5VKhd1uR61WU1xcjE6nQ6fT4eXlRWlpKSqVipKS Enx9fbHb7ej1eiwWi2rZsmWNtmzZ8kyHDh00CQkJH3fq1CmRykusdYWLz4+Ojr7rPr86WK1WTYMQ gMFgCLXZbE84kw+Osa3VasVoNLocL792315SUlLls81mM2azucq+69evA1BaWgpAUVERQ4cO9dm2 bdu42NhY6fjx4x9369btl4rD6yKE++bz3XH16lV1fR8FSAaDIVSv11ch3x1arRadTqc8l60AOCyB pkLrzsdJkoRer1eOk60BQMUQ3AWJiYkMGTLEOzMzc2znzp2nHT9+/EGcrtTV8ve08fX1XaZWq5dr tdp3VSpVX0m696GY3W63FxQUlNbnIFAyGAwhtSHfy8uLuLg4OnTogF6vR5Ikrly5gqenJ5IkodFo 0Ol02O12CgsLMRqNhIWFIUkSVqsVk8mEJEkUFRURFhaGRqPh6NGjHD58uNoTi42NZdu2baUREREb Tp069VG3bt3kmEC4Pbr8HkCyWq3PqNXq5ffa51ssFkXUNptNpKSkXHv22Wf31EcXIAHk5OSE6vX6 AcCcRYsWtauJfIDy8nJ0Oh1TpkyhcePGeHh4YDKZ8PHxAcBgMKDT6fD09KS8vBybzYaPjw9ms9kl MCwpKUGtVnPgwAGWLl1a4wnKlmDbtm1PP/TQQxw/flwWgYSDfPnR+TfdV58vhCAhIaFg7969uXl5 eSUHDx7MPnr0aNG9Po+bQQKknJycMKvVOsFqtZ754IMPqr302blzZxEYGOiybcyYMeLSpUvCaDSK W8W+ffuEt7d3le978MEHRcVQUmmxsbHi0qVLJRaLZfmRI0c64RjGqSqaLFjJYDC0tVqtE81m86s2 m22/xWK56eXcDz/80KXd7PibNbvdLt56661fgW+B9cAKYEl9igGUnh8aGjoAmPP3v/+92p6/ZcsW Nm/eTI8ePQgMDFS2f/PNN8yaNYsrV65gMpnqfAL79+9n8ODBSuAn44033uDUqVOMHz8erVarbJct QXZ29tNdu3addvDgQTkmkH+Pqr74fJvNJgoLC0upnAwit3oBpeebTKaJN+r5W7ZsUXprenq6GDhw 4B2xBDX1/DfeeMPluEmTJtVoCcxm84qDBw92xmEJ1IDGZDJNEkJYqvstzu1O93iLxSLsdruw2+3C YrHYT58+XdClS5c9wNc4ev8nwPt3gcs645bIv5MiqC35tRGB0WhcsXv37q445txpLly4MF8Icc9N vtlsFsePHy985513fp05c+YvXbp02QtsAL4CPgP+Brx1F/isE26L/DshgrqSfyMRdOzYUaSlpZWU l5dvzsvLe6OsrOwvVqv1wP3y+fPmzUsFdgJbgW+AVcD/Ah8CfwXm3HlKa487Qv7tiOBWyb+RCAYP HizKy8ttdrtdmZNXmzl8d8EF2GfMmJGIg/yNwGrg/4CPgAXA/wDT7zyttcMdJf9WRHC75AshhN1u FxMnThQajUZ5/4QJE4TFYrkpQXfb5ycmJhZWmH138t8B5gIzgWfvRx5AifaDgoKeUKvVf7lRtD90 6NBaf3BUVBSfffYZL7zwAkePHqWwsBBwjA4AFi5cSHh4OEeOHKkx2p8/f/5Nv0dUzNARQvDll18i hODrr7/GarUSHBxcbRbxbkMIwYkTJ4r27NlzNTc313jo0KGrJ06cKASMFa0cKHVrJfdaAHeNfBlR UVG8/fbbzJw5kzNnzlQRwahRo5g8eTJlZa6X9m9GvjPp7ttXrFjB8OHDSUpK4pFHHuF+5PY1Gg07 duwoqPD7FhyzfmXyy5xaKVBS0crupQDuOvkAZ86cYc2aNYwYMQKVSsXp06ddRPCPf/yjCkF1Jd95 HC8/HzlyJCNHjgQc1/PvNZzG+TWR70x8CffYAtx18uU/vVGjRqSmptK8eXOWLVvGc889x6lTpxQR 1IV8d+KdBaBS1S2Hdrdz+8nJycWHDh26yo3JdzH/3CMLcNfJT0hIwGw2o1arCQsLY9WqVahUKvbu 3Ut8fDwWi8XFHci4GfnO5t5utyOE4Pr16y7Zx/uFWvj86nq+i/nnHgjgrpO/Y8cOtmzZwoEDB7Db 7TzzzDP84Q9/ICwsjD179qDValm5ciVTpkxxCQxrIr86X+/83N/f/774eHfU0ue793wX8gHj3RTA PSF/zZo1rFu3TpnpI5M6efJk5s2bh7e3N56eni6jg2nTpt2QfKjez1d33P1CHX1+teRXtLuCuzLO d8bOnTvFCy+8IDw9PYVWqxUqlUr5zIiICLF161bhyMVUIj09XXz11Vc1juntdruw2WzCbrff9rj8 TrdajPO/wDHOfxd4HXgZeA6IB4YC/YGeOBaHtgaaAY3uhgW46z1fCEHr1q0JCwvj5Zdf5tdff+X7 779XrvVLkoROp8NisSgzfMAxRJw4cWK1nyc/GgwG/P3963xOdxt3yuc7HW8GzHdaAHUm32q1KtO1 aoP09HSCgoJo3rw5s2bNQq1Wc/jwYby9vfn666+x2WyYTCa8vb1dyK8J7j7fz8+vXvh4d9wpn48T +YD1TgqgzuRfv36d77//nqZNm9KzZ8+bfsGOHTs4evQooaGhjBs3jtDQUAAeffRREhISCAkJITs7 m08++YSHH364bid/A59fH3AHfb5CPndQAHUi/9FHH6W8vJxff/2Vr776ipCQELp06eIy2cIdzgFf 9+7dARQRWCwWwsLCKC0tZcOGDYwZM6ZWJ+0czN1sXH/u3DmX181bNr/h8Z4azxvuvxluc5xfK/IB 250QQJ3I79q1K0eOHOHs2bOMHj2akSNHMmLECDIzM7FYLLRu3brKFziTD3Ds2DFl37hx4wgJCaFt 27Zs2LCBAQMG1Onki4uL67vPv5abm1vu5PNN3IGeT0WRqNsVQJ3JP3z4MHPmzMHLy4uCggKee+45 LBYL69evZ9u2baxZs4bmzZsr73MnX4a7CHr06FEn0y0neuQJofUNFT6/cN68eRdxmH0jDvLLuQM9 n4pqYbcjgFsmPzU11WX/c889hyRJTJ482cUNWK1WfvnlF+VCjjtkEQwaNEiJB/5dYLPZMBgM8vw9 M5UikAXgntatM/mAuFUB1In87t27c/DgwSrkJyUlKc+fe+45fHx8CAgIACAvL4+wsDCmT5/ODz/8 wIEDB6qNzmfNmkXLli3rdPLOaV4hRLWWw2h1zZG4+/Sb5fbdY4a2bdve8JzcfD7Jycni0qVLPgEB AV5FRUUGandxp07kA9yKAOpE/pAhQzh69CgLFiyo0vOhUgR9+/bld7/7HQDfffcdWVlZDBgwgMjI SL799luGDx9eRQR1Cfiqg3u+/35CCMGBAwfYsWMHubm5nDlzRgoKCgp94IEHys+dO1dy7dq1Im5M viyAWpMPiLpOC68T+Y8/PhRJkujcuTOtW7eu0d8OGTJEIX/Hjh2sXbuW5cuXK/t9fHz49ttveeSR R5Scwa2S7066SqWqF+N+jUbDvn37WLhwIatXryYhIYGff/5ZHRISEtmjR4/WERERPriaf2c3UFax r07kU0cB1In8bt2G8sMP8M9/OtbcffXVVwwcOLCKCObMmcOCBQuAyoBv1apVhISEYDKZFLKcRfDN N9/cVs+XTb5KpUKSpHoz7vf29nY5l+LiYn788UdNWFhYzGOPPdYxJibGn+qJdxZArcmH2ruAOgZ8 Qzl0CN58E0pLYeFCGDPGg6+++opJkybx3XffYTAYXMgvLCxk//79yoWd48ePs3PnTp555hmll4aE hPDdd9/VKXPojIKCAgICAhBC1PkzbubT3WOCW0FYWBiNGzcmJydHEX5BQQHbt2/XTJo0qf3w4cON e/fuzT916lQelaTLxJuoI/ngWMJ0M9SZ/MOHYc4cSE6GK1dg1iz45hvw8PBQLMG8efMU8sGxLu/4 8eNotVrsdjtXr17lb3/7GzNmzGD27NnMmDGDa9euodFoMJlMFBYWkp+fX+s/d9++fcTHx5OYmFjn yRz3CiqVii5dutCsWTMXS3D16lXWrl2rDQkJ6RQfH/9ov379GlFp7p2JrxP5cHMLUGezf+iQg3w5 3jOZKkUADkuwZs2aKj1Qr9fTvHlzDh48CDiGgJcvX2b9+vXYbDY2b95MSEgIxcXFLF26lLNnzxIW Foa/vz9vvvnmDX/E7t27efLJJ/Hx8eHUqVM8+OCDN/nZ9wfXr19Ho9EQFxeHTqcjNTUVu91R1j8n J4dPP/1U98Ybb/R69tlny0NDQwu/+eabX3AIwFLR6kQ+3FgAdSJ/wIChnDgBr79eSb4MZxG0bQsd Ozq+dscOKCyECRMgODiYfv36kZaWxqFDhxBCYLfbsdvtbNiwgWHDhlFcXMycOXPYuXMn6enpSJKE EIKysjLee++9an/E7t27eeqpp7BarRQVFZGTk3ODn3z/YLPZKCoqQqPRoNVqGTBgAAcOHODs2bOK CC5fvsyCBQs8Fi1a9Ohzzz1nDgsLMyxduvQUjp7vTvpNyYeaBXBLl3RLSx0Ep6aCe2BtMsGkSdCx o+P1jh2wZg2sWwcnT8Lf/gZ/+MMfAIiIiODs2bMAzJ07lzFjxigxw3fffcelS5ccv6rCTy5atIjO nTszduxYl++UybdYKotiu1cNUbZbq98u42Y+3z0PcLOYwH3cf+zYMbZu3UpERIRSqGLUqFF4eHhw 6tQpZc7jxYsXefXVVz0///zzAc8++6w5PDy8/I033kjA0fNl0m3UgnyoXgB19Pn9SUjIo1OnMAYM ALnSyo4driKYMwf+3/+r3CeTD/D3vzseZRF06dIFHx8fhBC0aNECm83GoUOHMJvNNG3aFJVKxeXL lxViVSoVxcXFLkmdy5cv85e//MWF/PoEIQQ//vgj27dvJzc3l2PHjpGXl0dkZKRSy8DDw4PJkyez bt06jhw5ooggJSWFl156yWvVqlWDJ0yYYA0PDzc+//zzp3Dt9XAT8qGqAOpM/uHD2cyZ8yODBkXz 8cePUTEzGqgUwZw5IMd77uTLcBZBR9lMUDlu79atGx07dsRoNLJ3715WrFjByZMnsVqtxMTEoNfr 5fJqADRr1oxJkyZhtVpJTLwTRb3uLDQaDceOHWPJkiWKVQoODgYcwbKHhweenp54enoyc+ZMPD09 2bdvnyKCc+fO8fvf/95r/fr1w0eMGGELDAxc+vTTT8sikAtU3DTL5SwACSApKck7KCjoUY1G85e/ /e1vtSI/NbWIJUsSAKqI4IEH4O23Hc8vXYI9e6qSL8NZBOAYBy9fvpw//elPhISEKMdFR0djMpk4 d+4c/v7+dOvWjccff7xKYDljxgwAli1bxunTp2/2X9xz+Pv74+3tjdlsxm6306xZM6XCiYeHB3a7 XbEEr7/+Oh4eHnz//fdK4urs2bOMHz/ea+PGjSMHDhxo3759+5LBgwf/gsMFyFVJamUBlKIGwcHB oRqNZuLChQvbzp49u1bky3AXQZs20KGDY5/VasfLS0Xr1hATUzVQlNGrl+NRDvgyMzN56KGH6Nev n0sCJzQ0lIceeoioqCjeeecdwsPDq/286dOnI4Rg+fLlnD59mjZt2tzo/1Bws9z/wIEDXV7XNfcP jkJUfn5+FBYWEhsbS7du3dDpdHh4eJCens7GjRuZN28eoaGh6HQ63n33XXQ6Hdu2bVNEkJSUxOjR o/VbtmwZ3b9/f7F79+4ljz/+uLMI4CYxgHNFC0mn0zUG2s2ePbvKYNkR7T/JgQOZVciX4SwCmfxD h7Jo2tSX4GBPnnjCMU1r0aKqItiwAcaMwSXgs1gsFBUVuZh3u91O27Zt6d27N9OmTSMiIqLKeTjH A7II0tPTXdzL/YZarUatVtOhQwe6dOniYvpzcnJo2bIl6enptGvXTgkMFy9ejEajcVnhlJSUxPDh w/VbtmwZ06dPH7Fv374ljz766C9UugOoQQQyyYoIrFarVFPgJNfOA4GnZ80LIH19K+fi7dhxkU8+ OcXYsdtITS0iNNTME0/Af/+3wxLIkMm3WCysWLGCH374gfT0dIxGIz/++CMJCQmYTCZsNhsqlYom TZowd+7cask3GAycO3eO4uJiZduMGTOYM2cO7du3rxe5f3BUK23ZsiUPPfQQOp2OoqIicnNzKSgo YNiwYYwePZquXbvy2WefkZmZiVwY87PPPmPMmDEuLu/06dMMGzZMn5ub+3RcXNzUffv2PYgrv9Xm u52LGakAVXp6+lVJkpKXLl1a5caCEyZMYNOm9cTGhjJ/fhwdOgRX+cA5c3qwYEEfwEH+mjXJrFuX zLFjOTz//O5qRSCTD5XFH8+fP48QgqKiIjZt2sSXX37J+++/z/r16yktLSUsLAxvb+8q35+fn8+s WbOYN28ex44do7i4WMn3h4eHK/n/+w2bzYbRaCQgIACtVktiYiI//PADK1asYN26daxdu5Y2bdqQ mppKRkYGy5cvR6vVKlbjiy++YOzYsVVEMHToUH12dnadRaAGtIDnnDlzQjMzM39fUlKStHTpUnk8 6dJWr14tsrOvi40bz4sOHZYL+EDAB2LOnB+Vefbbt6eK8eO3K/vk1r37apGQcEUYDCaRmirEhQuO 461WqxBCCIvFIj799FPh4eGhfJ9arRZ6vV60a9dOvPDCCyI/P18IIYTNZnOZ219WViamTJkimjdv LgDRt29fkZaWVu08f6PV6NLc97uv3z937pxLq+5/uVFzm9cvTp48KaZPny4mTZokevToIYKDg12O DwoKEkOGDBFHjhwR77//vkhJSRHZ2dkiPz9fGAwGUVZWJkwmk5gwYYJLfQJwlKtJT08vNZvNK/bt 29cFh6t3r16mkO+sDtU777xjmj179t709PSPJk2alFKTJfjhhy307h2hWALnnv/LL1eVnu8OZ0vQ rJmdmBiHyd6xYwdnzpxBkiQGDx7ssl7AZrMRFBRE165dmTt3LkFBQfz888/k5eVhNpuV47y8vGjT pg15eXlIkkRQUBBFRfWjFJ58vf/VV19lzpw5rFixgoKCAlJTU0lPTyc/P9+lrkBBQQGXL1/mwoUL DBs2DA8PDzQajWIB1Go1KpWKlStXMn78eBdLkJiYWGtLIAeBshVQAZo1a9ZYMjMzf3zrrbf08fHx U4CYKVOmuChnwoQJrF69mv79h/H110N44IGQih8KbdoE4eVVc5b52LEc8vPL0WhUSrT/448/MmLE CEaMGEGHDh1YuHAhKpWKU6dOodPp6NmzJ2+++SZNmjRRMnxxcXGsXbuW4OBgZQ3AtGnTKCoq4syZ M4waNYrY2NhbZ+0OQqPRsH37drZv307Hjh3x8PBApVLh5+dHdHQ07dq1Izk5meLiYiUvIC9S0Wq1 aDQaDAYDFy5cwMPDg6ioKJo1awbAypUrkSSJdevWKYkvWQRbt259Oi4ujkuXLi2Mioo6j1tgKAtA bnJ5M+2BAwes06dP/9ebb77pM3bs2MlA85pE8MwzzyjbJAl0OhWLF/cHYPnyquPvDRuG8NhjUVVy +5cvV5bi79ChA0uXLuX48eP4+PgoK4Gc07v79+8nPj6+ighef/11zp49W6uh2L2CzWbD19eX2NhY ZYwfEBBAeHg43t7eeHh40KlTJ7755htycnLQ6/VERUXh7e2NRqPhypUrTJgwQblGYrFY2LhxoyLw lStXAlQrgs2bN4/29/e/cujQoY8efvjhPFxFgA7HLUV9gCCgEdAcaA90i4mJGbh8+fL3cnNzL1e4 g2pjAnfYbHZx/bpZTJ78nUsMsGHDOSGEEEVFReLFF19U/LXcfH19xdy5c8WJEycUHy/HB7t27apS lAkQ/fr1E9nZ2cJkMinr/Gw2m7DZbMJkMtVqrd/t1uxx9vHuzWq1iuTkZPHyyy+LSZMmiW7duomI iAjx+9//XsyfP18sWrRIfP7552L58uVi4MCBwtfXV3Tu3FmsXr1apKWliZ9//lm0b9++ync2bdpU JCYmuvzvkyZNclknSUVMYLVajyYnJ3es4FuJCWQ7rXJq6ooDNIA2NTVVvPHGG4kGg8F39OjRw4FG 1VkCwMUSqFQSer3GxRJs2DCEMWPaYDabXXq+M65fv87ixYvx8/NTloCp1WoSExOrXNiRIVuCzZs3 o9FolChfCHHPrv3LPn7fvn3KNi8vL7y8vJAkiczMTIqLizl//jwXL14kPz+fjRs38qc//YlGjRrh 4+ODRqMhNDSU1q1bM2PGDHr27Mn169eZNGkSGRkZeHl5UV5ernx+bm4uW7duVVLh8nfKVw9lXL9+ HSGEpry8XA4ClSyheypYFoCLCDIzM8U777xzrqSk5IeJEyc+LoQInTp1ap1E8OKLD9K1ayMAxad/ +umn1f6Z/v7+pKSkEBQUBDgSP4GBgQwfPrzGKeKBgYEkJibSt2/f+zLnT6PR8O2337J48WKX7b17 96ZNmzbodDrOnTvHhQsXlIkspaWlLFu2jFdffVWpUh4dHc3gwYN56KGH0Gq1XLhwgdGjR2OxWEhK SuKXX35RXKWcJpZL47/wwgt8/vnnLt8fHR3N1q1bjWVlZUd//vlnA643pLKD427S3jjuMR8ORFFh /nEsKR4OTAKmBQcHz3vttde+vXjx4rUlS5bU2h24rdJW8PHHH1dr1iZOnCgyMzOFEEKkpBSKkyev CKPRKC5duiTGjBlT5T0jRowQGzduVMy/e7sXZdssFouYMGGCy7ZOnTqJ559/XkybNk306dNHhISE VPtef39/8cknn4jDhw+Lo0ePiuTkZJGUlCR+/fVXcfXqVZGbmytyc3PFmTNnxMSJE0V4eLgAxMMP Pyy2bdsmzGazeP7556t8bnR0tDh16pSxsLBw28qVKwfhcPF+OG6oJbsCRQCBuPr/7sBjwEjgD8AM 4PXAwMC///nPf/4+JSWlsC4iqAnOInAnf9euNBEU9LGYO/egOHEit1oRuJN/p9b338inV+fjjx49 Klq3bq28v1u3bmL69Oli1qxZYurUqaJPnz41fpevr6/o27evOHTokDh79qw4dOiQaNeunfjrX/8q 0tPTRWlpqTAajaK8vFwcPHhQNGvWTPTp00d8+umnori4+Ebkm3Jzc79btWrVaBz1AMIqePbBcUt5 XZ1nVxYWFlr+7//+75LFYvF86aWXHlyyZIlfbdxBTZg6dSoA7733Ho8++ijvvPNOxVAvnaee2ozF Ymfx4pMVR7eiQ4dwFi5cCDiyhs888wyjRo1SPu9Ore8XQnDkyBEuX76suJTy8nIMBgMGgwEhBEFB QYSEhFBSUkJKSoqSeu7Vqxd9+vRR8vfylUyr1cqRI0dcvsfX15eWLVsyefJkgoODyc/P509/+hPJ ycm89tpraDQaJk6cqNQfNBgMDBo0iIceeoj4+HheffXVas3+5s2bLQEBAf9as2bN+v/+7/8+jyPR Jyf25JlDkoTDAmgqDvDAMSLwrmi+OEyGH+Bf8egL+Pr7+/tNmjQpZurUqR12797t6y4CoMoQ8UbY vXs37du3r0J+5R+lY8aMzowY0YoOHQK4fv06qamp9OjRQyFMfryVKl7usNvtvPnmm/z6668IIZTE THp6OmazmcaNGzNo0CCuXbuGj48P4eHhWCwW0tLS6Nq1KzqdDq1Wq1zg0Wq1pKenc+jQISVQ9PX1 pVWrVsycOZMePXqQn5/Pf/3Xf5Gc7JpAW7gX5OzLAAAT2ElEQVRwIZMmTSIoKIjs7GxSU1Pp0qUL f/7zn6slf9OmTVa9Xn/8yy+/3Pjuu++eoOraAXkeoVUO+NxHAC5BYDVNYzKZVOfPnzeVl5dbx48f 79+2bVvdP//5TxcRbN68mVatWtUqGRMTE4Ofn1+15AOYzTYSEvLw9/cgJiaYxo0DiIyMBBxVwho1 auRSxq02FT9vhLlz55KSkkJWVhbXr18nPT1dIb9JkyYMHz5cISMtLY1GjRoRFRVFdHS0cgs7b29v fHx88Pb2xtvbm2bNmhESEoJKpSIvL4/WrVvzyiuv0KtXLwoKCpg8eXIV8gF27dpF48aN6dChAyEh IURGRvLyyy/XSL4kSac/+eST7z/88MNfqeztznMGlebsAkTFQXKTZ5iaa2i64uLislWrVmUA0rRp 09ouWbLE53bcAUBKSlEV8mVcv27m4sViysutSg9///332bZtG+PGjePFF1+s1XeA65w8d9hsNtLT 08nIyFAi7OLiYkwmE5GRkTz99NOkpaWRkpLC+fPn8fLywmw2u2TtdDodGo2G0tJSLBYLkiQRGhpK z549CQwMpE2bNvTo0YOePXuiVqtJT0+vdumcjM2bN/PYY4/xwAMPMHXq1GrJ37hxo81isfy6ZMmS f61atSoHhzVX+MLR69VOTakP4DybtDry5TXpOiosQEVTGQwG9apVqzKEEKrp06e3vl0RvPTSQ9jt gmnT9lbZN2JEK0aObKVchXz//feZPXs2gDJ17KWXXrrpd8jHZ2ZmkpGRgclkUlyKyWQiIiKC9PR0 srKy8PPzo1WrVpSVlREeHs5TTz1Famoq58+f5/z58wA8/vjjPP744wr5Wq0WrVZLXl4eu3fv5vz5 88TFxTF69GiCgoLo1asXnTt3JigoSLmW0bNnTz7//HOef/55l+sbAA8//DDx8fFERUXx0ksv1Uh+ WVlZ2uLFi09u3LgxDwdXclMsN5UWXwJUaqre9sz5qpF7gkiqZr9kMpk4f/58eYU78L1dd9C9e2NC QrzYuTNN2TZiRCueeaYdo0Y5Ckg4kw+QkZGBwWAgMjKSmJiYm7qA+fPnc/jwYXbt2kVKSgrZ2dlk Z2djs9m4cuUK6enpnD17loKCAlq3bk2LFi2IjY0lKyuLhIQEZVHrqFGjiI+PR6/XuzQvLy/y8/NZ vnw5Fy9exMvLi6FDh+Ln54enpye+vr7k5eWxYMECWrVqRXR0NM2bN6djx45s375dmfsnkx8fH8/s 2bNrJN9gMGQuWrQo8R//+Ec2lR3YUk2TO7gNsKlwHT7Ynd4o93znogTOxQnKnLYZDQZD2erVqzM+ +uijX3/3u9+VLFmypDIbU4EJEyawZs2aGxIjY+rUTnz88WNAVfI//PBDF/JlHD58mJ9++qlWK36F EGRkZLBs2TLOnTuH3W4nPDwcT09PCgoKuHDhAsnJyRw8eJAff/wRf39/AgIC8PT0VK4wjhs3jsmT J+Pv74+Hhwd+fn74+fnh6+uLr68vHh4eytoFgNDQUCV5c/XqVSZMmMAvv/yiLAgJDAxk4MCBrFy5 Ep1OV2vyCwoKcj/44INft27dWkCleXe+wOfcYcGpw2uoJF7eIStEjUMEzh/inkp0nk6GwWBg9erV GQB3wh1MndqJmJgAysosCvk5OTmsXLkSX19fpxlKldi5cydTp06tkg51hhCCtLQ0Pv30U65du0Z2 djZ9+/bFZrNx6dIlzp07R1JSkpJ2PXDgAHq9ngkTJtC3b1/KysrQ6/UMHz4crVbL7t270Wq1xMXF ERgYqFyu1el0+Pr6UnEDawoLC2natCl5eXmMHz+es2fP0rhxY5fp7bIIduzYwcWLFxk3blyNQ72N Gzfa8/Pz8xYtWnTh+++/z3fio9aQzTpUnTHi/mFVCHfbLgGYTCZxJ91Bq1aBtG9fOfPI19eXzp07 c/jwYUpLS138ZVhYGLNmzaJp06ZIkoTBYAAci0GOHDlCUVER165dY/fu3bzyyiucOnWKTp068dxz z6FWq8nJySEhIYGEhIQq5eQvXLiAJEn07t2bzp078+CDD6LX6/n666/ZvHkzKSkpeHp60qJFCwID A/Hw8MBqtfKvf/2LsLAwXnvtNTp27IjNZmP58uV8++23yjzHvLw8WrVqhbe3N6Wlpfj6+tKsWTM6 d+7MK6+8UiP5165dy1u4cGHarl27rlFptZ1jNucmW3PnZWQ2dwHg9rw6cbhvq7LvTovAHU2aNKki grCwMBYsWED//v3x9vbm5MmTfPLJJ6SkpNCmTRu8vb0pLi5m06ZNzJ8/n0uXLtG9e3deeeUV1Go1 NpuNvLw8Dh06VOOi0+TkZLp3707Lli3x8vJi1apV7Nixg9TUVPLy8jAYDHh4eBATE0NAQAA2m419 +/bx2muvERcXh1qtRqvVcvDgQSUXYDQaKS4uJiEhgePHj2OxWAgPDycwMJApU6bUSP7Vq1evLlq0 KH337t3XqCwhIxMvj/fLnF6bcBWBFbDL46Cbzh932l/TcfdNBN7e3syfP5/HHnsMX19fTp8+zdtv v82mTZu4fv06RqOR2NhYNBoNiYmJ7N27l969e/P666+jUqnQaDR4enqiUqlQq9Xk5ua6XHWT8fzz zzN27Fg8PT358ssv2bp1KxcuXFD25+bmUlRUhE6no2XLloSHhzN48GBat26N1WpVbl978uRJ9u/f r8QGpaWlZGdn4+fnR2xsLD169GDatGk1kp+Xl3dt0aJFl/bs2SP3fJlYmWz3mM3ZEshisVGRCKrO ArjDnfR6I4IePXrQq1cv4uLiFPLfeustDhw4AEBWVhYlJSWYTCZiY2Np164dMTEx/PGPf1QIl8ft ISEhBAUFodfrycrKcnEDU6ZMYebMmcrijDVr1ijDQGfk5ORgt9sJCwujbdu2+Pr6kpOTw+uvv46/ vz8tW7akXbt2HDhwgMzMTMDh+3v37s348eMZN24cs2bNuhn56Xv27MnH1dw7E+9cRcS5bpC8lFwO 9G3OFsAZskWQ3F47o16IoHHjxkRHR6PRaEhKSmLevHns37/f5ZisrCzFVTz44INER0cr5MtjdnlB RqNGjQgODsbHx4fLly9TWlrKtGnTePnll5W0bkxMDLt27SIzM7PKiCMwMJCQkBAmTJhAREQEWVlZ DBs2jJ9++onU1FSaNWtG+/btGTFiBMeOHaN169Z0796d4cOH3zTgq4H86krHVUe+swBkC2B3ToXd SATOjzXtd3+v8ni3RaBWqzGZTLz//vvs2rWrSiIFHCLo0KEDffv2Va4VyL1fq9WiUqnw8vLC09OT xo0bKyIYMGAA06dPx8PDg40bNyop3WHDhvHzzz+TkZGhiCAwMJCOHTvy17/+lW7dupGVlcXQoUM5 ffo0RqORwsJCLly4QPPmzWnXrh1PP/00PXr0YODAgfTs2fNWer5MfnWl42qqGuZcR8Dungu9FRHY q9nu/Fn3RAQeHh6Eh4dXOzoAePLJJ/n73/+urBGQyddoNJSXl5Ofn8+1a9do2rQpOp2OiIgI2rZt y6OPPopWq2Xp0qXs3buXRx55hMaNG6PX65VenJGRQUBAgEJ+XFwcmZmZDBkyxGVNotFopKioiAsX LhAVFUWrVq0ICwsjICCgNj6/OrMv+3n3aqHOTRaIc++Xl5JXEYBCmNvrBiGCJk2a0KlTJ/71r3+5 iGDw4MGsW7fOpefLj2VlZaSkpLB48WLOnTtHSEgIMTEx6HQ6ZdHGxx9/zIYNG7h48SKPPPIIbdu2 VQLHkSNHkpycTGBgIG+//TZxcXGUlJQwderUKq4IUCyBl5cXHTt2xNfXt8aZPLX0+dXdC8j56p8z +XIhCbmJmtZ3NUgRSJJURQQDBw5UppGVlZUp2Tn5QlBOTg4fffQRu3fvJicnB6PRSJcuXQgODkaj 0bBp0ya++OILzp07h4eHBy1atKB79+5KLSMvLy+GDRtGr1696Nq1K5Ik4eHhQU5ODtnZ2Vy5cqXK eXbr1o0nnniCrl273mrPl02+e31g94KR7uQ7l5AR1GABlP+zmtf1XgQATZs2pVOnTnh4ePDFF18A cPLkSZKTkzGZTDRq1AiVSoVWq6WoqIhjx46Rn59PQUEB48aN46mnnkKj0WCxWDh69Cjr169XpmKn p6crS9fKy8spKSmhadOmhIWFuZxDz549MZvNVUTQp08f4uPjGTt27O1E+87+vjryS3FN/sjky5eE 5exvjRZARoMTgTwjuGnTpgwYMABJkjh27Bhr167lo48+QqvVEhgYSJMmTVCpVISFhdGsWTOuXLnC xIkTlcSQfA+i5ORkvvvuO5e7hv30008kJyeTkpLCwIEDXWoXOMNdBDL5N5rJUwfyS7h5tVAjbpk/ 3IpH1eYepw1WBJIkcfToUb7++mvWrl1Lbm4up06dIiAgwEUE8g0rBgwYgEqlYv9+FTExKnQ6HdnZ 2WRkZJCRkQE4riP4+vrSokUL3nzzTTp16nTDc5FF0KhRIwYNGnQvyHeuGCqnh93Jly+U3NQCKP9p Na/rvQiOHj3KunXrWLNmDQUFBQCYzWZFBAEBAURERCBJEn5+fqhUKj74QMXChSouXpR44gmJNm3a IEkSBQUF5OXl0aRJE9q0acOCBQvo3bt3td+dlpaGSqVSJpP07NmTmJgY+vXrV+M0rvtBPnUQADQw EVy5coVPP/2UtWvXKuTLMJvNJCQkEBgYSPv27fH19UWSJN57T2LNGomzZ+GnnyQMBomBAyU6depE ZGQkDz/8MKNGjWLcuHF069at2u99++23lZqGgYGBeHl5ARAeHs706dPrFflQOxfgjAYjAh8fH7Ky sli/fn21+81mM4MGDWLQoEFu5Fde25JF8MQT0KJFCzp16kR0dDRNmjSptsz8e++9x5o1a9izZw+X L1+mW7duymjiNoZ6d418qLsAoAGJoHPnzoSEhLBz584q++bPn8/cuXORJInPP5dYtsyZfGcROCqd 9XescEOtVpOXl4fRaFSWa8tISkpiw4YNWK1WIiMj6dixI23atLnRNK77Sj7cmgCgAYmge/fuVUQw f/583njjDQCKiiAzE3btclQtdUdQkKPIZb9+EBDgmHo2aNAgtm/fzpNPPomHh4cigq5du2K329Fo NIwdO5YhQ4bUOHu3PpAPty4AaKAicCY/L68MT08ICFATFgbnzrmKICjIUdl0wQLHY0ZGBoMHDyYx MZH09HROnDhRRQSPPPII7du3p1+/fvUq2q/mPwduTwDQwETw1FNPER8fD8C77x7lyy/P0K5dME2b amnc2FUEzuT37u1KvoyaRBAREcGMGTPqPflw+wKABiSCJk2aAA7yV68+y759GSQk5BEX18RFBDk5 EBlZSX5+fj5PPPFEtRVHZREMHz5cqfpRXwO+6nAnBAANSAQy+WfOOKZ9ZWWVuIigSRM1bdvC009D 9+6OxE9xcTHHjx9XCli7IzIyksjISNq2bcuLL77YYMiHOycAaAAicCdfhiyCvn0jiYzU0aqVishI KC42kZZWTESEP3FxcWRlZVURgZzeHTJkCDNnzmxQ5MOdFQDUYxGYzXb27LnMpk2/Vnvi5eVWysos DBjQHL1eTUbGdYYN+5bSUgvBwd5ER4dUEcE9zO3fFfLhzgsA6qkIJAl69GjMlStlJCTkuewLCvKk Y8dQXnmlKzExAWRkXGfw4M2cOHFFWZDqLoLg4OAGTz7cHQFAPRSBJEloNCp+97soFxHI5C9Y0Ife vSMU8hMTrwKuq5JlEfTv35+2bdsyaNCgBk0+3D0BQAMQwaVLhhuSL8NZBFFRgTRtGkiLFi0apM93 x90UANRjETz+eBQ6nYY//vEBevd2FJzeuTONTz45Ve0PMZtteHlp6NWrCRERvkyZUn/Tu3XB3RYA 1GMR9OoVQVRU5Y0sH3ggpMqqZBl9+jRlzJg29O/fjJkza1yf36DIh3sjAKinIlCp3E+r+qXpffo0 JT6+HfHx7Xj11fp3Sfd2cK8EAPVQBDXBWQT/zuTDvRUANDARxMaG0qJFwL8t+XDvBQANSATt2gUT GxvKK6/c1tTteks+3B8BQAMSwb9LtF8T7pcAoAGIoCFd1btV3E8BQD0WwX8C+XD/BQD1UAT/KeRD /RAA1CMR/CeRD/VHAFAPRHDw4EE2btzo8kH/zuRD/RIA3GcRpKW5poD/3cmH+icAuM8ikPGfQD7U TwHAfRbBfwr5UH8FAHdfBGXl5eXWsWPH+rZv314RQXR0NN98840tOzv72ocffiiXYpMLLNSmOEOD IR8qbx9fH+FOsh1Hqdo7cgcog8EgVq9efam8vFzEx8dHZmZm+up0OrXBYLAcPnw4/3//938zDx8+ XEgledWVZWnQ5EPVXlYf4dx7JSrrFculz+Uy6PLdTrxwveuJj1PzdmpegKefn5/ez8/Ps3379n6A qqyszJ6WllaelZVlxEGaezWumipzNDjyoWEIAO6OCPQVx3lQeQct2SUKHIQ593657o5772+w5EP9 dgHOuFPuQLg1O5UVs9wFIFfTdO/9JW6PDZZ8aDgCgFsTgfuf7C4A57ujyAKQg0kblZG/ez0+57Js DZZ8aFgCgNu3BM5/vkyy3NO1VBVAdaVYZQE4V+NqkORDwxMA3J4I3Hu/s593F4AsDOehn3sR5gZN PjRMAUDdReDe853NvxlHICgLAKf9zmXYncuvO1fgbLDkQ8MVANx6TOAuADnQc48B5NjA6Nac/b17 /d0GRT40bAFA7UQgnB7tTo/O5l8eBsrDS+f9shtwJt25/GqDJR/g/wPG89WLn1QtzgAAAABJRU5E rkJggg== --Apple-Mail-4--451632508 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Thursday, May 15, 2003, at 07:46 AM, Michael Williams wrote: > I prefer the Python to the Foot as, although experienced (older?!) > Python > developers will get the reference, they're not IDLEs target audience of > beginners. --Apple-Mail-4--451632508-- From kbk@users.sourceforge.net Thu May 15 19:52:54 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 15 May 2003 11:52:54 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.65,1.66 help.txt,1.8,1.9 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv29550 Modified Files: PyShell.py help.txt Log Message: 1. Add a command line switch to run without the subprocess 2. Remove the shell menu and associated bindings when running without the subprocess. 3. Update the IDLE Help and usage text. 4. Update display_port_binding_error to suggest using -n M PyShell.py M help.txt Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.65 retrieving revision 1.66 diff -C2 -r1.65 -r1.66 *** PyShell.py 15 May 2003 03:40:51 -0000 1.65 --- PyShell.py 15 May 2003 18:52:50 -0000 1.66 *************** *** 333,337 **** break except socket.error, err: ! print>>sys.__stderr__,"Idle socket error: " + err[1]\ + ", retrying..." else: --- 333,337 ---- break except socket.error, err: ! print>>sys.__stderr__,"IDLE socket error: " + err[1]\ + ", retrying..." else: *************** *** 651,655 **** ("file", "_File"), ("edit", "_Edit"), - ("shell", "_Shell"), ("debug", "_Debug"), ("options", "_Options"), --- 651,654 ---- *************** *** 662,665 **** --- 661,666 ---- def __init__(self, flist=None): + if use_subprocess: + self.menu_specs.insert(2, ("shell", "_Shell")) self.interp = ModifiedInterpreter(self) if flist is None: *************** *** 687,692 **** text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) ! text.bind("<>", self.view_restart_mark) ! text.bind("<>", self.restart_shell) # self.save_stdout = sys.stdout --- 688,694 ---- text.bind("<>", self.flist.open_shell) text.bind("<>", self.toggle_jit_stack_viewer) ! if use_subprocess: ! text.bind("<>", self.view_restart_mark) ! text.bind("<>", self.restart_shell) # self.save_stdout = sys.stdout *************** *** 811,815 **** COPYRIGHT = \ ! 'Type "copyright", "credits" or "license" for more information.' def begin(self): --- 813,817 ---- COPYRIGHT = \ ! 'Type "copyright", "credits" or "license()" for more information.' def begin(self): *************** *** 1073,1076 **** --- 1075,1079 ---- -h print this help message and exit + -n run IDLE without a subprocess (see Help/IDLE Help for details) The following options will override the IDLE 'settings' configuration: *************** *** 1121,1124 **** --- 1124,1128 ---- global flist, root, use_subprocess + use_subprocess = True enable_shell = False enable_edit = False *************** *** 1132,1136 **** sys.ps1 = '>>> ' try: ! opts, args = getopt.getopt(sys.argv[1:], "c:deihr:st:") except getopt.error, msg: sys.stderr.write("Error: %s\n" % str(msg)) --- 1136,1140 ---- sys.ps1 = '>>> ' try: ! opts, args = getopt.getopt(sys.argv[1:], "c:deihnr:st:") except getopt.error, msg: sys.stderr.write("Error: %s\n" % str(msg)) *************** *** 1151,1154 **** --- 1155,1160 ---- if o == '-i': enable_shell = True + if o == '-n': + use_subprocess = False if o == '-r': script = a *************** *** 1168,1174 **** cmd = sys.stdin.read() enable_shell = True - - use_subprocess = True - # process sys.argv and sys.path: for i in range(len(sys.path)): --- 1174,1177 ---- *************** *** 1203,1207 **** root.withdraw() flist = PyShellFileList(root) - if enable_edit: if not (cmd or script): --- 1206,1209 ---- *************** *** 1240,1256 **** def display_port_binding_error(): print """\ ! IDLE cannot run. ! IDLE needs to use a specific TCP/IP port (8833) in order to execute and ! debug programs. IDLE is unable to bind to this port, and so cannot ! start. Here are some possible causes of this problem: 1. TCP/IP networking is not installed or not working on this computer ! 2. Another program is running that uses this port 3. Personal firewall software is preventing IDLE from using this port ! IDLE makes and accepts connections only with this computer, and does not ! communicate over the internet in any way. Its use of port 8833 should not ! be a security risk on a single-user machine. """ --- 1242,1258 ---- def display_port_binding_error(): print """\ ! \nIDLE cannot run. ! IDLE needs to use a specific TCP/IP port (8833) in order to communicate with ! its Python execution server. IDLE is unable to bind to this port, and so ! cannot start. Here are some possible causes of this problem: 1. TCP/IP networking is not installed or not working on this computer ! 2. Another program (another IDLE?) is running that uses this port 3. Personal firewall software is preventing IDLE from using this port ! Run IDLE with the -n command line switch to start without a subprocess ! and refer to Help/IDLE Help "Running without a subprocess" for further ! details. """ Index: help.txt =================================================================== RCS file: /cvsroot/idlefork/idle/help.txt,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** help.txt 26 Jan 2003 04:17:16 -0000 1.8 --- help.txt 15 May 2003 18:52:51 -0000 1.9 *************** *** 192,193 **** --- 192,206 ---- Enter idle -h at the command prompt to get a usage message. + + Running without a subprocess: + + If IDLE is started with the -n command line switch it will run in a + single process and will not create the subprocess which runs the RPC + Python execution server. This can be useful if Python cannot create + the subprocess or the RPC socket interface on your platform. However, + in this mode user code is not isolated from IDLE itself. Also, the + environment is not restarted when Run/Run Module (F5) is selected. If + your code has been modified, you must reload() the affected modules and + re-import any specific items (e.g. from foo import baz) if the changes + are to take effect. For these reasons, it is preferable to run IDLE + with the default subprocess if at all possible. From noreply@sourceforge.net Thu May 15 21:28:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 13:28:53 -0700 Subject: [Idle-dev] [ idlefork-Bugs-558687 ] Printing arrays misses elements Message-ID: Bugs item #558687, was opened at 2002-05-21 09:10 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Michael Williams (mikewilliams) Assigned to: Nobody/Anonymous (nobody) Summary: Printing arrays misses elements Initial Comment: IDLEfork seems to be missing out an inconsistent number of the final few elements of a Numeric array when asked to print them. This has been replicated on both Linux and Solaris with Python2.2.1 and IDLEfork 0.8.1 Consider the following code snippet (problem exhibited both if run from module or typed at shell): from Numeric import * #Import Numeric (an array #library) xx = zeros(100, Float) #Create an empty array of #100 floats for i in range(100): xx[i] = i #Put numbers 0 to 99 in the #array print xx #Print the array (see the #problem?) print xx[99] #Although xx[99] does exist! This problem doesn't seem to occur much below 100 element arrays (although see, e.g. 87), but seems to get more severe above it. See, for example 102-108 (not 109 or 110), 150, 200, 1000 (which prints the first 947 elements!). I could not find a corellation between window width and the number of elements that were printed (which appears to be constant). Ther seems to be some reluctance to start a new line when printing until there are sufficient elements to put on it. This is a medium severity problem, especially for interactive work. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 15:28 Message: Logged In: YES user_id=149084 Numeric version 22.0 IDLEfork0.9a2++ Python 2.2.2 W2K "works for me" ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2002-06-20 08:41 Message: Logged In: YES user_id=34881 With idlefork-0.8.1 on RedHat Linux 7.2 with Numeric 21.0, when I try running exactly the same test in the shell, I see no difference between "print xx" and "xx", and both are correct. No clue as to what might be different in your environment. ---------------------------------------------------------------------- Comment By: Michael Williams (mikewilliams) Date: 2002-06-20 06:54 Message: Logged In: YES user_id=258804 OK. Tested again to convince myself I wasn't daydreaming and the problem is definitely there. Here's the output of a short IDLEfork session: >>> from Numeric import * >>> xx = zeros(100, Float) >>> for i in range(100): xx[i] = i >>> print xx [ 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98.] >>> xx array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29., 30., 31., 32., 33., 34., 35., 36., 37., 38., 39., 40., 41., 42., 43., 44., 45., 46., 47., 48., 49., 50., 51., 52., 53., 54., 55., 56., 57., 58., 59., 60., 61., 62., 63., 64., 65., 66., 67., 68., 69., 70., 71., 72., 73., 74., 75., 76., 77., 78., 79., 80., 81., 82., 83., 84., 85., 86., 87., 88., 89., 90., 91., 92., 93., 94., 95., 96., 97., 98., 99.]) Sorry if line-wrapping hasn't worked! Anyway, the moral of the story is if you "print xx" the problem is exhibited but if you just "xx" it isn't. Does this suggest the likely origin of the problem? I checked with the regular Python intrerpreter (both through the old IDLE and from the command line) and this definitely isn't a problem there. Doing "print str(xx)" instead of "print xx" makes no difference; this enironment doesn't exhibit the problem. By the way, this is all with the latest Numeric which is version 21.0. Is this the same version you're using Bruce? If it would be useful I could try and replicate the problem with earlier Numerics. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 07:33 Message: Logged In: YES user_id=6380 Without looking at any code, I venture that this is more likely a bug in Numeric rather than in idle(fork). If you don't see this when using the regular python interpreter, that could be because in IDLE, str() is used to print numeric objects, while in the regular interpreter an internal print handler may be used. To verify that theory, you could use "print str(xx)" in a regular interpreter. If that has the same problem, please submit the bug report to the Numeric folks (and report back here in either case). ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2002-06-18 20:50 Message: Logged In: YES user_id=34881 I'm using idlefork-0.8.1 for daily work. I cannot reproduce this problem; the test routine gives the correct output on RedHat Linux 7.2. This is with a version of Numeric from a few months ago. ---------------------------------------------------------------------- Comment By: Michael Williams (mikewilliams) Date: 2002-05-21 09:36 Message: Logged In: YES user_id=258804 This does not occur in the IDLE distributed with the Python source. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 From noreply@sourceforge.net Thu May 15 21:33:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 13:33:52 -0700 Subject: [Idle-dev] [ idlefork-Bugs-558687 ] Printing arrays misses elements Message-ID: Bugs item #558687, was opened at 2002-05-21 10:10 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Michael Williams (mikewilliams) Assigned to: Nobody/Anonymous (nobody) Summary: Printing arrays misses elements Initial Comment: IDLEfork seems to be missing out an inconsistent number of the final few elements of a Numeric array when asked to print them. This has been replicated on both Linux and Solaris with Python2.2.1 and IDLEfork 0.8.1 Consider the following code snippet (problem exhibited both if run from module or typed at shell): from Numeric import * #Import Numeric (an array #library) xx = zeros(100, Float) #Create an empty array of #100 floats for i in range(100): xx[i] = i #Put numbers 0 to 99 in the #array print xx #Print the array (see the #problem?) print xx[99] #Although xx[99] does exist! This problem doesn't seem to occur much below 100 element arrays (although see, e.g. 87), but seems to get more severe above it. See, for example 102-108 (not 109 or 110), 150, 200, 1000 (which prints the first 947 elements!). I could not find a corellation between window width and the number of elements that were printed (which appears to be constant). Ther seems to be some reluctance to start a new line when printing until there are sufficient elements to put on it. This is a medium severity problem, especially for interactive work. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-15 16:33 Message: Logged In: YES user_id=6380 As I said, and as the OP seems to ignore, this points out that there must be bug in Numeric. It's tp_str implementation is missing the last element; its tp_repr implementation is correct; its tp_print implementation is also correct. "print xx" uses tp_print when stdout is a real file, as when using the standard shell; but is uses tp_str when stdout is an object pretending to be a file, as is the case when run under IDLE. So, this is definitely not an IDLE bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 16:28 Message: Logged In: YES user_id=149084 Numeric version 22.0 IDLEfork0.9a2++ Python 2.2.2 W2K "works for me" ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2002-06-20 09:41 Message: Logged In: YES user_id=34881 With idlefork-0.8.1 on RedHat Linux 7.2 with Numeric 21.0, when I try running exactly the same test in the shell, I see no difference between "print xx" and "xx", and both are correct. No clue as to what might be different in your environment. ---------------------------------------------------------------------- Comment By: Michael Williams (mikewilliams) Date: 2002-06-20 07:54 Message: Logged In: YES user_id=258804 OK. Tested again to convince myself I wasn't daydreaming and the problem is definitely there. Here's the output of a short IDLEfork session: >>> from Numeric import * >>> xx = zeros(100, Float) >>> for i in range(100): xx[i] = i >>> print xx [ 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98.] >>> xx array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29., 30., 31., 32., 33., 34., 35., 36., 37., 38., 39., 40., 41., 42., 43., 44., 45., 46., 47., 48., 49., 50., 51., 52., 53., 54., 55., 56., 57., 58., 59., 60., 61., 62., 63., 64., 65., 66., 67., 68., 69., 70., 71., 72., 73., 74., 75., 76., 77., 78., 79., 80., 81., 82., 83., 84., 85., 86., 87., 88., 89., 90., 91., 92., 93., 94., 95., 96., 97., 98., 99.]) Sorry if line-wrapping hasn't worked! Anyway, the moral of the story is if you "print xx" the problem is exhibited but if you just "xx" it isn't. Does this suggest the likely origin of the problem? I checked with the regular Python intrerpreter (both through the old IDLE and from the command line) and this definitely isn't a problem there. Doing "print str(xx)" instead of "print xx" makes no difference; this enironment doesn't exhibit the problem. By the way, this is all with the latest Numeric which is version 21.0. Is this the same version you're using Bruce? If it would be useful I could try and replicate the problem with earlier Numerics. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 08:33 Message: Logged In: YES user_id=6380 Without looking at any code, I venture that this is more likely a bug in Numeric rather than in idle(fork). If you don't see this when using the regular python interpreter, that could be because in IDLE, str() is used to print numeric objects, while in the regular interpreter an internal print handler may be used. To verify that theory, you could use "print str(xx)" in a regular interpreter. If that has the same problem, please submit the bug report to the Numeric folks (and report back here in either case). ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2002-06-18 21:50 Message: Logged In: YES user_id=34881 I'm using idlefork-0.8.1 for daily work. I cannot reproduce this problem; the test routine gives the correct output on RedHat Linux 7.2. This is with a version of Numeric from a few months ago. ---------------------------------------------------------------------- Comment By: Michael Williams (mikewilliams) Date: 2002-05-21 10:36 Message: Logged In: YES user_id=258804 This does not occur in the IDLE distributed with the Python source. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=558687&group_id=9579 From noreply@sourceforge.net Fri May 16 00:11:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 16:11:03 -0700 Subject: [Idle-dev] [ idlefork-Patches-732395 ] Not compatible with Blender226 Message-ID: Patches item #732395, was opened at 2003-05-04 18:10 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=732395&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Not compatible with Blender226 Initial Comment: Dear, Thanks a lot for this wonderful tool. Due to the poor support of Python editing, I was happy to find out that Idle was the (only) editor which could be run from within Blender it self. Unfortunately debugging wouldn't work (AttributeError:__nonzero__ for DelegatorComment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 18:11 Message: Logged In: YES user_id=149084 not-a-patch Dup of Bug 732397 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=732395&group_id=9579 From kbk@users.sourceforge.net Fri May 16 00:23:23 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 15 May 2003 16:23:23 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.66,1.67 ScriptBinding.py,1.19,1.20 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv14095 Modified Files: PyShell.py ScriptBinding.py Log Message: 1. When a module is run from an EditorWindow, if its directory is not in sys.path, prepend it. This allows the module to import other modules in the same directory. Do the same for a script run from the command line. 2. Tweak the IDLE usage message a bit more. SF Bug 706860 (closed) SF Patch 686254 (reject specific solution) SF Patch 507327 (similar) M PyShell.py M ScriptBinding.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.66 retrieving revision 1.67 diff -C2 -r1.66 -r1.67 *** PyShell.py 15 May 2003 18:52:50 -0000 1.66 --- PyShell.py 15 May 2003 23:23:20 -0000 1.67 *************** *** 527,530 **** --- 527,542 ---- return filename + def prepend_syspath(self, filename): + "Prepend sys.path with file's directory if not already included" + self.runcommand("""if 1: + _filename = %s + import sys as _sys + from os.path import dirname as _dirname + _dir = _dirname(_filename) + if not _dir in _sys.path: + _sys.path.insert(0, _dir) + del _filename, _sys, _dirname, _dir + \n""" % `filename`) + def showsyntaxerror(self, filename=None): """Extend base class method: Add Colorizing *************** *** 1070,1076 **** usage_msg = """\ ! USAGE: idle [-deis] [-t title] [file]* ! idle [-ds] [-t title] (-c cmd | -r file) [arg]* ! idle [-ds] [-t title] - [arg]* -h print this help message and exit --- 1082,1088 ---- usage_msg = """\ ! USAGE: idle [-deins] [-t title] [file]* ! idle [-dns] [-t title] (-c cmd | -r file) [arg]* ! idle [-dns] [-t title] - [arg]* -h print this help message and exit *************** *** 1235,1238 **** --- 1247,1251 ---- shell.interp.execsource(cmd) elif script: + shell.interp.prepend_syspath(script) shell.interp.execfile(script) root.mainloop() Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.19 retrieving revision 1.20 diff -C2 -r1.19 -r1.20 *** ScriptBinding.py 15 May 2003 03:19:42 -0000 1.19 --- ScriptBinding.py 15 May 2003 23:23:21 -0000 1.20 *************** *** 145,150 **** _basename(_sys.argv[0]) != _basename(_filename)): _sys.argv = [_filename] ! del _filename, _sys, _basename ! \n""" % `filename`) interp.runcode(code) --- 145,151 ---- _basename(_sys.argv[0]) != _basename(_filename)): _sys.argv = [_filename] ! del _filename, _sys, _basename ! \n""" % `filename`) ! interp.prepend_syspath(filename) interp.runcode(code) From noreply@sourceforge.net Fri May 16 00:24:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 16:24:50 -0700 Subject: [Idle-dev] [ idlefork-Patches-507327 ] ScriptBinding.py auto modify sys.path Message-ID: Patches item #507327, was opened at 2002-01-22 22:01 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=507327&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephen M. Gava (elguavas) >Assigned to: Kurt B. Kaiser (kbk) Summary: ScriptBinding.py auto modify sys.path Initial Comment: patch submitted to idle-dev by Danny Yoo although this applies to ScriptBinding.py it may be of some use in future separate process execution stuff original message to idle-dev: ----------------------------- Hi everyone, A while back, I sent a patch to automagically add a script's directory path to sys.path. Here's a link to the original post: http://mail.python.org/pipermail/tutor/2001-December/010915.html The problem is this: if a user is experimenting with importing their own modules, they run into an ImportError because their modules aren't located in the system path. This is somewhat weird to me, as I would have expected IDLE to do this for me. I've isolated the code to run_script_event(), which uses an execfile() call. execfile() doesn't extend sys.path, probably for security reasons. But for someone running scripts through IDLE, this seems a bit paranoid. Here's a modified run_script_even that temporarily adjusts sys.path, just long enough for the run_script command to finish: #### def run_script_event(self, event): filename = self.getfilename() if not filename: return flist = self.editwin.flist shell = flist.open_shell() interp = shell.interp if (not sys.argv or os.path.basename(sys.argv[0]) != os.path.basename(filename)): # XXX Too often this discards arguments the user just set... sys.argv = [filename] old_syspath = sys.path[:] sys.path.append(os.path.dirname(os.path.abspath(filename))) interp.execfile(filename) sys.path = old_syspath ### Does this seem like a reasonable thing to add to IDLE? I always feel very worried about telling new Python programmers to edit their PYTHONPATH... *grin* ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 18:24 Message: Logged In: YES user_id=149084 ScriptBinding Rev 1.20 PyShell Rev 1.67 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=507327&group_id=9579 From noreply@sourceforge.net Fri May 16 02:29:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 15 May 2003 18:29:18 -0700 Subject: [Idle-dev] [ idlefork-Bugs-706860 ] sys.path does not contain source file directory Message-ID: Bugs item #706860, was opened at 2003-03-20 07:21 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Dickon Reed (dickon) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.path does not contain source file directory Initial Comment: With idlefork 0.8.1, when a script was run the current working directory was set to the script location, and the script location was added to sys.path. Therefore, imports of modules in the same directory as the script location worked even if the user had not made an effort to place the script location on the module path. With idlefork 0.9a2, for me it seems neither the current working directory nor sys.path get updated with the script location. Thus imports do not work for modules in the same location as the script (unless the location is in sys.path anyway). My actions were: 1. Install python 2.2.1 from python labs on Win2K in c:\python22 2. Install idlefork 0.9a2. 3. Rename C:\python22\scripts\idlefork to C:\python22\scripts\idlefork.py 4. Launch C:\python22\scripts\idlefork.py 5. Create a script using idlefork 0.9a2: import os, sys print 'cwd', os.getcwd() print 'path', sys.path 6. Save the script as C:\ 7. Run the script from within idlefork. 8. Output is: cwd C:\Python22\Scripts path ['C:\Python22\Scripts', 'C:\Python22\Scripts', 'C:\Python22\DLLs', 'C:\Python22\lib', 'C:\Python22\lib\lib-tk', 'C:\Python22', 'C:\Python22\lib\site-packages'] I'm not sure whether the CWD should be updated or not (I note idlefork 0.8.1 does, but running the script from the path on Linux doesn't). But it shouldn't it the case that one is able to import modules from the same directory as the launched script without having to worry about setting sys.path. I haven't tried this with other platforms or the CVS version. I believe this is the same problem reported on comp.lang.python here: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=3E79728C.AED36CCD%40alcyone.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26group%3Dcomp.lang.python win2k and winxp, python labs python 2.2.1 idlefork 0.9a2 from idlefork.sf.net ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 20:29 Message: Logged In: YES user_id=149084 ScriptBinding Rev 1.20 PyShell Rev 1.67 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 From noreply@sourceforge.net Fri May 16 22:44:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 14:44:03 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Fri May 16 23:15:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 15:15:11 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Sat May 17 04:15:50 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 16 May 2003 20:15:50 -0700 Subject: [Idle-dev] CVS: idle CREDITS.txt,1.5,1.6 NEWS.txt,1.17,1.18 idle,1.9,1.10 idle.py,1.7,1.8 idle.pyw,1.6,1.7 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv12843 Modified Files: CREDITS.txt NEWS.txt idle idle.py idle.pyw Log Message: Noam Raphael's patch. SF Patch 686254 "Run IDLEfork from any directory without set-up" Allows IDLE to run when not installed and cwd is not the IDLE directory. I took the liberty of moving it to the startup scripts since once IDLEfork is again a part of Python it will be superfluous and I don't want it to be forgotten. But it is very useful for those using IDLEfork standalone! M CREDITS.txt M NEWS.txt M idle M idle.py M idle.pyw Index: CREDITS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/CREDITS.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** CREDITS.txt 25 Apr 2003 16:37:31 -0000 1.5 --- CREDITS.txt 17 May 2003 03:15:48 -0000 1.6 *************** *** 14,19 **** 0.8.1 and later are Stephen M. Gava, who implemented the Configuration GUI, the new configuration system, and the new About menu, and Kurt B. Kaiser, who ! completed the integration of the RPC and remote debugger, and made a number of ! usability enhancements. Other contributors include Raymond Hettinger, Tony Lownds (Mac integration), --- 14,19 ---- 0.8.1 and later are Stephen M. Gava, who implemented the Configuration GUI, the new configuration system, and the new About menu, and Kurt B. Kaiser, who ! completed the integration of the RPC and remote debugger, implemented the ! threaded subprocess, and made a number of usability enhancements. Other contributors include Raymond Hettinger, Tony Lownds (Mac integration), *************** *** 21,26 **** integration and persistent breakpoints). ! Hernan Foffani, Christos Georgiou, Jason Orendorff, Josh Robb, and Bruce ! Sherwood have submitted useful patches. Thanks, guys! There are others who should be included here, especially those who contributed --- 21,27 ---- integration and persistent breakpoints). ! Hernan Foffani, Christos Georgiou, Martin v. Loewis, Jason Orendorff, ! Noam Raphael, Josh Robb, and Bruce Sherwood have submitted useful patches. ! Thanks, guys! There are others who should be included here, especially those who contributed Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** NEWS.txt 15 May 2003 03:19:41 -0000 1.17 --- NEWS.txt 17 May 2003 03:15:48 -0000 1.18 *************** *** 8,11 **** --- 8,18 ---- *Release date: XX-XXX-2003* + - Allow IDLE to run when not installed and cwd is not the IDLE directory + SF Patch 686254 "Run IDLEfork from any directory without set-up" - Raphael + + - When a module is run from an EditorWindow: if its directory is not in + sys.path, prepend it. This allows the module to import other modules in + the same directory. Do the same for a script run from the command line. + - Interrupt the subprocess if it is running when the user attempts to restart the shell, run a module, or exit. *************** *** 14,20 **** command line. - Added a comment to the shell startup header to indicate when IDLE is not ! using the subprocess. (For now, set PyShell.use_subprocess to False to run ! in this mode.) - Restore the ability to run without the subprocess. This can be important for --- 21,29 ---- command line. + - Added a -n command line switch to start IDLE without the subprocess. + Removed the Shell menu when running in that mode. Updated help messages. + - Added a comment to the shell startup header to indicate when IDLE is not ! using the subprocess. - Restore the ability to run without the subprocess. This can be important for Index: idle =================================================================== RCS file: /cvsroot/idlefork/idle/idle,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** idle 2 Jan 2003 17:09:34 -0000 1.9 --- idle 17 May 2003 03:15:48 -0000 1.10 *************** *** 5,10 **** except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! import PyShell ! PyShell.main() else: idlelib.PyShell.main() --- 5,20 ---- except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! try: ! import PyShell ! except ImportError: ! print "Can't locate PyShell.py" ! else: ! import os ! idledir = os.path.dirname(os.path.abspath(PyShell.__file__)) ! if idledir != os.getcwd(): ! # We're not in the IDLE directory, help the subprocess find run.py ! pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! PyShell.main() else: idlelib.PyShell.main() Index: idle.py =================================================================== RCS file: /cvsroot/idlefork/idle/idle.py,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** idle.py 2 Jan 2003 17:09:34 -0000 1.7 --- idle.py 17 May 2003 03:15:48 -0000 1.8 *************** *** 5,10 **** except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! import PyShell ! PyShell.main() else: idlelib.PyShell.main() --- 5,20 ---- except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! try: ! import PyShell ! except ImportError: ! print "Can't locate PyShell.py" ! else: ! import os ! idledir = os.path.dirname(os.path.abspath(PyShell.__file__)) ! if idledir != os.getcwd(): ! # We're not in the IDLE directory, help the subprocess find run.py ! pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! PyShell.main() else: idlelib.PyShell.main() Index: idle.pyw =================================================================== RCS file: /cvsroot/idlefork/idle/idle.pyw,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** idle.pyw 2 Jan 2003 17:09:34 -0000 1.6 --- idle.pyw 17 May 2003 03:15:48 -0000 1.7 *************** *** 1,10 **** - #!/usr/bin/python - try: import idlelib.PyShell except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! import PyShell ! PyShell.main() else: idlelib.PyShell.main() --- 1,18 ---- try: import idlelib.PyShell except ImportError: # IDLE is not installed, but maybe PyShell is on sys.path: ! try: ! import PyShell ! except ImportError: ! print "Can't locate PyShell.py" ! else: ! import os ! idledir = os.path.dirname(os.path.abspath(PyShell.__file__)) ! if idledir != os.getcwd(): ! # We're not in the IDLE directory, help the subprocess find run.py ! pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! PyShell.main() else: idlelib.PyShell.main() From noreply@sourceforge.net Sat May 17 04:22:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 20:22:24 -0700 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 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=686254&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) >Assigned to: Kurt B. Kaiser (kbk) 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-05-16 22:22 Message: Logged In: YES user_id=149084 M idle 1.10 M idle.py 1.8 M idle.pyw 1.7 I took the liberty of moving it to the startup scripts since once IDLEfork is again a part of Python it will be superfluous and I don't want it to be forgotten. But it is very useful for those using IDLEfork standalone! ---------------------------------------------------------------------- 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 Sat May 17 04:34:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 20:34:42 -0700 Subject: [Idle-dev] [ idlefork-Patches-661363 ] Run multiple IDLEforks on the same machine simultanously Message-ID: Patches item #661363, was opened at 2003-01-02 17:57 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=661363&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted >Priority: 4 Submitted By: Noam Raphael (noamr) >Assigned to: Kurt B. Kaiser (kbk) Summary: Run multiple IDLEforks on the same machine simultanously Initial Comment: Instead of defining a specific port (8833), a list of legitimate ports is defined. When IDLE starts, it goes over the list and tries each of the ports. When it finds a port which is ok, it starts the subprocess. The list of ports which I defined is very arbitrary, and should be reviewed. A more minor change, which is calling the spawn_subprocess method only after the RPCClient class was succesfully initialized, solves the bug that when opening a second IDLE, an error message is displayed but a malfunctioning shell window is displayed, and when it's closed, the subprocess keeps on running until the first IDLE is shut down. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:34 Message: Logged In: YES user_id=149084 I have implemented the second change: spawn after successful port binding. Having done this, I no longer see the spurious processes being spawned on Linux. However, on W2K I have at least once seen a second copy of IDLEfork start listening on the 8833 port used by the original copy. Then it went ahead and spawned a subprocess in spite of this change. Until we figure that out (it's not supposed to happen, as far as I know) I don't want to create a bigger mess by allowing multiple IDLEforks to run. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2003-04-12 18:01 Message: Logged In: YES user_id=679426 This better patch tries the ports at a random order, which is much faster when some IDLEfork instances are already running. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-02 22:55 Message: Logged In: YES user_id=149084 Converted Noam Raphael's file to a context patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=661363&group_id=9579 From kbk@users.sourceforge.net Sat May 17 04:51:59 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 16 May 2003 20:51:59 -0700 Subject: [Idle-dev] CVS: idle ParenMatch.py,1.6,1.7 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv24839 Modified Files: ParenMatch.py Log Message: Nigel Rowe's Patch [ 735527 ] Re Bug [ 678325 ] ParenMatching Missing AutoIndent AutoIndent was merged with EditorWindow, this patch corrects the references in ParenMatch. Index: ParenMatch.py =================================================================== RCS file: /cvsroot/idlefork/idle/ParenMatch.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** ParenMatch.py 17 Sep 2002 03:43:38 -0000 1.6 --- ParenMatch.py 17 May 2003 03:51:57 -0000 1.7 *************** *** 12,16 **** import PyParse ! from AutoIndent import AutoIndent, index2line from configHandler import idleConf --- 12,16 ---- import PyParse ! from EditorWindow import EditorWindow, index2line from configHandler import idleConf *************** *** 130,137 **** class LastOpenBracketFinder: ! num_context_lines = AutoIndent.num_context_lines ! indentwidth = AutoIndent.indentwidth ! tabwidth = AutoIndent.tabwidth ! context_use_ps1 = AutoIndent.context_use_ps1 def __init__(self, editwin): --- 130,137 ---- class LastOpenBracketFinder: ! num_context_lines = EditorWindow.num_context_lines ! indentwidth = EditorWindow.indentwidth ! tabwidth = EditorWindow.tabwidth ! context_use_ps1 = EditorWindow.context_use_ps1 def __init__(self, editwin): From noreply@sourceforge.net Sat May 17 04:52:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 16 May 2003 20:52:46 -0700 Subject: [Idle-dev] [ idlefork-Patches-735527 ] Re Bug [ 678325 ] ParenMatching Missing AutoIndent module Message-ID: Patches item #735527, was opened at 2003-05-09 20:14 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=735527&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nigel Rowe (fisheggs) >Assigned to: Kurt B. Kaiser (kbk) Summary: Re Bug [ 678325 ] ParenMatching Missing AutoIndent module Initial Comment: Re point of bug 678325. ParenMatch.py should be using EditorWindow, not AutoIndent ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:52 Message: Logged In: YES user_id=149084 Thanks for the Patch! We integrated AutoIndent into EditorWindow awhile back. ParenMatch.py Rev 1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=735527&group_id=9579 From jessw@netwood.net Sat May 17 07:25:05 2003 From: jessw@netwood.net (Jesse W) Date: Fri, 16 May 2003 23:25:05 -0700 Subject: [Idle-dev] IDLE application icon? In-Reply-To: Message-ID: <3EC57351.29569.1062A816@localhost> On 13 May 2003,, Tony Lownds wrote: > I'd like to add an icon for the IDLE application on Mac OS X. What do > you think of the attached? Was there ever an IDLE icon for Windows? Just for the Monty challenged(such as myself) among us, could someone send a quick sumery of "the foot reference" to the list? :-} Jesse W ---- http://netwood.net/usr/jessw This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford,California 94305, USA. From tony@lownds.com Sat May 17 10:04:32 2003 From: tony@lownds.com (Tony Lownds) Date: Sat, 17 May 2003 02:04:32 -0700 Subject: [Idle-dev] IDLE application icon? In-Reply-To: <3EC57351.29569.1062A816@localhost> References: <3EC57351.29569.1062A816@localhost> Message-ID: It was part of the title/intro sequence of the television show. A giant disembodied foot squashed a jumble of other animations with a farting sound to end the title sequence. I've attached another candidate icon, which incorporates the PC snake icon, and the hammer+sheets of paper just like the MacPython IDE and Apple's Project Builder. -Tony At 11:25 PM -0700 5/16/03, Jesse W wrote: >On 13 May 2003,, Tony Lownds wrote: >> I'd like to add an icon for the IDLE application on Mac OS X. What do >> you think of the attached? Was there ever an IDLE icon for Windows? >Just for the Monty challenged(such as myself) among us, could someone send a >quick sumery of "the foot reference" to the list? :-} > > Jesse W >---- >http://netwood.net/usr/jessw > >This work is licensed under the Creative Commons Attribution License. >To view a copy of this license, visit >http://creativecommons.org/licenses/by/1.0/ or send a letter to Creative >Commons, 559 Nathan Abbott Way, Stanford,California 94305, USA. > >_______________________________________________ >IDLE-dev mailing list >IDLE-dev@python.org >http://mail.python.org/mailman/listinfo/idle-dev From tony@lownds.com Sat May 17 10:11:25 2003 From: tony@lownds.com (Tony Lownds) Date: Sat, 17 May 2003 02:11:25 -0700 Subject: [Idle-dev] IDLE application icon? In-Reply-To: References: <3EC57351.29569.1062A816@localhost> Message-ID: --============_-1158959772==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I've attached another candidate icon This time I did. -Tony --============_-1158959772==_============ Content-Id: Content-Type: image/gif; name="idle_icon2.gif" ; x-mac-type="47494666" ; x-mac-creator="3842494D" Content-Disposition: attachment; filename="idle_icon2.gif" Content-Transfer-Encoding: base64 R0lGODlhgACAAPf/AP///zk5OUJCQkpKSmNjY3Nzc3t7e4SEhIyMjJSUlJycnLW1tb29 vcbGxt7e3ufn5+/v7/f39+/n59bOzufe3q2lpbWtrca9vZyUlKWcnIyEhFpSUlJCQiEY GDkpKf+1tf+trUoxMf+UlP+EhP97e/9jYxgICP9CQv8pKf8YGHMAAK0AAP8AAP9rY+cY ACkIANYpAEIpIXtjWufWzox7c4Rza2NSSko5MUIxKSkYEDkpIYRSOVJCOTEhGJxjQs6c e3tSOcZ7Sr1zQqVaKb1jKd7Gtd69pZx7Y2NKOaVrQsZzOa1jMb1rMa1aIVIhAIRaOc6E SsZ7QqVjMa1jKaVSELWMa96lc9aca86UY96MSrVzOaWclLWchGtaSko5Kd7WzpyUjLWl lJyMe97Grc6tjLWEUhAIALVaAIxzUr2ca/fnzsa9rUoxALWcWpRrACEYALWtlHNaAIxz AJyMMb21c6WcQlJKAPf375yclIyMhPf35+fn1u/v3r29refnztbWvd7evc7OnKWla729 e729c7W1a1paMaWlUr29WsbGWpSUQpycQpycOd7eSpSUKYSEGPf3KYSEEIyMEFJSCISE CP//CDExADk5AFpaAGNjAHNzAISEAIyMAJycAK2tAMbGAN7eAO/vAP//AJScGHuEANbe tc7WrXOMAHucAJStSik5AEJaAK3Ge2ulAGOcAHO1AIS1OZS9Woy9SlqlAFqtAK3ehFq1 CFKtAFK1AGO9IUq9AITOWs7exjGcADnGAN731jHeAJTOhDneECnWAGPnSiH3AHP3YwhK ABjnAIzvhBDvABD/AErWQkL3OQjWAAj3AOf/563OraXGpc73zr3vva33rYS9hJTWlHu1 e6X/pZz3nHPOc1q1Wnv3e2PeY2P/Y1L/Ukr/Sin3KQAYAAApAABCAABKAABjAAB7AACl AAC1AADOAADnAAD/AJSUnISEjFJStRgYWgAAhAAAnAAA/87G54RzrYR7lKWMxr21xoyE jK2EnM69xrWUpQAAAMDAwCH5BAEAAP8ALAAAAACAAIAAQAj/AP8JHEiwoMGDCBMqXMiw ocOHECNKRMigggIFFRhMeAABwgMHICFEGBmh40cHExxwJMmyJUsGCybKLLigQgIFFho4 EOlyZEePHHlGAADAZ8uiQ4kW9djA4gIGD3pKndrzQYKZEhVEjfCAgYUJRCdAIMogQc6x RSv4+9SInrxLovLQozfPTCZERCNMaKD3wQQGDaIWRUq1MFMLDyosWLxy5DsGWBNWAEvS QcadDhC3FAkBkCRSpDaJ3hSatOlNp1qRktOqmLpxl0SDJqWoD8p3FSo4WGBhQQLcCiYk XTphAm8FC7Zy5lzcQUmfDBRERrhAwVigQyMwQKAg+0gA2pq1/3uGrF07ZeaLOUPnrz25 VZ2KPRMX4VcxYOV9yTFNqlBPoUI9Z9RznEWA0hZIdCHGGiat5FFODcikQAIPKGXhAXxl RxQECuTBj3dqtMBCCi14Y8w3KH4zTXEjPfBLN77YosswusghR2mkHAKId1w1sEBTOXG0 EUlILdcRV365swEBN3TgZHsmmNABDyFUGYIOOlhggHQSVQSWhUQR0MBYXBmIgD5fUKUN OOaZp4sbN/LHxhuXZMKJbJs4MogDvBxCiWySFFLIIaFJYqRRP5Vk5E9AGbdBBhmEAcak NNQgwwY2bHBDDx50cIEBDzWlAJgAWBBcXtq9c89WJAmlhymwAP/jizLP6AJMO91Ukw1K E1yzzTbcBJtNNRKU1EBxE9jUgAI7+QTSssU1lVKBR/7kwA9EEDFFE1MMscQSO4gxoWLH NuDOAE52kMEGDwGmwAGkrlGKHndQ0A8CGvB05GbOFeiTvhBsRC2B1Sp6R4CMKlrwTw8Y oQQUUUQhhBZMSFGAOxZopBKj1lqwQQfnTtRAAwgsoFQEBhCgMgIGbPBOYBtxxCqB/1ab 6MI3L8qoAw0YYAC5jD7wxRVKREyxFks8UQByOsn8wNM7cczUbhZg1QADBVRQ0gMbdN31 ABswoJJfPCIKcEe7uaPAltXdFBVIPFdgAW4avXuRTn9hVAUREjP/oQXSS3TBnQIacRyU 1IgX59dV0/0THWIPNJBAAhm1qrBJXxmXgAEHMKBXzARLzQAEx7ozmUYLYFAGEVBgwYS2 TAghxQAGIPCOAu4kIBbivPeebEERzsQAAe84UNQDC2Qt3MA0H/5XRQdsDuHGUXs3Nhms Q8EEE1P4vYQPBmTQGwMw6dTUTRk3rv5AC5i+fFclR7Xc5RZY4M4BGC0wrUco+aZyAZw7 QBmYEIQrQIFi3VuCFtCwvgY6cCAWSABgjgUSzRGuIWLIQhawgEAi+K0GDwyhCB1YkQTo r2wg2QxyaoK7EYqwJmrLicCkYhJkpaR6hckhVUTyOxcS5CutKo5Q/5bCs2M9RX/JO8AG VHGJSxRAAJawhB04cQhTvO1kUhlMXhqjwxxCwAEH8OFAGOCOmO1GbIP5Tkq0GIE++MMS mMgEJlaBiTjK0Q6aGEUh/MCSfbnkZAH7i14gUJMxDYckE7BAvwbkLw5VLYTWGVBRGPCO BPxxEHKIQxxI4QZNYCIObtiEL4Ahh1u0YxnpKAc50NGmdpTDDJq4E2ko4QhBcAUC7nDH EWGYG40FxXIEC+bAOqK74EVmZBZAAP7QoqHEIKACAeJRCVLAAhWYwR9OOIUz2IEecPAC LB6hxibK44rRbEISphAJkGAitq3kxTi9mRBOyJexjbyjCwuYQQ2a5P+PKJlgA8EBCfIy BhmJLIB4pAJABiikRQA44B0auMBI7hABCqTgBFIBRDHa5As8hSY0c+ADRV3CkY0hqmYA WhTUUHI1mFTgAOjiABi6xoGaUskDOMVBBgoAkfMldEIiQcoC9OEOqrCplR3dRJziRIpT fHSpHyUFJfzzgD4sYxngKBa1AKaoy13OJAeQQRgq0I9+VOACF+DHQQugTAF0QAAeiNIA QqWAAjSAVBbYwx3u8IAxcOEd+diMYHliHI8Axh0Bw81euLiUrnKsj/+qoE0OkDkHFeFh UVACxb71BO70RnFByczHdOCPuUZkAQZIAJgmF5jI5QGIiUqjXiqAAMr/TSZRfcyZV3t3 M4Vd7gs/UELRtKDZii3tRyk5nNQ4gjVQzWRZFEIbApRpgAKoDEMhCSqiWCo3n5mlaTrr 7ReP9RXlPrYjRWCCcKPwt4oh4QAIyJhFGBa0+k4NAhUR3gQOwFbOlSUBB6id7nJrpCD9 pH7WjR7lJCi/BpT3sX3cCQMOwIWIBYG43vNBF95RW4zYl7eIW4wDk+ec2W4pQ5yJGoh5 65ePZORdBSBfcvog3DIEAXZIk0INcGITjFlgxY063zx92ICZ6u54qFXkSecH4o94ZLHe +eIFyqAELLjOg0ibAhhqIreCilGMMAmaXypiE85xOAEsq2T9KqA2ekKG/wFJUEIBoaCE 121PCmjw8pf3zJCYrM8CWzgCl/hM6EJT5yJeuQjlNBK5Rxr60X22iFk0MsP/dARZAj0S Uh7gDkg/0AI2QU5yo8y/TJ8kudHs4n/w4GmKmIpy+qNAqltlErip5I89IYyqVV0BPieg WbquWWNIZazc2O8yPNkQSsYXgaeIJSllU/WsBUQSs+y5OyXJzJiORzrnWIgrDlCAP0jx CVCswgyeAIW6N/GGTBziL34pDlKI8hG/5EYx+jPpDv8jFVN9GSYtKgtf5u2TMRnHKwZY CyTgEQ9ViCIR8GC4PzChiDXjWyPB1uHxPlIdmHzWnQCi9gQY92n3adcB0f9xx8w2U5NU UEITMIf5JmKuiaeS4he/cIQjJPGIQLToWCNXTG4IJzdjw/pxCjgWqxqrL0ZyRYIP/LVP hGq6ybSkK4MgxSXssAlOZKJOpLHRJmZxCznooh2jbOUxYClLqa7BL7wBtdy9YruMtFQs qFqyb7caAaaR0GQ++chf3IEAyrCkG+bpKDKGQYphIIMUZzcPO8bhj3E4AxibcI0/0lGM U+zno5sQxAFMp0h5e1HvTBYm6fRnzGNOeCvevuV0ZwYAsVVDG2QIhBVgcAY5sOGa/ngB Jq7qi29QIzPYAIat0G6j1eToAoLpIwCidbWjKMo4P+oZD3rghS7IYFMH+FH/s76YdD23 i3x2S8pZAOAXpEwAARiggEskMAIWuEAOaG/FM5YhjmUkI3ILgAB9UAFwwAzmMQuhVBqU 8Ag0UEYKUxyekxFkJIF1FRxfVGLGIgNdEAM9wAEbEAAhEFdRkgM9UIIxQAB54BUScT9a k1AHIBgWwgAasA8kgQIlAAIXNRV3QA1lUAa5YB7KMAvOZxqH8AckMVIFkne0llJfJXhk ljsHQAAiuAEyUFM3cAMhgAM44AExsAXO1RAIZzKkwh0wSBQVoA9ggIFSUQqu4Aqq4QuM 5wazoVSkgAmDQAGAYAp9AAd9UBY2sQV72Adp0hGA4Aik4FuoV19QA4EVMAA0/7APNWAp lzIAAsADN7CFHjABBRBGDEE+RUUqGzBgeQEA+lAy0xYBhBIas8B8+1FzpCFzeKIJgPII oBcaNrIfgrAH80MzNqN6aKMBGtAb9WMBkLIP+5ABGvCBMoADOWAGYPCFCtEUFfBTo1MU zvEb+KCGLBEew+AL3ogevnAL4iiOjBAL4CAMZDeO4qgIbXAIfQBq+LYxw0RtaPNsNtMR EgAHTUAF3CIFQoBWFzBU3CF0BNABIPgGAfAQqDWNpGI8I5GPCXAP2shv3xFuaGYWQmQg TyF0AVYBShdyieSRzYJSAoI591YFwsU9U7CS38NW85RcXfFEJtADZmBaDdEUBv+AFicz BnqgBnoACGmAAEUFWZZTIA8gQ43RdAvzVTYTOSOzAFHjIEOhUsEFBUHAXtuzBDIAaxT0 NIzSMwFgAjkQAhABGLUFJhFgAfmwEROgADRwAUMUZbWnhn6xE4TnDmLDIhQVXr2oWzgT NGRQNFfJXlowBBcjQ2PDOyPnD2TZJQ0wet/GObnBHZS1ESalhEWZMIeCOApzML3jWAwD XHyTWUcjBWzTlbxjahbAUzIxMgfwJSOBABtQAAWwAQKwAYqUaZBVMEQCgYn0Y+HlmTmD W0wpNFgwXH6DNDLAOWz1DsDJKBJgOJe2ESrYmjchXQGmMl0jJjBJEl3hFRR0a0v/WDPZ Vj+Tphh7ARgzwxTkAxOBqQQTQzHudQCKJY8eIZ0msTMCUxOtWQExVnsJsCQEIKCTIVu3 xkMasSw1sRNP8UvLNib2g5cfWRJiEUHRsQAdcQd7gAWjeTRLIAVIQAAK8A6j9xU/EZ28 ExSHw2nmJxFXsxdN4Zx5Mzn6QxgQcDDPARUOoDaK0yIbmQAOVj8+IjBoswBq1nGElADH GQWuwz1M8KE2wFaTAWpjslz5eZ9YuqKDpj5GajxdQaJQWZIJsxhjw5S9U0FxJ5TksgAZ oAWsc2XeMwQyED2MBmQs1j+442iNswAbgKHsRzIGkBxmY6a8wxXpGUH4Uz91pUsB/+MA lxUEV/k6RJAESzAEHNCRRLpceGo6fmZoj0kA9jhynTOP4yVBv5F0lYY4nJYb+KMx2IIF VJYtfwMuBACPbDZkrdYQFiAAoMocE+I5Relbwvk0PqIAJeMVi/EXvEFbBoAG6mVAStA9 SDMEaKCnuRoZKhc375AS9OhkQcMzEZQyKkMA3IExcoMABAAERKAEBrQ9K8kESeADLXqt DYQ7tkV4HYYR9fMU5WIT1koQwoUFBoRA3eMDR0CvhuYOO5EsuiQTqqMERKAFQhAFYoCw FnuxGJux9UMQLNRpGfuxAlERGFNijRogVgGy11odiPZsGRcwOxM3jOZgKBtCHeuRyf8V EoPFPzfERf+xpTNblqZyEfrDRRc4kluDEgK1crsWbj+bEB37FeK5GaVma9m1a6qWPiBb EbiTEZVmaV+ELL9ktWK7GSTnaTVxE0OraS7BME8TtmWja6NojUo7tj0hs19mPy/pRwQm M/uiFCLBMxupNd9xMs6hOQTVTnNLt0WJAPP6QMwitUARVBbyZFejTAdACZ3wCBCwBXdC CpGQThuxGIExHFiEa9JGbT3hG/+2AN55QkUSgEIrFhUCAGphBrbbHrY7DmZwCaFxCEph HIY3uCxhb72RITrUdIIVm53qQgnAHA06SUkxZhnTPvWzFpWQCAHwBqIACYiQCIbgD5n/ kAoeQbrT95uFMySHNLbWCLjPphcIcLfC0SNf8W0NhSQOUABrkQh0ARf3MBd1kQl1kA+m IjejFm1iCzfV0RtywxI2GgG58WXQhKfbpiEAMDL8MxYW4A+eUAmVYAdmEAocXAmcMHGH ULWle3ojYSoH0KrNkR0IQzME8hguxGbCQW9e4ZAaMr4GMgFgcARmQHnguwnA5w+X0Amc ABqmEAGAsMSAIAH1a6hX0zaAkTdXMybSK7stpncDUhYPJDdGaxz6qhkMTBKBQAeEEAld xwlqLBpqrMZiZyPG4A2XEAd3wgiDQAdwYEJa+5o3ARhsJrr6MySAJD+MRKrI8WlC8TQA /xAwFVA8hFG+geAIagwaXedRq2EjuvB4p0Ar7bAOx/AGsUQakcAIfwABAFZG5JMsJXM1 H1E+NeFsvTUgPoGiI+EAjOtAGdMizvI0i7EZDzAImmAGqqDGduAPU0Qaq3Erp2BKrWQe 5vACsUTJkgAHiiFflMPI4SdjFkE+hCzLMMx3AfMVjSsTVje4DrUdCJBqtTALtIAKm+CG ndAKriAHw9AOuHArznAMlYcOwKAM7JAO53AMzccfqbAbPgITgToyI6lrpMqLwlQSmdNA AMd+CwsSyQSs3/EAxmAe5GEe5dEOyIAe6HAO5RB8mIAMy+AL3bAN6WAewzDPQ1gIK8FG a/97Ug79ExSwBdCnmX97OuuzAC+4yMZTFA72DngwUiSxANQgDr6wycpwCsjwDKhwCUA8 DuvQUcMQDh2xBkq1ivqBJ/5BQ5URv8zjwol0AEDQBU+Q1uLDG8uDX0/ROMgUY0QyHMa6 AMXSKiXGfkLAAiywAu3xBu/xCsXAf9KAEgxwDehxHrRwI6DxCHQgu8dCZqMTMDNdQ4tx trpkHAKwT2LpBTpgAh5QeF7ZERL4XF5xZn9RwyIhM9uRAbOmBiSQAvdnB6qADr0ADPxn DMZQDTvhYNbADLoQjs0HGpTQB8nBrdD2OZJDozwDFRVcP8k1AUwSA2IwA1+wAf7QAT3Q jGb/0AMhYAPB8RjjnBARFF9gwiEV8kUufCYf0hLTxAJQfR4b9Q3XYA0bkQ/6EwtMwAjl IYRMtQmK8AfQV8tlkTlDkUi4kxLtm1IBowAb0AVIYALtsd0U7g85wANU4gUxcAM7VrYN kRt31ZA/Vr8WoAFrwBL1xwIlYBgRUAut5AqhxB8htbbSLRw8S57DOWZ1Na4D4AH9ZAIc MACWmIUhqANrQKLtEoVfAiZiopNFMQH6oAF5jQIiEAEXlXEjUQ3E0IZwSCMDHRqLsCMl yW+7SJ6gKXhRDGr38zH+YAM0YANWCIJbiAM6UAHQqBAMUF3kWxSiqBQPcCb7UCzFcgcg 8AEt/zEDbdAGddAK5QEMnlfcXUcHuvgvW2MctVcBXBQIbUBglm4kp4YsCOcBG7AFloIp VngDHqADOIUArLkQJZRQ72AA3qYUDaAP9xC/UzENtPIMz5BUp9F1mOAPkyAJkUAJyC4I ziYBLhcJnCC+EfAFjhAJkkCPw8SXi3hQYICMGkADBSADMiDnAnCJHtADmniToJZQA4AA FeIdGlB4VEEMyoAMIc18wU4Kb/AGk8wfoMEFikAJtbgfohEJhyCmvJh6hhNuWbMG/ZAB +7AFYKAPNEADkQIGPDCTOZDnCGEuFpBQpkImRVGK0DQVu6AL4nh2vpCAeNJ1A+1RfyIa kE0Hqf+gC7qAC4IACDh6NqDpi09GAH2wD2uQ2WsgjAJK4SHQAyZwUGCIACO+Wt72ERSA hhNJEuHQzM8Qh7doI7OADAiY9bcYGoIwdApgDdgQDTfaSHyXmUbiAFUwBE0gBnBQExZw AV+QAeR6EwgQAAYZ2gnZiWUx1BZiEe2eFghgD/XQExRFDZKwH2bXSs8wHqUwFN/g649v HuKQBypBpmjDzXqbHTC6GCsMmj8xAdHKklOgBUlQBckCBpwKEwQAVzhgAioDhnOTUCM/ EnywBghwD/tWC+AQDuHADHMgC+DwCzDBXwegD4qhO/WWN7XlDkCHGV1hrMiRG8azL2e+ NQyAYdv/0o+BYwD6wDQMflBxZe42uRA9YwAJ1QB7JQESQAZggAD5gLze3Lql5xdMMSEL Bf0QCBAQIgyEUDCCQAgPBi5ESDDhhAkMKhgwoKDBhCBKomhhwmTKlCUFECiwsACigwcQ Jrzb4EGHmQH/ZM6kSZNBgwMIAOzkeWfPHaClBOmrQHBhhDsCjw50IPFdBQYTGh5FaLDh VYcQHDjQaiABRKlUH6yZogRKFCUcmfh4pwDqxQcp5TIgEKJDjgA19dJswKAiT55kZujR MyNNHgR3GC5eqHhg2MVKD06uarRqwgQNuFa+XLDggyJllGCJEqVjEx95FCyAG9dzwQkW BHRYkHfv/+0GCwwsAAxgzRoKQCeAoeHA8VKkEBY4QE7QgYUJ7hoofE354Gvs1bO/fvAF i8aNWrQsAZKggklerrHHXUCgg4ENt+VLNDChd4UKE1IyeGeB+WQAIgiQqQccWICBBRJw ZwEIoqIgJYY4u+467CbcjrsvoDArPC2mAOKpqFBK6cIHLAjBA/lSbECBAx4ALIED8lPO HenkUmjAgR6AKK6lLqPMx+0OSsozCov8DBANSxNvvCfcgWoClC58bYIKEkhRRQsO4ElA Ago4gKIECnBHP/1GdOjHyayzisjO2iTyoAk0W68IJTRKq6MlnjAvxBG5i/NA/RyYwMor 5Wsgy50GQv+AgAE2eIeADQpgYKut2PzxKqWU6nNNKT27Sc5NtaLTTrV8kCEBQKMiETvN HiC0UL1u6o8gVw94pwBICRhTR64EpMwxlR7oy4IFF6hgQeowtSoC9TjtjAIywOPQB0a7 NG/TULEt81VY+WIAgQWYdQCBA77EdQMDoorLxZ0eMMkC8yqwgIFJIUTzzYN0LMmk3Caw 0ChB+UmjTiHSGg+IDSCVbrr1uHMYooK47Vam3ApoICEHzt1ggwEIgGuroyDqscIIBHV3 AgUSMAABd6DbLKEDS84N3AoUoHeCPoIgIjwmtJBCigLOg3KzEYv2LNSHuHJ14poaQKAA fyPYeONGCaj/gGiCAlw2Aiihq1UBklQtWaUFLKjygD0bcCeq3LKctC8j6uR5PB82QCBe iLPtFDYGFFiQaW+t7dIvA7o8YMwtmTUzziwtYFgrQRmA94ACEmAuSqoSutighXT8QaMg 1GIy0gIKUADKTpHmTgHA92rg2LPLNvadBBJggN2sDDKJa9ptzeAm6j5l4KtD/eVOx+gq F9aCjKAIoqOel9jBcLdK2vt6lFvXqy96GShgOQNrhy7C6qhc7iAHclPOgMr53M6BKqE7 cIH94NDCrCCmIGIK8Z4gwAD8CEoqCfnM9bZjAe2lCF7MoRLtGCCQIV3lAfRKwDsQIKdM dYo50yEWgmon/xEuEAEKZ/FI9HxQOjCZxIDX05E7Engb3TAHAg1Q2fjOdDwKrbApVOKe BVbjgJRVQYRYEML+eiYFHyTAcfoJ1gqPlj54OWkBL0xRe8LiLq8wwDJayaETPzO8lt1E XhAgAAEmMLARaoEIROjZFKhluKcMkESR8xtJAMcAKrZHATKkEgHOp6bUaUV+LJOXDw9g gSX+ByHfKYNp9seRKcgAAUtcV9GgqKDzUFGTM/Ee1HKEk8xY5lITSBBJbIdIk2wmh485 kOSgo4UoYIEjazxiFwyANiclAAEjQeAmfbkX/mzAP+izwG4UAkgI7Gs65AsSyhi2ECMw AQqkKeF4ksAaif/gZ4q/5KZ83DGAAxhPJW2JmrM6VTJSVmBF/SlI5MpWBSYEAQsaYqM1 81CSbubzSgzY2O2YsgAEPNBCVXlAPlhzHoAeLk5DSwgDDlDGhNGgiFigJp6kkAQa6FOj sELQZ1b0x6lcByJ8iougEoSrW94tZQZAw/2u8B0l7G8JS/ABGDZ60yv5zTzG2txnBHUR lDAuZbjKFdpqlgAWyWsBeVgCEShqGo8sYS1iwGlVu6WAAv3pWOSyoIIyUMh9wasCezmC WV6qhI6AZAlJsKlV3TqxlCm1lWBZgDtQdaUhkgatINFCEsb6VsAWqm9QigsplQg4GlhB lh/pCBq2GVjIyscchzTCIxUtcISyRGEJlY1sZz372ZpwFrSj1WhAAAA7 --============_-1158959772==_============-- From michael.williams@st-annes.oxford.ac.uk Sat May 17 10:55:43 2003 From: michael.williams@st-annes.oxford.ac.uk (Michael Williams) Date: Sat, 17 May 2003 10:55:43 +0100 Subject: [Idle-dev] IDLE application icon? In-Reply-To: Message-ID: On Saturday, May 17, 2003, at 10:11 am, Tony Lownds wrote: >> I've attached another candidate icon > > This time I did. > > -Tony This looks great to me! -- Michael From noreply@sourceforge.net Sat May 17 14:26:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 06:26:59 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@shore.net Sat May 17 15:12:21 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 17 May 2003 10:12:21 -0400 Subject: [Idle-dev] IDLE application icon? In-Reply-To: (Tony Lownds's message of "Sat, 17 May 2003 02:11:25 -0700") References: <3EC57351.29569.1062A816@localhost> Message-ID: Tony Lownds writes: >>I've attached another candidate icon Yeah, go for it. From noreply@sourceforge.net Sat May 17 16:05:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 08:05:15 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed >Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From tonylownds@users.sourceforge.net Sat May 17 16:14:12 2003 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sat, 17 May 2003 08:14:12 -0700 Subject: [Idle-dev] CVS: idle buildapp.py,1.1,1.2 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv16166 Modified Files: buildapp.py Log Message: Added icon for IDLE on OS X Index: buildapp.py =================================================================== RCS file: /cvsroot/idlefork/idle/buildapp.py,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** buildapp.py 13 May 2003 15:28:21 -0000 1.1 --- buildapp.py 17 May 2003 15:14:10 -0000 1.2 *************** *** 14,16 **** --- 14,17 ---- mainprogram="idle.py", argv_emulation=1, + iconfile="Icons/idle.icns", ) From tonylownds@users.sourceforge.net Sat May 17 16:14:12 2003 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sat, 17 May 2003 08:14:12 -0700 Subject: [Idle-dev] CVS: idle/Icons idle.icns,NONE,1.1 Message-ID: Update of /cvsroot/idlefork/idle/Icons In directory sc8-pr-cvs1:/tmp/cvs-serv16166/Icons Added Files: idle.icns Log Message: Added icon for IDLE on OS X --- NEW FILE: idle.icns --- icns ƵE ysC ؛N| A9C ޔ Ƶ! Ƚ^ ƽւ ｄ ֔Ƶsֆ B瀵ֵε {s[ wwoyR ssk΂ ޹ｄ ֔c{gcsΆ B95 ==5uR 991΂ ޹ｌ ֜)B-1sΆ ˷ ӾԾijǶ˸м Կ ֶ ´ 鸱Ŵϸ Ϻɡ㿣 忲#ɴյ0ɩزߢ Ŀ~䵲.˷մu^+J;tC40Wܒ' c˻Ư騹 «r ٟΰ滯̦  Gq*̾ (knīMG;MĘƸiN:Z!.%4D]ЏץӌQ  )UFCED=:ύ­ ڰǁ ?[R碇 3҃35 J2 Í2HHIQVտqӺ㼛ŷw|z33^Nԟڷ~׭㰣ĸwԕS4W 洫¢Ѻ)Ⱦ{ƾzޣi17YÃب 7ˁ$鸊¶Ŀ}05!Ê٣ƿv켁Ӆ鵙 !üШőy!ƿ㱇ֆpqyq+Żɳx^ib\ 廊ظdzʼu ̸ ɓ| ޻؟Ļٝº ɵפy$ۥwĻ oz&ᾙţniƿkaw ҽ jȌ~)ɽx»[}} Ϲ ض ԽаȺúⰰⱻƹ ˷ Ӿ Ծij!Ƕ˸ м Ծ ֶ ´ 鸱 Ŵϸ Ϻɡ㿣忲#ɴյ0ɩزߢ Ŀ~䵲.˷մu^+J;tC40Wܒ' c˻Ư騹 «r ٟΰ滯̥ ے.~~|>|߲͑ȴ ѥ ̖~/xrt䅏Jw񑋟ɾЦۿǶ xGRg?dyu{tځO (穋h н⽺ʹ}y5ۼѫ؜U^D   E<61&;zȎØ*񛍲q jǨҶtuƧ!ЗSf= B4232*%ύ­ ٰ ̔ z߀3гȺЦ¡ɞãkk_^`]cdYմa'qӌ 罍{3蔺迳qӺ㼛vok_^\^`g^zz3!^窒߅Nԟڷ~׭㰣owlbb`_acwԕS" W 쫕紫âѺ)Ⱦ{Ӂ}pli__`qޣi1)Yà Ɯ̹ƜҐ4ڤquume`cp/'Oŏ ӝݼ 7ˁ$깉¶ъq|uvqdP05!Ê٣۩n{vsrl^s켁Ӆ鶙 !˃u{qqmgdШőy!֣o|{spojft㱇ֆpqyq !~֚nypmngZo߻ܒϋkFTiNpy{~wqpke_νօ᳒]vuO@Y ͭ!Ґvyqpoid}qݑ*锄t]\^ľ u}zrml_lOhr贑(⎉ztl_~y ԭut{}wpkdNؑ)⏴މ|rdVvѩ)׮ƹʒrxwwrlhRZgZ贑"߉|naWNq㾺.۬Źÿ¹r|wsqmicD~֑S|tfYSOKfԞ~活Ƕ˶q}ppnhf`s᳑S\UTRNOZⲚ|åӟֻh{woomed_βQ|YUTNNV^ݮ㒇մǘƺtv|rooke`UցٸSuWf`Xcnܼο˯魗nxopngaQeVzxnvwyhq~׿ҿwפspookdZWrxp鱖/w{误yh˱񿂚|yvlmlh`\乷ʐýűˠw°v|llkldVbn 廊ظdzvopdfpi]f ̸ ɓ|#޻؟Ļٝiwidkn^i ɵפyۥwzz~legpdaw oz+ྙţnițurgdmm^fiaw ҽ jȌ~5ɽxwuiehodYK}} Ϲ utngffhy ɚ'ξζvmz}pt}{ogdfhe3ơȭ|ibcilNnxslcdgfs2űƲvbfWj~Łko{qidfhg(վy}}ttngfjfyºԄ {{ogdffnűݷɾ߆ u|rlcdgeŖ̸ r~{pidfgq ޔҹ uieekl ط redjo|ѱ‡xejurⰰluq ˷ ӾԾijǶ&˸ м Կ ֶ ´鸱 Ŵϸ Ϻɡ㿣忲#ɴյ Pܒ «#r ٟΰ滯̑` (knĬB ;76.2tȎØq b cbaa ://11'ύ­ڱ V_B@831-+'(tЄqˊ-;I  V [ă یH g 8 W鎍Ӄ洬âѺ)Ⱦ{LAF641*,2qޣi1"Yà 訁 7ˁ%금¶N4K@=?9/:05!Ê٣م'CF==942s켁Ӆ鶙 3;Wrxp鱖/w{鯮yh˱񿂀=@O<44575R乷ʐĽıˠw¦N7UE221759bn˙ п7ݝ常ʬǵߴk.HU6-,296LvϭŔ䴙 ֳ7Щƴyyۨʷ;7WH,,-96:h|촚 ϲƔ̷}ΝͼӴT&NV4),4<0Iyѕ֙ ֦徽Ლ%DYG-+/82Ertx~˓ 廊ظdz@-UT5*.95-\ ̸ ɓ|!޻؟Ļٝo%KWB.+2:/G ɵפy ҽ jȌ~)ɽxܴ4GK?/)/=/(A}} Ϲ Hb[=2+-5; ط qf<,,3:Xѱ_<'4B?ⰰ|0.AD From noreply@sourceforge.net Sat May 17 18:54:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 10:54:53 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sat May 17 18:59:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 10:59:29 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sat May 17 19:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 11:12:57 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739203 ] Default help includes "Visual" Message-ID: Bugs item #739203, was opened at 2003-05-17 18:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Default help includes "Visual" Initial Comment: On Windows at least, the default help lists "Visual" with a link to the same place as the Python help (namely C:\Python23\Doc\index.html). Since most people presumably don't have the Visual module installed, it seems inappropriate to have "Visual" in the list (and for current and future distributions of Visual the documentation is in site-packages/visual/docs). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 From noreply@sourceforge.net Sat May 17 21:24:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 13:24:17 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739203 ] Default help includes "Visual" Message-ID: Bugs item #739203, was opened at 2003-05-17 13:12 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Default help includes "Visual" Initial Comment: On Windows at least, the default help lists "Visual" with a link to the same place as the Python help (namely C:\Python23\Doc\index.html). Since most people presumably don't have the Visual module installed, it seems inappropriate to have "Visual" in the list (and for current and future distributions of Visual the documentation is in site-packages/visual/docs). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:24 Message: Logged In: YES user_id=149084 I believe you will find that this is because "Visual" is in the [HelpFiles] section of your .idlerc/config-main.cfg Personalized configuration is not lost on upgrade or re-installation. The [HelpFiles] section of config-main.def is empty in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 From kbk@users.sourceforge.net Sat May 17 22:04:13 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 17 May 2003 14:04:13 -0700 Subject: [Idle-dev] CVS: idle run.py,1.17,1.18 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv24334 Modified Files: run.py Log Message: Show Freddy the mirror i.e. improve subprocess exit paths and exeception reporting Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** run.py 14 May 2003 18:15:40 -0000 1.17 --- run.py 17 May 2003 21:04:10 -0000 1.18 *************** *** 54,58 **** try: if exit_requested: ! os._exit(0) try: seq, request = rpc.request_queue.get(0) --- 54,58 ---- try: if exit_requested: ! sys.exit(0) try: seq, request = rpc.request_queue.get(0) *************** *** 65,71 **** except KeyboardInterrupt: continue except: ! print_exception() ! rpc.response_queue.put((seq, None)) continue --- 65,77 ---- except KeyboardInterrupt: continue + except SystemExit: + raise except: ! try: ! print_exception() ! rpc.response_queue.put((seq, None)) ! except: ! traceback.print_exc(file=sys.__stderr__) ! sys.exit(1.1) continue *************** *** 208,218 **** exec code in self.locals except: try: ! if exit_requested: ! os._exit(0) print_exception() except: ! sys.stderr = sys.__stderr__ ! raise else: flush_stdout() --- 214,226 ---- exec code in self.locals except: + if exit_requested: + sys.exit(0) try: ! # even print a user code SystemExit exception, continue print_exception() except: ! # link not working? ! traceback.print_exc(file=sys.__stderr__) ! sys.exit(1.2) else: flush_stdout() From noreply@sourceforge.net Sat May 17 22:15:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 14:15:26 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sat May 17 23:49:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 15:49:59 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 02:17:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 18:17:01 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 01:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 21:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Sun May 18 03:21:57 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 17 May 2003 19:21:57 -0700 Subject: [Idle-dev] CVS: idle config-extensions.def,1.10,1.11 config-highlight.def,1.6,1.7 config-keys.def,1.18,1.19 config-main.def,1.14,1.15 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2222 Modified Files: config-extensions.def config-highlight.def config-keys.def config-main.def Log Message: Whitespace Normalization Modified Files: config-extensions.def config-highlight.def config-keys.def config-main.def Index: config-extensions.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-extensions.def,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** config-extensions.def 26 Jan 2003 04:17:16 -0000 1.10 --- config-extensions.def 18 May 2003 02:21:55 -0000 1.11 *************** *** 1,4 **** ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle extensions settings. # # Each extension must have at least one section, named after the extension --- 1,4 ---- ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle extensions settings. # # Each extension must have at least one section, named after the extension Index: config-highlight.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-highlight.def,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** config-highlight.def 20 Jun 2002 04:01:47 -0000 1.6 --- config-highlight.def 18 May 2003 02:21:55 -0000 1.7 *************** *** 1,4 **** ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle highlight theme settings. [IDLE Classic] --- 1,4 ---- ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle highlight theme settings. [IDLE Classic] *************** *** 21,25 **** error-foreground= #000000 error-background= #ff7777 ! #cursor (only foreground can be set) cursor-foreground= black #shell window --- 21,25 ---- error-foreground= #000000 error-background= #ff7777 ! #cursor (only foreground can be set) cursor-foreground= black #shell window *************** *** 50,54 **** error-foreground= #000000 error-background= #ff7777 ! #cursor (only foreground can be set) cursor-foreground= black #shell window --- 50,54 ---- error-foreground= #000000 error-background= #ff7777 ! #cursor (only foreground can be set) cursor-foreground= black #shell window Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.18 retrieving revision 1.19 diff -C2 -r1.18 -r1.19 *** config-keys.def 22 Jan 2003 00:23:23 -0000 1.18 --- config-keys.def 18 May 2003 02:21:55 -0000 1.19 *************** *** 1,4 **** ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle key binding settings. # Where multiple keys are specified for an action: if they are separated # by a space (eg. action= ) then the keys are altenatives, if --- 1,4 ---- ! # IDLE reads several config files to determine user preferences. This ! # file is the default config file for idle key binding settings. # Where multiple keys are specified for an action: if they are separated # by a space (eg. action= ) then the keys are altenatives, if *************** *** 19,23 **** end-of-file= python-docs= ! python-context-help= history-next= history-previous= --- 19,23 ---- end-of-file= python-docs= ! python-context-help= history-next= history-previous= *************** *** 78,83 **** plain-newline-and-indent= print-window= ! python-docs= ! python-context-help= redo= remove-selection= --- 78,83 ---- plain-newline-and-indent= print-window= ! python-docs= ! python-context-help= redo= remove-selection= *************** *** 117,121 **** end-of-file= python-docs= ! python-context-help= history-next= history-previous= --- 117,121 ---- end-of-file= python-docs= ! python-context-help= history-next= history-previous= *************** *** 129,133 **** plain-newline-and-indent= print-window= ! redo= remove-selection= save-window-as-file= --- 129,133 ---- plain-newline-and-indent= print-window= ! redo= remove-selection= save-window-as-file= Index: config-main.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-main.def,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** config-main.def 10 May 2003 00:49:56 -0000 1.14 --- config-main.def 18 May 2003 02:21:55 -0000 1.15 *************** *** 1,5 **** ! # IDLE reads several config files to determine user preferences. This # file is the default config file for general idle settings. ! # # When IDLE starts, it will look in # the following two sets of files, in order: --- 1,5 ---- ! # IDLE reads several config files to determine user preferences. This # file is the default config file for general idle settings. ! # # When IDLE starts, it will look in # the following two sets of files, in order: *************** *** 20,34 **** # # Any options the user saves through the config dialog will be saved to ! # the relevant user config file. Reverting any general setting to the ! # default causes that entry to be wiped from the user file and re-read # from the default file. User highlighting themes or keybinding sets are # retained unless specifically deleted within the config dialog. Choosing ! # one of the default themes or keysets just applies the relevant settings ! # from the default file. # # Additional help sources are listed in the [HelpFiles] section and must be # viewable by a web browser (or the Windows Help viewer in the case of .chm ! # files). These sources will be listed on the Help menu. The pattern is ! # # You can't use a semi-colon in a menu item or path. The path will be platform # specific because of path separators, drive specs etc. --- 20,34 ---- # # Any options the user saves through the config dialog will be saved to ! # the relevant user config file. Reverting any general setting to the ! # default causes that entry to be wiped from the user file and re-read # from the default file. User highlighting themes or keybinding sets are # retained unless specifically deleted within the config dialog. Choosing ! # one of the default themes or keysets just applies the relevant settings ! # from the default file. # # Additional help sources are listed in the [HelpFiles] section and must be # viewable by a web browser (or the Windows Help viewer in the case of .chm ! # files). These sources will be listed on the Help menu. The pattern is ! # # You can't use a semi-colon in a menu item or path. The path will be platform # specific because of path separators, drive specs etc. *************** *** 57,65 **** [Theme] ! default= 1 name= IDLE Classic [Keys] ! default= 1 name= IDLE Classic Windows --- 57,65 ---- [Theme] ! default= 1 name= IDLE Classic [Keys] ! default= 1 name= IDLE Classic Windows From kbk@users.sourceforge.net Sun May 18 03:24:35 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 17 May 2003 19:24:35 -0700 Subject: [Idle-dev] CVS: idle IOBinding.py,1.15,1.16 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv3134 Modified Files: IOBinding.py Log Message: Whitespace Normalization Index: IOBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/IOBinding.py,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** IOBinding.py 10 May 2003 00:49:56 -0000 1.15 --- IOBinding.py 18 May 2003 02:24:32 -0000 1.16 *************** *** 74,78 **** def __init__(self, master, enc): self.should_edit = False ! self.root = top = Toplevel(master) top.bind("", self.return_event) --- 74,78 ---- def __init__(self, master, enc): self.should_edit = False ! self.root = top = Toplevel(master) top.bind("", self.return_event) *************** *** 107,111 **** command=self.do_edit) b2.pack(side=LEFT, fill=BOTH, expand=1) ! self._set_transient(master) --- 107,111 ---- command=self.do_edit) b2.pack(side=LEFT, fill=BOTH, expand=1) ! self._set_transient(master) *************** *** 417,449 **** # Nothing was declared, and we had not determined an encoding # on loading. Recommend an encoding line. ! config_encoding = idleConf.GetOption("main","EditorWindow", ! "encoding") ! if config_encoding == 'utf-8': ! # User has requested that we save files as UTF-8 ! return BOM_UTF8 + chars.encode("utf-8") ! ask_user = True ! try: ! chars = chars.encode(encoding) ! enc = encoding ! if config_encoding == 'locale': ask_user = False ! except UnicodeError: ! chars = BOM_UTF8 + chars.encode("utf-8") ! enc = "utf-8" ! if not ask_user: return chars ! dialog = EncodingMessage(self.editwin.top, enc) ! dialog.go() ! if dialog.num == 1: ! # User asked us to edit the file ! encline = "# -*- coding: %s -*-\n" % enc ! firstline = self.text.get("1.0", "2.0") ! if firstline.startswith("#!"): ! # Insert encoding after #! line ! self.text.insert("2.0", encline) ! else: ! self.text.insert("1.0", encline) ! return self.encode(self.text.get("1.0", "end-1c")) ! return chars def fixlastline(self): --- 417,449 ---- # Nothing was declared, and we had not determined an encoding # on loading. Recommend an encoding line. ! config_encoding = idleConf.GetOption("main","EditorWindow", ! "encoding") ! if config_encoding == 'utf-8': ! # User has requested that we save files as UTF-8 ! return BOM_UTF8 + chars.encode("utf-8") ! ask_user = True ! try: ! chars = chars.encode(encoding) ! enc = encoding ! if config_encoding == 'locale': ask_user = False ! except UnicodeError: ! chars = BOM_UTF8 + chars.encode("utf-8") ! enc = "utf-8" ! if not ask_user: return chars ! dialog = EncodingMessage(self.editwin.top, enc) ! dialog.go() ! if dialog.num == 1: ! # User asked us to edit the file ! encline = "# -*- coding: %s -*-\n" % enc ! firstline = self.text.get("1.0", "2.0") ! if firstline.startswith("#!"): ! # Insert encoding after #! line ! self.text.insert("2.0", encline) ! else: ! self.text.insert("1.0", encline) ! return self.encode(self.text.get("1.0", "end-1c")) ! return chars def fixlastline(self): From noreply@sourceforge.net Sun May 18 04:17:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 17 May 2003 20:17:57 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 16:40:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 08:40:54 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 01:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 21:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 19:52:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 11:52:36 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 21:34:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:34:19 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 20:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 18:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 01:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 21:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 21:35:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 13:35:25 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 04:02 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 20:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 20:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 18:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 01:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 21:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 17:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 22:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 21:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 03:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 05:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 23:08:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 15:08:48 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 00:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Sun May 18 23:19:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 15:19:39 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-19 00:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Mon May 19 02:09:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 18:09:38 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 17:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 13:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 10:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Mon May 19 02:35:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 18:35:10 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 17:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 13:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 10:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Mon May 19 03:07:47 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 18 May 2003 19:07:47 -0700 Subject: [Idle-dev] CVS: idle idle,1.10,1.11 idle.py,1.8,1.9 idle.pyw,1.7,1.8 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv17358 Modified Files: idle idle.py idle.pyw Log Message: Let Python inform the user what went wrong with the import. Modified Files: idle idle.py idle.pyw Index: idle =================================================================== RCS file: /cvsroot/idlefork/idle/idle,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** idle 17 May 2003 03:15:48 -0000 1.10 --- idle 19 May 2003 02:07:44 -0000 1.11 *************** *** 8,12 **** import PyShell except ImportError: ! print "Can't locate PyShell.py" else: import os --- 8,12 ---- import PyShell except ImportError: ! raise else: import os Index: idle.py =================================================================== RCS file: /cvsroot/idlefork/idle/idle.py,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** idle.py 17 May 2003 03:15:48 -0000 1.8 --- idle.py 19 May 2003 02:07:44 -0000 1.9 *************** *** 8,12 **** import PyShell except ImportError: ! print "Can't locate PyShell.py" else: import os --- 8,12 ---- import PyShell except ImportError: ! raise else: import os Index: idle.pyw =================================================================== RCS file: /cvsroot/idlefork/idle/idle.pyw,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** idle.pyw 17 May 2003 03:15:48 -0000 1.7 --- idle.pyw 19 May 2003 02:07:44 -0000 1.8 *************** *** 6,10 **** import PyShell except ImportError: ! print "Can't locate PyShell.py" else: import os --- 6,10 ---- import PyShell except ImportError: ! raise else: import os From noreply@sourceforge.net Mon May 19 03:27:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 18 May 2003 19:27:39 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-18 17:19 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) >Assigned to: Kurt B. Kaiser (kbk) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 21:27 Message: Logged In: YES user_id=149084 Note that the interrupt module is not part of the "alpha distro". It was added to CVS on 10 March after 0.9a2 was released. I have improved the exception handling, idle, idle.py and idle.pyw should now report exactly why the import failed. Also note that interrupt.pyd may not be compatible across Python versions. Idle Rev 1.11 etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Mon May 19 14:37:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 06:37:55 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 00:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Mon May 19 14:53:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 06:53:53 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-19 00:19 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- >Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:53 Message: Logged In: YES user_id=112690 you said in the other thread: > I can say that moving the interrupt.pyd from W2K/Py2.2 > to XP/Py2.3 doesn't work, Python2.3 can't import it. correct. the one that's uploaded here works on Python 2.3 > Also, the Windows installer created on Python2.2 > won't install on a Py2.3 system because "Python2.2 > is not in the registry." idlefork-0.92a-win32 installs ok on 2.2.2 and on 2.3 provided you have installed both pythons from the Win installers. actually the idlefork installer asks the user in which one does she want it. > But I finally got the extension > compiled. Hopefully a windows installer built on Py2.3 > will work on 2.2, but maybe I need to supply both. one installer should work but you will need to supply two interrupt.pyd, one for each python, or a version independent one, if possible (?) -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 04:27 Message: Logged In: YES user_id=149084 Note that the interrupt module is not part of the "alpha distro". It was added to CVS on 10 March after 0.9a2 was released. I have improved the exception handling, idle, idle.py and idle.pyw should now report exactly why the import failed. Also note that interrupt.pyd may not be compatible across Python versions. Idle Rev 1.11 etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Mon May 19 15:13:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 07:13:24 -0700 Subject: [Idle-dev] [ idlefork-Bugs-661676 ] some cosmetic configure window issues Message-ID: Bugs item #661676, was opened at 2003-01-03 16:35 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661676&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: some cosmetic configure window issues Initial Comment: some widgets in the configure windows are uninitalized on the first run: - font (it doesn't highlight the default font) - "Built-in Theme" option is not checked - which Tab key insertion scheme is the default - "Built-in Key Set" option is not checked - one of both option at Startup Preference should be checked ---------------------------------------------------------------------- >Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 16:13 Message: Logged In: YES user_id=112690 idelfork 0.9a2 displays everything correct *except* the font highlighting either python 2.2.2 or python 2.3. in python 2.2.2 the background color of the font list is gray where in 2.3 the bg color of the list is white. no differences are seen on CVS idlefork. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-16 03:02 Message: Logged In: YES user_id=149084 On W2K Python2.2 I can see that the font is not highlighted but the other radio buttons have the default selected as expected. Can anyone else running 2.3 on Windows confirm this bug? (on Linux the default font is highlighted ok) ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-01-03 16:37 Message: Logged In: YES user_id=112690 ups... forgot to tell: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 IDLEfork 0.9a1 Windows 2k spanish version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661676&group_id=9579 From noreply@sourceforge.net Mon May 19 16:54:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 08:54:26 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-18 17:19 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 10:54 Message: Logged In: YES user_id=149084 Man, that's a real developer trap: have a machine with Py2.2 and 2.3, build installer under 2.2, then test installation and it goes great. But it fails on a system with only 2.3. Better to have two installers than have the users slinging dll files around. Does the new idle.py give you better diagnostics? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 08:53 Message: Logged In: YES user_id=112690 you said in the other thread: > I can say that moving the interrupt.pyd from W2K/Py2.2 > to XP/Py2.3 doesn't work, Python2.3 can't import it. correct. the one that's uploaded here works on Python 2.3 > Also, the Windows installer created on Python2.2 > won't install on a Py2.3 system because "Python2.2 > is not in the registry." idlefork-0.92a-win32 installs ok on 2.2.2 and on 2.3 provided you have installed both pythons from the Win installers. actually the idlefork installer asks the user in which one does she want it. > But I finally got the extension > compiled. Hopefully a windows installer built on Py2.3 > will work on 2.2, but maybe I need to supply both. one installer should work but you will need to supply two interrupt.pyd, one for each python, or a version independent one, if possible (?) -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 21:27 Message: Logged In: YES user_id=149084 Note that the interrupt module is not part of the "alpha distro". It was added to CVS on 10 March after 0.9a2 was released. I have improved the exception handling, idle, idle.py and idle.pyw should now report exactly why the import failed. Also note that interrupt.pyd may not be compatible across Python versions. Idle Rev 1.11 etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Mon May 19 16:55:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 08:55:23 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739203 ] Default help includes "Visual" Message-ID: Bugs item #739203, was opened at 2003-05-17 13:12 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Bruce Sherwood (bsherwood) >Assigned to: Kurt B. Kaiser (kbk) Summary: Default help includes "Visual" Initial Comment: On Windows at least, the default help lists "Visual" with a link to the same place as the Python help (namely C:\Python23\Doc\index.html). Since most people presumably don't have the Visual module installed, it seems inappropriate to have "Visual" in the list (and for current and future distributions of Visual the documentation is in site-packages/visual/docs). ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 15:24 Message: Logged In: YES user_id=149084 I believe you will find that this is because "Visual" is in the [HelpFiles] section of your .idlerc/config-main.cfg Personalized configuration is not lost on upgrade or re-installation. The [HelpFiles] section of config-main.def is empty in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739203&group_id=9579 From noreply@sourceforge.net Mon May 19 20:28:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 12:28:23 -0700 Subject: [Idle-dev] [ idlefork-Bugs-740041 ] Windows location of .idlerc Message-ID: Bugs item #740041, was opened at 2003-05-19 19:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=740041&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Windows location of .idlerc Initial Comment: Minor bug: On Windows XP, the folder .idlerc is in C:\Documents and Settings\Bruce Sherwood (or whatever user name), which seems the correct place for individual preferences. On Win2000 however, the folder is at C:\.idlerc, despite the existence of C:\Documents and Settings, and this is not a good place for individual preferences. A particularly bad consequence is that a user might be on an administered machine without permission to write to C:\.idlerc, whereas a user can always write to their Documents and Settings folder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=740041&group_id=9579 From noreply@sourceforge.net Mon May 19 21:40:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:40:22 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-19 00:19 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- >Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 22:40 Message: Logged In: YES user_id=112690 > Man, that's a real developer trap: have a > machine with Py2.2 and 2.3, build installer under > 2.2, then test installation and it goes great. > But it fails on a system with only 2.3. i don't get this... where is failing? i was so stranged by what you said, that i cleaned my PC every python reference. including the registry. after that i installed Python 2.3b1 and idlefork-0.92a2. it works. > Better to have two installers than have the users > slinging dll files around. i meant to have only one installer that can decide at runtime which interrupt.pyd install. i don't know how difficult it is to program a conditional copy in that installer. besides, it can work with several python versions in the same PC. also consider that if you choose for different installers for 2.2.x and 2.3 you might need to program a condition as well, to warn users that they are using the right installation file. just an idea, it's your call anyway. > Does the new idle.py give you better diagnostics? yep. works great! thanks, -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 17:54 Message: Logged In: YES user_id=149084 Man, that's a real developer trap: have a machine with Py2.2 and 2.3, build installer under 2.2, then test installation and it goes great. But it fails on a system with only 2.3. Better to have two installers than have the users slinging dll files around. Does the new idle.py give you better diagnostics? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:53 Message: Logged In: YES user_id=112690 you said in the other thread: > I can say that moving the interrupt.pyd from W2K/Py2.2 > to XP/Py2.3 doesn't work, Python2.3 can't import it. correct. the one that's uploaded here works on Python 2.3 > Also, the Windows installer created on Python2.2 > won't install on a Py2.3 system because "Python2.2 > is not in the registry." idlefork-0.92a-win32 installs ok on 2.2.2 and on 2.3 provided you have installed both pythons from the Win installers. actually the idlefork installer asks the user in which one does she want it. > But I finally got the extension > compiled. Hopefully a windows installer built on Py2.3 > will work on 2.2, but maybe I need to supply both. one installer should work but you will need to supply two interrupt.pyd, one for each python, or a version independent one, if possible (?) -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 04:27 Message: Logged In: YES user_id=149084 Note that the interrupt module is not part of the "alpha distro". It was added to CVS on 10 March after 0.9a2 was released. I have improved the exception handling, idle, idle.py and idle.pyw should now report exactly why the import failed. Also note that interrupt.pyd may not be compatible across Python versions. Idle Rev 1.11 etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Mon May 19 21:58:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 13:58:59 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 22:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 00:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Tue May 20 00:11:53 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 19 May 2003 16:11:53 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.67,1.68 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv6331 Modified Files: PyShell.py Log Message: Fix race exposed by 2.4 GHz XP box: Don't tear down PyShell until subprocess polling has terminated. Tk callit gets unhappy if it can't find the function 'after' scheduled to run. M PyShell.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.67 retrieving revision 1.68 diff -C2 -r1.67 -r1.68 *** PyShell.py 15 May 2003 23:23:20 -0000 1.67 --- PyShell.py 19 May 2003 23:11:51 -0000 1.68 *************** *** 427,432 **** # lost connection or subprocess terminated itself, restart # [the KBI is from rpc.SocketIO.handle_EOF()] - if self.tkconsole.closing: - return response = None self.restart_subprocess() --- 427,430 ---- *************** *** 449,454 **** # we received a response to the currently active seq number: self.tkconsole.endexecuting() ! # Reschedule myself in 50 ms ! self.tkconsole.text.after(50, self.poll_subprocess) debugger = None --- 447,454 ---- # we received a response to the currently active seq number: self.tkconsole.endexecuting() ! # Reschedule myself ! if not self.tkconsole.closing: ! self.tkconsole.text.after(self.tkconsole.pollinterval, ! self.poll_subprocess) debugger = None *************** *** 717,720 **** --- 717,721 ---- self.history = self.History(self.text) # + self.pollinterval = 50 # millisec if use_subprocess: self.interp.start_subprocess() *************** *** 799,803 **** return "cancel" else: ! return EditorWindow.close(self) def _close(self): --- 800,809 ---- return "cancel" else: ! self.closing = True ! # Wait for poll_subprocess() rescheduling to stop ! self.text.after(2 * self.pollinterval, self.close2) ! ! def close2(self): ! return EditorWindow.close(self) def _close(self): From noreply@sourceforge.net Tue May 20 04:23:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 20:23:00 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 22:22 Message: Logged In: YES user_id=149084 Hernan, no, save your testing time for when I think I've got it nailed. That should be soon, I think it's working here on my XP box. I'll let you know here. The problem would have started when I started processing user code in MainThread instead of SockThread on 11 May, but that's not too important at this point. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 08:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 17:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 13:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 10:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Tue May 20 04:27:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 19 May 2003 20:27:50 -0700 Subject: [Idle-dev] [ idlefork-Bugs-739582 ] "Can't locate PyShell" error message Message-ID: Bugs item #739582, was opened at 2003-05-18 17:19 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: "Can't locate PyShell" error message Initial Comment: when running the last IDLE alpha distro it gaves the following error message: C:\Python23\Lib\site-packages\idleforklib>c:\python23\python idle.py Can't locate PyShell.py C:\Python23\Lib\site-packages\idleforklib> most probably means that you miss the file interrupt.pyd. it's not bundled within the win32 alpha distro. as a workaround copy the file attached to the DLLs directory under your Python distribution. (thanks to bruce for the attached copy of the library) regards, -Hernan ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 22:27 Message: Logged In: YES user_id=149084 0.9a2 installs ok probably because there is no extension dll related to interruptmodule.c. That was introduced 10 March. Getting extensions to play across several Python releases can be a challenge for developers. GvR has indicated that the interrupt module could become a part of the Python library. Then IDLE would once again be pure Python. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:40 Message: Logged In: YES user_id=112690 > Man, that's a real developer trap: have a > machine with Py2.2 and 2.3, build installer under > 2.2, then test installation and it goes great. > But it fails on a system with only 2.3. i don't get this... where is failing? i was so stranged by what you said, that i cleaned my PC every python reference. including the registry. after that i installed Python 2.3b1 and idlefork-0.92a2. it works. > Better to have two installers than have the users > slinging dll files around. i meant to have only one installer that can decide at runtime which interrupt.pyd install. i don't know how difficult it is to program a conditional copy in that installer. besides, it can work with several python versions in the same PC. also consider that if you choose for different installers for 2.2.x and 2.3 you might need to program a condition as well, to warn users that they are using the right installation file. just an idea, it's your call anyway. > Does the new idle.py give you better diagnostics? yep. works great! thanks, -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 10:54 Message: Logged In: YES user_id=149084 Man, that's a real developer trap: have a machine with Py2.2 and 2.3, build installer under 2.2, then test installation and it goes great. But it fails on a system with only 2.3. Better to have two installers than have the users slinging dll files around. Does the new idle.py give you better diagnostics? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 08:53 Message: Logged In: YES user_id=112690 you said in the other thread: > I can say that moving the interrupt.pyd from W2K/Py2.2 > to XP/Py2.3 doesn't work, Python2.3 can't import it. correct. the one that's uploaded here works on Python 2.3 > Also, the Windows installer created on Python2.2 > won't install on a Py2.3 system because "Python2.2 > is not in the registry." idlefork-0.92a-win32 installs ok on 2.2.2 and on 2.3 provided you have installed both pythons from the Win installers. actually the idlefork installer asks the user in which one does she want it. > But I finally got the extension > compiled. Hopefully a windows installer built on Py2.3 > will work on 2.2, but maybe I need to supply both. one installer should work but you will need to supply two interrupt.pyd, one for each python, or a version independent one, if possible (?) -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 21:27 Message: Logged In: YES user_id=149084 Note that the interrupt module is not part of the "alpha distro". It was added to CVS on 10 March after 0.9a2 was released. I have improved the exception handling, idle, idle.py and idle.pyw should now report exactly why the import failed. Also note that interrupt.pyd may not be compatible across Python versions. Idle Rev 1.11 etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=739582&group_id=9579 From noreply@sourceforge.net Sat May 24 19:33:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 11:33:20 -0700 Subject: [Idle-dev] [ idlefork-Bugs-742815 ] Problem with Slackware 9.0 Message-ID: Bugs item #742815, was opened at 2003-05-24 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Slackware 9.0 Initial Comment: I cannot use Menu ( File, Edition etc...) to open or save any files. This is what I get when I try to open a file with File : user1@darkstar:~/IDLEfork-0.9a2$ ./idle Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1299, in __call__ args = apply(self.subst, args) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1032, in _substitute e.num = getint(b) ValueError: invalid literal for int(): ?? Anyone any idea ? I am just very python newbie. Does exists a IDLE Slackware package ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 From kbk@users.sourceforge.net Sat May 24 21:59:17 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 24 May 2003 13:59:17 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.68,1.69 ScriptBinding.py,1.20,1.21 rpc.py,1.24,1.25 run.py,1.18,1.19 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv5617 Modified Files: PyShell.py ScriptBinding.py rpc.py run.py Log Message: 1. Stake Freddy. e.g. further improve subprocess interrupt, exceptions, and termination. 2. Remove the workarounds in PyShell.py and ScriptBinding.py involving interrupting the subprocess prior to killing it, not necessary anymore. 3. Fix a bug introduced at PyShell Rev 1.66: was getting extra shell menu every time the shell window was recreated. M PyShell.py M ScriptBinding.py M rpc.py M run.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.68 retrieving revision 1.69 diff -C2 -r1.68 -r1.69 *** PyShell.py 19 May 2003 23:11:51 -0000 1.68 --- PyShell.py 24 May 2003 20:59:12 -0000 1.69 *************** *** 297,300 **** --- 297,308 ---- UndoDelegator.delete(self, index1, index2) + + class MyRPCClient(rpc.RPCClient): + + def handle_EOF(self): + "Override the base class - just re-raise EOFError" + raise EOFError + + class ModifiedInterpreter(InteractiveInterpreter): *************** *** 330,334 **** time.sleep(i) try: ! self.rpcclt = rpc.RPCClient(addr) break except socket.error, err: --- 338,342 ---- time.sleep(i) try: ! self.rpcclt = MyRPCClient(addr) break except socket.error, err: *************** *** 427,433 **** # lost connection or subprocess terminated itself, restart # [the KBI is from rpc.SocketIO.handle_EOF()] response = None self.restart_subprocess() - self.tkconsole.endexecuting() if response: self.tkconsole.resetoutput() --- 435,442 ---- # lost connection or subprocess terminated itself, restart # [the KBI is from rpc.SocketIO.handle_EOF()] + if self.tkconsole.closing: + return response = None self.restart_subprocess() if response: self.tkconsole.resetoutput() *************** *** 674,678 **** def __init__(self, flist=None): if use_subprocess: ! self.menu_specs.insert(2, ("shell", "_Shell")) self.interp = ModifiedInterpreter(self) if flist is None: --- 683,689 ---- def __init__(self, flist=None): if use_subprocess: ! ms = self.menu_specs ! if ms[2][0] != "shell": ! ms.insert(2, ("shell", "_Shell")) self.interp = ModifiedInterpreter(self) if flist is None: *************** *** 794,806 **** if response == False: return "cancel" ! # interrupt the subprocess ! self.canceled = True ! if use_subprocess: ! self.interp.interrupt_subprocess() ! return "cancel" ! else: ! self.closing = True ! # Wait for poll_subprocess() rescheduling to stop ! self.text.after(2 * self.pollinterval, self.close2) def close2(self): --- 805,811 ---- if response == False: return "cancel" ! self.closing = True ! # Wait for poll_subprocess() rescheduling to stop ! self.text.after(2 * self.pollinterval, self.close2) def close2(self): *************** *** 886,890 **** self.top.quit() elif (self.executing and self.interp.rpcclt): ! self.interp.interrupt_subprocess() return "break" --- 891,898 ---- self.top.quit() elif (self.executing and self.interp.rpcclt): ! if self.interp.getdebugger(): ! self.interp.restart_subprocess() ! else: ! self.interp.interrupt_subprocess() return "break" *************** *** 1022,1035 **** def restart_shell(self, event=None): ! if self.executing: ! self.cancel_callback() ! # Wait for subprocess to interrupt and restart ! # This can be a long time if shell is scrolling on a slow system ! # XXX 14 May 03 KBK This delay (and one in ScriptBinding) could be ! # shorter if we didn't print the KeyboardInterrupt on ! # restarting while user code is running.... ! self.text.after(2000, self.interp.restart_subprocess) ! else: ! self.interp.restart_subprocess() def showprompt(self): --- 1030,1034 ---- def restart_shell(self, event=None): ! self.interp.restart_subprocess() def showprompt(self): Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.20 retrieving revision 1.21 diff -C2 -r1.20 -r1.21 *** ScriptBinding.py 15 May 2003 23:23:21 -0000 1.20 --- ScriptBinding.py 24 May 2003 20:59:15 -0000 1.21 *************** *** 126,140 **** if PyShell.use_subprocess: shell.restart_shell() - if shell.executing: - delay = 2700 - else: - delay = 500 - # Wait for the interrupt and reset to finish - shell.text.after(delay, self.run_module_event2, interp, - filename, code) - else: - self.run_module_event2(interp, filename, code) - - def run_module_event2(self, interp, filename, code): # XXX Too often this discards arguments the user just set... interp.runcommand("""if 1: --- 126,129 ---- Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.24 retrieving revision 1.25 diff -C2 -r1.24 -r1.25 *** rpc.py 10 May 2003 00:09:52 -0000 1.24 --- rpc.py 24 May 2003 20:59:15 -0000 1.25 *************** *** 42,46 **** import marshal - import interrupt def unpickle_code(ms): --- 42,45 ---- *************** *** 328,337 **** try: n = self.sock.send(s) ! except AttributeError: # socket was closed raise IOError - except socket.error: - self.debug("putmessage:socketerror:pid:%s" % os.getpid()) - os._exit(0) else: s = s[n:] --- 327,333 ---- try: n = self.sock.send(s) ! except (AttributeError, socket.error): # socket was closed raise IOError else: s = s[n:] *************** *** 472,476 **** cv.notify() cv.release() - interrupt.interrupt_main() # call our (possibly overridden) exit function self.exithook() --- 468,471 ---- Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.18 retrieving revision 1.19 diff -C2 -r1.18 -r1.19 *** run.py 17 May 2003 21:04:10 -0000 1.18 --- run.py 24 May 2003 20:59:15 -0000 1.19 *************** *** 22,26 **** # completion and exit flags: ! exit_requested = False def main(): --- 22,27 ---- # completion and exit flags: ! exit_now = False ! quitting = False def main(): *************** *** 42,45 **** --- 43,48 ---- """ + global exit_now + global quitting port = 8833 if sys.argv[1:]: *************** *** 53,58 **** while 1: try: ! if exit_requested: ! sys.exit(0) try: seq, request = rpc.request_queue.get(0) --- 56,65 ---- while 1: try: ! if exit_now: ! try: ! sys.exit(0) ! except KeyboardInterrupt: ! # exiting but got an extra KBI? Try again! ! continue try: seq, request = rpc.request_queue.get(0) *************** *** 64,78 **** rpc.response_queue.put((seq, ret)) except KeyboardInterrupt: continue except SystemExit: raise except: try: print_exception() rpc.response_queue.put((seq, None)) except: ! traceback.print_exc(file=sys.__stderr__) ! sys.exit(1.1) ! continue def manage_socket(address): --- 71,90 ---- rpc.response_queue.put((seq, ret)) except KeyboardInterrupt: + if quitting: + exit_now = True continue except SystemExit: raise except: + type, value, tb = sys.exc_info() try: print_exception() rpc.response_queue.put((seq, None)) except: ! # Link didn't work, print same exception to __stderr__ ! traceback.print_exception(type, value, tb, file=sys.__stderr__) ! sys.exit(0) ! else: ! continue def manage_socket(address): *************** *** 90,95 **** else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." ! global exit_requested ! exit_requested = True return server.handle_request() # A single request only --- 102,107 ---- else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." ! global exit_now ! exit_now = True return server.handle_request() # A single request only *************** *** 98,104 **** flush_stdout() efile = sys.stderr ! typ, val, tb = info = sys.exc_info() tbe = traceback.extract_tb(tb) ! print >>efile, 'Traceback (most recent call last):' exclude = ("run.py", "rpc.py", "threading.py", "Queue.py", "RemoteDebugger.py", "bdb.py") --- 110,116 ---- flush_stdout() efile = sys.stderr ! typ, val, tb = sys.exc_info() tbe = traceback.extract_tb(tb) ! print >>efile, '\nTraceback (most recent call last):' exclude = ("run.py", "rpc.py", "threading.py", "Queue.py", "RemoteDebugger.py", "bdb.py") *************** *** 162,167 **** raise except EOFError: ! global exit_requested ! exit_requested = True interrupt.interrupt_main() except: --- 174,179 ---- raise except EOFError: ! global exit_now ! exit_now = True interrupt.interrupt_main() except: *************** *** 175,179 **** print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 ! os._exit(0) --- 187,191 ---- print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 ! sys.exit(0) *************** *** 191,203 **** def exithook(self): "override SocketIO method - wait for MainThread to shut us down" ! while 1: pass def EOFhook(self): "Override SocketIO method - terminate wait on callback and exit thread" ! global exit_requested ! exit_requested = True def decode_interrupthook(self): "interrupt awakened thread" interrupt.interrupt_main() --- 203,218 ---- def exithook(self): "override SocketIO method - wait for MainThread to shut us down" ! time.sleep(10) def EOFhook(self): "Override SocketIO method - terminate wait on callback and exit thread" ! global quitting ! quitting = True ! interrupt.interrupt_main() def decode_interrupthook(self): "interrupt awakened thread" + global quitting + quitting = True interrupt.interrupt_main() *************** *** 214,226 **** exec code in self.locals except: ! if exit_requested: sys.exit(0) ! try: ! # even print a user code SystemExit exception, continue ! print_exception() ! except: ! # link not working? ! traceback.print_exc(file=sys.__stderr__) ! sys.exit(1.2) else: flush_stdout() --- 229,236 ---- exec code in self.locals except: ! if quitting: sys.exit(0) ! # even print a user code SystemExit exception, continue ! print_exception() else: flush_stdout() From kbk@users.sourceforge.net Sat May 24 22:01:41 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 24 May 2003 14:01:41 -0700 Subject: [Idle-dev] CVS: idle idle,1.11,1.12 idle.py,1.9,1.10 idle.pyw,1.8,1.9 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv5986 Modified Files: idle idle.py idle.pyw Log Message: Fix a bug in Rev 1.10 - Windows can't handle a leading ':' if the user's PYTHONPATH is empty (though Linux can). Modified Files: idle idle.py idle.pyw Index: idle =================================================================== RCS file: /cvsroot/idlefork/idle/idle,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** idle 19 May 2003 02:07:44 -0000 1.11 --- idle 24 May 2003 21:01:39 -0000 1.12 *************** *** 15,19 **** # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir PyShell.main() else: --- 15,22 ---- # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! if pypath: ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! else: ! os.environ['PYTHONPATH'] = idledir PyShell.main() else: Index: idle.py =================================================================== RCS file: /cvsroot/idlefork/idle/idle.py,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** idle.py 19 May 2003 02:07:44 -0000 1.9 --- idle.py 24 May 2003 21:01:39 -0000 1.10 *************** *** 15,19 **** # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir PyShell.main() else: --- 15,22 ---- # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! if pypath: ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! else: ! os.environ['PYTHONPATH'] = idledir PyShell.main() else: Index: idle.pyw =================================================================== RCS file: /cvsroot/idlefork/idle/idle.pyw,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** idle.pyw 19 May 2003 02:07:44 -0000 1.8 --- idle.pyw 24 May 2003 21:01:39 -0000 1.9 *************** *** 13,17 **** # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! os.environ['PYTHONPATH'] = pypath + ':' + idledir PyShell.main() else: --- 13,20 ---- # We're not in the IDLE directory, help the subprocess find run.py pypath = os.environ.get('PYTHONPATH', '') ! if pypath: ! os.environ['PYTHONPATH'] = pypath + ':' + idledir ! else: ! os.environ['PYTHONPATH'] = idledir PyShell.main() else: From kbk@users.sourceforge.net Sat May 24 22:12:49 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 24 May 2003 14:12:49 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.69,1.70 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv10063 Modified Files: PyShell.py Log Message: Improved the RESTART annotation in the shell window when the user restarts the shell while it is generating output. Also improved annotation when user repeatedly hammers the Ctrl-F6 restart. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.69 retrieving revision 1.70 diff -C2 -r1.69 -r1.70 *** PyShell.py 24 May 2003 20:59:12 -0000 1.69 --- PyShell.py 24 May 2003 21:12:46 -0000 1.70 *************** *** 312,315 **** --- 312,316 ---- InteractiveInterpreter.__init__(self, locals=locals) self.save_warnings_filters = None + self.restarting = False port = 8833 *************** *** 358,361 **** --- 359,365 ---- def restart_subprocess(self): + if self.restarting: + return + self.restarting = True # close only the subprocess debugger debug = self.getdebugger() *************** *** 370,373 **** --- 374,378 ---- self.unix_terminate() console = self.tkconsole + was_executing = console.executing console.executing = False self.spawn_subprocess() *************** *** 376,379 **** --- 381,387 ---- # annotate restart in shell window and mark it console.text.delete("iomark", "end-1c") + if was_executing: + console.write('\n') + console.showprompt() halfbar = ((int(console.width) - 16) // 2) * '=' console.write(halfbar + ' RESTART ' + halfbar) *************** *** 387,390 **** --- 395,399 ---- # reload remote debugger breakpoints for all PyShellEditWindows debug.load_breakpoints() + self.restarting = False def __request_interrupt(self): From noreply@sourceforge.net Sat May 24 22:17:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 24 May 2003 14:17:59 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open >Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-24 16:17 Message: Logged In: YES user_id=149084 OK, I checked in an update. Give it a shot. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 22:22 Message: Logged In: YES user_id=149084 Hernan, no, save your testing time for when I think I've got it nailed. That should be soon, I think it's working here on my XP box. I'll let you know here. The problem would have started when I started processing user code in MainThread instead of SockThread on 11 May, but that's not too important at this point. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 08:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 17:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 13:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 10:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Mon May 26 07:23:12 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 25 May 2003 23:23:12 -0700 Subject: [Idle-dev] CVS: idle ScriptBinding.py,1.21,1.22 config-main.def,1.15,1.16 configDialog.py,1.52,1.53 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2756 Modified Files: ScriptBinding.py config-main.def configDialog.py Log Message: Bruce Sherwood RFE/Patch SF 661318 Adds autosave capability to IDLE and IDLE configuration dialog. User can Run/F5 without explicit save dialog. The default is to require the user to confirm the save. M ScriptBinding.py M config-main.def M configDialog.py Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -r1.21 -r1.22 *** ScriptBinding.py 24 May 2003 20:59:15 -0000 1.21 --- ScriptBinding.py 26 May 2003 06:23:10 -0000 1.22 *************** *** 25,28 **** --- 25,30 ---- import PyShell + from configHandler import idleConf + IDENTCHARS = string.ascii_letters + string.digits + "_" *************** *** 145,168 **** the current version of the source buffer has been saved. If the user declines to save or cancels the Save As dialog, return None. """ if not self.editwin.get_saved(): ! msg = """Source Must Be Saved ! OK to Save?""" ! mb = tkMessageBox.Message( ! title="Save Before Run or Check", ! message=msg, ! icon=tkMessageBox.QUESTION, ! type=tkMessageBox.OKCANCEL, ! default=tkMessageBox.OK, ! master=self.editwin.text) ! reply = mb.show() ! if reply == "ok": self.editwin.io.save(None) else: ! return None ! # filename is None if file doesn't exist ! filename = self.editwin.io.filename ! self.editwin.text.focus_set() return filename def errorbox(self, title, message): --- 147,180 ---- the current version of the source buffer has been saved. If the user declines to save or cancels the Save As dialog, return None. + + If the user has configured IDLE for Autosave, the file will be + silently saved if it already exists and is dirty. + """ + filename = self.editwin.io.filename if not self.editwin.get_saved(): ! autosave = idleConf.GetOption('main', 'General', ! 'autosave', type='bool') ! if autosave and filename: self.editwin.io.save(None) else: ! reply = self.ask_save_dialog() ! self.editwin.text.focus_set() ! if reply == "ok": ! self.editwin.io.save(None) ! filename = self.editwin.io.filename ! else: ! filename = None return filename + + def ask_save_dialog(self): + msg = "Source Must Be Saved\n" + 5*' ' + "OK to Save?" + mb = tkMessageBox.Message(title="Save Before Run or Check", + message=msg, + icon=tkMessageBox.QUESTION, + type=tkMessageBox.OKCANCEL, + default=tkMessageBox.OK, + master=self.editwin.text) + return mb.show() def errorbox(self, title, message): Index: config-main.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-main.def,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** config-main.def 18 May 2003 02:21:55 -0000 1.15 --- config-main.def 26 May 2003 06:23:10 -0000 1.16 *************** *** 41,44 **** --- 41,45 ---- [General] editor-on-startup= 0 + autosave= 0 print-command-posix=lpr %s print-command-win=start /min notepad /p %s *************** *** 50,54 **** font-size= 12 font-bold= 0 ! encoding=none [Indent] --- 51,55 ---- font-size= 12 font-bold= 0 ! encoding= none [Indent] Index: configDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/configDialog.py,v retrieving revision 1.52 retrieving revision 1.53 diff -C2 -r1.52 -r1.53 *** configDialog.py 10 May 2003 00:49:56 -0000 1.52 --- configDialog.py 26 May 2003 06:23:10 -0000 1.53 *************** *** 335,338 **** --- 335,339 ---- self.winHeight=StringVar(self) self.startupEdit=IntVar(self) + self.autoSave=IntVar(self) self.encoding=StringVar(self) self.userHelpBrowser=BooleanVar(self) *************** *** 343,346 **** --- 344,348 ---- #body section frames frameRun=Frame(frame,borderwidth=2,relief=GROOVE) + frameSave=Frame(frame,borderwidth=2,relief=GROOVE) frameWinSize=Frame(frame,borderwidth=2,relief=GROOVE) frameEncoding=Frame(frame,borderwidth=2,relief=GROOVE) *************** *** 348,356 **** #frameRun labelRunTitle=Label(frameRun,text='Startup Preferences') ! labelRunChoiceTitle=Label(frameRun,text='On Startup : ') radioStartupEdit=Radiobutton(frameRun,variable=self.startupEdit, value=1,command=self.SetKeysType,text="Open Edit Window") radioStartupShell=Radiobutton(frameRun,variable=self.startupEdit, value=0,command=self.SetKeysType,text='Open Shell Window') #frameWinSize labelWinSizeTitle=Label(frameWinSize,text='Initial Window Size'+ --- 350,365 ---- #frameRun labelRunTitle=Label(frameRun,text='Startup Preferences') ! labelRunChoiceTitle=Label(frameRun,text='At Startup') radioStartupEdit=Radiobutton(frameRun,variable=self.startupEdit, value=1,command=self.SetKeysType,text="Open Edit Window") radioStartupShell=Radiobutton(frameRun,variable=self.startupEdit, value=0,command=self.SetKeysType,text='Open Shell Window') + #frameSave + labelSaveTitle=Label(frameSave,text='Autosave Preference') + labelRunSaveTitle=Label(frameSave,text='At Start of Run (F5) ') + radioSaveAsk=Radiobutton(frameSave,variable=self.autoSave, + value=0,command=self.SetKeysType,text="Prompt to Save") + radioSaveAuto=Radiobutton(frameSave,variable=self.autoSave, + value=1,command=self.SetKeysType,text='No Prompt') #frameWinSize labelWinSizeTitle=Label(frameWinSize,text='Initial Window Size'+ *************** *** 371,375 **** value="none",text="None") #frameHelp ! labelHelpTitle=Label(frameHelp,text='Help Options') frameHelpList=Frame(frameHelp) frameHelpListButtons=Frame(frameHelpList) --- 380,384 ---- value="none",text="None") #frameHelp ! ##labelHelpTitle=Label(frameHelp,text='Help Options') frameHelpList=Frame(frameHelp) frameHelpListButtons=Frame(frameHelpList) *************** *** 397,408 **** #body frameRun.pack(side=TOP,padx=5,pady=5,fill=X) frameWinSize.pack(side=TOP,padx=5,pady=5,fill=X) ! frameEncoding.pack(side=TOP,padx=5,pady=5,fill=X) frameHelp.pack(side=TOP,padx=5,pady=5,expand=TRUE,fill=BOTH) #frameRun labelRunTitle.pack(side=TOP,anchor=W,padx=5,pady=5) labelRunChoiceTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) ! radioStartupEdit.pack(side=LEFT,anchor=W,padx=5,pady=5) ! radioStartupShell.pack(side=LEFT,anchor=W,padx=5,pady=5) #frameWinSize labelWinSizeTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) --- 406,423 ---- #body frameRun.pack(side=TOP,padx=5,pady=5,fill=X) + frameSave.pack(side=TOP,padx=5,pady=5,fill=X) frameWinSize.pack(side=TOP,padx=5,pady=5,fill=X) ! frameEncoding.pack(side=TOP,padx=5,pady=5,fill=X) frameHelp.pack(side=TOP,padx=5,pady=5,expand=TRUE,fill=BOTH) #frameRun labelRunTitle.pack(side=TOP,anchor=W,padx=5,pady=5) labelRunChoiceTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) ! radioStartupShell.pack(side=RIGHT,anchor=W,padx=5,pady=5) ! radioStartupEdit.pack(side=RIGHT,anchor=W,padx=5,pady=5) ! #frameSave ! labelSaveTitle.pack(side=TOP,anchor=W,padx=5,pady=5) ! labelRunSaveTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) ! radioSaveAuto.pack(side=RIGHT,anchor=W,padx=5,pady=5) ! radioSaveAsk.pack(side=RIGHT,anchor=W,padx=5,pady=5) #frameWinSize labelWinSizeTitle.pack(side=LEFT,anchor=W,padx=5,pady=5) *************** *** 417,421 **** radioEncLocale.pack(side=RIGHT,anchor=E,pady=5) #frameHelp ! labelHelpTitle.pack(side=TOP,anchor=W,padx=5,pady=5) frameHelpListButtons.pack(side=RIGHT,padx=5,pady=5,fill=Y) frameHelpList.pack(side=TOP,padx=5,pady=5,expand=TRUE,fill=BOTH) --- 432,436 ---- radioEncLocale.pack(side=RIGHT,anchor=E,pady=5) #frameHelp ! ##labelHelpTitle.pack(side=TOP,anchor=W,padx=5,pady=5) frameHelpListButtons.pack(side=RIGHT,padx=5,pady=5,fill=Y) frameHelpList.pack(side=TOP,padx=5,pady=5,expand=TRUE,fill=BOTH) *************** *** 449,452 **** --- 464,468 ---- self.winHeight.trace_variable('w',self.VarChanged_winHeight) self.startupEdit.trace_variable('w',self.VarChanged_startupEdit) + self.autoSave.trace_variable('w',self.VarChanged_autoSave) self.encoding.trace_variable('w',self.VarChanged_encoding) *************** *** 543,546 **** --- 559,566 ---- self.AddChangedItem('main','General','editor-on-startup',value) + def VarChanged_autoSave(self,*params): + value=self.autoSave.get() + self.AddChangedItem('main','General','autosave',value) + def VarChanged_encoding(self,*params): value=self.encoding.get() *************** *** 1039,1047 **** self.startupEdit.set(idleConf.GetOption('main','General', 'editor-on-startup',default=1,type='bool')) #initial window size self.winWidth.set(idleConf.GetOption('main','EditorWindow','width')) self.winHeight.set(idleConf.GetOption('main','EditorWindow','height')) # default source encoding ! self.encoding.set(idleConf.GetOption('main','EditorWindow','encoding')) # additional help sources self.userHelpList = idleConf.GetAllExtraHelpSourcesList() --- 1059,1071 ---- self.startupEdit.set(idleConf.GetOption('main','General', 'editor-on-startup',default=1,type='bool')) + #autosave state + self.autoSave.set(idleConf.GetOption('main', 'General', 'autosave', + default=0, type='bool')) #initial window size self.winWidth.set(idleConf.GetOption('main','EditorWindow','width')) self.winHeight.set(idleConf.GetOption('main','EditorWindow','height')) # default source encoding ! self.encoding.set(idleConf.GetOption('main', 'EditorWindow', ! 'encoding', default='none')) # additional help sources self.userHelpList = idleConf.GetAllExtraHelpSourcesList() From noreply@sourceforge.net Mon May 26 10:07:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 02:07:08 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-26 11:07 Message: Logged In: YES user_id=112690 Freddy's gone. :-) Tested in 2 different PCs (both Win2K), works ok. (Just for the record, Kaspersky Antivirus seriously affects Python's performance.) Thanks and Regards, -Hernan ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-24 23:17 Message: Logged In: YES user_id=149084 OK, I checked in an update. Give it a shot. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-20 05:22 Message: Logged In: YES user_id=149084 Hernan, no, save your testing time for when I think I've got it nailed. That should be soon, I think it's working here on my XP box. I'll let you know here. The problem would have started when I started processing user code in MainThread instead of SockThread on 11 May, but that's not too important at this point. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 22:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 00:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Mon May 26 10:17:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 02:17:34 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-30 05:02 Message generated for change (Comment added) made by hfoffani You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None Status: Open Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-26 11:17 Message: Logged In: YES user_id=112690 umpf. "Just for the record, Kaspersky Antivirus seriously affects Python's performance." I meant, "affects a Python program running under Idlefork" and it really depends on the AV config. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-26 11:07 Message: Logged In: YES user_id=112690 Freddy's gone. :-) Tested in 2 different PCs (both Win2K), works ok. (Just for the record, Kaspersky Antivirus seriously affects Python's performance.) Thanks and Regards, -Hernan ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-24 23:17 Message: Logged In: YES user_id=149084 OK, I checked in an update. Give it a shot. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-20 05:22 Message: Logged In: YES user_id=149084 Hernan, no, save your testing time for when I think I've got it nailed. That should be soon, I think it's working here on my XP box. I'll let you know here. The problem would have started when I started processing user code in MainThread instead of SockThread on 11 May, but that's not too important at this point. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 22:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 03:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 00:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 22:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 20:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 17:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 05:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 03:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 00:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 23:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 19:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 15:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 00:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 23:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-15 05:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 07:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 17:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From noreply@sourceforge.net Mon May 26 16:54:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 08:54:21 -0700 Subject: [Idle-dev] [ idlefork-Feature Requests-661318 ] Configure autosave Message-ID: Feature Requests item #661318, was opened at 2003-01-02 16:46 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=359579&aid=661318&group_id=9579 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: Configure autosave Initial Comment: It is important to me and my students to be able to specify as a configuration option that autosave be in effect. That is, when I press F5 and I have made changes to the file, the file is overwritten with the current version, with no dialog box intruding. The value of autosave is that it reduces the likelihood of losing work in case of an interruption, and the value of eliminating the dialog box is that it increases interactivity and avoids a loss of focus due to the intrusion. The goal is to make full-program edit/run cycles as highly interactive as the interactive shell. The practically infinite un-do capability of IDLE makes autosave acceptable. And the knowledgeable can always if desired save a copy at a particular stage in the development process. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 10:54 Message: Logged In: YES user_id=149084 (I reconfigured the SF site to send RFE to the Idle-dev list.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 01:29 Message: Logged In: YES user_id=149084 Completed and applied. Thanks for the patch!! configDialog 1.53 ScriptBinding 1.22 config-main.def 1.16 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 21:45 Message: Logged In: YES user_id=149084 Here's the equivalent in a context diff. Also there was a spurious tab at lin 411 frameEncoding.pack which I included in the diff.... ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 13:53 Message: Logged In: YES user_id=34881 I've attached a version of configDialog.py containing controls for specifying whether to prompt for saving the file at the start of a run or just save the file without prompting (assuming the file has been saved to disk sometime in the past -- that is, the first run of an unsaved file should prompt to save to disk). Sorry, I don't know how to produce a diff package, but I did put "#bas" comments in front of each of my minor changes. I wasn't sure how to properly initialize the new variable self.askSave, nor did I wander through the rest of idlefork to see where to use this variable when starting a run, on the assumption that you would be able to do this easily and quickly. I just wanted to spare you the annoyance of setting up the GUI aspects. Hope this helps. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 12:13 Message: Logged In: YES user_id=34881 I may not be remembering this correctly, but I thought there had been statements to the effect that although 0.9a2 would make the save dialog box the default, there would be a configuration mechanism to disable it. That's why I reported the new situation as a bug. I do agree that being able to kill subprocesses is vastly more important than this detail! However, for the (slightly?) longer run, this feature is very important to me, for the reasons I gave in my original request. It shouldn't matter whether one agrees or disagrees with my view of this. The point of configurability is to make it possible for people with different views to use the same tool. As you say, I do agree with the initial save dialog (before there is any file on the hard drive), and I much appreciate the improvements to the initial save dialog. I'm only objecting to the save dialog that intrudes on further saves after the initial one. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:08 Message: Logged In: YES user_id=149084 On Idle-dev you've agreed that the initial Save dialog is acceptable as it teaches good habits: http://mail.python.org/pipermail/idle-dev/2003-January/001475.html The dialog which previously complained about an unsaved program and aborted the Run has been enhanced so that it offers to save the file. In addition, its OK is bound to "enter", so one keystroke will save the file and proceed with the Run. If you don't want to see the dialog, just remember to hit the save keybinding before F5. This is not a big deal, and teaches good habits. Adding the option to automatically re-save the program to the config GUI will take a bit of work (because it means fully comprehending ConfigDialog.py) and I don't have as high a priority on this as some of the other issues like killing the subprocess correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=359579&aid=661318&group_id=9579 From noreply@sourceforge.net Mon May 26 19:58:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 11:58:30 -0700 Subject: [Idle-dev] [ idlefork-Bugs-693418 ] Normal text background color not refreshed Message-ID: Bugs item #693418, was opened at 2003-02-25 23:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Wont Fix >Priority: 2 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. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 13:58 Message: Logged In: YES user_id=149084 You cannot change the normal text or highlight foregrounds or backgrounds w/o (re)opening a window. It is great that Stephen actually was able to update the definition, commment, keyword, string and error text foregrounds and backgrounds on the fly. But only the latter are handled by the colorizer; the former are set up when the window is created. This is not impossible to fix, just not worth the effort IMHO. You could offer a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579 From kbk@users.sourceforge.net Mon May 26 21:35:55 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 26 May 2003 13:35:55 -0700 Subject: [Idle-dev] CVS: idle config-main.def,1.16,1.17 configDialog.py,1.53,1.54 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv7177 Modified Files: config-main.def configDialog.py Log Message: 1. SF Bug 661676 The default font is not highlighted in the Options dialog when IDLEfork is first installed. 2. Reduce default font to 10 pt and increase default window height to give a better initial impression on Windows. M config-main.def M configDialog.py Index: config-main.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-main.def,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -r1.16 -r1.17 *** config-main.def 26 May 2003 06:23:10 -0000 1.16 --- config-main.def 26 May 2003 20:35:53 -0000 1.17 *************** *** 47,53 **** [EditorWindow] width= 80 ! height= 30 font= courier ! font-size= 12 font-bold= 0 encoding= none --- 47,53 ---- [EditorWindow] width= 80 ! height= 40 font= courier ! font-size= 10 font-bold= 0 encoding= none Index: configDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/configDialog.py,v retrieving revision 1.53 retrieving revision 1.54 diff -C2 -r1.53 -r1.54 *** configDialog.py 26 May 2003 06:23:10 -0000 1.53 --- configDialog.py 26 May 2003 20:35:53 -0000 1.54 *************** *** 94,98 **** #self.tabCols=IntVar(self) self.indentBySpaces=BooleanVar(self) ! self.editFont=tkFont.Font(self,('courier',12,'normal')) ##widget creation #body frame --- 94,98 ---- #self.tabCols=IntVar(self) self.indentBySpaces=BooleanVar(self) ! self.editFont=tkFont.Font(self,('courier',10,'normal')) ##widget creation #body frame *************** *** 838,842 **** def OnListFontButtonRelease(self,event): ! self.fontName.set(self.listFontName.get(ANCHOR)) self.SetFontSample() --- 838,843 ---- def OnListFontButtonRelease(self,event): ! font = self.listFontName.get(ANCHOR) ! self.fontName.set(font.lower()) self.SetFontSample() *************** *** 957,963 **** configuredFont=idleConf.GetOption('main','EditorWindow','font', default='courier') ! self.fontName.set(configuredFont) ! if configuredFont in fonts: ! currentFontIndex=fonts.index(configuredFont) self.listFontName.see(currentFontIndex) self.listFontName.select_set(currentFontIndex) --- 958,966 ---- configuredFont=idleConf.GetOption('main','EditorWindow','font', default='courier') ! lc_configuredFont = configuredFont.lower() ! self.fontName.set(lc_configuredFont) ! lc_fonts = [s.lower() for s in fonts] ! if lc_configuredFont in lc_fonts: ! currentFontIndex = lc_fonts.index(lc_configuredFont) self.listFontName.see(currentFontIndex) self.listFontName.select_set(currentFontIndex) *************** *** 965,969 **** ##font size dropdown fontSize=idleConf.GetOption('main','EditorWindow','font-size', ! default='12') self.optMenuFontSize.SetMenu(('7','8','9','10','11','12','13','14', '16','18','20','22'),fontSize ) --- 968,972 ---- ##font size dropdown fontSize=idleConf.GetOption('main','EditorWindow','font-size', ! default='10') self.optMenuFontSize.SetMenu(('7','8','9','10','11','12','13','14', '16','18','20','22'),fontSize ) From noreply@sourceforge.net Mon May 26 21:36:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 13:36:54 -0700 Subject: [Idle-dev] [ idlefork-Bugs-661676 ] some cosmetic configure window issues Message-ID: Bugs item #661676, was opened at 2003-01-03 10:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661676&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: some cosmetic configure window issues Initial Comment: some widgets in the configure windows are uninitalized on the first run: - font (it doesn't highlight the default font) - "Built-in Theme" option is not checked - which Tab key insertion scheme is the default - "Built-in Key Set" option is not checked - one of both option at Startup Preference should be checked ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 15:36 Message: Logged In: YES user_id=149084 configDialog.py 1.54 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 09:13 Message: Logged In: YES user_id=112690 idelfork 0.9a2 displays everything correct *except* the font highlighting either python 2.2.2 or python 2.3. in python 2.2.2 the background color of the font list is gray where in 2.3 the bg color of the list is white. no differences are seen on CVS idlefork. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-15 21:02 Message: Logged In: YES user_id=149084 On W2K Python2.2 I can see that the font is not highlighted but the other radio buttons have the default selected as expected. Can anyone else running 2.3 on Windows confirm this bug? (on Linux the default font is highlighted ok) ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-01-03 10:37 Message: Logged In: YES user_id=112690 ups... forgot to tell: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 IDLEfork 0.9a1 Windows 2k spanish version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661676&group_id=9579 From noreply@sourceforge.net Mon May 26 22:32:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 14:32:48 -0700 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 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=538584&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed 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: Kurt B. Kaiser (kbk) Date: 2003-05-26 16:32 Message: Logged In: YES user_id=149084 GvR checked in IOBinding.py 1.14 25Apr ---------------------------------------------------------------------- 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 06: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 21: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 Mon May 26 22:33:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 14:33:24 -0700 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 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661759&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed 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: Kurt B. Kaiser (kbk) Date: 2003-05-26 16:33 Message: Logged In: YES user_id=149084 GvR checked in IOBinding.py 1.14 25Apr ---------------------------------------------------------------------- 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 Mon May 26 22:46:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 14:46:21 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677260 ] Display of Startup option Message-ID: Bugs item #677260, was opened at 2003-01-29 22:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 Category: None Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: Display of Startup option Initial Comment: In 0.9a2 on the General tab of the options menu, the current setting of the "On Startup" choice is not displayed. I'm able to set it, and it displays as long as I just move among the option tabs, but if I exit options and return to it there is no indication as to which choice is currently in effect. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 16:46 Message: Logged In: YES user_id=149084 This is working for me on Python2.3/XP/Tk8.4, Python2.2/W2K/Tk8.3, and Python2.3/2.2/Linux/Tk8.3 Do you still see it? If so, please delete/rename your .idlerc/config-main.cfg and check again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 13:56 Message: Logged In: YES user_id=34881 When I try your test I get "8.4". I didn't do anything special -- I just installed Python 2.3a1, and apparently that's the version of Tk that comes with. I'll be happy to try to help in any way I can. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 13:17 Message: Logged In: YES user_id=149084 Hm. I may be in the position of trying to fix something that I can't reproduce :) I may need your help. What's your Tk version? >>> import Tkinter >>> Tkinter.TkVersion 8.3000000000000007 here.... ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 12:23 Message: Logged In: YES user_id=34881 I'm running Python 2.3 on Windows XP. It is completely reproducible that the Startup Preference choice on the General tab is never highlighted upon entering the Options menu, even after setting this option, clicking ok (or apply and ok), and then immediately returning to the General tab to see whether the choice is highlighted. On the other hand, if I set a new font and exit Options and return, I do see my font choice highlighted. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:16 Message: Logged In: YES user_id=149084 Duplicate of 661676, except I believe in that case, once the options have been set the first time everything is fine. I can't reproduce this on Linux or W2K. Exactly what is your system configuration? I can reproduce the non-highlighting of the font selection right after first installation, but everything else looks ok to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 From noreply@sourceforge.net Mon May 26 23:14:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 15:14:13 -0700 Subject: [Idle-dev] [ idlefork-Bugs-742815 ] Problem with Slackware 9.0 Message-ID: Bugs item #742815, was opened at 2003-05-24 13:33 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Slackware 9.0 Initial Comment: I cannot use Menu ( File, Edition etc...) to open or save any files. This is what I get when I try to open a file with File : user1@darkstar:~/IDLEfork-0.9a2$ ./idle Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1299, in __call__ args = apply(self.subst, args) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1032, in _substitute e.num = getint(b) ValueError: invalid literal for int(): ?? Anyone any idea ? I am just very python newbie. Does exists a IDLE Slackware package ? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 17:14 Message: Logged In: YES user_id=149084 I believe there was a problem with Tk8.4.2 which was handled in Python2.3. If you are using Tk8.4 (check the IDLE About dialog) then I'd say move to Python2.3b1. See Python Patch 707701: http://sourceforge.net/tracker/? group_id=5470&atid=305470&func=detail&aid=707701 The rest of us are not seeing this problem, so it's probably something in your configuration. Try some simple Tk programs without using IDLE and see what happens. There is no Slackware package. 0.9a2 is pure Python, so if you follow the release notes on the SF IDLEfork Files page, you will have no problem with the installation. Use the tar.gz package. Good luck and welcome to Python! If this doesn't help, you might try asking at comp.lang.python, I'm sure someone is running Slackware. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 From noreply@sourceforge.net Mon May 26 23:15:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 15:15:58 -0700 Subject: [Idle-dev] [ idlefork-Bugs-742815 ] Problem with Slackware 9.0 Message-ID: Bugs item #742815, was opened at 2003-05-24 13:33 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 Category: None Group: None >Status: Pending Resolution: Postponed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Slackware 9.0 Initial Comment: I cannot use Menu ( File, Edition etc...) to open or save any files. This is what I get when I try to open a file with File : user1@darkstar:~/IDLEfork-0.9a2$ ./idle Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1299, in __call__ args = apply(self.subst, args) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1032, in _substitute e.num = getint(b) ValueError: invalid literal for int(): ?? Anyone any idea ? I am just very python newbie. Does exists a IDLE Slackware package ? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 17:14 Message: Logged In: YES user_id=149084 I believe there was a problem with Tk8.4.2 which was handled in Python2.3. If you are using Tk8.4 (check the IDLE About dialog) then I'd say move to Python2.3b1. See Python Patch 707701: http://sourceforge.net/tracker/? group_id=5470&atid=305470&func=detail&aid=707701 The rest of us are not seeing this problem, so it's probably something in your configuration. Try some simple Tk programs without using IDLE and see what happens. There is no Slackware package. 0.9a2 is pure Python, so if you follow the release notes on the SF IDLEfork Files page, you will have no problem with the installation. Use the tar.gz package. Good luck and welcome to Python! If this doesn't help, you might try asking at comp.lang.python, I'm sure someone is running Slackware. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=742815&group_id=9579 From kbk@users.sourceforge.net Mon May 26 23:20:40 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 26 May 2003 15:20:40 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.70,1.71 ScriptBinding.py,1.22,1.23 buildapp.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv15282 Modified Files: PyShell.py ScriptBinding.py buildapp.py Log Message: Whitespace Normalization Modified Files: PyShell.py ScriptBinding.py buildapp.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.70 retrieving revision 1.71 diff -C2 -r1.70 -r1.71 *** PyShell.py 24 May 2003 21:12:46 -0000 1.70 --- PyShell.py 26 May 2003 22:20:32 -0000 1.71 *************** *** 304,308 **** raise EOFError ! class ModifiedInterpreter(InteractiveInterpreter): --- 304,308 ---- raise EOFError ! class ModifiedInterpreter(InteractiveInterpreter): Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.22 retrieving revision 1.23 diff -C2 -r1.22 -r1.23 *** ScriptBinding.py 26 May 2003 06:23:10 -0000 1.22 --- ScriptBinding.py 26 May 2003 22:20:34 -0000 1.23 *************** *** 150,154 **** If the user has configured IDLE for Autosave, the file will be silently saved if it already exists and is dirty. ! """ filename = self.editwin.io.filename --- 150,154 ---- If the user has configured IDLE for Autosave, the file will be silently saved if it already exists and is dirty. ! """ filename = self.editwin.io.filename Index: buildapp.py =================================================================== RCS file: /cvsroot/idlefork/idle/buildapp.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** buildapp.py 17 May 2003 15:14:10 -0000 1.2 --- buildapp.py 26 May 2003 22:20:34 -0000 1.3 *************** *** 1,4 **** # ! # After running python setup.py install, run this program from the command # line like so: # --- 1,4 ---- # ! # After running python setup.py install, run this program from the command # line like so: # *************** *** 11,17 **** buildapp( ! name="IDLE", ! mainprogram="idle.py", ! argv_emulation=1, ! iconfile="Icons/idle.icns", ) --- 11,17 ---- buildapp( ! name="IDLE", ! mainprogram="idle.py", ! argv_emulation=1, ! iconfile="Icons/idle.icns", ) From noreply@sourceforge.net Tue May 27 01:59:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 17:59:41 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677260 ] Display of Startup option Message-ID: Bugs item #677260, was opened at 2003-01-30 03:49 Message generated for change (Comment added) made by bsherwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: Display of Startup option Initial Comment: In 0.9a2 on the General tab of the options menu, the current setting of the "On Startup" choice is not displayed. I'm able to set it, and it displays as long as I just move among the option tabs, but if I exit options and return to it there is no indication as to which choice is currently in effect. ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-27 00:59 Message: Logged In: YES user_id=34881 Works now for me, thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 21:46 Message: Logged In: YES user_id=149084 This is working for me on Python2.3/XP/Tk8.4, Python2.2/W2K/Tk8.3, and Python2.3/2.2/Linux/Tk8.3 Do you still see it? If so, please delete/rename your .idlerc/config-main.cfg and check again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 18:56 Message: Logged In: YES user_id=34881 When I try your test I get "8.4". I didn't do anything special -- I just installed Python 2.3a1, and apparently that's the version of Tk that comes with. I'll be happy to try to help in any way I can. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 18:17 Message: Logged In: YES user_id=149084 Hm. I may be in the position of trying to fix something that I can't reproduce :) I may need your help. What's your Tk version? >>> import Tkinter >>> Tkinter.TkVersion 8.3000000000000007 here.... ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 17:23 Message: Logged In: YES user_id=34881 I'm running Python 2.3 on Windows XP. It is completely reproducible that the Startup Preference choice on the General tab is never highlighted upon entering the Options menu, even after setting this option, clicking ok (or apply and ok), and then immediately returning to the General tab to see whether the choice is highlighted. On the other hand, if I set a new font and exit Options and return, I do see my font choice highlighted. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 16:16 Message: Logged In: YES user_id=149084 Duplicate of 661676, except I believe in that case, once the options have been set the first time everything is fine. I can't reproduce this on Linux or W2K. Exactly what is your system configuration? I can reproduce the non-highlighting of the font selection right after first installation, but everything else looks ok to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 From noreply@sourceforge.net Tue May 27 02:54:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 26 May 2003 18:54:52 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677260 ] Display of Startup option Message-ID: Bugs item #677260, was opened at 2003-01-29 22:49 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 Category: None Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: Display of Startup option Initial Comment: In 0.9a2 on the General tab of the options menu, the current setting of the "On Startup" choice is not displayed. I'm able to set it, and it displays as long as I just move among the option tabs, but if I exit options and return to it there is no indication as to which choice is currently in effect. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-26 19:59 Message: Logged In: YES user_id=34881 Works now for me, thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-26 16:46 Message: Logged In: YES user_id=149084 This is working for me on Python2.3/XP/Tk8.4, Python2.2/W2K/Tk8.3, and Python2.3/2.2/Linux/Tk8.3 Do you still see it? If so, please delete/rename your .idlerc/config-main.cfg and check again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 13:56 Message: Logged In: YES user_id=34881 When I try your test I get "8.4". I didn't do anything special -- I just installed Python 2.3a1, and apparently that's the version of Tk that comes with. I'll be happy to try to help in any way I can. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 13:17 Message: Logged In: YES user_id=149084 Hm. I may be in the position of trying to fix something that I can't reproduce :) I may need your help. What's your Tk version? >>> import Tkinter >>> Tkinter.TkVersion 8.3000000000000007 here.... ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-01-30 12:23 Message: Logged In: YES user_id=34881 I'm running Python 2.3 on Windows XP. It is completely reproducible that the Startup Preference choice on the General tab is never highlighted upon entering the Options menu, even after setting this option, clicking ok (or apply and ok), and then immediately returning to the General tab to see whether the choice is highlighted. On the other hand, if I set a new font and exit Options and return, I do see my font choice highlighted. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:16 Message: Logged In: YES user_id=149084 Duplicate of 661676, except I believe in that case, once the options have been set the first time everything is fine. I can't reproduce this on Linux or W2K. Exactly what is your system configuration? I can reproduce the non-highlighting of the font selection right after first installation, but everything else looks ok to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677260&group_id=9579 From noreply@sourceforge.net Tue May 27 16:14:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 27 May 2003 08:14:57 -0700 Subject: [Idle-dev] [ idlefork-Bugs-677263 ] On W32 Can't Terminate Subprocess Not Doing IO Message-ID: Bugs item #677263, was opened at 2003-01-29 23:02 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 8 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: On W32 Can't Terminate Subprocess Not Doing IO Initial Comment: With 0.9a2 it is still the case that something is very wrong with the run environment for VPython programs, at least on Windows. I run the simplest program from visual import * sphere() Next I kill the graphics display window (by clicking in the close box), then type in the shell "2+2". I get the following: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 187, in asynccall self.putmessage((seq, request)) File "C:\Python23\Lib\site-packages\idleforklib\rpc.py", line 289, in putmessage n = self.sock.send(s) File "", line 1, in send error: (10054, 'Connection reset by peer') I then try to kill the shell window and get a dialog box asking this: "The program is still running; do you want to kill it?" I say I want to kill it, the dialog box goes away, but nothing happens to the shell window. The only way I can kill Python is with the Windows task manager. Even independent of what may be special about a VPython program, shouldn't IDLE honor the request to kill? I emphasize that with the original idlefork when one killed a VPython graphics window you were in a good state. Another possible hint at the source of the new problem is that with the original idlefork after F5 to run I could press F5 and the existing graphics window would be killed and I'd get a new spawned process. Now I seem to get two spawned processes in this situation. http://vpython.org is a place to get the VPython stuff. I have no idea whether the problem is in some sense with VPython or with the new idlefork. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-26 04:17 Message: Logged In: YES user_id=112690 umpf. "Just for the record, Kaspersky Antivirus seriously affects Python's performance." I meant, "affects a Python program running under Idlefork" and it really depends on the AV config. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-26 04:07 Message: Logged In: YES user_id=112690 Freddy's gone. :-) Tested in 2 different PCs (both Win2K), works ok. (Just for the record, Kaspersky Antivirus seriously affects Python's performance.) Thanks and Regards, -Hernan ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-24 16:17 Message: Logged In: YES user_id=149084 OK, I checked in an update. Give it a shot. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-19 22:22 Message: Logged In: YES user_id=149084 Hernan, no, save your testing time for when I think I've got it nailed. That should be soon, I think it's working here on my XP box. I'll let you know here. The problem would have started when I started processing user code in MainThread instead of SockThread on 11 May, but that's not too important at this point. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 15:58 Message: Logged In: YES user_id=112690 kurt: do you want me to test a special cvs version between the current one and 0.9a2 ? it seems that the problem fires since some version in between. -H. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-19 08:37 Message: Logged In: YES user_id=112690 more data: file test2plus2.py: print 2 + 2 on a different win2K pro where there were no python up to date, did the following: - install python 2.2.2, then idlefork-0.92, load and run test2plus2.py result: only 2 pythonw.exe, *always*. - install python 2.3, then idlefork-0.92 (it works, kurt), load and run test2plus2.py result: only 2 pythonw.exe, *always*. - idlefork from CVS May,19th. on python 2.3 Lib/site- packages/idle ; interrupt.pyd as posted; load and run test2plus2.py result: one pythonw.exe adds to the process list on every F5 i don't know if it's relevant, but this PC has a Visual Studio .NET installed. no debug kernel, though. -H. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:35 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-18 20:09 Message: Logged In: YES user_id=149084 Hernan, there is no need for a bug report because there is no interrupt module required for 0.9a2, and I am very well aware that it needs to be compiled for the next release. In fact, it is not possible to generate a bdist_wininst without that happening! The source is in the IDLEfork directory: interruptmodule.c Ok, I finally got to the end of the row bringing Python and IDLEfork up on the new 2.4GHz P4 XP box. Started with a floppy drive which wouldn't write, and ended with the Microsoft server down when trying to get VC5 SP3. So my fritter factor (defined as ratio of time dorking with computer to time doing something useful) has been infinite most of the day. I can say that moving the interrupt.pyd from W2K/Py2.2 to XP/Py2.3 doesn't work, Python2.3 can't import it. Also, the Windows installer created on Python2.2 won't install on a Py2.3 system because "Python2.2 is not in the registry." But I finally got the extension compiled. Hopefully a windows installer built on Py2.3 will work on 2.2, but maybe I need to supply both. We'll see. And I'm happy to report that I see the problem as described by Bruce. So now I've got something to work on. I've already got it down to something happening just after rpc.SocketIO.handle_EOF tries to interrupt the MainThread: invalid command name "11153040callit" while executing "11153040 callit" (after script)........ It's curious that you guys can see it on W2K and I cannot. But anyway, down to it. And yes, that is the simple test. Start with a shell and exit. The GUI drops the link and the subprocess is supposed to see that and exit. You expect to see two processes after the shell opens because the subprocess is spawned when it does. And you expect to see none when IDLEfork exits! ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 17:08 Message: Logged In: YES user_id=112690 bruce: yes, i know the setup.py thing. i don't have a c compiler at home, so i can't build the dll myself. thanks for uploading the .pyd. kurt: i'm going to report a bug of the missing interrupt.pyd in the win32 alpha distro as a reminder just in case there is another package build before the merge. bruce & kurt: performance degrades on subsequent hits of F5. as kurt pointed out, i can see precisely this: "As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%." those zombies keep running even after exiting IDLE. btw, does pythonw.exe work there? i can only start idle in windows in the command line using the standard interpreter (python.exe) w2K pro, PIII 900 mhz python 2.3, idlefork extracted from CVS on May, 18th ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:35 Message: Logged In: YES user_id=34881 Oops. Failed to attach interrupt.pyd. I'll try again. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 15:34 Message: Logged In: YES user_id=34881 At the risk of giving unneeded information: You might not realize (as I did not realize) that you have to install using the distutil feature of Python. Open a command prompt, cd to the folder where you have the downloaded the files from CVS, and execute this: c:\python23\python.exe setup.py install Assuming you have an appropriate C compiler on your PC, this will produce the binary and copy it to c:\python23\Lib\site- packages\interrupt.pyd, and all other needed files to c:\python23\Lib\site-packages\idlelib. If you don't have an appropriate C compiler (I have Microsoft Visual Studio 6, which works), then indeed you need a binary distribution. In the hopes that this would help, I've uploaded my own c:\python23\Lib\site-packages\interrupt.pyd ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-05-18 13:52 Message: Logged In: YES user_id=112690 i tried to help but failed. first installed a fresh python 2.3, later download the last idelfork CVS. idlefork didn't load. i don't have the interrupt binary library. and it seems that it's missing in the alpha binary distrib also (IDLEfork-0.9a2.win32.exe) regards, -hernan ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-18 10:40 Message: Logged In: YES user_id=34881 I tried the latest CVS idlefork (downloaded 11 am May 18) on a Win2000 machine with Python 2.3. Same catastrophic behavior as on my XP machine. Both machines are 500 MHz. Additional detail: After trying various other sequences, I tried the very simplest test I could think of. Set preferences to start in shell. Quit. Start up (in shell). I see two pythons--is that correct at the start, before doing anything? Without doing anything else, I choose the File/Exit menu option. The window disappears, but I'm left with a zombie python still up. Could some people besides Kurt and me please try the latest idlefork on various Win systems? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 22:17 Message: Logged In: YES user_id=149084 On W2K 500MHz P3 it normally takes about 2 sec to restart the subprocess and print something. A 233Mhz P2 Linux box is somewhat faster. The slow start you are seeing is completely abnormal and seems to be caused by the newly spawned process fighting for the socket. There's a time-out somewhere. I see it also if I do something that causes the subprocess to block when the link is dropped by the GUI (that's how the GUI signals an exit). As far as the cpu being 100%, that is expected because the subprocess is in a pass loop waiting for termination. Normally that happens in a few millisec but in your case the subprocess MainThread seems to be blocking and so the SockThread never gets killed. As you create more and more pseudo-zombies, they share the cpu equally. So you may see e.g. three each getting 33%. There are more sophisticated ways of doing the wait, e.g. join the MainThread, but the spin gives a good indication of what's going on for now. Normally it only lasts a few ms, as I said. All of what you are seeing is abnormal. I don't see anything like that here. Clearly a long restart is unusable. So is leaving a mess of stuck processes behind. OK, time to fire up the XP box here. Thanks very much for your help on this. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 20:17 Message: Logged In: YES user_id=34881 I tried run.py 1.18 and it's just as bad. The quit problem presumably has a solution. But what about the extremely serious problems that it takes 30 seconds to get output, and that after reaching the end of the program the CPU is pinned at 100%? Or are these problems related to the quit problem? The 30-second delay in getting output would make idlefork unusable as a programming environment. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 17:49 Message: Logged In: YES user_id=149084 BTW, with the original IDLEfork the subprocess terminates when the user code runs off the end. In the current implementation it doesn't; the shell stays connected to the subprocess so you can examine the final environment. That's why you only see the one pythonw.exe in the original version. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 16:15 Message: Logged In: YES user_id=149084 I've checked in run.py 1.18, give it a try (though I don't have much hope...) I imagine you are starting up with just an edit window. In that case you will see one pythonw.exe. Once you run the program the GUI will open a shell/output window and spawn the subprocess. Every time you re-run the code the subprocess is terminated and a new one spawned. So what you normally see from then on is two pythonw.exe. Nothing to be alarmed about. Now, if for some reason the MainThread can't exit on Windows the GUI process loses track of it and it just sits there and spins. Every time the subprocess is restarted, another pseudo-zombie is created. On W2K I can do all sorts of terrible things: put the subprocess into a pass loop or a print loop and then kill the GUI with the task manager. When I do that, the subprocess exits OK. But on your system, it seems the MainThread is getting blocked somehow. Try the new run.py and let me know. If it doesn't work, I have a nice fast XP box I built a while ago which I haven't had time to install Python on. Thanks for spending the time to help on this! Freddy has been holding up the release for a month. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:59 Message: Logged In: YES user_id=34881 One other comment: With the original idlefork, running my trivial program (print 2+2) brings up a 2nd pythonw.exe very briefly, but it then quickly goes away as soon as the"4" is printed, leaving only one copy active. It is somewhat alarming that with the new idlefork there are THREE copies of idlefork, and neither of the additional two copies goes away after the "4" is printed. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 12:54 Message: Logged In: YES user_id=34881 I replaced os._exit(0) with return, and that didn't fix it. I also installed idlefork with Python 2.2 and verified that behavior is identical on 2.2 and 2.3 on Windows XP. More details: It takes only a few seconds for the shell/output window to open (corresponding to the 2nd copy of pythonw.exe starting to run). It takes another 30 seconds before I see the output of my tiny program (print 2+2), and this corresponds to seeing in the system monitor the 3rd copy of pythonw.exe very slowly starting up, with its memory allocation growing very slowly until at about 5.7 MB I see my output. Thereafter CPU usage is pinned at 100%. I then quit either by clicking the close boxes on the two windows or by choosing the Exit menu option in one of the windows. The first pythonw.exe quits, but the 2nd and 3rd copies stay up and consume 100% of the CPU. I have to kill them in the system monitor. Now what? Note that it isn't just the quitting that fails catastrophically. There are two other very serious problems: It takes a very long time to get output (30 seconds), and there is 100% CPU usage even before I try to quit the program. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-17 10:05 Message: Logged In: YES user_id=149084 I assume you can see this if you just restart the shell without running any program. CVS works fine on W2K. But if I replace run.py:56 os._exit(0) with sys.exit(0), then the subprocess hangs as you are seeing. That's why I used os._exit. It appears something changed between Py2.2/2.3 and/or W2K/XP and os._exit() on your box is acting like sys.exit() on my setup. The way this works is when SockThread gets an EOF due to the link being closed by the GUI, it sets the global exit_requested and goes into a pass loop waiting for the MainThread to terminate the whole process. Every 10 bytecodes the MainThread gets control and checks exit_requested. If True, it exits and is supposed to take the SockThread with it since it's setDaemon. But if the MainThread exits without shutting down SockThread the latter just spins, taking 100%, which is what you are seeing. If I exit the SockThread instead of waiting, there are other problems due to the Server objects disappearing when then are still needed by MainThread and its various socket threads (Thread-1, Thread-2 etc) not having wrapped up communication. That also causes hangs. Try this, it works on my system: replace run.py:56 os._exit(0) with run.py:56 return. We'll let Python decide how to exit. ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-17 08:26 Message: Logged In: YES user_id=34881 I do have run.py Rev 1.17. I got everything from CVS on 5/16. And I've checked by hand that I do have the addition of "except KeyboardInterrupt" in my copy of run.py. So that's not the explanation. What should I try now? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 17:15 Message: Logged In: YES user_id=149084 It's critical that you have run.py Rev 1.17 which was checked in 2003/05/14 18:15:40to fix this problem. The relevant line is run.py:65 except KeyboardInterrupt: This line and the except clause following must be present. Without this, the restart doesn't work because the subprocess SockThreadstops servicing the socket while the MainThread is trying to print an exception. I was seeing the same before the fix. Freddy's baaack? ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2003-05-16 16:44 Message: Logged In: YES user_id=34881 On Windows XP I installed Python 2.3 and idlefork from CVS. I see massive problems. Minimal program "print 2+2" takes 30 seconds or more after pressing F5 before I see the output (consuming 100% of the CPU all the while), and even after seeing the output the system monitor shows me consuming 100% of the CPU. I then close both windows (source and output), and I'm left with two instances of python.exe which together or singly consume 100% of the CPU, and I have to kill them in the system monitor. Is there something I'm missing about installation? I have the idlefork package in C:\Python23\idle. I did run C:\Python23\python.exe setup.py install inside the idle directory in order to get the interrupt module compiled. I assume that I have all the pieces in that I did get output. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-14 22:48 Message: Logged In: YES user_id=149084 Please try current CVS and report any problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-04-01 00:51 Message: Logged In: NO More on run/kill issues: When I'm running my Tkinter app and editing the source code, idlefork will sometimes hang when looking up a CallTip. The IDLE windows won't redraw until I kill my app, and then the editor is in a confused state. I can't evaluate expressions in the shell or restart the program. I also can't restart the shell. I'm using Win32. I think I'll get around to investigating this more and typing up a bug report, but I was hoping this little bit would help some. Randall Farmer, rfarmer@simons-rock.spam.edu ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-30 11:24 Message: Logged In: YES user_id=149084 I changed the title, this isn't just a VPython issue. I can confirm what you are seeing, and I have some ideas on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=677263&group_id=9579 From kbk@users.sourceforge.net Wed May 28 02:47:49 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 27 May 2003 18:47:49 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.71,1.72 config-main.def,1.17,1.18 run.py,1.19,1.20 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv2014 Modified Files: PyShell.py config-main.def run.py Log Message: Added a config-main General option to delete sys.exitfunc. The default is not to do that. VPython and student environment support. M PyShell.py M config-main.def M run.py Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.71 retrieving revision 1.72 diff -C2 -r1.71 -r1.72 *** PyShell.py 26 May 2003 22:20:32 -0000 1.71 --- PyShell.py 28 May 2003 01:47:46 -0000 1.72 *************** *** 313,316 **** --- 313,317 ---- self.save_warnings_filters = None self.restarting = False + self.subprocess_arglist = self.build_subprocess_arglist() port = 8833 *************** *** 319,323 **** def spawn_subprocess(self): ! args = self.build_subprocess_arglist() self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) --- 320,324 ---- def spawn_subprocess(self): ! args = self.subprocess_arglist self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) *************** *** 327,334 **** # or maybe it's not installed and the idle.py script is being # run from the IDLE source directory. if __name__ == 'idlelib.PyShell': ! command = "__import__('idlelib.run').run.main()" else: ! command = "__import__('run').main()" return [sys.executable] + w + ["-c", command, str(self.port)] --- 328,337 ---- # or maybe it's not installed and the idle.py script is being # run from the IDLE source directory. + del_exitf = idleConf.GetOption('main', 'General', 'delete-exitfunc', + default=False, type='bool') if __name__ == 'idlelib.PyShell': ! command = "__import__('idlelib.run').run.main(" + `del_exitf` +")" else: ! command = "__import__('run').main(" + `del_exitf` + ")" return [sys.executable] + w + ["-c", command, str(self.port)] Index: config-main.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-main.def,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** config-main.def 26 May 2003 20:35:53 -0000 1.17 --- config-main.def 28 May 2003 01:47:46 -0000 1.18 *************** *** 44,47 **** --- 44,48 ---- print-command-posix=lpr %s print-command-win=start /min notepad /p %s + delete-exitfunc= 0 [EditorWindow] Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.19 retrieving revision 1.20 diff -C2 -r1.19 -r1.20 *** run.py 24 May 2003 20:59:15 -0000 1.19 --- run.py 28 May 2003 01:47:46 -0000 1.20 *************** *** 25,29 **** quitting = False ! def main(): """Start the Python execution server in a subprocess --- 25,29 ---- quitting = False ! def main(del_exitfunc=False): """Start the Python execution server in a subprocess *************** *** 45,48 **** --- 45,50 ---- global exit_now global quitting + global no_exitfunc + no_exitfunc = del_exitfunc port = 8833 if sys.argv[1:]: *************** *** 58,62 **** if exit_now: try: ! sys.exit(0) except KeyboardInterrupt: # exiting but got an extra KBI? Try again! --- 60,64 ---- if exit_now: try: ! exit() except KeyboardInterrupt: # exiting but got an extra KBI? Try again! *************** *** 84,88 **** # Link didn't work, print same exception to __stderr__ traceback.print_exception(type, value, tb, file=sys.__stderr__) ! sys.exit(0) else: continue --- 86,90 ---- # Link didn't work, print same exception to __stderr__ traceback.print_exception(type, value, tb, file=sys.__stderr__) ! exit() else: continue *************** *** 160,163 **** --- 162,175 ---- pass + def exit(): + """Exit subprocess, possibly after first deleting sys.exitfunc + + If config-main.cfg/.def 'General' 'delete-exitfunc' is True, then any + sys.exitfunc will be removed before exiting. (VPython support) + + """ + if no_exitfunc: + del sys.exitfunc + sys.exit(0) class MyRPCServer(rpc.RPCServer): *************** *** 187,191 **** print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 ! sys.exit(0) --- 199,203 ---- print>>erf, '\n*** Unrecoverable, server exiting!' print>>erf, '-'*40 ! exit() *************** *** 230,234 **** except: if quitting: ! sys.exit(0) # even print a user code SystemExit exception, continue print_exception() --- 242,246 ---- except: if quitting: ! exit() # even print a user code SystemExit exception, continue print_exception() From noreply@sourceforge.net Thu May 29 15:27:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 07:27:36 -0700 Subject: [Idle-dev] [ idlefork-Bugs-745525 ] current working directory Message-ID: Bugs item #745525, was opened at 2003-05-29 14:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=745525&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: current working directory Initial Comment: I'm not sure whether this is a bug or a feature, but it represents a significant change from the original idlefork. Put this at the start of a file and run it: import os print os.getcwd() In the past this was the directory where the file is saved, but now it is always the starting directory for IDLE (on Windows, the directory specified in the "Start in:" property of the shortcut used to start IDLE), independent of where the file is stored. This makes it awkward to test and run programs that do simple file I/O in the program's own directory, where in the past it was sufficient just to do an open on the data file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=745525&group_id=9579 From noreply@sourceforge.net Thu May 29 21:19:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 29 May 2003 13:19:01 -0700 Subject: [Idle-dev] [ idlefork-Bugs-745525 ] Current Working Directory Message-ID: Bugs item #745525, was opened at 2003-05-29 09:27 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=745525&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Bruce Sherwood (bsherwood) >Assigned to: Kurt B. Kaiser (kbk) >Summary: Current Working Directory Initial Comment: I'm not sure whether this is a bug or a feature, but it represents a significant change from the original idlefork. Put this at the start of a file and run it: import os print os.getcwd() In the past this was the directory where the file is saved, but now it is always the starting directory for IDLE (on Windows, the directory specified in the "Start in:" property of the shortcut used to start IDLE), independent of where the file is stored. This makes it awkward to test and run programs that do simple file I/O in the program's own directory, where in the past it was sufficient just to do an open on the data file. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-29 15:19 Message: Logged In: YES user_id=149084 Currently it's working the same way as Python IDLE but different from VPython IDLE. There are three possibilities: 1. Only change directory when the user issues a change directory command. This is what Unix people expect, and this is what Python IDLE does. The working directory is the one where you started IDLE. 2. Change directory when opening a file. This seems to be what Windows does. Your working directory is that of the last file you opened. This has advantages because it's *really* hard to change directory on Windows otherwise if you are not using a Command window. You have to set .py to associate with IDLE and fiddle with Folder Options / File Types / Advanced, I think, and then diddle the PATH environment variable. 3. Change directory when running a program; change to the directory of the program. This is what VPython IDLE does via Remote.py. This has the disadvantage that if you happen to be calling a script from another directory, you will be abruptly and surprisingly chdir'd to, say, python22/lib/site-packages/ scripts. I think adhering to the principle of least surprise is the right thing to do, but in this case the amount of surprise depends on which platform you are used to. Now, if you were using pure Python you would not expect a cd to the directory of the script!! When I fixed Bug 706860 I noted that the submitter was not sure whether a chdir was warranted, and he's a Windows man. But at least we now have the script's directory on sys.path. To me, the aggravation comes as follows: I open IDLEfork, then open a file in my working directory under My Documents. Then I start a new file to continue the project, go to save it, and IDLEfork wants to save it to the "start in" directory. This is closely related to your complaint, and we may be able to handle both with the same solution. My preference would be #2 above. Change directory every time a file is opened with the file open browser. But don't change directory if IDLE is fed a script from the command line. I wonder what other people think about this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=745525&group_id=9579 From hernan@orgmf.com.ar Thu May 29 22:13:36 2003 From: hernan@orgmf.com.ar (Hernan Martinez Foffani) Date: Thu, 29 May 2003 23:13:36 +0200 Subject: [Idle-dev] RE: Current Working Directory In-Reply-To: Message-ID: >> Comment By: Kurt B. Kaiser (kbk) > > My preference would be #2 above. Change > directory every time a file is opened with the > file open browser. heh... it'd also be a way to chdir without typing. mmmm... right now if you have different py scripts opened in idlefork, next time you open the file browser the default dir corresponds to the file being edited. will that change? > But don't change directory if IDLE is fed a script > from the command line. Ok. regards, -Hernan From kbk@shore.net Fri May 30 00:35:07 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Thu, 29 May 2003 19:35:07 -0400 Subject: [Idle-dev] RE: Current Working Directory In-Reply-To: ("Hernan Martinez Foffani"'s message of "Thu, 29 May 2003 23:13:36 +0200") References: Message-ID: "Hernan Martinez Foffani" writes: > mmmm... right now if you have different py scripts > opened in idlefork, next time you open the file > browser the default dir corresponds to the file > being edited. will that change? Yes, that seems to be the way Windows does it. Whatever directory you open/save to last becomes the cwd. This seems to be per application. i.e. the cwd is local to the app. __ KBK From kbk@users.sourceforge.net Fri May 30 03:42:05 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 29 May 2003 19:42:05 -0700 Subject: [Idle-dev] CVS: idle CREDITS.txt,1.6,1.7 INSTALL.txt,1.7,1.8 LICENSE.txt,1.1,1.2 aboutDialog.py,1.9,1.10 setup.py,1.14,1.15 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv13413 Modified Files: CREDITS.txt INSTALL.txt LICENSE.txt aboutDialog.py setup.py Log Message: Update for release Modified Files: CREDITS.txt INSTALL.txt LICENSE.txt aboutDialog.py setup.py Index: CREDITS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/CREDITS.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** CREDITS.txt 17 May 2003 03:15:48 -0000 1.6 --- CREDITS.txt 30 May 2003 02:42:02 -0000 1.7 *************** *** 21,27 **** integration and persistent breakpoints). ! Hernan Foffani, Christos Georgiou, Martin v. Loewis, Jason Orendorff, ! Noam Raphael, Josh Robb, and Bruce Sherwood have submitted useful patches. ! Thanks, guys! There are others who should be included here, especially those who contributed --- 21,27 ---- integration and persistent breakpoints). ! Hernan Foffani, Christos Georgiou, Martin v. Loewis, Jason Orendorff, Noam ! Raphael, Josh Robb, Nigel Rowe, and Bruce Sherwood have submitted useful ! patches. Thanks, guys! There are others who should be included here, especially those who contributed Index: INSTALL.txt =================================================================== RCS file: /cvsroot/idlefork/idle/INSTALL.txt,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** INSTALL.txt 13 May 2003 15:28:21 -0000 1.7 --- INSTALL.txt 30 May 2003 02:42:02 -0000 1.8 *************** *** 6,58 **** There are several distribution files (where xx is the subversion): ! IDLEfork-0.9xx.win32.exe ! This is a Windows installer which will install IDLEfork in ! ..../site-packages/idleforklib/ and place the idefork startup script ! at ..../scripts/idlefork. Rename this to idlefork.pyw and ! point your launcher icons at it. Installation is as idlefork ! to avoid conflict with the original Python IDLE. ! ! IDLEfork-0.9xx-1.noarch.rpm ! This is an rpm which is designed to install as idleforklib in an ! existing /usr/lib/python2.2 tree. It installs as idlefork to avoid ! conflict with Python IDLE. ! ! Python rpms are available at http://www.python.org/2.2.2/rpms.html and ! http://www.python.org/2.2.1/rpms.html. IDLEfork-0.9xx.tar.gz This is a distutils sdist (source) tarfile which can be used to make ! installations on platforms not supported by the above files. ! ** It remains configured to install as idlelib, not idleforklib. ** Unpack in ..../Tools/, cd to the IDLEfork directory created, and ! "python setup.py install" to install in ....site-packages/idlelib. ! This will overwrite the Python IDLE installation. - If you don't want to overwrite Python IDLE, it is also possible to - simply call "python idle.py" to run from the IDLEfork source directory - without making an installation. In this case, IDLE will not be on - your PATH unless you are in the source directory. Also, it is then - advisable to remove any Python IDLE installation by removing - ..../site-packages/idlelib so the two identically named packages don't - conflict. On Redhat Linux systems prior to 8.0, /usr/bin/python may be pointing at python1.5. If so, change the first line in the /usr/bin/idle script to read: !# /usr/bin/python2.2 On Mac OS X, /usr/bin/python may be pointing at the OS-installed python, which does not have GUI support. Change the first line of /usr/bin/idle to read: #! /usr/bin/env pythonw Also, to build an IDLE application that can be used from the Finder on Mac OS X, run: pythonw buildapp.py build open build You will see an IDLE application. ! See README.txt for more details on this version of IDLEfork. --- 6,88 ---- There are several distribution files (where xx is the subversion): ! IDLEfork-0.9xx.win32-py2.2.exe ! IDLEfork-0.9xx.win32-py2.3.exe ! ! These are Windows installers which will install IDLEfork in ! ..../site-packages/idleforklib/ and place the idefork startup script at ! ..../scripts/idlefork. Rename this script to idlefork.pyw and point ! your launcher icons at it. Installation is as idlefork to avoid ! conflict with the original Python IDLE. Choose the installer ! appropriate for your version of Python. IDLEfork-0.9xx.tar.gz This is a distutils sdist (source) tarfile which can be used to make ! installations on non-Windows platforms, or on Windows if a custom ! installation is desired. It installs as idlefork and will not ! conflict with Python IDLE. Unpack in ..../Tools/, cd to the IDLEfork directory created, and ! "python setup.py install" to install in ....site-packages/idleforklib. ! ! IDLE-0.9xx.tar.gz ! This is also a distutils sdist (source) tarfile. ! ! ** It remains configured to install as idlelib, not idleforklib. ** ! ! First, remove your existing ..../site-packages/idlelib directory. ! ! Unpack in ..../Tools/, cd to the IDLE directory (note the caps) ! created, and "python setup.py install" to install in ! ....site-packages/idlelib. This will replace the Python IDLE ! installation. ! ! If you don't want to overwrite Python IDLE, I'd recommend using the ! IDLEfork release mentioned above. However, it is also possible to ! simply build IDLE without installing it: "python setup.py build" and ! then copy the interrupt.so library out of the build directory into the ! IDLE directory where IDLE can find it, ! ! In this case, IDLE will not be on your PATH unless you are in the ! source directory. Either append your PATH or use a fully qualified ! path to access IDLE, something like ! ! python /usr/bin/python/Tools/IDLE/idle.py ! ! That way you can continue to use the original IDLE at ! ..../Tools/idle/idle.py if you like. (note lower case) ! ! Using this approach, it's possible to have many different versions ! of IDLE on your system at the same time, for comparison/test. On Redhat Linux systems prior to 8.0, /usr/bin/python may be pointing at python1.5. If so, change the first line in the /usr/bin/idle script to read: + !# /usr/bin/python2.2 + + An RPM has not been released since with addition of the interrupt + extension it is no longer platform/architecture independent. The + distutils make it easy to build and install from the .tar.gz + distribution. Certainly it's just as easy as installing the rpm. + + On Mac OS X, /usr/bin/python may be pointing at the OS-installed python, which does not have GUI support. Change the first line of /usr/bin/idle to read: + #! /usr/bin/env pythonw Also, to build an IDLE application that can be used from the Finder on Mac OS X, run: + pythonw buildapp.py build open build + You will see an IDLE application. + ! See README.txt and NEWS.txt for more details on this version of IDLEfork. Index: LICENSE.txt =================================================================== RCS file: /cvsroot/idlefork/idle/LICENSE.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** LICENSE.txt 11 Aug 2001 07:44:28 -0000 1.1 --- LICENSE.txt 30 May 2003 02:42:02 -0000 1.2 *************** *** 1,11 **** To apply this license to IDLE or IDLEfork, read 'IDLE' or 'IDLEfork' ! for every occurence of 'Python 2.1.1' in the text below. ! PSF LICENSE AGREEMENT ! --------------------- 1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and ! otherwise using Python 2.1.1 software in source or binary form and its associated documentation. --- 1,11 ---- To apply this license to IDLE or IDLEfork, read 'IDLE' or 'IDLEfork' ! for every occurence of 'Python 2.3' in the text below. ! PSF LICENSE AGREEMENT FOR PYTHON 2.3 ! ------------------------------------ 1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and ! otherwise using Python 2.3 software in source or binary form and its associated documentation. *************** *** 13,38 **** hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, ! prepare derivative works, distribute, and otherwise use Python 2.1.1 alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) ! 2001 Python Software Foundation; All Rights Reserved" are retained in ! Python 2.1.1 alone or in any derivative version prepared by Licensee. 3. In the event Licensee prepares a derivative work that is based on ! or incorporates Python 2.1.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of ! the changes made to Python 2.1.1. ! 4. PSF is making Python 2.1.1 available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS ! FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 2.1.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON ! 2.1.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS ! A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 2.1.1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. --- 13,39 ---- hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, ! prepare derivative works, distribute, and otherwise use Python 2.3 alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) ! 2001, 2002, 2003 Python Software Foundation; All Rights Reserved" are ! retained in Python 2.3 alone or in any derivative version prepared by ! Licensee. 3. In the event Licensee prepares a derivative work that is based on ! or incorporates Python 2.3 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of ! the changes made to Python 2.3. ! 4. PSF is making Python 2.3 available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS ! FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 2.3 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON ! 2.3 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS ! A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 2.3, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. *************** *** 46,50 **** products or services of Licensee, or any third party. ! 8. By copying, installing or otherwise using Python 2.1.1, Licensee agrees to be bound by the terms and conditions of this License Agreement. --- 47,51 ---- products or services of Licensee, or any third party. ! 8. By copying, installing or otherwise using Python 2.3, Licensee agrees to be bound by the terms and conditions of this License Agreement. Index: aboutDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/aboutDialog.py,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** aboutDialog.py 31 Dec 2002 16:03:22 -0000 1.9 --- aboutDialog.py 30 May 2003 02:42:02 -0000 1.10 *************** *** 61,69 **** labelDesc.grid(row=2,column=0,sticky=W,columnspan=3,padx=10,pady=5) labelCopyright = Label(frameBg, ! text="Copyright (c) 2001 Python Software Foundation;\nAll Rights Reserved", justify=LEFT,fg=self.fg,bg=self.bg) labelCopyright.grid(row=3,column=0,sticky=W,columnspan=3,padx=10,pady=5) labelLicense = Label(frameBg, ! text='Released under the Python 2.1.1 PSF Licence', justify=LEFT,fg=self.fg,bg=self.bg) labelLicense.grid(row=4,column=0,sticky=W,columnspan=3,padx=10,pady=5) --- 61,69 ---- labelDesc.grid(row=2,column=0,sticky=W,columnspan=3,padx=10,pady=5) labelCopyright = Label(frameBg, ! text="Copyright (c) 2001 - 2003 Python Software Foundation\nAll Rights Reserved", justify=LEFT,fg=self.fg,bg=self.bg) labelCopyright.grid(row=3,column=0,sticky=W,columnspan=3,padx=10,pady=5) labelLicense = Label(frameBg, ! text='Released under the Python 2.3 PSF License', justify=LEFT,fg=self.fg,bg=self.bg) labelLicense.grid(row=4,column=0,sticky=W,columnspan=3,padx=10,pady=5) Index: setup.py =================================================================== RCS file: /cvsroot/idlefork/idle/setup.py,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** setup.py 10 Mar 2003 20:41:07 -0000 1.14 --- setup.py 30 May 2003 02:42:02 -0000 1.15 *************** *** 105,108 **** --- 105,110 ---- the RPC was changed to incorporate code by GvR, which supports the debugger. IDLEfork also incorporates a GUI configuration utilility. + It is written in almost pure Python :-P + For further details, refer to idlefork.sourceforge.net. """, From kbk@shore.net Fri May 30 04:06:36 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Thu, 29 May 2003 23:06:36 -0400 Subject: [Idle-dev] Testing Contributions Message-ID: I'd like to acknowledge the work that Bruce Sherwood and Hernan Foffani have done over the last couple of weeks helping me test the new subprocess on Windows. Without their help, I'm sure that I would have released a broken package. I know you are all tired of your mailboxes filling up with the "On W32 can't terminate..." stuff. It's too bad SF can't just send the diffs on the bugs and patches. Thanks again, guys!! -- KBK From hernan@orgmf.com.ar Fri May 30 07:35:15 2003 From: hernan@orgmf.com.ar (Hernan Martinez Foffani) Date: Fri, 30 May 2003 08:35:15 +0200 Subject: [Idle-dev] RE: Current Working Directory In-Reply-To: Message-ID: [KBK] > [me] >> mmmm... right now if you have different py scripts >> opened in idlefork, next time you open the file >> browser the default dir corresponds to the file >> being edited. will that change? > > Yes, that seems to be the way Windows does it. Whatever > directory you open/save to last becomes the cwd. > > This seems to be per application. i.e. the cwd is local to the app. I'm afraid that that would also change directory for "Save", "Save As", "Save Copy As" and "Find in Files", right? The change you propose sounds good if you only work with one file at a time. But suppose you open a python library file just for the sake of cheeting some code, you are back to your working script and the cwd changed. MHO is only change dir per explicit user request. Ideally, file operations ("Open", "Save", "Save As", "Save Copy As" and "Find in Files") in the Idlefork Shell window defaults to the current working directory. File operations in Idlefork Editor windows defaults to the absolute path of the editing file. "Run" operations uses the CWD application wide, of course. This picture completes with a "Change Current Dir" menu item under "File" (or under "Run"!) menu along with a way to see which is it and a "Shell Start Dir" user config option. But that's my (an) opinion, NOT a feature request. (I haven't thought the case where Idlefork starts without a shell window neither) regards, -Hernan From guido@python.org Fri May 30 12:56:58 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 30 May 2003 07:56:58 -0400 Subject: [Idle-dev] RE: Current Working Directory In-Reply-To: "Your message of Fri, 30 May 2003 08:35:15 +0200." References: Message-ID: <200305301156.h4UBuwp15182@pcp02138704pcs.reston01.va.comcast.net> > [KBK] > > [me] > >> mmmm... right now if you have different py scripts > >> opened in idlefork, next time you open the file > >> browser the default dir corresponds to the file > >> being edited. will that change? > > > > Yes, that seems to be the way Windows does it. Whatever > > directory you open/save to last becomes the cwd. > > > > This seems to be per application. i.e. the cwd is local to the app. > > I'm afraid that that would also change directory for > "Save", "Save As", "Save Copy As" and "Find in Files", right? > > The change you propose sounds good if you only work with one > file at a time. But suppose you open a python library file > just for the sake of cheeting some code, you are back > to your working script and the cwd changed. > > MHO is only change dir per explicit user request. > Ideally, file operations ("Open", "Save", "Save As", > "Save Copy As" and "Find in Files") in the Idlefork Shell window > defaults to the current working directory. > File operations in Idlefork Editor windows defaults to the > absolute path of the editing file. > "Run" operations uses the CWD application wide, of course. > This picture completes with a "Change Current Dir" menu > item under "File" (or under "Run"!) menu along with a way > to see which is it and a "Shell Start Dir" user config option. > > But that's my (an) opinion, NOT a feature request. > (I haven't thought the case where Idlefork starts without a > shell window neither) > > regards, > -Hernan Here's the model I'd like to see. It's similar to what Emacs does, and it works very well for me there. Each window has a directory associated with it. This is normally the directory containing the file loaded in the window; if a window has no file loaded in it, it should be the directory of the window from which this window was created. E.g. if I'm editing a file /foo/bar.py, and I hit ^N to create a new window, the new window's directory should be /foo. The directory associated with a window should be used as the initial directory for all Open and Save dialogs. If you use Save As into a different directory, the window's directory changes (but not so for Save A Copy). All this has nothing to do with the current directory of the IDLE process itself, which is never changed. If the initial window has no file associated with it (e.g. it is a Python Shell window) then it should be the startup directory of IDLE. (I think this is pretty much already implemented except for file-less windows, which seem to inherit IDLE's initial directory.) The Run command should use the file's directory as the initial cwd of the subprocess started, and this should also set directory associated with the Python Shell window where the output is sent. --Guido van Rossum (home page: http://www.python.org/~guido/) From basherwo@unity.ncsu.edu Fri May 30 15:20:12 2003 From: basherwo@unity.ncsu.edu (Bruce Sherwood) Date: Fri, 30 May 2003 10:20:12 -0400 Subject: [Idle-dev] RE: Current Working Directory In-Reply-To: <200305301156.h4UBuwp15182@pcp02138704pcs.reston01.va.comcast.net> References: <200305301156.h4UBuwp15182@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3ED7689C.20803@unity.ncsu.edu> What Guido describes is how the original idlefork worked, and which I too found both convenient and intuitive. Maybe it is idiosyncratic, but I often have programs accompanied by data files, and these constitute packages that may move as a whole from one folder and/or computer to another, or sent to a friend. When I read up the program in IDLE I expect to be able to reference the data file because I expect the cwd to be by default the folder in which the program resides. The rule that Guido outlines achieves that desired effect. Factual point though, Guido, is that this is NOT "pretty much already implemented" (or is broken), which is why I turned in a bug report. The current idlefork starts the process in the startup folder (on Windows, in the "Start in" directory given in the shortcut I use to invoke Idle), not in the folder where the program file resides. Bruce Sherwood Guido van Rossum wrote: > Here's the model I'd like to see. It's similar to what Emacs does, > and it works very well for me there. Each window has a directory > associated with it. This is normally the directory containing the > file loaded in the window; if a window has no file loaded in it, it > should be the directory of the window from which this window was > created. E.g. if I'm editing a file /foo/bar.py, and I hit ^N to > create a new window, the new window's directory should be /foo. The > directory associated with a window should be used as the initial > directory for all Open and Save dialogs. If you use Save As into a > different directory, the window's directory changes (but not so for > Save A Copy). All this has nothing to do with the current directory > of the IDLE process itself, which is never changed. If the initial > window has no file associated with it (e.g. it is a Python Shell > window) then it should be the startup directory of IDLE. > > (I think this is pretty much already implemented except for file-less > windows, which seem to inherit IDLE's initial directory.) > > The Run command should use the file's directory as the initial cwd of > the subprocess started, and this should also set directory associated > with the Python Shell window where the output is sent. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > http://mail.python.org/mailman/listinfo/idle-dev