gnuplot-beta — Developers and beta testers of new gnuplot code

Re: wxwidgets terminal follows its pace

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 29 June 2005 06:23 am, Timoth=E9e Lecomte wrote:
>=20
>>I had to chose in which order things are drawn. Until now, I've decided=
=20
>>to group things by categories : polygons, lines, text, fillboxes. And I=
=20
>>draw polygons before lines, so lines appear over the pm3d plot, as if i=
t=20
>>were transparent. However, I can change its behaviour to make things=20
>>drawn exactly in the order that gnuplot give.
>=20
>=20
> I think it is important that objects are drawn in the order given by
> gnuplot.  Otherwise the "front" and "back" qualifiers lose their meanin=
g,
> and certain plot styles may be oddly rendered (e.g. candlesticks+fill;=20
> histograms+errorbars). The plot styles could, if necessary, be rewritte=
n
> to omit the occluded elements rather than over-writing them with a soli=
d
> fill, but to me it seems there is value in having the core code be
> able to control the order of drawing.

Agreed.  This also makes one's life easier.  That would still leave open =
the possibility for altering the plot after the fact via something like t=
kwidgets, but at the driver level maintain order.

Dan

Re: wxwidgets terminal follows its pace

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> I'm still not clear on why you can't wrap your widget set around
>> a window and then use gnuplot's existing x11 terminal driver to
>> draw in that window.  Probably I am misunderstanding the control
>> flow.
> 
> 
> In addition to portability of this GUI-based terminal (with menus), 
> there will be one immediate gain for current X11 users: speed. As the 
> gnuplot -> gnuplot_x11 is still ascii with millions of sprintf() and 
> sscanf(), the new wx terminal will have the transfer speed of the 
> Windows terminal. Drawing maps, surfaces and images will be considerabl 
> faster.

A comparison should be done, but I wouldn't immediately reach that conclusion.  The use of sscanf is definitely not a winner, but Hans' and Ethan's discussion with that speed bug one user reported suggests the problem lies in long lines that have many elements to be scanned.  (I.e., that principle Hans' concluded a few years ago in a different discussion list and then forgot.)

The sscanf's in the X11 driver are of the variety where only a few items are read (e.g., coordinates) followed by a newline character.  That means there are a *lot* of lines in the plot buffer, but they are short and avoid the slow-down issue somewhat.  Furthermore, if one chooses the "binary transfer" option I implemented for large data sets such as images and pm3d surfaces (which I think is on by default now and over the past year there have been no complaints about treating an ASCII character as 8 bits of binary data), that should help matters.

I don't know what the overhead for refreshing an X11 widget based plot are, but my experience is that the refresh of gnuplot_x11 seems not too bad.  A comparison would be interesting.

Dan

Re: wxwidgets terminal follows its pace

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

On Wednesday 29 June 2005 06:23 am, Timoth=E9e Lecomte wrote:
> >
> I had to chose in which order things are drawn. Until now, I've decided=20
> to group things by categories : polygons, lines, text, fillboxes. And I=20
> draw polygons before lines, so lines appear over the pm3d plot, as if it=
=20
> were transparent. However, I can change its behaviour to make things=20
> drawn exactly in the order that gnuplot give.

I think it is important that objects are drawn in the order given by
gnuplot.  Otherwise the "front" and "back" qualifiers lose their meaning,
and certain plot styles may be oddly rendered (e.g. candlesticks+fill;=20
histograms+errorbars). The plot styles could, if necessary, be rewritten
to omit the occluded elements rather than over-writing them with a solid
fill, but to me it seems there is value in having the core code be
able to control the order of drawing.


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

Re: wxwidgets terminal follows its pace

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

> I'm still not clear on why you can't wrap your widget set around
> a window and then use gnuplot's existing x11 terminal driver to
> draw in that window.  Probably I am misunderstanding the control
> flow.

In addition to portability of this GUI-based terminal (with menus), there 
will be one immediate gain for current X11 users: speed. As the gnuplot -> 
gnuplot_x11 is still ascii with millions of sprintf() and sscanf(), the new 
wx terminal will have the transfer speed of the Windows terminal. Drawing 
maps, surfaces and images will be considerabl faster.

