octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: '__gnuplot_has_feature__' undefined


From: Rik
Subject: Re: '__gnuplot_has_feature__' undefined
Date: Fri, 2 Sep 2016 08:22:22 -0700

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.

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.

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

--Rik 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]