gnuplot-beta

non-interactive usage and color error messages

[Petr M. <mi...@ph...>]

It is neither nice or useful when gnuplot is writing error message such as:

Error: terminal "dumb" does not support continuous colors.
This terminal does not support palette-based images.
This terminal does not support rgb images.
This terminal does not support filled polygons.

when in non-interactive mode (e.g. driven via Octave). They are actually 
just warnings, not errors.

I propose to surround the respective code by

if (interactive)
  ...error message...

What do you think? Are there any other messages that would deserve the same 
care?

---
PM

Re: non-interactive usage and color error messages

[Ethan M. <merritt@u.washington.edu>]

On Friday 23 October 2009 10:05:49 Petr Mikulik wrote:
> It is neither nice or useful when gnuplot is writing error message such as:
> 
> Error: terminal "dumb" does not support continuous colors.
> This terminal does not support palette-based images.
> This terminal does not support rgb images.
> This terminal does not support filled polygons.
> 
> when in non-interactive mode (e.g. driven via Octave). They are actually 
> just warnings, not errors.

Comments:

I'm not an Octave user, so maybe I am missing something.
Would that actually work?  Isn't an Octave session also interactive?

Every message that is generated by 
  fprintf(stderr,ERROR_NOTICE(foo))
should be changed to use int_warn() instead.
I think these were added by Dan Sebald at a time when he was not familiar
with the existing mechanisms and conventions.

Having done that, we could put the   "if (interactive) ..."
test in int_warn() and cover all of these messages in one go.

Or maybe we could add a command line option
   gnuplot -nowarnings
and/or an internal command
   unset warnings


> I propose to surround the respective code by
> 
> if (interactive)
>   ...error message...
> 
> What do you think? Are there any other messages that would deserve the same 
> care?


-- 
Ethan A Merritt

Re: non-interactive usage and color error messages

[Petr M. <mi...@ph...>]

> > It is neither nice or useful when gnuplot is writing error message such as:
> > 
> > Error: terminal "dumb" does not support continuous colors.
> > This terminal does not support palette-based images.
> > This terminal does not support rgb images.
> > This terminal does not support filled polygons.
> > 
> > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > just warnings, not errors.
>
> Every message that is generated by 
>   fprintf(stderr,ERROR_NOTICE(foo))
> should be changed to use int_warn() instead.

Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
tried to patch this replacement in color.c and graphics.c, it works fine.

Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
that they serve for reporting problems with ipc communication, so they 
should "never" happen. The int_warn() construct cannot be used in gplt_x11.

The (interactive) mode is off also for the load command, where the messages 
can be useful.


Well, I came to this problem when testing the "dumb" terminal from within 
Octave (ssh without x11). Then every plot was entitled 
    Error: terminal "dumb" does not support continuous colors.
I want to get rid of that annoying message in this terminal - the dumb 
terminal is too dumb for this message :-)

Thus I propose to add
  if (strcmp(term->name,"dumb"))
before these warnings in graphics.c:
  int_warn "terminal ... does not support continuous colors.",term->name;
  int_warn "terminal ... does not support palette-based images.",term->name;
  int_warn "terminal ... does not support rgb images.",term->name;

Further, there is:
  int_error(NO_CARET, "This terminal does not support filled polygons");
I think that this should be changed to
  int_warn "terminal ... does not support filled polygons.",term->name;
with the same if ("dumb").

All other screen/interactive terminals implement all of these functions so 
the message never appears for them.

> Or maybe we could add a command line option
>    gnuplot -nowarnings
> and/or an internal command
>    unset warnings

Yes, this may be interesting. There are indeed languages where you can set 
warnings on and off.

---
PM

Re: non-interactive usage and color error messages

[Ethan M. <merritt@u.washington.edu>]

On Saturday 24 October 2009, Petr Mikulik wrote:
> > > It is neither nice or useful when gnuplot is writing error message such as:
> > > 
> > > Error: terminal "dumb" does not support continuous colors.
> > > This terminal does not support palette-based images.
> > > This terminal does not support rgb images.
> > > This terminal does not support filled polygons.
> > > 
> > > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > > just warnings, not errors.
> >
> > Every message that is generated by 
> >   fprintf(stderr,ERROR_NOTICE(foo))
> > should be changed to use int_warn() instead.
> 
> Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> tried to patch this replacement in color.c and graphics.c, it works fine.

I am inclined to agree that warning "this terminal does not support..."
is not very useful.  Maybe we should jusr remove these altogether.

> Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
> that they serve for reporting problems with ipc communication, so they 
> should "never" happen. 

I have actually seen these trigger, and used them to debug problems with the 
x11 terminal.  Of course, that's probably only useful for developers.  
So maybe these should be wrapped in #if (DEBUG) ... #endif ?

Re: non-interactive usage and color error messages

[Petr M. <mi...@ph...>]

> > > > It is neither nice or useful when gnuplot is writing error message such as:
> > > > 
> > > > Error: terminal "dumb" does not support continuous colors.
> > > > This terminal does not support palette-based images.
> > > > This terminal does not support rgb images.
> > > > This terminal does not support filled polygons.
> > > > 
> > > > when in non-interactive mode (e.g. driven via Octave). They are actually 
> > > > just warnings, not errors.
> > >
> > > Every message that is generated by 
> > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > should be changed to use int_warn() instead.
> > 
> > Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> > tried to patch this replacement in color.c and graphics.c, it works fine.
> 
> I am inclined to agree that warning "this terminal does not support..."
> is not very useful.  Maybe we should jusr remove these altogether.

I see you have removed the message from color. I think it is OK and I agree 
all these messages can be removed (graphics.c). You can change to comment 
only, i.e.fprintf(...) => /* This terminal does not support palette-based 
images. */

> > Constructions with ERROR_NOTICE are found also in gplt_x11.c. It seems to me 
> > that they serve for reporting problems with ipc communication, so they 
> > should "never" happen. 
> 
> I have actually seen these trigger, and used them to debug problems with the 
> x11 terminal.  Of course, that's probably only useful for developers.  
> So maybe these should be wrapped in #if (DEBUG) ... #endif ?

Yes, this wrapping would be enough.

---
PM

Re: non-interactive usage and color error messages

[Ethan M. <merritt@u.washington.edu>]

On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > Every message that is generated by 
> > > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > > should be changed to use int_warn() instead.
> > > 
> > > Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> > > tried to patch this replacement in color.c and graphics.c, it works fine.
> > 
> > I am inclined to agree that warning "this terminal does not support..."
> > is not very useful.  Maybe we should jusr remove these altogether.

I have removed them, and changed the remaining ERROR_NOTICE instances
to call int_warn() instead.  I did the same for the small number of warnings
sent directly to stderr by term.c and axis.c.

I leave it to you if you want to experiment with making int_warn() 
output condition on    if (interactive)  or some other controlling flag.

-- 
Ethan A Merritt

Re: non-interactive usage and color error messages

[Philipp K. J. <ja...@ie...>]

Sorry for stepping into this discussion late. 

I think it would be highly desirable to be able to 
switch warnings on or off (or possibly even set
where they are sent).

I often call gnuplot from scripts, producing many
graphs. In such situations, I would like to suppress
warnings - or maybe put them into a log file.

So, if we could support something like this, that
would be great:

set warnings         # directs to STDERR or terminal
set warnings "file" # directs to file
unset warnings     # suppresses output

Interactive terminals can then be "smart" to default
to direct warnings to STDERR. But people who use
gnuplot in the background have the flexibility to do
what they need.

In a similar spirit: would it be possible to include the
start-up greeting message in the list of messages
that can be redirected in this way?

Best,

		Ph.


On Monday 26 October 2009 11:53:47 am Ethan Merritt wrote:
> On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > > Every message that is generated by
> > > > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > > > should be changed to use int_warn() instead.
> > > >
> > > > Good idea. These ERROR_NOTICEs are actually warnings only, not
> > > > errors. I've tried to patch this replacement in color.c and
> > > > graphics.c, it works fine.
> > >
> > > I am inclined to agree that warning "this terminal does not support..."
> > > is not very useful.  Maybe we should jusr remove these altogether.
>
> I have removed them, and changed the remaining ERROR_NOTICE instances
> to call int_warn() instead.  I did the same for the small number of
> warnings sent directly to stderr by term.c and axis.c.
>
> I leave it to you if you want to experiment with making int_warn()
> output condition on    if (interactive)  or some other controlling flag.

Re: non-interactive usage and color error messages

[Hans-Bernhard B. <HBB...@t-...>]

Philipp K. Janert wrote:

> I think it would be highly desirable to be able to 
> switch warnings on or off (or possibly even set
> where they are sent).
> 
> I often call gnuplot from scripts, producing many
> graphs. In such situations, I would like to suppress
> warnings - or maybe put them into a log file.

