Re: '__gnuplot_has_feature__' undefined

[Daniel J Sebald]

On 09/02/2016 10:22 AM, Rik wrote:
> On 09/01/2016 08:56 PM, John W. Eaton wrote:
> > On 09/01/2016 06:28 PM, Dmitri A. Sergatskov wrote:
> > >   HG ID for this build is "e5ae26e50374"
> > >
> > > octave> gnuplot_binary("/usr/bin/gnuplot")
> > > error: '__gnuplot_has_feature__' undefined near line 49 column 5
> > > error: called from
> > >      gnuplot_binary at line 49 column 5
> >
> > Are you running Octave in the build tree with the run-octave script? And
> > is your build tree separate from your source tree?
> >
> > This problem happens after
> >
> >    changeset:   22682:08aa03dfb00e
> >    user:        Rik <address@hidden>
> >    date:        Thu Sep 01 13:22:03 2016 -0700
> >    summary:     Allow switching gnuplot_binary value during a session.
> >
> > because the gnuplot_binary.m file is generated and so is stored in the
> > build tree.  But the private functions like __gnuplot_has_feature__ are
> > in the source tree.  Since the private directory where
> > __gnuplot_has_feature__ is located is not a subdirectory of the directory
> > where gnuplot_binary is located, Octave doesn't find it.
> >
> > I also noticed another problem due to this changeset.  The test executes
> >
> >    gnuplot_binary ("X")
> >
> > and that now ends up calling __gnuplot_version__ which attempts to
> > execute the command "X --version".  On many systems, "X" is the X11
> > server.  So then I see errors about the X server failing to start
> > properly and Octave hangs.
> >
> > It also seems bad that "gnuplot_binary (new_prog)" will now call
> > gnuplot_binary recursively.  It currently works because the persistent
> > value that stores the program name is set before calling
> > __gnuplot_version__, but that seems a bit fragile.
> >
> > For now I've backed out this changeset.
> >
> > I'm also wondering how important it is to be able to change the gnuplot
> > binary during a single Octave session.  Is this something that comes up
> > frequently?
> >
> > jwe
>
> It isn't a big deal, but I was finding it difficult to do testing with
> different gnuplot versions.  I put 'graphics_toolkit gnuplot" in a local
> .octaverc which was then fixing the version of gnuplot used by Octave to
> the default (5.0.3 in my case).
>
> One can work around it by adding
>
> gnuplot_binary XXX
> graphics_toolkit gnuplot
>
> to the .octaverc file, but then the file has to be edited every time you
> switch versions and you have to exit/re-enter Octave.

I just did a little test here in which I created a symbolic link 
"gnuplot" to a different version than system-wide installed.  Launching 
Octave from that directory appears to use the symbolic link version.  It 
means launching two different instances of Octave to make the 
comparison, but that's at least a little better than having to edit some 
file.


> Of course, one of the bigger questions is whether we should even be trying
> to support multiple versions of gnuplot.  In particular, we are having
> trouble with the 4.X branch of gnuplot and there has a suggestion to drop
> support for it in this release (https://savannah.gnu.org/bugs/?48033).  If
> we did that, I wouldn't be worrying about testing conformance with so many
> different versions.

My thinking is "yes" and "no".  Yes on the bigger items, such as things 
that might cause a v4.0 series gnuplot to fail to interpret properly and 
therefore not create a plot.  No on fairly special cases that might be 
outside the ordinary type of plot.

By disallowing older versions of gnuplot, that's ruling out users who 
are looking to put in some simple data and create a simple plot (say a 
line plot), e.g., the non-power-user class.  Say, for example students 
creating a lab report.

The good thing is that upgrading gnuplot is fairly easy, so asking 
people who report arcane gnuplot-compatibility bugs to use the latest 
version isn't too much.


> The BIST test in gnuplot_binary should never have been using such an
> obvious name as "X" which might overlap with a real binary on the system.
> I changed it to use "__foobar__" which I expect has a much lower
> probability of existence.  See cset
> (http://hg.savannah.gnu.org/hgweb/octave/rev/2a00f323cd94).

Well, __foobar__ is probably not super unlikely, but unlikely enough.

Dan