Thread: test palette

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

I get a strange error message in recent CVS:

...

Terminal type set to 'x11'
gnuplot> test palette
gnuplot> test palette
         line 835: undefined variable: character

gnuplot>

Juergen

> I get a strange error message in recent CVS:
>
> ...
>
> Terminal type set to 'x11'
> gnuplot> test palette
> gnuplot> test palette
>         line 835: undefined variable: character

It fails in command.c:test_palette_subcommand(). Firstly it does 
save_set(f), then load_file(f, NULL, FALSE);

The error message is after/during the 2nd load.

I had a look what is inside of these temporary files. "diff" says that the 
1st file contains
 	set style histogram clustered gap 2 title 0, 0, 0

while the 2nd
 	set style histogram clustered gap 2 title character 0, 0, 0

This looks like a bug in the "set" or "save" of histogram.

---
PM

On Tuesday 26 July 2005 08:41 am, Juergen Wieferink wrote:
> Hi,
> 
> I get a strange error message in recent CVS:
> 
> ...
> 
> Terminal type set to 'x11'
> gnuplot> test palette
> gnuplot> test palette
>          line 835: undefined variable: character

Simpler example of breakage:

gnuplot>  set title offset 1,1
          undefined variable: offset

What has happened is that whenever the keyword "title"
is seen, the parser calls try_to_get_string(), which
then chokes if the next token on the line is a keyword
rather than a string or an expression.

I don't know when or how this broke - possibly at the
time of Harald Harders' addition of the generalized
"offset" keyword for all string positions.

I'm not sure yet where to fix it.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Ethan Merrit wrote:
> Simpler example of breakage:
>
> gnuplot>  set title offset 1,1
>           undefined variable: offset
>
>
> What has happened is that whenever the keyword "title"
> is seen, the parser calls try_to_get_string(), which
> then chokes if the next token on the line is a keyword
> rather than a string or an expression.
>
> I don't know when or how this broke - possibly at the
> time of Harald Harders' addition of the generalized
> "offset" keyword for all string positions.
>
> I'm not sure yet where to fix it.

I think try_to_get_string() should check the expression before
evaluating it (using isstring() and friends :-)

I'm quite surprised it doesn't do so far.  This bug must have been
there for quite a long time...

I'm short of time at the moment, so I haven't really checked this
suggestion.

Juergen

On Tuesday 26 July 2005 09:49 am, Ethan Merritt wrote:
> 
> gnuplot>  set title offset 1,1
>           undefined variable: offset
>  
> What has happened is that whenever the keyword "title"
> is seen, the parser calls try_to_get_string(), which
> then chokes if the next token on the line is a keyword
> rather than a string or an expression.

I have just fixed the class of error exemplified above by
adding an explicit check for valid keywords in set_xyzlabel().
This is similar to existing code in set_label().  

However, I think it would be cleaner if the expression evaluation
code triggered by try_to_get_string() simply returned an undefined
variable rather than bailing to the command line with an error message.
That would be a more general solution to the problem, and would
remove the need for long lists of explicit tests for various keywords
in these and other places.

The first place to change is f_push(), if anyone wants to look
into this.  

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Tuesday 26 July 2005 12:53 pm, Juergen Wieferink wrote:
> 
> gnuplot> plot 'file' notitle with lines
> 
> 1) Two gnuplot syntax rules collide at this point: On the one hand
>    gnuplot is greedy: If "with" is a string variable it is to be
>    ignored because it is the title for "title with".  On the other
>    hand it is a key word and as such not to be interpreted as
>    variable name.

Hmm. I wish you had brought that up a few months ago, when the
syntax    ... notitle "title"
was added.  This is indeed a problem.  I am rather inclined to say
we should back out the option altogether since it creates ambiguous
syntax.

> I'd prefer the second case, but how to cope here for "title"?  I
> *really* think we need a stricter syntax policy how to handle these
> cases.

I wonder how far away we are from being able to have that policy
be simply "no ambigous syntax is permitted".   Several disambiguating
keywords have been added already  (e.g.  "font", "offset", "at")
for exactly this reason.   Do you know of any other cases that are
violators, like  ... notitle "title"?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

>> gnuplot> plot 'file' notitle with lines
>>
>> 1) Two gnuplot syntax rules collide at this point: On the one hand
>>    gnuplot is greedy: If "with" is a string variable it is to be
>>    ignored because it is the title for "title with".  On the other
>>    hand it is a key word and as such not to be interpreted as
>>    variable name.
>
> Hmm. I wish you had brought that up a few months ago, when the
> syntax    ... notitle "title"
> was added.  This is indeed a problem.  I am rather inclined to say
> we should back out the option altogether since it creates ambiguous
> syntax.
>
>> I'd prefer the second case, but how to cope here for "title"?  I
>> *really* think we need a stricter syntax policy how to handle these
>> cases.
>
> I wonder how far away we are from being able to have that policy
> be simply "no ambigous syntax is permitted".

The problem is only when user defines a variable with name same as a 
keyword. This is not allowed in normal programming languages.

> Several disambiguating keywords have been added already (e.g.  "font", 
> "offset", "at") for exactly this reason.  Do you know of any other cases 
> that are violators, like ... notitle "title"?

