headers
Kurt B. Kaiser | 1 Feb 2005 04:44
Picon
Favicon

Re: script changed by another process

paul breen <pgb9607 <at> yahoo.com> writes:

> I like to use my favorite editor to make most changes to a script then
> switch to IDLE to run the program. The trouble is that idle does not
> detect that the file has been changed like most editors do. Usually a
> code editor will ask to reload the file. Idle will not reflect the
> change even if the file is opened again within the same window. The
> only way to get around the problem is to close the window and re-open
> the file in a new window. Are there plans to change to change this
> behavior?

This sounds familiar, though I don't see a Bug in either Python or
IDLEfork.

It's not high on my list.  Fixing it is not too big an issue, it
would require adding a timestamp attribute to the EditorWindow class
and comparing it to the file on disk before running or saving.

Maybe you could provide a patch.  Otherwise enter a Bug in the
Python tracker and maybe we'll get to it someday.

Why not use IDLE to edit the code?  It's very convenient, with
one keystroke save, syntax check, and run in shell.

--

-- 
KBK
Permalink | Reply | 0 comments |
headers
tpc | 15 Feb 2005 03:38
Picon

IDLE freezing/hanging


hello, have any of you experienced this ?  This has been going on
intermittently for quite some time, I have no idea what causes it.  What
can I do to help debug the problem or find out the cause ?  Enclosed below
is a more or less accurate log of IDLE freezes, and as you can see I went
for a few months where it didn't crash.  I am wondering if this all has to
do with how IDLE interacts with Debian system.  I am on Debian unstable
and I do once a week apt-get updates and apt-get dist-upgrades.

15OCT2004 2:06pm
while testing code to see if convertListToString is necessary
Debian Sarge Python IDLE just froze on me again
pressing keys does nothing, unresponsive, total loss of data
second time this has happened to me
only thing I can do is kill -9 the process

and it pisses me off, this is the third time I can remember where Python
IDLE just crashes on me, just freezes up and is non-responsive and I have
to kill -9 the process and reboot and reload everything I've done up to
this point
this occurred while I was typing up experiment re looping through two
lists where len(eachList) was different, what would happen in such a case
?
01NOV2004 10:29am IDLE froze, apt-get removed, rebooted system, then
apt-get installed

01NOV2004 11:43am IDLE just crashed again

12NOV2004 1:57pm
ok, so after another event where IDLE froze, I must say I am very
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Zelle | 15 Feb 2005 03:55

Re: IDLE freezing/hanging

Hello,

This is just a quick "me too." I am running Debian testing (Sarge), and 
IDLE is terribly unstable. It hangs frequently while in the middle of 
typing. I thought this was probably a library problem due to some mixing 
of distributions that I've done, but I now have a "pure" Sarge install 
and am seeing exactly this same behavior. I have basically told my 
students to use Emacs or Eclipse instead. A shame, because I really like 
IDLE, when it works.

Is this just a Debian issue, or is it a general problem on Linux (Tk 
library, perhaps?).

--John

tpc <at> csua.berkeley.edu wrote:
> hello, have any of you experienced this ?  This has been going on
> intermittently for quite some time, I have no idea what causes it.  What
> can I do to help debug the problem or find out the cause ?  Enclosed below
> is a more or less accurate log of IDLE freezes, and as you can see I went
> for a few months where it didn't crash.  I am wondering if this all has to
> do with how IDLE interacts with Debian system.  I am on Debian unstable
> and I do once a week apt-get updates and apt-get dist-upgrades.
> 
> 15OCT2004 2:06pm
> while testing code to see if convertListToString is necessary
> Debian Sarge Python IDLE just froze on me again
> pressing keys does nothing, unresponsive, total loss of data
> second time this has happened to me
> only thing I can do is kill -9 the process
(Continue reading)

Permalink | Reply | 5 comments |
headers
Grégoire Dooms | 15 Feb 2005 10:42
Picon

Re: IDLE freezing/hanging

Me too.
I use Debian unstable and Idle patched with Raphael Noam's enhancements 
(they are great I would love to see this merged).

I tried to debug the problem but am not aware of a way to attach a 
debugger to a python process
(I would like to do it at a higher level than interpreter level with gdb).

All I could do up to now is strace both processes and see one of them 
repeating a sequence of futex and select calls (this is normal I think)
 while the other is blocked in a futex call.

I tried to get that process out of the futex call by sending a signal 
but all signals I tried up to now made it exit (HUP and CHLD, if I 
remember correctly). The problem is not easily reproductible as it seems 
to occur at random. But I feel it could be related to rate of typing as 
I nearly always get it when typing on my laptop keyboard.

