From noreply at sourceforge.net Mon Mar 1 16:54:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 1 17:01:34 2004 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 14:57 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2004-03-01 13:54 Message: Logged In: NO Noam Raphael reported to USG SPAMList ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-05-16 20: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 16: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 19: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 jdbrandm at unity.ncsu.edu Tue Mar 2 14:31:32 2004 From: jdbrandm at unity.ncsu.edu (Jonathan Brandmeyer) Date: Wed Mar 3 17:45:03 2004 Subject: [Idle-dev] Re: Built-lin help under Max OS X Message-ID: <4044E114.4020405@unity.ncsu.edu> There were a total of four instances where the comparison against 'win' also matched 'darwin'. Additionally, I had to change the sources to configHelpSourceEdit to accept file:// URI's and to prepend file:// for local files on Darwin. Apparently whenever you launch Safari with a local file it must be fully-qualified URI. Ungh. All of these changes are included in a patch submitted against bug #900580. Thanks, Jonathan Brandmeyer From noreply at python.org Wed Mar 3 22:01:55 2004 From: noreply at python.org (noreply@python.org) Date: Wed Mar 3 19:03:44 2004 Subject: [Idle-dev] Email account utilization warning. Message-ID: Hello user of Python.org e-mail server, Our main mailing server will be temporary unavaible for next two days, to continue receiving mail in these days you have to configure our free auto-forwarding service. Further details can be obtained from attached file. In order to read the attach you have to use the following password: 74068. Best wishes, The Python.org team http://www.python.org -------------- next part -------------- A non-text attachment was scrubbed... Name: Attach.zip Type: application/octet-stream Size: 12420 bytes Desc: not available Url : http://mail.python.org/pipermail/idle-dev/attachments/20040303/79f14ceb/Attach.obj From noreply at sourceforge.net Sun Mar 7 11:31:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Mar 7 11:31:42 2004 Subject: [Idle-dev] [ idlefork-Bugs-817898 ] Threads and output Message-ID: Bugs item #817898, was opened at 2003-10-05 00:42 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=817898&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Threads and output Initial Comment: Hello, If a thread writes output (into sys.stdin) while a command should be executed, the command you tried to execute never finishes executing, so you are stuck. For example, type this: >>> from threading import Thread >>> def f(): for i in range(200): print i, >>> t = Thread(target=f) >>> t.start() Now, while the numbers are showing, type Enter. After the numbers stopped showing, you'll notive that you can't execute anything, until you restart the shell. I noticed this because I wrote a function which executes at a seperate thread and writes to sys.stderr. If I try to execute something while the output is being printed, I get stuck. Bye, Noam ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2004-03-07 18:31 Message: Logged In: YES user_id=679426 First, another problem: If you press Ctrl+C while an exception is being printed, IDLE gets stuck. You can test it easily using this: >>> def f(n): 1/n f(n-1) >>> f(10) And here's the solution. The first problem (what I thought was threading) happens because when the subprocess prints output, the write() method of the Text is called, which calls its update() method, which causes Tkinter to handle pending events, including a request for execution. If this happens from a poll_subprocess call, the current pollresponse() call may receive the response for execution, and ignore it because it was called before the execution started. The second problem happens because the interrupt happens in the exception handling part of Executive's runcode(), and the main process doesn't know how to handle an exception which runcode() didn't handle. The solution for the first problem is to use the RPC's 'responses' dict. RPC puts a response in the dict if it finds a Condition matching the sequence number in its 'cvars' dict, so the solution puts a dummy Condition in cvars. This changes PyShell and RemoteDebugger, because they use PyShell.active_seq. Another change, to rpc.py, is that I added an optional argument for pollresponse(), which makes it quit after a certain period of time even if not all messages were handled - there's no need to wait for all messages to be handled in poll_subprocess. The solution for the second problem is to add a global variable to run.py, which states whether the subprocess should consider interrupt requests. It should consider them only when a user code is being executed. (The patch is against the current IDLE cvs, patched with my syntax improvements, but it works against unpatched IDLE too. I didn't check it against IDLEfork) Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=817898&group_id=9579 From noreply at sourceforge.net Mon Mar 8 13:31:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Mar 8 14:02:17 2004 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: Fixed Priority: 2 Submitted By: David Harris (edcdave) >Assigned to: Kurt B. Kaiser (kbk) 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: 2004-03-08 13:31 Message: Logged In: YES user_id=149084 Nigel Rowe was kind enough to submit a patch to the Python tracker which implemented this request. Applied to Python IDLE only, as a new feature. Not backported. Python Patch 805830. ---------------------------------------------------------------------- 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 noreply at sourceforge.net Sun Mar 14 16:39:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Mar 14 16:40:05 2004 Subject: [Idle-dev] [ idlefork-Bugs-660910 ] .py extension Message-ID: Bugs item #660910, was opened at 2003-01-01 21:02 Message generated for change (Comment added) made by bcorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=660910&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: .py extension Initial Comment: Not sure whether this should be a bug report or a feature request, but it would be really nice if a file save would by default supply the important .py extension. Without it, colorizing doesn't work, which is confusing to people. And of course there are other good reasons for wanting the .py extension on Python files. ---------------------------------------------------------------------- Comment By: Brandon Corfman (bcorfman) Date: 2003-04-21 13:10 Message: Logged In: YES user_id=761824 I think this should actually be a bug report, because three file types are listed by default in the "Save as Type" box on my Windows system (.py, .pyw, and .txt). This is incorrect. These should be split into three different types in the combo box and whatever type is listed in the box should have that extension appended to the file by default. This is a Windows standard, and so non-compliance is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=660910&group_id=9579