bugGNU Octave - Bugs: bug #44978, gnuplot toolkit fails to recognize...

 
 

bug #44978: gnuplot toolkit fails to recognize problems with older gnuplot versions

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Fri 01 May 2015 12:19:04 PM UTC  
 
Category: Plotting with gnuplotSeverity: 2 - Minor
Priority: 3 - LowItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.0.0Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 03 Jul 2015 04:56:20 PM UTC, comment #15:

Fixed the typo here (http://hg.savannah.gnu.org/hgweb/octave/rev/9de6949ec15f).

Rik <rik5>
Project Administrator
Thu 02 Jul 2015 10:07:02 PM UTC, comment #14:

There's a typo in the changeset:

error ("graphics_toolkit: gnuplot version to old.");

should be "too old"

Avinoam Kalma <avinoam>
Project Member
Mon 29 Jun 2015 02:46:16 AM UTC, comment #13:

I changed graphics_toolkit to emit an error if the gnuplot version number is too low (http://hg.savannah.gnu.org/hgweb/octave/rev/13ede127ec9a). I made the change on the default branch, but if someone else feels strongly they can backport it to stable. I also put in a FIXME note to remove the code when there is no longer a reasonable chance of encountering a gnuplot version < 4.2.5.

Rik <rik5>
Project Administrator
Tue 02 Jun 2015 04:11:00 PM UTC, comment #12:

Retagging release from 4.0.0-rc4 to 4.0.0.

John W. Eaton <jwe>
Project Administrator
Fri 01 May 2015 10:31:35 PM UTC, comment #11:

Low priority is fine, but if it is easy to fix, I'd prefer addressing it rather than have a big long list of bugs that people have to revisit that are no longer fresh in one's mind once 4.0 is released, which will be a while.

I've attached a simple variation on the gnuplot version script that uses redirection to capture the output, which in most cases isn't even needed. Is using redirection of the screen output a problem for Windows? _gp_eval_.m is quite simple--evaluates a gnuplot command and if gnuplot doesn't understand it, the status comes back '1' rather than '0'.

Rather than a function _gnuplot_has_feature_ (), maybe it is easier to just have a host of small functions _gnuplot_has_object_ (), etc.

>> _gnuplot_has_object_ ()

ans = 1

(file #33865, file #33866)

Dan Sebald <sebald>
Fri 01 May 2015 07:18:52 PM UTC, comment #10:

Priority low is right. This can wait until fltk and qt are
working correctly. See bug #44840 and 33748 for instaance.

Michael Godfrey <godfrey>
Project Member
Fri 01 May 2015 05:18:00 PM UTC, comment #9:

And I don't think addressing this is in any way urgent, as the links Carnë posted show this has been an issue for a long time, no one has bothered to report it or try to fix it yet, only affects RHEL 5 or other systems with an ancient gnuplot.

Mike Miller <mtmiller>
Project Administrator
Fri 01 May 2015 05:15:45 PM UTC, comment #8:

The only problem I could see with that is how to report the error. Report it when the toolkit is initially registered and the user might forget, or want to change gnuplot_binary later and re-register it. I don't know if there is a way to report the error when the toolkit is switched, graphics_toolkit will just say "gnuplot toolkit is not available" without a reason.

If instead let the user switch to the gnuplot toolkit, and then when gnuplot tries to be used report the error there, that might be more user-friendly.

Mike Miller <mtmiller>
Project Administrator
Fri 01 May 2015 04:36:14 PM UTC, comment #7:

I think we should issue an error message early and not even switch the toolkit over to gnuplot if it isn't suitable for plotting. In my mind, having an executable that doesn't work is the same thing as not having the executable at all.

Rik <rik5>
Project Administrator
Fri 01 May 2015 04:29:12 PM UTC, comment #6:

It would make sense for users to have gnuplot
available whether actually installed on the system
at compile-time or not. Thus, users could install whatever
gnuplot they want without the need to re-compile Octave.

Michael Godfrey <godfrey>
Project Member
Fri 01 May 2015 04:25:02 PM UTC, comment #5:

I guess a version check and guess of the minimum version to support would be fine to start with.

I'm not sure where you thought it would be good to patch this in, somewhere early in the gnuplot initialization process? Do we want to make it look like gnuplot is not even callable, gnuplot toolkit is not even available to switch to? Note that if the gnuplot executable is not found, gnuplot is not an available toolkit, that's something I changed for this release. Or should this look like it is available but just fails to plot anything with a nice error message?

I can test any proposed patches with gnuplot 4.0.0.

Mike Miller <mtmiller>
Project Administrator
Fri 01 May 2015 04:03:21 PM UTC, comment #4:

A runtime check is definitely preferable. It won't even be much of a penalty because it would only need to be called once during initialization when the pipes are set up. Note that there are two m-files which are of interest in scripts/plot/util/private. These are _gnuplot_has_feature_ and _gnuplot_version_. Given that _gnuplot_has_feature_ really just checks the version number to determine whether the feature exists, I think we would be fine to check the version number explicitly and say that it is too old. What version is too old to work with? Maybe < 4.2.5? That is the first version check that is used in _gnuplot_has_feature_.

Rik <rik5>
Project Administrator
Fri 01 May 2015 03:03:28 PM UTC, comment #3:

I think it makes sense, reporting as a separate wishlist bug #44981.

Mike Miller <mtmiller>
Project Administrator
Fri 01 May 2015 02:44:57 PM UTC, comment #2:

But following the spirit of checking for features instead of version numbers, what should this check be? I never used gnuplot itself, I'm not familiar with it.

Also, relative to the error in strcat(), maybe it makes sense to have it handle nargin 0:

Seems like Matlab will also throw an error but we maybe we can handle it better.

Carnë Draug <carandraug>
Project Member
Fri 01 May 2015 02:24:13 PM UTC, comment #1:

Confirmed, I've been seeing this for a long time and use a self-compiled gnuplot 4.4 or 4.6 on CentOS 5 machines when I need it.

I think a run-time check would be better than a configure-time check, as you said it can be changed at run-time to use a different gnuplot executable. A configure-time check might be useful for example if you are trying to build the docs. But a run-time check would be needed for interactive use regardless. Retitling, hope you're ok with that.

A new private function to validate if gnuplot can do some feature that reveals whether it is a working version or not?

The strcat error is in the gnuplot_get_var private function. It is expected that gnuplot will always return a string, but the older version errors on the expression, returns nothing, and Octave gets nothing back when it reads back from the pipe.

Mike Miller <mtmiller>
Project Administrator
Fri 01 May 2015 12:19:04 PM UTC, original submission:

Building Octave 4.0.0-rc4 on CentOS 5 and using gnuplot 4.0.0. This causes the tests for legend, copyobj, and hgsave to fail. This version of gnuplot is too old according to multiple posts on the mailing list and the web

http://octave.1599824.n4.nabble.com/plotting-problem-tp2218392p2218582.html

http://octave.1599824.n4.nabble.com/help-on-plot-in-octave-tp1636537p1636538.html

http://www.sbarjatiya.com/notes_wiki/index.php/Installing_octave_from_source

A simple example

I understand that gnuplot communication is done via pipes, so the version may change since Octave is built. But then, should this be checked at runtime? Or at least a warning during the build that the version is too old but can be updated later.

Also, the error at the end about invalid call to strcat seems weird.

Carnë Draug <carandraug>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #33865:  __gnuplot_eval__.m added by sebald (151B - application/vnd.wolfram.mathematica.package)
file #33866:  __gnuplot_has_object__.m added by sebald (136B - application/vnd.wolfram.mathematica.package)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by sebald (Updated the item)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by carandraug (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 26 May 2016 06:05:28 PM UTCmtmillerDependencies-=>bugs #48024 is dependent
    Mon 29 Jun 2015 02:46:16 AM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Tue 02 Jun 2015 04:10:59 PM UTCjweRelease4.0.0-rc4=>4.0.0
    Fri 01 May 2015 10:31:35 PM UTCsebaldAttached File-=>Added _gnuplot_eval_.m, #33865
      Attached File-=>Added _gnuplot_has_object_.m, #33866
    Fri 01 May 2015 05:18:00 PM UTCmtmillerSeverity3 - Normal=>2 - Minor
      Priority5 - Normal=>3 - Low
    Fri 01 May 2015 02:24:13 PM UTCmtmillerCategoryConfiguration and Build System=>Plotting with gnuplot
      Item GroupNone=>Incorrect Result
      StatusNone=>Confirmed
      Summaryconfigure script does not fail to recognize problems with gnuplot version=>gnuplot toolkit fails to recognize problems with older gnuplot versions

    Back to the top


    Powered by Savane 3.1-cleanup1