---
PM

Re: user-defined function & string file name

[<br...@ph...>]

Juergen Wieferink wrote:

> A function isstringfunc() will have to evaluate the whole
> expression.

If so, that strongly suggests a serious design flaw to me.  The 
expression evaluation engine didn't have a type system before the 
introduction of string-variables, because it didn't need one.  Now we 
need one, but what you say there means we don't have it.  It must be 
possible to find out an expression's result type without computing its 
actual value.  If there's any ambiguity, force people to resolve it by 
using type-punning operators like real(), int() or string(), or 
equivalently by starting (sub-)expressions with ''. or 0+

> This should only be tried if we know that the syntax
> requires an expression.  Such a function must not be called if the
> next token can be a key word.

Then let's make sure we find all such cases early enough to change the 
syntax to require keywords wherever possible.

 > An invalid expression would lead to
> an int_error().

This, however, seems deeply wrong.  A simple parsing helper function has 
no business bailing out to the command line.  If it were 
"parse_expression()", i.e. it was supposed to do something with the 
expression, that might be a different thing, but a mere test meant to 
reveal what the next token actually is must not under any circumstances 
fail that badly.

> All call sites in the sources would have to be checked and quite few
> would have to be rewritten if they were to use isstringfunc().

All call sites have to be checked anyway.

Re: wxwidgets terminal follows its pace

[<tim...@en...>]

Juergen Wieferink wrote:

>Timoth=E9e Lecomte wrote:
> =20
>
>>Here some news about the wxwidgets terminal I'm writing. Most of the
>>drawing functions are implemented, as you can see in the two following
>>screenshots :
>>
>>http://tipote.free.fr/wxt3.png
>>http://tipote.free.fr/wxt4.png
>>   =20
>>
>
>The pm3d plot is transparent!  Looks nice, but is it intended to be
>so?
>
>
>Juergen
> =20
>
I had to chose in which order things are drawn. Until now, I've decided=20
to group things by categories : polygons, lines, text, fillboxes. And I=20
draw polygons before lines, so lines appear over the pm3d plot, as if it=20
were transparent. However, I can change its behaviour to make things=20
drawn exactly in the order that gnuplot give. I guess that border lines=20
only will be hidden, as you can see with x11 terminal.

Timoth=E9e

Re: wxwidgets terminal follows its pace

[Juergen W. <wie...@fr...>]

Timoth=E9e Lecomte wrote:
> Here some news about the wxwidgets terminal I'm writing. Most of the
> drawing functions are implemented, as you can see in the two following
> screenshots :
>
> http://tipote.free.fr/wxt3.png
> http://tipote.free.fr/wxt4.png

The pm3d plot is transparent!  Looks nice, but is it intended to be
so?


Juergen

Re: user-defined function & string file name

[Juergen W. <wie...@fr...>]

Ethan Merritt wrote:
> I will consolidate the (isstring() || isstringvar()) test into a single
> call isstringvalue().  This simplifies the code, which is good.
> If/when Juergen comes up with a fully working isstringfunc(), that can be
> added at a single point in isstringvalue().

This is tricky.  The functions isstring() and isstringvar() only
check the next token if it is/contains a string.  The current syntax
implies that the whole expression has to be a string then.  A call
to isstring() and isstringvar() is thus safe.

A function isstringfunc() will have to evaluate the whole
expression.  This should only be tried if we know that the syntax
requires an expression.  Such a function must not be called if the
next token can be a key word.  An invalid expression would lead to
an int_error().

Theoretically, this could be implemented.  But it means that all
command line parsing would have to check for key words *before* the
call to isstringfunc() [or an extended isstring()].  All call sites
in the sources would have to be checked and quite few would have to
be rewritten if they were to use isstringfunc().

BTW: I wouldn't like to evaluate an expression and to throw away
everything but the type of the result.  The function
try_to_get_string() seems more appropriate in the cases where
isstringfunc() can be used.

> By my current count there are 14 of these consolidated tests,
> as compareded to  ~60 remaining instances of the original isstring().
>
> So I agree with you in principle, but let's get the simplified code
> checked out first before considering a grand re-naming.


Juergen

Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

