[Idle-dev] Remote execution for IDLE

[David Scherer]

I've been working on a number of extensions and changes to IDLE, in support
of the goals I mentioned in a previous post.  I would like to share what
I've done with this list, and ask for your comments.

A copy of IDLE including my changes is available at

http://cil.andrew.cmu.edu/projects/visual/XIDLE-2000-03-13.zip

IWFM on Windows and Linux.

I'd appreciate your thoughts on my changes to the interface and the
architecture for remote execution, as well as bug reports.

Changes:

1.  I've added a new extension, ExecBinding, which serves the same purpose
as ScriptBinding, but:

a) Executes the program in a new process, communicating with it through a
remote method call protocol built on top of sockets.  Even user programs
like "while 1: pass" can be reliably terminated or restarted, and IDLE
remains fully responsive while they are running.  I have not implemented
debugging, but I have attempted to design with that in mind.

b) Displays the standard I/O of the program in a new window, which persists
for multiple runs of the same program.  At the beginning of each run, the
window scrolls to hide the output of previous runs.

c) Saves all named buffers before running (to ensure that the source of all
modules is up to date)

d) Supports executing an unnamed buffer (through a temporary file)

e) Displays tracebacks with "system modules" excluded.  For the moment,
modules outside the directory of the user program are considered system
modules.

2.  I've reorganized the menus a bit, splitting the excessively large Edit
menu into Edit, Format, and Run.

3.  I made the "Python Documentation" feature work on Windows, and bound it
to the F1 key.

4.  IDLE will read files with any end-of-line convention ("\r\n" for
Windows, "\n" for UNIX, or "\r" for Macintosh).  Files are always saved with
the native convention.

5.  The need for a well-known socket for ExecBinding mandates that only one
instance of IDLE can be running on the system.  Additional instances use a
"netscape --remote"-like mechanism to pass their command-line parameters to
the first instance, and then terminate.

6.  Executed with no command line parameters, IDLE now loads a blank editor.
Opening a file into this or any other unnamed, empty buffer replaces that
window rather than opening a new one.  The people who have tested my changes
have found this behavior much more convenient.  (Probably startup behavior
should be configurable through config.txt).

7.  idle.bat and idle.pyw have been fixed on Windows.  idle.bat contained an
absolute pathname for the Python interpreter which is not guaranteed to
hold.  I replaced idle.pyw with a copy of idle.py, which fixed some odd
problems.

Let me know what you think,

Dave