set label {<tag>} {"<label text>"}
set timestamp {"<format>"} ... {"<font>"}
set title {"<title-text>"}
set xlabel {"<label>"}

---
PM

Petr Mikulik wrote:
> The problem is only when user defines a variable with name same as a 
> keyword. This is not allowed in normal programming languages.

That narrows down 'normal' quite a bit more than acceptable.

Whether or not the keywords of the command syntax are just keywords or 
actually "reserved words" is one of many things that programming 
languages are classified by.  It's not justified to declare all 
languages that don't reserve their keywords strictly to themselves as 
"not normal".

And let's not forget that gnuplot allows quite heavy abbreviation.  You 
can't seriously be planning to forbid users from creating functions or 
variables named 't' or 'w' just because they might collide with

	p 'file' t "foo" w l

On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > Several disambiguating keywords have been added already (e.g.  "font", 
> > "offset", "at") for exactly this reason.  Do you know of any other cases 
> > that are violators, like ... notitle "title"?
> 
> set label {<tag>} {"<label text>"}

That is unambiguous, since <tag> cannot be a string, and "<label text>"
cannot be a number.  The existing code correctly handles this.

> set timestamp {"<format>"} ... {"<font>"}

OK. There's a case I missed when adding the disambiguating keyword "font".
I'll fix that.  The "set timestamp" command is also an example of the
documentation lagging the code by not mentioning the keyword "offset".

> set title {"<title-text>"}
> set xlabel {"<label>"}

What is ambiguous in these commands?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Wednesday 27 July 2005 18:18, Ethan Merritt wrote:
> On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > > Several disambiguating keywords have been added already (e.g.  "font",
> > > "offset", "at") for exactly this reason.  Do you know of any other
> > > cases that are violators, like ... notitle "title"?
> >
> > set label {<tag>} {"<label text>"}
>
> That is unambiguous, since <tag> cannot be a string, and "<label text>"
> cannot be a number.  The existing code correctly handles this.

But then also "plot 'file.dat' notitle with lines" is unambiguus.
The token "with" is a valid key word at its place, so it has to be
read as one.  It should be general policy that key words have higher
precedence than optional expressions (numbers and strings).

That said, the implementation of "notitle" is buggy.  And I don't
really know how it should be fixed.

Juergen

Ethan Merritt wrote:
> On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> 
>>>Several disambiguating keywords have been added already (e.g.  "font", 
>>>"offset", "at") for exactly this reason.  Do you know of any other cases 
>>>that are violators, like ... notitle "title"?
>>
>>set label {<tag>} {"<label text>"}
> 
> 
> That is unambiguous, since <tag> cannot be a string, and "<label text>"
> cannot be a number.  

It's still at least somewhat ambiguous, because <tag> can be a variable, 
which could be either the string or a number.

>>set title {"<title-text>"}
>>set xlabel {"<label>"}

> What is ambiguous in these commands?

Well, does

	set title f

change the title text, the x offset, or the font?

On Wednesday 27 July 2005 02:48 pm, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > 
> >>>Several disambiguating keywords have been added already (e.g.  "font", 
> >>>"offset", "at") for exactly this reason.  Do you know of any other cases 
> >>>that are violators, like ... notitle "title"?
> >>
> >>set label {<tag>} {"<label text>"}
> > 
> > That is unambiguous, since <tag> cannot be a string, and "<label text>"
> > cannot be a number.  
> 
> It's still at least somewhat ambiguous, because <tag> can be a variable, 
> which could be either the string or a number.

How is that ambiguous?  
If it evaluates to a number, then it is in fact the label tag (id #).
If it evaluates to a string, then it is the label text.
The parsing code handles both cases correctly.
This was a pain to get right, but it does work.

> >>set title {"<title-text>"}
> >>set xlabel {"<label>"}
> 
> > What is ambiguous in these commands?
> 
> Well, does
> 
> 	set title f
> 
> change the title text, the x offset, or the font?

We are never looking for a variable or an expression after "set",
so "title" is unambiguously a keyword.  The version 4.1 syntax
wants an explicit keyword "font" before a font string, and an
explicit keyword "offset" before an offset. That is what I meant
when I said that addition of these keywords has disambiguated the
syntax.

Old scripts did not use these keywords, but then again old scripts
did not use string variables.  So backwards compatibility is
maintained by accepting commands without these new keywords.
But if you want to use string variables, then for correctness you
must also use the keywords.  

You might quibble that  `set title "arial"`  is somehow recognizable
as intending to change the font rather than the title string.
But neither the old nor the new code treats this as anything other
than the title string. Similarly,  `set title "foo" "arial"`  is
interpreted by both the old (pre 4.1) and the new code as setting
both the title string and the font, though 4.1 issues a warning that
you should have used a "font" keyword.

I think we are in pretty good shape.  The guiding rule is to
check for all legal keywords first, and only then consider the
possibility that it may be a case of deprecated syntax where the
keyword is omitted.  If the input script predates the introduction
of string variables, this works correctly because there will never
be a string variable that might be confused with a keyword.  If it
is a newer script that does use string variables, well then it's
a case of operator error if they fail to use the new syntax.

But there may be a few commands like the one that started this
discussion, where I forgot to add parsing code for the new keywords.
Those are the cases I'm asking about.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Thread: test palette

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta