Mon 30 May 2016 04:44:36 AM UTC, comment #17:
Checking this bug again, the reason for the error
message is from popen2, as @Mike noted in comment #12.
It comes from the line:
in __gnuplot_open_stream__
@Rik (comment #14) : I think we should distinguish between Unix-like systems,
in which the user installs gnuplot, and defineד it's variables, and Windows-like systems,
in which gnuplot is bundled already, and it is "black box" for the user.
There could be discrepancy between user's definitions for gnuplot, and the bundled version of gnuplot.
Defining GNUTERM in octave.vbs will NOT change user's preferences
as embodied by the GNUTERM variable, but will fix this error message. So I suggest to add to octave.vbs the line
|
Wed 25 May 2016 10:32:40 AM UTC, comment #16:
There is a script file that is used to start octave in windows, in which it could be added.
|
Wed 25 May 2016 04:27:05 AM UTC, comment #15:
6) From the command line--though I don't know how this works in Windows--there is the option to set GNUTERM prior to calling octave, e.g.:
sebald@ ~ $ GNUTERM='x11' octave
One could create an application icon in their workbench/gui to launch such a command, then use that launching icon instead of the normal Octave launch icon.
|
Wed 25 May 2016 02:30:40 AM UTC, comment #14:
I tracked this down in a Windows XP VM. The issue is not new. The reason the warning is now visible is because of the change to properly hook up stderr when popen is called. It is not Octave, but gnuplot, which is generating the warning message. Given that we do not want to change user's preferences as embodied by the GNUTERM variable, I am marking this as "Won't Fix".
For individual installations where this is bothersome there are several solutions
1) Unset the GNUTERM environment variable in Windows
2) Set the GNUTERM environment variable to a supported value
3) In Octave, use gnuplot_binary to point to a gnuplot which supports the required term value
4) In Octave, setenv ('GNUTERM', value) to a known good value such as "windows"
5) In Octave, unsetenv ('GNUTERM') to have Octave pick the value.
|
Tue 24 May 2016 11:08:08 PM UTC, comment #13:
getenv on mine returns an empty string, but I dont have gnuplot installed anywhere except via mxe-octave
|
Tue 24 May 2016 09:44:12 PM UTC, comment #12:
The reason the error message is showing up on the default branch but not in the 4.0.2 release may be due to http://hg.savannah.gnu.org/hgweb/octave/rev/212783dc8c9a.
If you build from the tip of the stable branch do you also see the same error message? This may simply be because the stderr stream was being suppressed before and is now being printed on the command window.
I agree that we shouldn't prevent the user from setting GNUTERM to whatever they want. It's probably some configuration on your system that sets GNUTERM to "wxt", either an environment setting or a gnuplot.ini file somewhere.
It has probably been doing so for all previous versions of Octave you tested but the error message was not shown because of the popen2 bug that is now fixed.
|
Tue 24 May 2016 09:33:49 PM UTC, comment #11:
Octave, and gnuplot, both respect the GNUTERM environment variable. I don't think we should change that because it is the user's decision as to which terminal they want to use.
This looks like it might be installation specific. How is the GNUTERM environment variable getting set on the machine? Is it a Windows Environment Variable set by the other installation of gnuplot? The simplest thing would be to change the environment variable.
Or, use gnuplot_binary to point to the gnuplot that you do want to use which includes support for wxt. You can put that in your .octaverc file to have it take effect every time.
I'm not sure why it is generating the error message. You might want to use the debugger and single step through _gnuplot_drawnow_.m. One of the first things it does is is call
which in turn is
I set the GNUTERM to wxt which doesn't exist for me either. I get into this routine and _gnuplot_has_terminal_ returns false so the code moves through the if/elseif tree and eventually selects "windows".
|
Tue 24 May 2016 08:35:02 PM UTC, comment #10:
Yes. The plot is OK in both (the term is set to windows before plotting), but in 4.1.0 I get the error message.
setting GNUTERM to windows in octave.vbs is a good idea.
|
Tue 24 May 2016 08:31:31 PM UTC, comment #9:
But behaves differently in 4.0.2 vs 4.1.0 ?
We could explicitly set that variable in the octave.vbs file
|
Tue 24 May 2016 08:14:11 PM UTC, comment #8:
wxt, in both
|
Tue 24 May 2016 08:12:03 PM UTC, comment #7:
if you run getenv('GNUTERM') in both octave versions, what is the answer?
|
Tue 24 May 2016 07:58:58 PM UTC, comment #6:
@Rik,
Thanks for your advice. You are right the GNUTERM variable
it is set to 'wxt', and that causes the problem.
(Actually, after the message "Unknown or ambiguous terminal name 'wxt'" the plot is OK).
setting GNUTERM to windows solves this problem.
There are still two problems:
1. On the same machine I run version 4.0.2, and I do not
see this error message.
2. On the same machine I have another version of gnuplot, which supports "wxt", so maybe Octave gnuplot shouldn't use GNUTERM.
|
Tue 24 May 2016 03:31:20 PM UTC, comment #5:
I just opened up a cmd.exe window and went to 'C:\Octave\Octave-4.1.0+\bin'. From there you can execute gnuplot.exe. Try
from within gnuplot which displays a list of available terminals. That showed that no wxt terminal was included. The default terminal was 'windows'.
From within Octave, plotting with gnuplot works. I think you might want to investigate whether something is setting the GNUTERM variable, or your Windows path variable somehow has a different version of gnuplot than the one we are shipping. See the gnuplot_binary command and give it the fully qualified path to the gnuplot in the Octave bin directory to see if that is the problem.
|
Tue 24 May 2016 12:48:57 PM UTC, comment #4:
ok - will try a rebuild of dev and see if it does the same for me
|
Tue 24 May 2016 12:45:40 PM UTC, comment #3:
I am using standard windows cross compile, with quantum-depth=16
in GraphicsMagick. I build the dev branch.
The gnuplot version in MXE-Octave is 4.6.7, without 'wxt'
terminal (it is bundled with Octave installer).
In Octave 4.0.2, the gnuplot default terminal for windows is
"windows", so it works fine with the same gnuplot version.
Somehow, in current dev branch, the default terminal was changed to "wxt".
So either gnuplot installation should be change to include wxt terminal, or the default terminal for windows should be changed.
|
Tue 24 May 2016 12:31:17 PM UTC, comment #2:
What mxe-octave configuration settings are you using? I am assuming from other bug reports, this is not a standard windows cross compile?
|
Tue 24 May 2016 07:30:21 AM UTC, comment #1:
A.K., the issue may be that your version of gnuplot does not have 'wxt' terminal built in. As a test, run gnuplot externally on its own and then type:
Terminal type set to 'qt'
gnuplot> set term 'wxt'
Terminal type set to 'wxt'
Options are '0 enhanced'
If this fails, then you don't have 'wxt'. If there is some other terminal built in, then you may be able to use that if you select the terminal properly in, say,
GNUTERM='qt'
export GNUTERM
Or, if you want to use 'wxt' terminal (or perhaps something is forcing that terminal because you are using windows), then you can built gnuplot from scratch pretty easily with WXT.
|
Tue 24 May 2016 05:03:03 AM UTC, original submission:
Using changeset http://hg.savannah.gnu.org/hgweb/octave/rev/7190a26977cb
on MXE-Octave
MXE-Octave is bundled with gnuplot 4.6.7
|