[Idle-dev] new idlefork package

[Bruce Sherwood]

[Kurt B. Kaiser]
> There is a general problem with breaking into the Windows subprocess.
> Right now, if I initiate a tight loop (no I/O) in the shell on
> Windows, I have to kill IDLEfork with the task manager.  Note that
> terminating the IDLEfork application is not enough, the subprocess
> will continue to run disconnected from the user.  You have to kill
> all the python processes.  This is less than ideal :)
>
> The problem doesn't occur on Linux (and, I assume, OS X) because the
> subprocess can be signalled (though the Kill dialog doesn't work
> correctly).  I will look at David Scherer's code to see what tricks he
> might have been using.  Also, Guido had a method using the debugger
> hooks which may have possibilities on Windows.  I have not
> experimented with it and don't know how serious the performance hit
> is.
>
> The Windows workaround is to put
>         print '*',
> in the outer loop and on W2K, anyway, a KeyboardInterrupt will
> be recognized.
>
> Can you tell me how to access some test code?

The only tests I'm really familiar with are VPython. If you install VPython
(http://vpython.org) and run the original idlefork (for which there are
shortcuts provided, as explained at vpython.org), "Open" gives you a set of
demo programs to run. Pick one, say bounce2.py (a ball bouncing around in a
3D box). If you hit the close box on the graphics window, the subprocess
ends. Or leave the animation running and make some edit to the program, then
hit F5. You'll see the graphics window disappear as the old subprocess
exits, then the new run will start with your edits in effect.

I should explain that Scherer built the Visual module (which together with
Python is what we call VPython, along with idlefork; also Numeric is
installed) in such a way that one can break into an infinite loop simply by
hitting the close box on the animation window. This is highly desirable
behavior in the hands of novice programmers! The reason this works is due to
the basic architecture of Visual; it's not a general solution.

Take the bouncing ball program. It starts by declaring a sphere and boxes
making up the walls of the container. Then there is an infinite loop which
moves the ball and checks for collisions with the walls. In the loop there
are no graphics commands; there are just calculational commands to update
ball.pos, the position attribute of the sphere object names "ball". A
parallel thread periodically looks at the current attributes of the
previously declared graphics objects and creates a 3D image corresponding to
the current attributes. This means that you get a navigable 3D animation as
a side effect of computations, which was a brilliantly original idea of
David Scherer and which makes programmatic 3D animation accessible to
nonexpert programmers. You can see that it has the additional benefit that
it is impossible for the programmer to write an infinite loop that can't be
killed, because the parallel thread notices when the user hits the close box
and kills the program gracefully. I don't know what it is about the new
idlefork that has broken this important feature.

A general statement about the VPython environment is that there are lots of
features which are aimed at making programming safe and productive for
ordinary mortals, including navigable 3D animations as side effects of
computation, a single-key interactive edit/run cycle for complete programs,
safe infinite loops, and autosave to make sure the file is kept up to date.
One might also mention the fact that graphics windows automatically spring
into existence when you declare a graphics object, with none of the abstruse
window-creation code found in most graphics environments.

Bruce Sherwood