And with that, I think now is as good a time as any to consider the key layout patch and the exterior X window patch.  Please give them a try.  I have a short open window of time here.  After this weekend's holiday there is a good chance I will ramp up consulting work again and not be free for quite a while.

Dan

Re: Key layout patch

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> #if 0
>     /* Dan Sebald 21jun2005:  Hans had added this hunk of code after
>      * a new key patch was created.  It was placed somewhere that made
>      * no sense in the new patch.  Sorry if this has created a bug,
>      * but I can't exactly recall what the issue was.  Perhaps if
>      * that bug crops up again we can find a proper home for this code.
>      */
>         /* HBB 20040725: leave manually set bmargin alone */
>         if (bmargin < 0) {
>             ybot += key_entry_height * key_rows
>             + (int) (t->v_char * (ktitl_lines + 1));
>             ybot += (int) (key->height_fix * t->v_char);
>         }
> #endif

OK, I've looked at this hunk of code.  It appears I've already accounted for the above with the new logic:

if (key->flag == KEY_AUTO_PLACEMENT && key->region == GPKEY_EXTERIOR) {
    if (key->stack_dir == GPKEY_HORIZONTAL || key->hpos == CENTRE) {
	if (key->vpos == JUST_BOT && bmargin < 0) {
	    ybot += key_entry_height * key_rows
		+ (int) (t->v_char * (ktitl_lines + 1));
	    ybot += (int) (key->height_fix * t->v_char);
	} else if (key->vpos == JUST_TOP && tmargin < 0) {
	    ytop -= key_entry_height * key_rows
		+ (int) (t->v_char * (ktitl_lines + 1));
	    ytop += (int) (key->height_fix * t->v_char);
	}
    }

That is, flag==KEY_AUTO_PLACEMENT and region==GPKEY_EXTERIOR and vpos==JUST_BOT and hpos==CENTRE is now the equivalent of the old TUNDER.

So, I've removed that hunk of code above which was commented out anyway.  If the developers disagree with behavior it is very easy to fix the current tests at a later date.  I think it should do fine for now.

Dan

Re: wxwidgets terminal follows its pace

[<tim...@en...>]

Daniel J Sebald wrote:

> I guess I can see some advantages to the wxwidgets.  For example, I=20
> think it would be a step toward what Octave developers have been=20
> pining, i.e., a graphics system that resembles Matlab.  They've=20
> already made moves in that direction using other plotting engines. =20
> (They've a scheme, I think, to move the plotting engine outside the=20
> core so that people can choose what to use; but I've not totally=20
> understood what they have in mind.)
>
> Dan

You're right. I think Octave and Maxima can take advantage in an=20
improved graphic system. Gnuplot has wonderful capabilities, so=20
polishing its backend seems really worthwhile.

I plan to send a message to the mailing-lists of Octave and Maxima to=20
ask for their needs and ideas.

Timoth=E9e

Re: wxwidgets terminal follows its pace

[<tim...@en...>]

Ethan A Merritt wrote:

>On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote:
> =20
>
>>   =20
>>
>>A large part of the idea behind having
>>a wxwidgets output driver is that it will work not just on X11.
>>   =20
>>
>
>I see. I was confused by Timoth=E9e's screen shots, which showed the
>plot in an X-window.
>
I'm sorry ;-). The "X" icon is just the default one for wxwidgets apps=20
compiled with gtk.

>So you're saying that wxwidgets layers on top
>of X if the system supports X, and layers on top of something else
>on systems that don't support X?
> =20
>
Exactly. The screenshots come from the gtk+2 version of wxwidgets, but=20
it can be compiled with the Windows, MacOS, OS/2 versions to get native=20
appearance.

>>The way I look at it, maybe its strongest promise is that it may allow
>>us to put the old MS Windows driver to rest.
>>   =20
>>
>
>At the cost of accepting C++.  But I suppose that's a net win :-)
>
> =20
>
This C++ code shouldn't be intrusive, as it's limited to gui=20
functionnalities.

Greetings,
Timoth=E9e

Re: wxwidgets terminal follows its pace

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote:
>=20
>>Ethan Merritt wrote:
>>
>>>Am I missing the point?
>>
>>Partly so, by my understanding.  A large part of the idea behind having
>>a wxwidgets output driver is that it will work not just on X11.
>=20
>=20
> I see. I was confused by Timoth=E9e's screen shots, which showed the
> plot in an X-window.

I too thought the plot looked exactly like the X11 plots and was misleadi=
ng, but I assumed there was more to come in the way that Hans describes.

>  So you're saying that wxwidgets layers on top
> of X if the system supports X, and layers on top of something else
> on systems that don't support X?
>=20
<snip>
>=20
> At the cost of accepting C++.  But I suppose that's a net win :-)

But you described before that it should be insulated, right?  I.e., some =
drivers would be broken out, which means the wxwidgets need only be the o=
ne compiled under C++ so long as there is a compatible function call/retu=
rn.

I guess I can see some advantages to the wxwidgets.  For example, I think=
 it would be a step toward what Octave developers have been pining, i.e.,=
 a graphics system that resembles Matlab.  They've already made moves in =
that direction using other plotting engines.  (They've a scheme, I think,=
 to move the plotting engine outside the core so that people can choose w=
hat to use; but I've not totally understood what they have in mind.)

Dan

Re: wxwidgets terminal follows its pace

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

On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > Am I missing the point?
>
> Partly so, by my understanding.  A large part of the idea behind having
> a wxwidgets output driver is that it will work not just on X11.

I see. I was confused by Timoth=E9e's screen shots, which showed the
plot in an X-window.  So you're saying that wxwidgets layers on top
of X if the system supports X, and layers on top of something else
on systems that don't support X?

> The way I look at it, maybe its strongest promise is that it may allow
> us to put the old MS Windows driver to rest.

At the cost of accepting C++.  But I suppose that's a net win :-)

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxwidgets terminal follows its pace

[<br...@ph...>]

Ethan Merritt wrote:
> input. Is that right?  But to implement this new input channel
> seems a separate task from duplicating the output to an x11 plot.
> 
> Am I missing the point?

Partly so, by my understanding.  A large part of the idea behind having 
a wxwidgets output driver is that it will work not just on X11.  Once 
completed, we should have a GUI terminal driver that works on all major 
platforms (and maybe some minor ones, too).   The way I look at it, 
maybe its strongest promise is that it may allow us to put the old MS 
Windows driver to rest.

Re: wxwidgets terminal follows its pace

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

On Tuesday 28 June 2005 05:39 pm, Timoth=E9e Lecomte wrote:

> Please feel free to give me your ideas !

I'm still not clear on why you can't wrap your widget set around
a window and then use gnuplot's existing x11 terminal driver to
draw in that window.  Probably I am misunderstanding the control
flow.  As I understand it, the widgets act like the hotkeys=20
bound by the `bind <key> "action"`.  So it is a new channel of
input. Is that right?  But to implement this new input channel
seems a separate task from duplicating the output to an x11 plot.

Am I missing the point?

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

wxwidgets terminal follows its pace

[<tim...@en...>]

Hi !

Here some news about the wxwidgets terminal I'm writing. Most of the=20
drawing functions are implemented, as you can see in the two following=20
screenshots :

http://tipote.free.fr/wxt3.png
http://tipote.free.fr/wxt4.png

Mouse support is partially implemented : rotation, scaling (3D) and zoom=20
(2D) work.

Thanks to our discussion about setjmp/longjmp, I have got a working=20
terminal-to-gnuplot communication for commands which may raise errors.=20
In particular,  it allows me to rescale the plot properly when the size=20
of the window changes.

This is not really impressive compared to x11, windows, or OS/2=20
functionnalities, but for me it's already huge : it's the first time I=20
write more than 50 lines for a program (currently 1200 in the terminal) !

The next step : complete mouse capabilities (based on the behaviour of=20
the x11 terminal) : ruler, zoombox, etc.

And then : either enhanced text, or cleanup, or (the most attractive to=20
me) a modified mouse behaviour based on a toolbar plus menus for some=20
properties (labels to begin).

Please feel free to give me your ideas !

Greetings,
Timoth=E9e

Re: user-defined function & string file name

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

On Tuesday 28 June 2005 12:54 pm, Hans-Bernhard Br=F6ker wrote:
> IMHO, isstring() should have been renamed=20
> to isstringconst(), and a new isstring() been implemented that computes=20
> the above || expression.

I will consolidate the (isstring() || isstringvar()) test into a single
call isstringvalue().  This simplifies the code, which is good.
If/when Juergen comes up with a fully working isstringfunc(), that can be
added at a single point in isstringvalue(). =20

By my current count there are 14 of these consolidated tests,=20
as compareded to  ~60 remaining instances of the original isstring().

So I agree with you in principle, but let's get the simplified code
checked out first before considering a grand re-naming.


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

Re: user-defined function & string file name

[<br...@ph...>]

Ethan Merritt wrote:

> Right. It used to be sufficient to do "if (isstring(c_token))".
> Now it is necessary to check
>     "if (isstring(c_token) || isstringvar(c_token) || isstringfunc(c_token))"

It shouldn't be that complex.  IMHO, isstring() should have been renamed 
to isstringconst(), and a new isstring() been implemented that computes 
the above || expression.  Then a single go through all the sources, 
replacing those (few?) uses of isstring() that actually have to be 
isstringconst(), would have sufficed to change the global behaviour.

I.e. isstring() should have changed meaning from "token is a string 
literal" to "token starts a string-valued expression".

> The problem is we don't *have* a function isstringfunc().

Re: user-defined function & string file name

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

On Tuesday 28 June 2005 10:31 am, Hans-Bernhard Br=F6ker wrote:
>=20
> To recognize that a file name is being input, the parser needs=20
> some way of figuring out that what the type of a given expression is.=20
> Before string variables, that was simple: strings could only be=20
> literals, and those were easy to recognize by the opening ' or ".  Now=20
> it's trickier, and in the example discussed here, it fails.

Right. It used to be sufficient to do "if (isstring(c_token))".
Now it is necessary to check
    "if (isstring(c_token) || isstringvar(c_token) || isstringfunc(c_token)=
)"
The problem is we don't *have* a function isstringfunc().
We do have the first two, and they are properly used in many places.
But the loop-over-functions in plot2d.c neglected the isstringvar() test.
I've corrected this and the equivalent place in plot3d.c, and will add
the bug-fix to cvs after it's been through the usual checks and testing.


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

Re: user-defined function & string file name

[<br...@ph...>]

Ethan A Merritt wrote:

> The difficult case (which this is not an example of) is
> distinguishing a user-defined function that returns the name of a
> file from a user- defined function that returns a numerical value.

We may be closer to that case than you realize.

     plot fdat

could be a plot of a file (if fdat is a string-valued variable), a
linear function (if 'set dummy fdat' is in effect), or a constant (if
fdat is a numerical variable). There are four cases, distinguished by
the attribute pairs string<-->numeric and literal<-->expression.

There is not actually a distinction between function and expression to 
be made here.  I.e. the 'plot' command line parser is not trying to find 
a function --- it's trying to find an expression that it can evaluate, 
and a simple variable or even a literal fit that bill nicely. That's why 
all of

    plot 5
    plot a
    plot x
    plot 5*a+f(x)

work.  To recognize that a file name is being input, the parser needs 
some way of figuring out that what the type of a given expression is. 
Before string variables, that was simple: strings could only be 
literals, and those were easy to recognize by the opening ' or ".  Now 
it's trickier, and in the example discussed here, it fails.

In the case of a 'plot fdat', there's no syntactic hint at all --- you 
have to actually check the type of fdat to see if this is a filename or 
a numeric variable.  I.e. the exact same plot command line could produce 
a function or a data plot, at different times in the same gnuplot session.

Re: Building issues under Solaris 9

[Daniel J S. <dan...@ie...>]

Christopher Cordell wrote:
> Hello,
> 
>    I am not certain that I am emailing the proper address but this is 
> the address I saw on the development page.
> 
>    I am using Solaris 9 and attempting to build the latest CVS version 
> 4.1 for a scientist who needs to use a feature only under 4.1 apparently.
> 
>    I tried the sample unix makefile with no success so then I grabbed 
> the required versions of autoconf, m4, etc. and tried to follow the 
> directions on the page.
> 
>    The process hangs/waits with ./prepare:
> 
> opik{root}76# ./prepare
> rm -f Makefile.am Makefile.amt
> sed -n '1,/^##m4-files-begin/p' Makefile.am.in > Makefile.amt
> echo EXTRA_DIST = README Makefile.am.in buildvms.com config.* \
>  djconfig.sh make_vms.com term_pc.h makefile.* | fmt | \
>  (tr '\012' @; echo) |sed 's/@$/%/;s/@/ \\@/g' |tr @% '\012 ' >> 
> Makefile.amt
> sed -n '/^##m4-files-end/,$p'  >> Makefile.amt
> 
> 
>    What tips do you have for building (other than on the dev. page).

You might have to do a bit more investigation on that one.  The string editor is 
a strange command to hang on.  You are running from root, so it probably is not 
a problem with file access privilege.  Perhaps it is the command after the above 
"sed" command.

It appears to have stopped early on in the "config" subdirectory.  Check to see 
what "Makefile.amt" looks like (or the non-temporary "Makefile.am" if it happens 
to exist).  That is, the command inside "prepare" is

   && (cd config && make -f Makefile.am.in Makefile.am ) \

So, looking at "config/Makefile.am.in", the command following your last echoed 
command is

	sed -n '/^##m4-files-end/,$$p' $< >> $@t
	chmod a-w $@t

Could Solaris be hanging on a "chmod" command?

Dan

Re: user-defined function & string file name

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

On Tuesday 28 June 2005 08:34 am, Hans-Bernhard Br=F6ker wrote:
> Taro Sato wrote:
> >
> > f(x) =3D x
> > fdat =3D 'xy.dat'
> > plot f(x), fdat u 1:2
> > "plot.nogood.gp", line 4: warning: encountered a string when expecting
> > a number "plot.nogood.gp", line 4: NB: you cannot plot a string-valued
> > function
>
> This is not exactly a bug, but a known syntactical limitation.  The way
> around it is to drop the parser a hint that fdat is meant to be a
> string, not a number, like this:
>
>     plot f(x), ''+fdat u 1:2    # or was that ''.fdat  ?

The string concatenation operator is .  so the hint would be ''.fdat

However, I think this really is a bug.  `plot f(x)` and `plot fdat`
both work individually; it is only the combination of the two that
triggers an error message.  That should be fixable.  I suspect that
whatever causes this will also turn out to explain a problem in one of Juer=
gen Wieferink's patches.

The difficult case (which this is not an example of) is distinguishing
a user-defined function that returns the name of a file from a user-
defined function that returns a numerical value.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Building issues under Solaris 9

[<br...@ph...>]

Christopher Cordell wrote:
>    I tried the sample unix makefile with no success so then I grabbed 
> the required versions of autoconf, m4, etc. and tried to follow the 
> directions on the page.

Looks like you also need a different 'make' --- GNU make should do,
or any other one that gets the $< reference in config/Makefile.am.in 
correctly expanded:

> sed -n '/^##m4-files-end/,$p'  >> Makefile.amt
                                ^^--- there's supposed to be a
Makefile.am.in inserted here, but it's not.

It's generally quite tricky to build CVS versions of completely auto*'ed 
packages like gnuplot on any not completely GNUed-up platform.

Re: user-defined function & string file name

[<br...@ph...>]

Taro Sato wrote:
> It seems the gnuplot has difficulty distinguishing a user-defined
> function and a string file name stored in a variable.  

> reset
> f(x) = x
> fdat = 'xy.dat'
> plot f(x), fdat u 1:2
> pause -1
> "plot.nogood.gp", line 4: warning: encountered a string when expecting a number
> "plot.nogood.gp", line 4: NB: you cannot plot a string-valued function

This is not exactly a bug, but a known syntactical limitation.  The way 
around it is to drop the parser a hint that fdat is meant to be a 
string, not a number, like this:

    plot f(x), ''+fdat u 1:2    # or was that ''.fdat  ?

Concatenating fdat with the empty string yields a string constant, and 
the parser seeing the "'" that start off this entry in the command line 
can directly deduce that this is not a number, but a string.