IMHO, that's putting the cart before the horse.

> So, if we could support something like this, that
> would be great:
> 
> set warnings         # directs to STDERR or terminal

For all practical purposes, the terminal _is_ STDERR.

> set warnings "file" # directs to file

What's wrong with plain and simple redirection from the outside?

	gnuplot 2>file

> unset warnings     # suppresses output

	gnuplot 2>/dev/null

> Interactive terminals can then be "smart" to default
> to direct warnings to STDERR.

Except it isn't the terminal

> But people who use gnuplot in the background have the flexibility to
> do what they need.

They have that flexibility already, without us having to anything!

> In a similar spirit: would it be possible to include the
> start-up greeting message in the list of messages
> that can be redirected in this way?

It already is.

Re: non-interactive usage and color error messages

[Philipp K. J. <ja...@ie...>]

You have a point, that works. I even convinced myself
that I can do redirection of this form when I call gnuplot
as a subprocess from Perl:

open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
$cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
print GP $cmd;
close GP;

Personally, I find it hacky, and would prefer a way for
gnuplot to take care of its logging destination itself,
without having to rely on shell redirection.

But I admit that the shell redirection works.

Best,

		Ph.


On Tuesday 27 October 2009 01:37:33 pm you wrote:
> Philipp K. Janert wrote:
> > I think it would be highly desirable to be able to
> > switch warnings on or off (or possibly even set
> > where they are sent).
> >
> > I often call gnuplot from scripts, producing many
> > graphs. In such situations, I would like to suppress
> > warnings - or maybe put them into a log file.
>
> IMHO, that's putting the cart before the horse.
>
> > So, if we could support something like this, that
> > would be great:
> >
> > set warnings         # directs to STDERR or terminal
>
> For all practical purposes, the terminal _is_ STDERR.
>
> > set warnings "file" # directs to file
>
> What's wrong with plain and simple redirection from the outside?
>
> 	gnuplot 2>file
>
> > unset warnings     # suppresses output
>
> 	gnuplot 2>/dev/null
>
> > Interactive terminals can then be "smart" to default
> > to direct warnings to STDERR.
>
> Except it isn't the terminal
>
> > But people who use gnuplot in the background have the flexibility to
> > do what they need.
>
> They have that flexibility already, without us having to anything!
>
> > In a similar spirit: would it be possible to include the
> > start-up greeting message in the list of messages
> > that can be redirected in this way?
>
> It already is.

Re: non-interactive usage and color error messages

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 28 October 2009, Philipp K. Janert wrote:
> 
> You have a point, that works. I even convinced myself
> that I can do redirection of this form when I call gnuplot
> as a subprocess from Perl:
> 
> open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
> $cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
> print GP $cmd;
> close GP;
> 
> Personally, I find it hacky, and would prefer a way for
> gnuplot to take care of its logging destination itself,
> without having to rely on shell redirection.
> 
> But I admit that the shell redirection works.

It also has the advantage that you can use this mechanism from
a cgi script (web server back end) independent of whether the
gnuplot scripts it calls know anything about the redirection.
I use this to create task-specific log files from the web server
even if the various distinct tasks call the same gnuplot script
somewhere along the way.

But what happened to the impetus for the original complaint?
I understood the problem to be that Octave triggers error messages
that appear on the user's screen, even though the user has no way
to do anything about it.  That does seem worth fixing if there is
a well-defined set of harmless messages that are triggered.
Of course, that fix may lie on the Octave side rather than the
gnuplot side :-)  

I never got an answer to my question of whether gnuplot considered 
itself to be in "interactive" mode while being driven from Octave.
Does it?

   Ethan

Re: non-interactive usage and color error messages

[Petr M. <mi...@ph...>]

> But what happened to the impetus for the original complaint?
> I understood the problem to be that Octave triggers error messages
> that appear on the user's screen, even though the user has no way
> to do anything about it.  That does seem worth fixing if there is
> a well-defined set of harmless messages that are triggered.
> Of course, that fix may lie on the Octave side rather than the
> gnuplot side :-)  
> 
> I never got an answer to my question of whether gnuplot considered 
> itself to be in "interactive" mode while being driven from Octave.
> Does it?

It uses the popen("gnuplot", ...), thus gnuplot runs in non-interactive 
mode.

---
PM