Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2721 maxima can't refresh plots in gnuplot_pipes format

closed
None
5
2014-12-07
2014-04-13
David J. López
No

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

Related

Bugs: #2721

Discussion

  • 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
    Robert Dodier
    2014-05-13

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

     
  • 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.

     
  • 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:

    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
    Ben Price
    2014-05-26

    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.

     
  • 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...

     
  • 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
    
     
    • assigned_to: Jaime E. Villate
    • Group: None --> Includes_proposed_fix
     
  • 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).

     
  • 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:

    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?

     
    Last edit: Rupert Swarbrick 2014-05-26
    • 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

       
      • 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/

         

        Related

        Bugs: #2721

    • status: open --> closed