homepage

When started from a Cygwin window 
(duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has 
no menus.
If started as:
duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ /usr/lib/python2.3/idlelib/idle.py -n
(no subprocess) the menus are present.
Starting Python:
duane@USD22C821 /cygdrive/d/my_python/Cygwin_test
$ python
Python 2.3 (#1, Aug 1 2003, 15:01:23)
[GCC 3.2 20020927 (prerelease)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>>
Win2k SP2
Duane Kaufman
duane.kaufman@med.ge.com 

Logged In: YES 
user_id=33168
Jason, if you can't help can you assign to Kurt (kbk)? Thanks.

Logged In: YES 
user_id=86216
I would like to assign this (at least temporarily) to Kurt
for the following reasons:
1. I will be off-net for a while
2. I am not very familiar with Tkinter
3. I am not very familiar with IDLE
4. IDLE works fine under Python 2.2.3 with the identical
underlying software (e.g, Cygwin, Tcl/Tk, etc.)
However, IDLE under Python 2.3 could be tickling YA
Cygwin bug...
I will check in when I'm back...
Thanks.

Logged In: YES 
user_id=149084
It appears that IDLE can't start its subprocess. I have
a patch in process that will give proper error messages
and timeouts under that condition, at least giving the
user a notice about the failure. 
Then there is the question why the subprocess doesn't
start under Cygwin. There are no error messages in the
shell window?
I'm going to be away for a few days myself.

Logged In: YES 
user_id=86216
kbk> There are no error messages in the
kbk> shell window?
No, the shell window just looks like the following:
Python 2.3 (#1, Aug 5 2003, 09:49:11) 
[GCC 3.2 20020927 (prerelease)] on cygwin
Type "copyright", "credits" or "license()" for more information.
 
**********************************************
******************
 Personal firewall software may warn about the connection 
IDLE
 makes to its subprocess using this computer's internal 
loopback
 interface. This connection is not visible on any external
 interface and no data is sent to or received from the 
Internet.
 
**********************************************
******************
 
IDLE 1.0 
>>>
And appears to work, until one types "^D", then it hangs.

Logged In: YES 
user_id=149084
Well, that's peculiar. So the subprocess is starting up
ok but the menus aren't posted. Now I'm thinking a 
TK problem -- what bug are you thinking of?

Logged In: YES 
user_id=86216
> what bug are you thinking of?
Nothing in particular. However, experience has taught me
to consider Cygwin bugs when porting to Cygwin...
Anyway, I just found a difference between Python 2.2.3
and 2.3 after starting IDLE.
Under 2.2.3:
$ ps | fgrep python
 3308 1400 3308 3092 0 19695 
11:57:56 /home/jt/src/python-2.2.3-2/python
Under 2.3:
$ ps | fgrep python
 2244 1400 2244 2864 0 19695 
12:02:57 /usr/bin/python2.3
 700 2244 2244 3592 0 19695 
12:02:58 /usr/bin/python2.3
Note one python process under 2.2.3 and two under 2.3.
This may explain why IDLE works under 2.2.3 and not.
Were there major IDLE changes between 2.2.3 and 2.3?
If so, what?

Logged In: YES 
user_id=149084
Oh, big differences: Without the -n switch, which makes
IDLE act like the 2.2 version, IDLE starts up an execution
server subprocess which then connects to the user's
GUI. This subprocess is restarted every time the user
does a Run/F5 or a Shell/Restart Shell.
There are other major differences. The IDLE in 2.3 is the
version developed on the IDLEfork project at Sourceforge.
It sounds like you are getting farther than Duane Kaufman.
I wonder if he was seeing the initial message in the shell
window like you are. Do you see the menus?
Well, gotta go :-)

Logged In: YES 
user_id=86216
> It sounds like you are getting farther than Duane
> Kaufman.
I don't think so. AFAICT, we are observing the same
behavior.
> I wonder if he was seeing the initial message in the
> shell window like you are.
My WAG is yes.
Duane, please confirm.
> Do you see the menus?
No.

Logged In: YES 
user_id=574999
I am seeing the same behavior, and do _not_ see menus 
when started with a sub-process.
Duane

Logged In: YES 
user_id=574999
Hi,
I was wondering if there has been any motion on this item yet?
Thanks,
Duane

Logged In: YES 
user_id=86216
Unfortunately, not. The bug report was created
right before I was going on vacation last summer.
Since I'm still on vacation... :,)
Well...actually the assumed high "head banger"
factor has facilitated my procrastination.
Additionally, since I do not use use IDLE, I'm not
very motivated to build a debuggable Python and
Cygwin and attach to the hung process with gdb and
debug.
FWIW, I haven't forgetton. The bug report
stares me in the face everytime I read my email.
Unfortunately, I haven't taken any action. :,(
Are you a developer type? If so, would you be
willing to try to debug this problem yourself?

Logged In: YES 
user_id=956087
Don't know if this sheds any more light, but on WinXP, Python 
2.3.3: when starting IDLE with a file to edit (e.g. 'idle foo.py') 
the edit window becomes visible first. _And_ it has a visible 
menu bar. But when the shell window becomes visible, it has 
no menu bar, and the menu bar _disappears_ from the edit 
window.

Logged In: YES 
user_id=86216
Sean, thanks for the info.
Kurt, ring any bells?

Logged In: YES 
user_id=1321088
I found the problem! :D
Around line 394 of PyShell.py roughly, this function:
 def start_subprocess(self):
 # spawning first avoids passing a listening socket
to the subprocess
 self.spawn_subprocess()
 #time.sleep(20) # test to simulate GUI not accepting
connection
 addr = (LOCALHOST, self.port)
 # Idle starts listening for connection on localhost
 for i in range(3):
 time.sleep(i)
 try:
 self.rpcclt = MyRPCClient(addr)
 break
 except socket.error, err:
 pass
 else:
 self.display_port_binding_error()
 return None
 # Accept the connection from the Python execution server
 self.rpcclt.listening_sock.settimeout(10)
 try:
 self.rpcclt.accept()
 except socket.timeout, err:
 self.display_no_subprocess_error()
 return None
 self.rpcclt.register("stdin", self.tkconsole)
 self.rpcclt.register("stdout", self.tkconsole.stdout)
 self.rpcclt.register("stderr", self.tkconsole.stderr)
 self.rpcclt.register("flist", self.tkconsole.flist)
 self.rpcclt.register("linecache", linecache)
 self.rpcclt.register("interp", self)
 self.transfer_path()
 self.poll_subprocess()
 return self.rpcclt
It spawns the subprocess, but never manages to talk to it.
The socket.timeout exception is raised. Communication to the
subprocess fails in here:
 try:
 self.rpcclt = MyRPCClient(addr)
 break
 except socket.error, err:
 pass
Then, it tries to register the functions with tkconsole, and
TkInter seems to die. I haven't dug down into it yet to see
what exactly happens. But, I suspect that rpcclt is null
when self.rpcclt.register() is called.
So, it's not a Tk error. It's an error with trying to
contact the subprocess.

Is the problem described by Daniel, "So, it's not a Tk error. It's an
error with trying to contact the subprocess", still present? 
It's not cleat to me from messages that it'd be restricted to Cygwin, if
confirmed on other build please change title again.

I just tried idle here under cygwin and menus are not shown. This cygwin
includes python 2.5.2, btw.
But I verified what Daniel Joyce said and I see the problem is no longer
there, so it has to be tracked down again.

Is this still an issue with later versions of Python and Cygwin?

ping

AFAICT, this issue is resolved in the latest Cygwin Python package (i.e., 2.6.7-1) that is built against a X11-based Tcl/Tk instead of a Win32 GDI version:
http://cygwin.com/ml/cygwin-announce/2012-02/msg00014.html 

I like to close the issue if problem has been solved by cygwin itself.

Please do.
When I tested the Cygwin Python 2.6.7-1 release, IDLE was one of my testcases. In my limited testing (I'm not a regular IDLE user), the menus appeared to function properly.

Closing as the latest cygwin build works fine.