Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Mon, 2003-09-29 at 22:24, Gary Pajer wrote:
> ----- Original Message ----- 
> From: "Joe Heafner" <hea...@vn...>

> > I'm still experiencing problems with gdisplay objects. If I create, for
> > example, a graph with gcurve the program usually stalls upon execution,
> > but no errors are indicated. Sometimes, roughly 90% of the time, both
> > the main window and the graph window open up but the graph window is
> > just blank and the other window, usually containing an animation of a
> > physical system (e.g. oscillating spring-mass system) remains static.
> > Sometimes, roughly 10% of the time, the graph shows up correctly, but
> > NOT point by point. The entire graph is displayed after the animation
> > is over, and the oscillating spring-mass never appears to move at all.
> > On a very, very few occasions I get the correct output, which is an
> > oscillating spring-mass system in one window and a graph updated in
> > real time in the other window. However, I never ever get the program to
> > work completely correctly twice in a row. Everything works fine when
> > all the gdisplay related statements are commented out.
> 
> In my case the program never locks up, but it does stutter a bit, especially
> when the animation first starts.  And I have seen the stutter be long enough
> that the simulation is all but finished before the graphics start, and then
> they're there all at once (as you described).   I've experimented with
> placing a time.sleep(n) [where n is typically between 2 and 7]  at various
> places.  I find that if I initialize the gdisplay window,  then
> time.sleep(),  then start my "while" loop,  I don't lose any of the
> animation.  Of course, there is a bit of a delay, and it's still a bit
> jerky, but it works.  YMMV.


The worst part of this is that it is a probabilistic problem.  Sometimes
you will get a complete lock-up, sometimes just a stutter, sometimes
totally smooth operation.  All of this makes it *hard* to debug, but
most of the issues are resolved on the boostification branch, and can be
backported.

The most stressful case for me ended up being a program that produced
two graphs simultaneously while running a simulation, and that one runs
smoothly now.

Since we don't have anything in our demos that really exercises this
bug, can you submit a particularly damning test case to the online
bugtracker at Sourceforge?  I'll probably be adding one or two of my
own, but it always helps to have multiple people attacking probabilistic
bugs like this one.

> > Another issue is that when a program that uses a gdisplay object
> > terminates, the only way to remove the open windows is to choose "End
> > program" from inside IDLE. Otherwise, the output windows remain active
> > and can only be removed by opening up an xterm, issuing "top", getting
> > the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of
> > the correct python22 process.
> 
> Yep.  But simply restarting the program (F5) kills the old windows and opens
> new ones. At the end of the day, though, its "End Program".  Would "ps" be a
> hair more convenient than "top"?
> 
> -gary

Unfortunately process termination still sucks for multiple windows.  I
have gotten it to work for the case where a simulation has ended and the
interpreter is waiting on you to close the windows, but not when you are
still running the simulation (or are running an infinite simulation).  I
have a couple of ideas that I can try in the next couple of days, but
the debugger isn't helping at all in this case.

Thanks for your reports,
-Jonathan Brandmeyer