I did not submit a bug as this is patched code and I never had a student 
annoyed by this bug.
I'm willing to help trace and fix the bug if you can direct me in the 
right direction.
--
Grégoire Dooms
Permalink | Reply | 4 comments |
headers
David S. | 16 Feb 2005 21:51
Picon

subprocess problem on Windows in IDLE

please see:
http://thread.gmane.org/gmane.comp.python.general/388373
Permalink | Reply | 1 comment |
headers
Kurt B. Kaiser | 17 Feb 2005 21:37
Picon
Favicon

Re: subprocess problem on Windows in IDLE

"David S." <davidschein <at> alumni.tufts.edu> writes:

> please see:
> http://thread.gmane.org/gmane.comp.python.general/388373

Python Bug 1126208

=====================
From: David S. <davidschein <at> alumni.tufts.edu>
Subject: subprocess problem on Windows in IDLE and PythonWin
Newsgroups: gmane.comp.python.general
Date: Wed, 16 Feb 2005 02:05:24 +0000

Python 2.4 on Windows XP
In the python command-line the following works fine:

>>> from subprocess import *
>>> p = Popen('dir', stdout=PIPE)

>From within IDLE or PythonWin I get the following exception:

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in -toplevel-
    p = Popen('dir', stdout=PIPE)
  File "c:\python24\lib\subprocess.py", line 545, in __init__
    (p2cread, p2cwrite,
  File "c:\python24\lib\subprocess.py", line 605, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "c:\python24\lib\subprocess.py", line 646, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthra Norell | 22 Feb 2005 14:44
Picon

IDLE output speed problem

I posted the follwing message on python.sig and there was no response. I hope to have more luck here. Thanks very much. - Frederic
 
Hi,
   I upgraded from 2.2.2 to 2.4 and all is well except the output to the IDLE window is now twenty times slower than it was before, making the window utterly unusable for verbose output. The statement -- for i in range (100): print i -- now takes about forty-five seconds to complete! Used to be two.
Python 2.4 on Windows ME.
Hints will be gratefully received by
Frederic
 
 
 
_______________________________________________
IDLE-dev mailing list
IDLE-dev <at> python.org
http://mail.python.org/mailman/listinfo/idle-dev
Permalink | Reply | 1 comment |
headers
Anthra Norell | 22 Feb 2005 11:11
Picon

IDLE output too slow

I posted the follwing message on python.sig and there was no response. Hopefully you can offer some advice. Thanks very much. - Frederic
 
Hi,
   I upgraded from 2.2.2 to 2.4 and all is well except the output to the IDLE window is now twenty times slower than it was before, making the window utterly unusable for verbose output. The statement -- for i in range (100): print i -- now takes about forty-five seconds to complete! Used to be two.
Python 2.4 on Windows ME.
Hints will be gratefully received by
Frederic
 
 
 
_______________________________________________
IDLE-dev mailing list
IDLE-dev <at> python.org
http://mail.python.org/mailman/listinfo/idle-dev
Permalink | Reply | 0 comments |
headers
Kurt B. Kaiser | 23 Feb 2005 19:04
Picon
Favicon

Re: IDLE output speed problem

"Anthra Norell" <anthra.norell <at> tiscalinet.ch> writes:

> I posted the follwing message on python.sig and there was no
> response. I hope to have more luck here. Thanks very much. -
> Frederic
>
> Hi, I upgraded from 2.2.2 to 2.4 and all is well except the output
> to the IDLE window is now twenty times slower than it was before,
> making the window utterly unusable for verbose output. The statement
> -- for i in range (100): print i -- now takes about forty-five
> seconds to complete! Used to be two.  Python 2.4 on Windows ME.

IDLE changed quite a bit at 2.3, user code is now executed in a
subprocess connected to the GUI via sockets.

But I have no idea why you are having this problem.  

On Windows 2000 (using 2.4 at about P2/300MHz) I get:

for i in range(100): print i   ==> less than two seconds
for i in range(1000): print i  ==> 19 seconds
for i in range(1000): print i, ==> 60 seconds

The slowdown for the last example is due to Tk issues with printing
long lines, i.e. that was one long line, while the other two are
individual lines.

Try running IDLE with the -n switch, either from the command line or
by changing the target in the Run / Python / IDLE menu.  Then IDLE
runs the same way it did in 2.2, without the subprocess.

If that fixes the problem, there may be an issue with Windows ME
sockets.  Try upgrading (or even downgrading to W98 :-)

Overall, as I recollect, the new IDLE is about 30% slower than the old
on Linux, OpenBSD, W2K, and WXP, due to the socket communication.  But
taking advantage of Moore's law, the overall effect since 2.2 has been
a speedup ;-) 

