[Idle-dev] Serious problems getting idlefork to display on multiple xservers

[Michael Williams]

On Thu, May 09, 2002 at 02:02:37PM +1000, Stephen M. Gava wrote:
> Guido van Rossum wrote:
> > > The first user to run idlefork gets on fine. However, the next
> > > user, who is at a different terminal, which recieves the output of
> > > a different xserver instance (i.e. has a different $DISPLAY),
> > > cannot get idlefork at their own terminal.
> > 
> > Could it be that the RPC mechanism used to communicate between IDLE
> > and its child process (where code is executed) uses a constant port?

<snip explanation>

> So as I see it, and if my assumption that Guido is right about the
> nature of the problem is correct, I can think of a couple of possible
> courses of action you can take. One is, depending on your reasons for
> preferring idlefork's behaviour to idle's for your installation, it
> may be possible to set up python idle in such a way that it is
> acceptable for your purposes until idlefork's rpc mechanism is
> re-developed.  Another possibility is that the idlefork 0.8.1 (I
> wouldn't recommend using cvs idlefork in a production environment, as
> with all development software it is in a constant state of buggy flux)
> version may be able to be somehow patched to work around your problem
> in the short term, with the new rpc implementation being the long term
> fix. If the second suggestion turns out to be the necessary one, and
> no helpful person jumps in to take a look at this for me ( __hint,
> hint, other idle-dev readers...__  :) then I will have a look at it as
> soon as I am able.

The reason we particularly like(d!) idlefork compared to idle was:

- The simplification of the pull down menus. In idle they are rather
  crufty for our purposes. Presumably this wouldn't be too hard to fix
  with a hacky solution for the time being. If someone could point me to
  the file we need to look at to fiddle with the contents of the menus
  I'll even have a go myself.

- At present the way one would "run" a saved module in idle is by going
  to the Edit (!) menu (which is a pretty long menu already and
  selecting "import module". We were hoping to avid the complications of
  module importing in our short course -- we don't expect any students
  to get beyond simple one module programs in the two days they have so
  I guess we'd like to rename this menu item.

- Probably the most important thing though, is where the programs
  output goes. In idle it is directed to the Python Shell window. This
  potentially leads to conceptual confusion for students (we were
  already wary of telling them about the shell at all). Is there an easy
  way to direct output to a new window as it is done in idlefork.

- And it would be nice to F5/"import module/"run" a module without
  saving it. What idlefork presumably does is save somewhere in /tmp.

So that's what we want! Unfortunatly our trial starts next Tuesday. We
had been quite happily testing the system without trouble until my
supervisor and I coincidentally tried to run idlefork at the same time,
which kind-of explains the appallingly late discovery of this problem
with our course (it's basically my own fault!)

We need a stop gap solution for next week. idle as it stands will
probably do the job. The other possibity is to remove the use of the
interactive environment from the course entirely (the course teaches
basic procedural programming) and use an editor like SciTe which directs
output to a separate window and has no integrated support for the Python
Shell. Unfortunately SciTe doesn't seem to do the semi-automatic
indentation of idle(fork) which is potentially a big problem.

So if anyone has any suggestions of how we could solve the four problems
preventing us from using the core idle, or could even recommend another
Python-friendly editor (*not* Vim or Emacs!), ideally which integrates
the shell I'm all ears!

Thanks for the prompt replies though guys. I might be working on this
course over the summer and be being paid by the department (I'm doing
this as my Masters project but if it actually gets used then I may well
get some cash for it) which will allow me to spend a bit more time
actually coding. I'm a reasonably competent Python developer so hope to
be able to offer help or have ago at the reimplementation of the RPC
mapping so we can use idlefork on "real" first years next October.

But we need a solution for next week...

-- 
Michael