#2721 maxima can't refresh plots in gnuplot_pipes format

[David J. López]

Hi. I use 64 bits Archlinux with maxima 5.33.0, wxmaxima 13.04.2 and gnuplot 4.6.5 installed from Arch's repo. I've noticed a bug when plotting. For example

(%i1) plot2d(sin(x),[x,0,2*%pi]);
(%o1) "/home/david/maxout.gnuplot_pipes"

opens a gnuplot window with the sin function as usual, but

(%i2) plot2d(cos(x),[x,0,2*%pi]);
(%o2) "/home/david/maxout.gnuplot_pipes"

doesn't refresh the gnuplot window, it shows sin() instead of cos(). Moreover, if I close the gnuplot window and re-execute

(%i3) plot2d(cos(x),[x,0,2*%pi]);
(%o3) "/home/david/maxout.gnuplot_pipes"

it doesn't open a new gnuplot window. I have to close and restart wxmaxima to get plot2d working again. Same happens with plot3d for 3D graphics

Plotting with [plot_format, gnuplot] works fine, for example

(%i4) plot2d(cos(x),[x,0,2*%pi],[plot_format, gnuplot]);
(%04) "/home/david/maxout.gnuplot"

opens a new window with the graphic. The wxplot2d function from wxmaxima also work fine. It seems that the problem only happens in the default gnuplot_pipes format

I've asked to Arch developers but they think the problem belogs to maxima or gnuplot. I'm suffering this problem since I use maxima 5.32.1 and gnuplot 4.6.4. Now I'm using maxima 5.33.0 and gnuplot 4.6.5, but the bug persists.

I'm going to open a ticket in gnuplot and post the link

[David J. López]

The gnuplot ticket with this bug: https://sourceforge.net/p/gnuplot/bugs/1379/

The bug I open in Archlinux: https://bugs.archlinux.org/task/38760

[Rupert Swarbrick]

Hi there,

Thanks for reporting this bug. Unfortunately, I'm not able to reproduce it here. My attempts to install Arch in a virtual machine have been... laughable, so I'm hoping you can help us debug this further remotely.

Firstly, it's hard to tell from your report above: Have you tried running Maxima from the command line, rather than from wxMaxima? If not, could you try that and could you paste the startup banner that appears? I think that the Arch packages use SBCL as the host lisp, but it would be good to check exactly which one. (Incidentally, if line editing doesn't work in the command line version of Maxima, try running it inside rlwrap)

I assume that gnuplot is staying alive, because otherwise you'd presumably have noticed the window suddenly disappearing. What seems to be happening is that the commands we send down a pipe to the gnuplot process are just not getting to it. This is rather mysterious...

The first debugging thing you could try is running gnuplot_close(). This closes the stream that we use to talk to the gnuplot process, which should make the process exit. If you run a plot command afterwards, do we successfully generate a new plot?

(If this works, the problem probably doesn't lie with our stream management)

The next thing we can try is putting in a fake gnuplot program that logs the commands it gets sent on its standard input. If you're good at shell scripting, you can probably make one with a careful use of the tee command. Otherwise reply to this bug and I'll try to figure one out. To use your own program for gnuplot, you'll want to set the gnuplot_command variable.

I hope that all makes sense - if not, just let us know.

Rupert

[Robert Dodier]

Thanks for the report. Can you please try the same thing with command-line Maxima?

[David J. López]

Thanks for your replies.

The header from terminal is:

david@upct ~ % maxima
Maxima 5.33.0 http://maxima.sourceforge.net
using Lisp SBCL 1.1.17
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.

The problem with the plots remains exactly the same when executing maxima in the terminal, I haven't noticed any differences: the first plot is fine, but gnuplot windows isn't updated with the rest of the plots.

I've tried gnuplot_close(), but it doesn't solve the bug. The window with the plot closes as it's expected, and a new window is created with the the next plot. However, that new window is not uptated with following plots. We're at the same point that in the beginning of the maxima session: the first plot is fine, but not the rest.

I've tested with plot3d with the same problems than plot2d. However plotting works fine with [plot_format_gnuplot] option: a new window opens for each plotting with the right figure. It seems the problem only happens with the default gnuplot_pipes format.

I've downgraded maxima/sbcl to test the right moment when the problem arises in archlinux. I've made some tests with the same gnuplot 4.6.5 version, and always in a terminal:

maxima 5.30.0 / sbcl 1.1.2 : fine
maxima 5.31.0 / sbcl 1.1.4 : fine
maxima 5.32.1 / sbcl 1.1.6 : wrong
maxima 5.33.0 / sbcl 1.1.7 : wrong

Is it possible that something changed in the maxima's plotting system between 5.31.0 and 5.32.1 versions? I'm telling you this because I've noticed there's no output message when plotting with the 'right' versions 5.30.0/1.1.2 and 5.31.0/1.1.4. However in the 'wrong' versions 5.32.1/1.1.6 and 5.33.0/1.1.7 there's an output /home/david/maxout.gnuplot_pipes when plotting, even if the gnuplot window is not updated or it's closed.

Tell me if I can do something to help.

[Rupert Swarbrick]

Hi,

Yes, there were some reasonably major changes to the plotting system in between those two revisions. Thank you very much for the detailed investigation. Rather frustratingly, I still can't reproduce your symptoms: I just tried SBCL 1.1.6 with a freshly compiled Maxima 5.32.1 and GNUplot 4.6.5 and... it worked just fine.

Please can you try using the attached script as a "man in the middle" to work out what we're sending to GNUplot (and why it's not working...)? I put it at /home/rupert/fake-gnuplot.sh (don't forget to make it executable) and then ran the following:

::text
Swank loaded successfully
Maxima 5.32.1 http://maxima.sourceforge.net
using Lisp SBCL 1.1.6
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) gnuplot_command;
(%o1)                               gnuplot
(%i2) gnuplot_command: "/home/rupert/fake-gnuplot.sh";
(%o2)                    /home/rupert/fake-gnuplot.sh
(%i3) plot2d(sin(x), [x, 0, 1]);
(%o3) /home/rupert/maxout.gnuplot_pipes
(%i4) plot2d(cos(x), [x, 0, 1]);
(%o4) /home/rupert/maxout.gnuplot_pipes

