Re: [Maxima-discuss] gnuplot-send-command and broken pipes

[Gunter K. <gu...@pe...>]

>     Gunter> If I understand the patch right it tells the user that
>     Gunter> gnuplot has crashed and has been restarted. And it is also
>     Gunter> wise enough not to retry the gnuplot command that has
>     Gunter> crashed unless the user decides to issue it again.
> 
>     Gunter> As restarting gnuplot manually currently needs additional
>     Gunter> research by the user I think doing this automatically when
>     Gunter> it is necessary improves the usability of the program.
> 
> Why is that hard?  The user said "Plot it!", gnuplot crashed.  Why
> wouldn't he just give the same plot command again.  And if computers
> were deterministic as you say, it should crash again, right?  So
> what's the point of maxima retrying for itself even once?
> 

My idea was that the command would not be automatically issued again =>
we must have interpreted the patch in different ways. What I was
convinced that the lisp code says is:

1.) if gnuplot_pipes is used and gnuplot crashes this currently means
that all subsequent plot commands issued in the same maxima session will
fail causing the following error message to appear:

> Maxima encountered a Lisp error:
> UNIX error 32 (EPIPE): Broken pipe, child process terminated or socket
closed
> Automatically continuing.
> To enable the Lisp debugger set *debugger-hook* to nil.

It is of course possible to restart gnuplot manually. But there is no
obvious way of doing so and from the user's view the error message that
suddenly appears in response to every plot command (even in response to
plot commands that previously worked) isn't entirely helpful.


2.) If the patch is applied maxima detects that gnuplot has crashed and
outputs a warning that this has happened.
In addition to telling the user that gnuplot has crashed gnuplot is
restarted *without* re-sending the last command maxima has sent to gnuplot.

=> If a plot has failed the user is able to issue new plot commands
without having to find out how to restart gnuplot manually.
Also issuing a warning when gnuplot crashes is a big step forward as
currently the crash is only reported only if another plot is attempted -
which fails since gnuplot has crashed during the previous plot.


3.) We cannot determine if gnuplot has crashed due to the command we
have sent - or if it just tends to crash from time to time (for example
a milisecond after every restart) => if the newly restarted gnuplot
crashes before we send a new gnuplot command we give up completely and
tell the user that we did do so.

I have actually thought, too, about a gnuplot that sometimes crashes by
itself immediately after starting it up so your comment made me laugh
(and my girlfriend angry). This case wouldn't be caught by the new
gnuplot-restart-logic.

The question is, though, if I have understood the patch right. What I
have understood is more or less the logic wxMaxima employs for
restarting a maxima that has crashed unexpectedly.

Kind regards,

  Gunter.