At least we didn't use all the cycles, like Gates does.  (I had a
jerky Flight Simulator on an Apple II+, now I've got a jerky Flight
Simulator on WXP 2.4 GHz, except (default install) it has nice pink
fractal clouds and realistic scenery instead of vector graphics.)

I wonder if anyone else on the list is using Windows ME with IDLE?

--

-- 
KBK
Permalink | Reply | 0 comments |
headers
Kurt B. Kaiser | 23 Feb 2005 20:04
Picon
Favicon

Re: IDLE freezing/hanging

Grégoire Dooms <dooms <at> info.ucl.ac.be> writes:

> Me too.
> I use Debian unstable and Idle patched with Raphael Noam's
> enhancements (they are great I would love to see this merged).

This will happen fairly soon.  He has an enthusiatic following.

> I tried to debug the problem but am not aware of a way to attach a
> debugger to a python process (I would like to do it at a higher level
> than interpreter level with gdb).

There is a graphics version of gdb: ddd

http://www.gnu.org/software/ddd/ddd.html

> All I could do up to now is strace both processes and see one of them
> repeating a sequence of futex and select calls (this is normal I think)
>  while the other is blocked in a futex call.

OK, it may be that the subprocess is somehow blocked looking for input
from the GUI.  

> I tried to get that process out of the futex call by sending a signal
> but all signals I tried up to now made it exit (HUP and CHLD, if I
> remember correctly). The problem is not easily reproductible as it
> seems to occur at random. But I feel it could be related to rate of
> typing as I nearly always get it when typing on my laptop keyboard.

The blizzard of futex calls is due to polling the sockets.  That is
done by both the GUI and the subprocess (execution server).  The tricky
thing debugging IDLE is to do it amid all that activity.

If you can get to a point where you have something at least partially
reproducible, try running IDLE with the -n switch :

(cd ..../Lib/idlelib && ../../python ./PyShell.py -n) or idle -n,
depending on how your system is set up.  See if the problem goes away.

> I did not submit a bug as this is patched code and I never had a
> student annoyed by this bug.
> I'm willing to help trace and fix the bug if you can direct me in the
> right direction.

One thing you can try is to turn on the tracing built into IDLE's 
rpc.py:

File / Open Module  : rpc

In class RPCHandler and class RPCClient there are 'debugging'
variables.  Set them to True and restart IDLE.  You'll now see
extensive output in the command window.  Note that this output is an
interleave of everything going on, and, as is typical of output from
several threads, may be slightly out of sequence.  But there are
sequence numbers associated with each rpc call to help you decode all
that.  If that isn't enough, there are some print>>sys.__stderr__ 
statements in rpc.py which are commented out.  You can turn them on to
get a veritable blizzard of traces :-)

When IDLE freezes, I assume you mean that the GUI is unresponsive, and
that you can't restart the shell from the Shell menu.  If so, try
this: kill the subprocess with 

'kill -KILL xxxxx'.  The subprocess is the one with '8833' in its
command line (ps ax).

IDLE should then spawn a fresh subprocess and you should be able to
continue without losing any of your work.

If it doesn't, that points to a problem with Tk.  Does it happen while
you're typing quickly, or will it freeze while you're having lunch?

I must say: I've been using IDLE for years, on W98, W2K, WXP, RH6.2,
Arch Linux, and OpenBSD.  I've never had IDLE freeze on me unless I
made a coding error while working on IDLE itself.  Then I see a
traceback in the command window.

I have had X crash.  And even a couple of emacs hangs.  These things
seem to happen once in a blue moon when I'm using Gnome on Arch (which
is pretty bleeding edge).  What's your desktop/window manager?

(I mostly use Ion, it works extremely well with IDLE because Ion uses
non-overlapping panes and each pane can contain multiple tabbed IDLE
windows which can be dragged/dropped into different panes.  After you
use Ion for awhile you realize that overlapping windows are just an
awful design choice made at Xerox PARC lo those many years ago.  It's
also super lightweight and stable.)

IDLE is written in pure Python.  So if the 'freeze' isn't due to some
hitherto undetected GUI/subprocess interaction deadlock (which can be
resolved w/o losing work by killing the subprocess), then there is an
issue in the C code implementing Python or Tk.  Hardware seems to be
ruled out because all of you are having problems on Debian Sid.

And the way to debug that is to attach gdb to it.  It won't be pretty.
The subprocess has two threads: one executing user code, and one
minding the sockets. The GUI has one thread which executes the Tk
event loop, with polling implemented using after() calls.  Additional
threads are created as necessary for callbacks from the subprocess.

--

-- 
KBK
Permalink | Reply | 3 comments |

Gmane