After running it, you should find a fake_gnuplot.input and fake_gnuplot.output in your home directory. My output file is empty (because gnuplot didn't report any errors) and my input file has the commands to plot sin() and cos().

Please could you try this out and give us the results? That will hopefully tell us whether we're sending rubbish to gnuplot for some reason or whether we're completely failing to send the strings for the second plot.

Many thanks,

Rupert

[Ben Price]

Hi,

I also have this problem.

Using gnuplot 4.6 patchlevel 5 and sbcl 1.1.18, i find maxima 5.31.0 works fine, but 5.33.0 doesn't, and neither does branch_5_33_base_62_g707110a. This is all done with command-line maxima.

The symptoms are exactly the same: the plot does not refresh, but the window does stay alive - from the plot window, bringing up the settings panel works, but zooming and toggling the grid does not; if the plot window is closed, then no new plots are displayed; but the first plot after a gnuplot_close() works fine; [plot_format, gnuplot] also works, always.

I attach output from the fake-gnuplot script when trying to display two plots. I've added in a line of hashes '#' between the attempts.

Hope this helps. Let me know if there's anything else helpful I could do.

[Rupert Swarbrick]

Ahah! We have a culprit :-)

Looking at the input traces, it seems we're setting the terminal and then immediately unsetting it again. But then the default wxt terminal doesn't work properly under Qt for some reason? Bizarre. Quoting from a macports bug(!):

To answer your question: qt and wxt are not mutually exclusive. The problem is that (they claim that) one cannot switch between qt and wxt. If you have aquaterm installed, you can always switch to either of them. But once you switch to qt (and do something with it), you cannot switch to wxt any longer. Not sure if qt as default terminal prevents you from using wxt altogether.

This is from https://trac.macports.org/ticket/43738. Presumably GNUplot is defaulting to a qt terminal. We try to set wxt and fail miserably, then plot something, ending up with the qt terminal. The next time we plot, we try again to set wxt. This time GNUplot says "No, no, no. You're in qt-land now" and everything falls over...

[Jaime E. Villate]

This is the same bug that was previously reported as #2683. The source of the problem is that your copy of gnuplot does not include a WXT terminal. It can be fixed by adding:

set_plot_option([gnuplot_default_term_command, "set term pop"])$

which can be placed in the file

~/.maxima/maxima-init.mac

[Jaime E. Villate]

I have finally figured it out how to solve this bug (sorry it took me 4 months). When initializing the plot_options array, the command 'gnuplot -e "show term"' will be executed. If the output includes the string "wxt", then gnuplot_default_term_command will be set to:

set term wxt size 640,480 font ",12"

(the current behavior in v. 5.33) otherwise, it will be set equal to:

set term pop

(that was the value used in versions previous to 5.32, which will use the default terminal for the local system).

[Rupert Swarbrick]

Jaime: Are you certain that the Arch linux users don't have the WXT terminal? The way I read the macports bug, it seems that you just can't run both in the same session. The GNUplot changelog has this:

::text
2012-01-21  Ethan A Merritt  <merritt@u.washington.edu>


        * src/datafile.h src/datafile.c src/plot2d.c src/breaders.c src/plot3d.c
        src/stats.c:  When reporting bad data in an input file, give the file
        name in addition to the current line number.


        * term/wxt.trm src/term_api.h src/term.c src/qtterminal/qt_term.cpp
        src/wxterminal/wxt_gui.cpp:  Switching the terminal from qt to wxt or
        vice versa causes the program to lock up or segfault.  Introduce a flag
        terminal_interlock to prevent such a switch.

which seems to agree.

Have you looked at the input logs that Ben attached? We seem to completely mess up setting the terminal... Perhaps if we actually asked for a WXT plot the first time around, we'd get it?

[Jaime E. Villate]

On 26-05-2014 16:18, Rupert Swarbrick wrote:

Jaime: Are you certain that the Arch linux users don't have the WXT
terminal? The way I read the macports bug, it seems that you just can
run both in the same session. The GNUplot changelog has this:

