Re: Problems with while/splot/wxt

[Philipp K. J. <ja...@ie...>]

On Fri, 13 Feb 2015 12:52:50 -0800
Ethan A Merritt <sf...@us...> wrote:

Wanting to exit a loop (whether it's technically 
infinite or merely long running) is not a programming 
error. 

I think what you are saying is that a user
should not expect gnuplot to recover gracefully
if a loop is terminated by other means than the
loop condition, and that therefore the user
MUST provide such an exit condition. 

With such a warning in place, I think that's
perfectly acceptable behavior, and could have
been said in just so many words. 

I am not sure I follow the logic of your last
paragraph entirely, though. Why "pause 0.01"?
Why not "pause 0.0001"? Or "pause 1", for that
matter? How can I (as the user) know what kind 
of delay is enough for wxt (?) to catch up with 
gnuplot's core? If gnuplot overflows an internal
data structure or fails to respond to keyboard
events, then that's a programming error, not a
user error. Or is it a fact that any loop that
needs to respond to a user event MUST contain
pause? Again: that's totally acceptable - it it's
communicated as such. Since I did not find that
info in the docs, I am asking here - where else?

Best,

		Ph.


> On Friday, 13 February, 2015 07:02:32 Philipp K. Janert wrote:
> > 
> > [snip]
> > 
> > > 
> > > Well what did you expect?
> > 
> > I do expect that gnuplot cleans up its own
> > messes. It is not acceptable to put a program 
> > (any program) in a totally wedged state through
> > a series of totally legal commands.
> 
> Let's be clear.
> Control-C is not a normal way to interact with a program.
> It is an externally-triggered kill switch that in this case
> you are using to bail out of your own programming error - an
> infinite loop with no clean exit path.
> 
> Gnuplot or indeed any program would be perfectly entitled to
> exit entirely in response.  
> 
> Instead, gnuplot tries to be a little nicer and at least get you back
> to a command prompt without losing your entire session context.
> It may not always succeed, in which case a second externally
> triggered kill signal may complete the job.
> 
> If you have suggestions how to detect the infinite loop as
> a syntax error, that would be helpful.
> 
> If you have thoughts about how to design a thread synchonization
> mutex that is more robust in response to a user killing one of
> the two threads, that might also be helpful.
> 
> Complaining that your foot hurts after you have chosen to 
> shoot it multiple times in succession is not so helpful.
> 
> Here is a more correct version of the loop you intended to write:
> 
> spin.gp:
>   t = 0
>   done = 0
>   bind all 'd' "done = 1"
>   while( !done ) {
>     t = t + 0.1
>     splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
>   }
> 
> Now a gnuplot command "load 'spin.gp'" will terminate
> cleanly when you type a 'd' in the plot window.
> 
> Of course there is still the problem that your loop contains
> no delay, so the display command stream it generates will
> get longer and longer as it runs. That means the lag between
> hitting 'd' and exhaustion of the accumulated command stream
> will increase.  Adding "pause 0.01" to the loop would address this,
> or perhaps the "load" command could be followed by some
> cleanup to terminate the current display window and open 
> a new one.  It depends on what you want.
> 
> 	Ethan