|
From: Ethan A M. <sf...@us...> - 2015-02-13 20:56:11
|
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
|