2012-01-21 Ethan A Merritt merritt@u.washington.edu

     * src/datafile.h src/datafile.c src/plot2d.c src/breaders.c src/plot3d.c
     src/stats.c:  When reporting bad data in an input file, give the file
     name in addition to the current line number.

     * term/wxt.trm src/term_api.h src/term.c src/qtterminal/qt_term.cpp
     src/wxterminal/wxt_gui.cpp:  Switching the terminal from qt to wxt or
     vice versa causes the program to lock up or segfault.  Introduce a flag
     terminal_interlock to prevent such a switch.

which seems to agree.

You're right; I was typing an answer while you also answer, so I did not
read that macports bug report.

Have you looked at the input logs that Ben attached? We seem to
completely mess up setting the terminal... Perhaps if we actually
asked for a WXT plot the first time around, we'd get it?

---

I still think it is safer to use "set term pop" to use the default
terminal. It would work also for those who have not installed a wxt
terminal. If a user has both wxt and qt terminals, with qt as default,
and wants to use wxt in Maxima, he can always set the
gnuplot_default_term_command as he wants, after testing that it works
in its system.

Regards,
Jaime

[David J. López]

Sorry, I completely forgot this bug and this conversation. My apologies.

Recently maxima has been updated to 5.34.0 in archlinux repo, and this
bug is solved. So thanks for your effort

Wishes,

David

El 26/05/14 a las #4, Jaime E. Villate escribió:

On 26-05-2014 16:18, Rupert Swarbrick wrote:

Jaime: Are you certain that the Arch linux users don't have the WXT
terminal? The way I read the macports bug, it seems that you just can
run both in the same session. The GNUplot changelog has this:

2012-01-21 Ethan A Merritt merritt@u.washington.edu
<mailto:merritt@u.washington.edu>

      *  src/datafile.h  src/datafile.c  src/plot2d.c  src/breaders.c  src/plot3d.c
      src/stats.c:   When  reporting  bad  data  in  an  input  file,  give  the  file
      name  in  addition  to  the  current  line  number.

      *  term/wxt.trm  src/term_api.h  src/term.c  src/qtterminal/qt_term.cpp
      src/wxterminal/wxt_gui.cpp:   Switching  the  terminal  from  qt  to  wxt  or
      vice  versa  causes  the  program  to  lock  up  or  segfault.   Introduce  a  flag
      terminal_interlock  to  prevent  such  a  switch.

which seems to agree.

You're right; I was typing an answer while you also answer, so I
did not
read that macports bug report.

Have you looked at the input logs that Ben attached? We seem to
completely mess up setting the terminal... Perhaps if we actually
asked for a WXT plot the first time around, we'd get it?

------------------------------------------------------------------------

I still think it is safer to use "set term pop" to use the default
terminal. It would work also for those who have not installed a wxt
terminal. If a user has both wxt and qt terminals, with qt as
default,
and wants to use wxt in Maxima, he can always set the
gnuplot_default_term_command as he wants, after testing that it works
in its system.

Regards,
Jaime

---

[bugs:#2721] http://sourceforge.net/p/maxima/bugs/2721/ maxima
can't refresh plots in gnuplot_pipes format

Status: open
Group: Includes_proposed_fix
Created: Sun Apr 13, 2014 03:28 PM UTC by David J. López
Last Updated: Mon May 26, 2014 03:18 PM UTC
Owner: Jaime E. Villate

Hi. I use 64 bits Archlinux with maxima 5.33.0, wxmaxima 13.04.2 and
gnuplot 4.6.5 installed from Arch's repo. I've noticed a bug when
plotting. For example

(%i1) plot2d(sin(x),[x,0,2*%pi]);
(%o1) "/home/david/maxout.gnuplot_pipes"

opens a gnuplot window with the sin function as usual, but

(%i2) plot2d(cos(x),[x,0,2*%pi]);
(%o2) "/home/david/maxout.gnuplot_pipes"

doesn't refresh the gnuplot window, it shows sin() instead of cos().
Moreover, if I close the gnuplot window and re-execute

(%i3) plot2d(cos(x),[x,0,2*%pi]);
(%o3) "/home/david/maxout.gnuplot_pipes"

it doesn't open a new gnuplot window. I have to close and restart
wxmaxima to get plot2d working again. Same happens with plot3d for 3D
graphics

Plotting with [plot_format, gnuplot] works fine, for example

(%i4) plot2d(cos(x),[x,0,2*%pi],[plot_format, gnuplot]);
(%04) "/home/david/maxout.gnuplot"

opens a new window with the graphic. The wxplot2d function from
wxmaxima also work fine. It seems that the problem only happens in the
default gnuplot_pipes format

I've asked to Arch developers but they think the problem belogs to
maxima or gnuplot. I'm suffering this problem since I use maxima
5.32.1 and gnuplot 4.6.4. Now I'm using maxima 5.33.0 and gnuplot
4.6.5, but the bug persists.

I'm going to open a ticket in gnuplot and post the link

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/maxima/bugs/2721/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Jaime E. Villate]

Fixed by commit [e86fb0]