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

Re: change in handling missing data.

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

Ethan A Merritt wrote:

> 
> You need to say 
> 	plot "t3.dat" using ($1):($2)

Oh yeah.  I recall that now from the demo examples.


> Someone long ago decided that  "using 1:2" should
> behave differently than "using ($1):($2)". I don't know
> why, but we're stuck with it unless we want to break 
> with all previous versions.  

This sounds like a familiar discussion.

Dan

Re: change in handling missing data.

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

On Sunday 06 August 2006 10:45 pm, Daniel J Sebald wrote:
> Dmitri A. Sergatskov wrote:
> > 0 2
> > 2 0
> > NaN NaN
> > 4 2
> > 2 4
> > 
> > with gnuplot 4.1 (today's CVS snapshot):
> > gnuplot> plot "t3.dat"
> >               ^
> >          Bad data on line 3


You need to say 
	plot "t3.dat" using ($1):($2)

>   plot "t3.dat" using 1:2
> 
> That appears to work the same.  Not sure why.

This is explained in the help files, with examples.
Really.
Now I agree that it's a peculiar way for it to work, but
it is in fact doing exactly what it is documented to do.

Someone long ago decided that  "using 1:2" should
behave differently than "using ($1):($2)". I don't know
why, but we're stuck with it unless we want to break 
with all previous versions.  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: change in handling missing data.

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

Dmitri A. Sergatskov wrote:
 
> 
> Here is the data file ("t3.dat"):
> # -- begin
> 0 2
> 2 0
> NaN NaN
> 4 2
> 2 4
> # -- end
> 
> with gnuplot 4.1 (today's CVS snapshot):
> gnuplot> plot "t3.dat"
>               ^
>          Bad data on line 3

Try

  plot "t3.dat" using 1:2

without setting data file missing.  That appears to work the same.  Not sure why.

Dan

Re: change in handling missing data.

[Dmitri A. S. <das...@gm...>]

On 8/6/06, Ethan A Merritt <merritt@u.washington.edu> wrote:

> > It is an issue, because previously I did not bother to check
> > if NaNs in my files written as "NaN" or as "nan".
>
> gnuplot reads the number using strtod().
> The linux man page for strtod() says:
>
>       An infinity is either ``INF'' or ``INFINITY'', disregarding case.
>       A  NAN  is  ``NAN''  (disregarding  case) optionally followed by `(', a
>       sequence of characters, followed by ')'.  The character  string  speci-
>       fies in an implementation-dependent way the type of NAN.


Here is the data file ("t3.dat"):
# -- begin
0 2
2 0
NaN NaN
4 2
2 4
# -- end

with gnuplot 4.1 (today's CVS snapshot):
gnuplot> plot "t3.dat"
              ^
         Bad data on line 3

gnuplot> set datafile missing "NaN"
gnuplot> plot "t3.dat"
gnuplot>

(gnuplot 4.0 just plots it)


> That's a bit hard to believe.
>
> How big are your data files?

For the benchamrk I made 2 column data file
x = (-10,10), y = sin(x)
with 1e6 (one million) rows.

cmd is just a one line script
first it is:

plot "t.dat"

[dima@das200 tmp]$ time gnuplot < cmd

real    0m3.814s
user    0m3.488s
sys     0m0.152s

Now changed it to

plot "t.dat" using 1:2

[dima@das200 tmp]$ time gnuplot < cmd

real    0m3.831s
user    0m3.528s
sys     0m0.176s

And finally changed it to

plot "t.dat" using ($1):($2)

[dima@das200 tmp]$ time gnuplot < cmd

real    0m11.086s
user    0m5.828s
sys     0m4.600s

So the wall clock actually increased by factor of 4 mostly due to
"sys" time (originally I just looked at user time -- that is where 150%
came from). I tried both X11 terminal and "dumb" (and output to
/dev/null)  w/o any noticeable difference. These numbers do not
include time of
gnuplot_x11 doing actual drawing.

I did multiple passes, so I am pretty sure the data file is in disk cache.

All this is on FedoraCore 5/ Pentiun4 2.6GHz / 2GB of RAM

>
>         EAM
>

Sincerely,

Dmitri.
--

Re: change in handling missing data.

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

Ethan A Merritt wrote:

>>A simple benchmark (time gnuplot < cmd) shows that (on my computer
>>at least) plot "file" using ($1):($2) takes about 150% as long
>>as plot "file".
> 
> 
> That's a bit hard to believe.  

Actually, it may be correct.  Isn't the difference between "using 1:2" and "using ($1):($2)" that the latter passes the data through a function?  (In this case a very simple function.)  That is, the "action table" code is called.

Try just "using 1:2", Dmitri, and see if that speeds things back to what you expect.

Dan

Re: change in handling missing data.

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

On Sunday 06 August 2006 09:07 pm, Dmitri A. Sergatskov wrote:
> > For what it's worth...
> > Your "NaN" strings *are* being read as legal IEEE format numbers.
> > Using "set datafile missing ..." is not the issue.
> > The issue is what to do when a number is not legal (NaN, Inf,
> > underflow).
> 
> It is an issue, because previously I did not bother to check
> if NaNs in my files written as "NaN" or as "nan".

gnuplot reads the number using strtod().
The linux man page for strtod() says:

      An infinity is either ``INF'' or ``INFINITY'', disregarding case.
      A  NAN  is  ``NAN''  (disregarding  case) optionally followed by `(', a
      sequence of characters, followed by ')'.  The character  string  speci-
      fies in an implementation-dependent way the type of NAN.

> Also, how do I handle file that has both "NaN" and "Inf"?

They are the same, for this purpose.
Do not try to describe them via "set datafile missing";
just let them be read in as floating point numbers.

It is in general not safe to read files without the "using"
specifier unless you are absolutely certain what each line contains.
We have tried to maintain backwards compatibility with old behaviour,
but recent extensions and new plot modes require "using" in order
to work at all. For example, in order to read color information from
the data file, or point size, you need extra columns.  But if you
do not tell the program which column is which, it will get confused
and plot the wrong thing altogether. 

> A simple benchmark (time gnuplot < cmd) shows that (on my computer
> at least) plot "file" using ($1):($2) takes about 150% as long
> as plot "file".

That's a bit hard to believe.  

How big are your data files?

Do they have many columns per line, or only two? 
(This used to be an issue but I thought we fixed it).

Are you willing/able to run profiling so that you can tell us
which routine[s] the time is being lost to?

	EAM

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: change in handling missing data.

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

Dmitri A. Sergatskov wrote:

> So I was hoping there is some setting that would allow old
> behavior. Apparently it is not the case, so be it, we will adapt.
> Perhaps it is time to convert to "binary" datafile format...

That would give a speed increase, but of course there isn't the flexibility with DF_MISSING, DF_UNDEFINED as there is with ASCII files, unless we want to define strings some how... but I think that is low priority.  Binary is for speed purposes.

>>The issue is what to do when a number is not legal (NaN, Inf,
>>underflow).
> 
> 
> It is an issue, because previously I did not bother to check
> if NaNs in my files written as "NaN" or as "nan".
> Also, how do I handle file that has both "NaN" and "Inf"?

[snip]

> I understand this problem. I also prefere the old (4.0) behavior.
> For one thing, since the plot is the graphical representation of
> the data I want to have a visual feedback that I have "funny"
> datapoints. Broken line provides such a feedback. Plotting
> over it -- hides it.
> Again, I am not asking to change anything. At least not at this
> moment...

You are confirming the issue, however.  I say give the user the flexibility and not try to interpret what they mean, then it is no more worries for developers.

Dan

Re: change in handling missing data.

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

Ethan A Merritt wrote:
> On Sunday 06 August 2006 02:20 pm, Dmitri A. Sergatskov wrote:
> 
>>I there any way I can get an old (4.0) behavior with new
>>gnuplot when plotting data files with missing data?
> 
> 
> Short answer:  Yes.
> 	plot 'test1.dat' using ($1):($2) with lines
> 
> Longer answer:
> 
> The whole "missing" issue drives me to distraction.
> No two people expect the same thing from it, so it's no wonder
> that many bug reports are filed against it.  3.7 and 4.0 did 
> not behave identically, so existing scripts are not an 
> infallible guide either.
> 
> For what it's worth... 
> Your "NaN" strings *are* being read as legal IEEE format numbers.  
> Using "set datafile missing ..." is not the issue.
> The issue is what to do when a number is not legal (NaN, Inf,
> underflow). 
> Plot, or not plot? 
> Increment the line number, or not?
> Error message?

I agree.  No one particular way of dealing with this will satisfy everybody.  Hence I say it should be configurable.  And doing so would really be a nice feature that users like.

The problem with satisfying everyone right now is that there simply isn't enough variation in treating the data.  Being so limited is the problem.  We have expanded things a bit with DF_MISSING, but not enough.

There should be

1) Enough variety to satisfy everyone.
2) And/or configurability.
3) Multiple definitions for the class of data type.

We don't want to get so abstract that things become arcane, so lets go with say three types with some default behavior.  Internally these would be

DF_MISSING:  Simply SKIP, no break between points
DF_UNDEFINED:  BREAK between points.
DF_NAN:  Don't know, also BREAK?

Well, then we also allow some configurability with multiple definitions.  That would be enough flexibility so that the user has more than one way of attacking this problem.  S/he could add more strings to a data class or switch around strings in the definition of these classes, or configure the manner in which each class is treated.

With a demo, the user should get the idea clearly.

Dan

Re: change in handling missing data.

[Dmitri A. S. <das...@gm...>]

On 8/6/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
> On Sunday 06 August 2006 02:20 pm, Dmitri A. Sergatskov wrote:
> > I there any way I can get an old (4.0) behavior with new
> > gnuplot when plotting data files with missing data?
>
> Short answer:  Yes.
>         plot 'test1.dat' using ($1):($2) with lines

I figure this out. This has a couple problems.
The issue came about from using gnuplot from octave. Since
octave interpreter writes the (temporary) data file for gnuplot to
plot, it knows the data format and thus does not need to specify
"using" string.
A simple benchmark (time gnuplot < cmd) shows that (on my computer
at least) plot "file" using ($1):($2) takes about 150% as long
as plot "file".
So I was hoping there is some setting that would allow old
behavior. Apparently it is not the case, so be it, we will adapt.
Perhaps it is time to convert to "binary" datafile format...

>
> Longer answer:
>
> The whole "missing" issue drives me to distraction.
> No two people expect the same thing from it, so it's no wonder
> that many bug reports are filed against it.  3.7 and 4.0 did
> not behave identically, so existing scripts are not an
> infallible guide either.
>
> For what it's worth...
> Your "NaN" strings *are* being read as legal IEEE format numbers.
> Using "set datafile missing ..." is not the issue.
> The issue is what to do when a number is not legal (NaN, Inf,
> underflow).

It is an issue, because previously I did not bother to check
if NaNs in my files written as "NaN" or as "nan".
Also, how do I handle file that has both "NaN" and "Inf"?

> Plot, or not plot?
> Increment the line number, or not?
> Error message?

I understand this problem. I also prefere the old (4.0) behavior.
For one thing, since the plot is the graphical representation of
the data I want to have a visual feedback that I have "funny"
datapoints. Broken line provides such a feedback. Plotting
over it -- hides it.
Again, I am not asking to change anything. At least not at this
moment...

>
>         EAM
>

Sincerely,

Dmitri.
--

Re: change in handling missing data.

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

On Sunday 06 August 2006 02:20 pm, Dmitri A. Sergatskov wrote:
> I there any way I can get an old (4.0) behavior with new
> gnuplot when plotting data files with missing data?

Short answer:  Yes.
	plot 'test1.dat' using ($1):($2) with lines

Longer answer:

The whole "missing" issue drives me to distraction.
No two people expect the same thing from it, so it's no wonder
that many bug reports are filed against it.  3.7 and 4.0 did 
not behave identically, so existing scripts are not an 
infallible guide either.

For what it's worth... 
Your "NaN" strings *are* being read as legal IEEE format numbers.  
Using "set datafile missing ..." is not the issue.
The issue is what to do when a number is not legal (NaN, Inf,
underflow). 
Plot, or not plot? 
Increment the line number, or not?
Error message?

	EAM

 
> E.g. consider the file (say "test1.dat")
> 
> # -- begin
> 0 1
> 1 0
> NaN NaN
> 2 1
> 1 2
> # -- end
> 
> In gnuplot 4.0
> plot "test1.dat" with line
> produces plot with two segments.
> 
> With 4.1, first one has to do
> set datafile missing "NaN"
> (that still would not handle "nan")
> but after that
> plot "test1.dat" with line
> would connect the segments along (1 0) (2 1) line.
> 
> I am not to argue wich way is better (though I would prefer
> gnuplot to handle IEEE special numbers automatically),
> I am just wondering if this behavior (to connect the segments)
> is indeed the expected one (not a bug) and if it is indeed so,
> is there any variable I can set to get old style behavior?
> 
> Sincerely,
> 
> Dmitri.
> --
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: change in handling missing data.

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

Daniel J Sebald wrote:

> From: Daniel J Sebald <danielDOTsebaldATieeeDOTorg>

Oh no!  I sent my email address inside the body.  Shouldn't do that...

Re: change in handling missing data.

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

Dmitri A. Sergatskov wrote:
> I there any way I can get an old (4.0) behavior with new
> gnuplot when plotting data files with missing data?

At one point I had created a patch for better control of this and gave a demo illustrating how to create plots with breaks in the line and simply skipping points.  I thought it was a good idea for a feature, i.e., a method of telling gnuplot how it should handle various types, but it didn't get much traction.

> 
> E.g. consider the file (say "test1.dat")
> 
> # -- begin
> 0 1
> 1 0
> NaN NaN
> 2 1
> 1 2
> # -- end
> 
> In gnuplot 4.0
> plot "test1.dat" with line
> produces plot with two segments.
> 
> With 4.1, first one has to do
> set datafile missing "NaN"
> (that still would not handle "nan")

There is patch for multiple missing, e.g., set missint "NaN" "nan" "?".

Give that a try if you need such a feature.

> but after that
> plot "test1.dat" with line
> would connect the segments along (1 0) (2 1) line.
> 
> I am not to argue wich way is better (though I would prefer
> gnuplot to handle IEEE special numbers automatically),
> I am just wondering if this behavior (to connect the segments)
> is indeed the expected one (not a bug) and if it is indeed so,
> is there any variable I can set to get old style behavior?

I say it should be configurable.  Anyway, the thread of this discussion in the past is titled:

Subject: Re: MISSING and UNDEFINED
Date: Sun, 18 Jun 2006 18:00:57 -0500
From: Daniel J Sebald <dan...@ie...>

There are some PNGs there showing the output of the demo.

Dan

change in handling missing data.

[Dmitri A. S. <das...@gm...>]

I there any way I can get an old (4.0) behavior with new
gnuplot when plotting data files with missing data?

E.g. consider the file (say "test1.dat")

# -- begin
0 1
1 0
NaN NaN
2 1
1 2
# -- end

In gnuplot 4.0
plot "test1.dat" with line
produces plot with two segments.

With 4.1, first one has to do
set datafile missing "NaN"
(that still would not handle "nan")
but after that
plot "test1.dat" with line
would connect the segments along (1 0) (2 1) line.

I am not to argue wich way is better (though I would prefer
gnuplot to handle IEEE special numbers automatically),
I am just wondering if this behavior (to connect the segments)
is indeed the expected one (not a bug) and if it is indeed so,
is there any variable I can set to get old style behavior?

Sincerely,

Dmitri.
--

Re: demos

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

Ethan Merritt wrote:

> My recommendation would be that any locally-modified version should
> change the contents of the PATCHLEVEL file.  Everything else will
> be handled automatically.  Perhaps this should be documented somewhere
> (INSTALL? README?)

It's actually sort-of required, by the Copyright statement.  It says 
that any modified binary distributed to others has to report itself as a 
modified version, and give the contacts of the person who modified it.

Re: demos

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

Ethan Merritt wrote:
> On Friday 04 August 2006 10:12 am, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote:
>>>
>>>>First, could this
>>>>"gnuplot-defined variables" be made a permanent thing?
>>>
>>>I do not understand the question.
>>
>>You said: "Of course, this requires that string variables are
>>configure in (now the default)."  But string vars are something
>>different.  The GPVAL_VERSION is always present then and can't be
>>configured out of gnuplot some how?  (I haven't followed the GPVAL_
>>threads.)
> 
> 
> I still don't understand the question.
> 
> GPVAL_VERSION is a floating point number, and is always defined.
> 
> But GPVAL_COMPILE_OPTIONS is a string, so it can only
> be loaded into a variable if string support is configured.

RIght, I sort of figured that out when I thought twice about "string" qualifier.  The GPVAL_VERSION is always present.  So the user can do a print(GPVAL_VERSION) and get the value back.


>>That helps a little bit in the sense that it weeds out a lot.  But it
>>still isn't at the command line...
> 
> 
> Er, then what do you mean by "command line"?

I guess I meant the "gnuplot prompt".  Slightly different ways of getting the same thing.  But both ways are available, so whichever method a programmer might prefer is currently available.  Good.

Dan

Re: demos

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

On Friday 04 August 2006 10:12 am, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote:
> >>First, could this
> >>"gnuplot-defined variables" be made a permanent thing?
> >
> > I do not understand the question.
>
> You said: "Of course, this requires that string variables are
> configure in (now the default)."  But string vars are something
> different.  The GPVAL_VERSION is always present then and can't be
> configured out of gnuplot some how?  (I haven't followed the GPVAL_
> threads.)

I still don't understand the question.

GPVAL_VERSION is a floating point number, and is always defined.

But GPVAL_COMPILE_OPTIONS is a string, so it can only
be loaded into a variable if string support is configured.

> >>I think I've  been asked if gnuplot somehow could return its
> >> version.
> >
> > gnuplot --version
> > gnuplot -V
>
> That helps a little bit in the sense that it weeds out a lot.  But it
> still isn't at the command line...

Er, then what do you mean by "command line"?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: demos

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

Ethan Merritt wrote:
> On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote:
> 
>>First, could this
>>"gnuplot-defined variables" be made a permanent thing?
> 
> 
> I do not understand the question.

You said: "Of course, this requires that string variables are configure in
(now the default)."  But string vars are something different.  The GPVAL_VERSION is always present then and can't be configured out of gnuplot some how?  (I haven't followed the GPVAL_ threads.)


>>I think I've  been asked if gnuplot somehow could return its version.
> 
> 
> gnuplot --version
> gnuplot -V

That helps a little bit in the sense that it weeds out a lot.  But it still isn't at the command line... eh, let user demand drive this.  If more people ask, then I'll raise the issue again.


>>Second, is what you've done, Ethan, easy enough so that a user might
>>be able to program their own special version of gnuplot and add a
>>custom variable to identify their version?  Or don't we want to
>>encourage that sort of thing?)
> 
> 
> My recommendation would be that any locally-modified version should
> change the contents of the PATCHLEVEL file.  Everything else will
> be handled automatically.

OK.

Dan

Re: demos

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

On Friday 04 August 2006 09:43 am, Daniel J Sebald wrote:
> First, could this
> "gnuplot-defined variables" be made a permanent thing?

I do not understand the question.

> I think I've  been asked if gnuplot somehow could return its version.

gnuplot --version
gnuplot -V

> Second, is what you've done, Ethan, easy enough so that a user might
> be able to program their own special version of gnuplot and add a
> custom variable to identify their version?  Or don't we want to
> encourage that sort of thing?)

My recommendation would be that any locally-modified version should
change the contents of the PATCHLEVEL file.  Everything else will
be handled automatically.  Perhaps this should be documented somewhere
(INSTALL? README?)


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: demos

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

Petr Mikulik wrote:
>>>Unfortunately, this is not portable. I've just tried a windows version
>>>compiled with all of the "default" #defines in makefile&config.mgw,
>>>including IMAGE; but its "show version long" reports only:
>>>
>>>Compile options:
>>>+READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE
>>>
>>>and thus it is not updated to options set from within config.h.
>>>Cannot the string for the "compiled options" be concanated according to
>>>#define's?
>>
>>I see no windows-specific code in show_version(), so I am at
>>a loss to explain how this could go wrong.
> 
> 
> I'm sorry, it was a false alarm. I was launching wgnuplot from July ... but 
> 2004 on this computer ... so all is fine, and I vote for the proposed new 
> GPVAL_.

So it did what it was supposed to do and you misinterpretted.  That's the developers trap: always doubting if thing are programmed correctly. :-)

It seemed to work for me, very useful, good idea Ethan.  And the sure-fired conditional script in all.dem is the way I'd go.  (Remember, part of scripts is to be tutorial and from the users standpoint that is helpful to see.)

I will keep thinking about future compatibility issues, but I think it should be fine...  Couple things.  First, could this "gnuplot-defined variables" be made a permanent thing?  I think I've been asked if gnuplot somehow could return its version.  (The trick I use now is to lauch gnuplot, get that startup info and sort through that looking for the version.  Or is there already a better way?)...  Second, is what you've done, Ethan, easy enough so that a user might be able to program their own special version of gnuplot and add a custom variable to identify their version?  Or don't we want to encourage that sort of thing?)

Dan

Re: demos

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

>> Unfortunately, this is not portable. I've just tried a windows version
>> compiled with all of the "default" #defines in makefile&config.mgw,
>> including IMAGE; but its "show version long" reports only:
>>
>> Compile options:
>> +READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE
>>
>> and thus it is not updated to options set from within config.h.
>> Cannot the string for the "compiled options" be concanated according to
>> #define's?
>
> I see no windows-specific code in show_version(), so I am at
> a loss to explain how this could go wrong.

I'm sorry, it was a false alarm. I was launching wgnuplot from July ... but 
2004 on this computer ... so all is fine, and I vote for the proposed new 
GPVAL_.

---
PM

Re: demos

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

On Friday 04 August 2006 12:21 am, Petr Mikulik wrote:
> 
> Unfortunately, this is not portable. I've just tried a windows version 
> compiled with all of the "default" #defines in makefile&config.mgw, 
> including IMAGE; but its "show version long" reports only:
> 
> Compile options:
> +READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE
> 
> and thus it is not updated to options set from within config.h.
> Cannot the string for the "compiled options" be concanated according to 
> #define's?

I see no windows-specific code in show_version(), so I am at
a loss to explain how this could go wrong.  

If a windows build does not correctly report its configuration,
that's a bug all by itself and should be fixed.  But yes, we would
need to to solve that problem first.

show.c: #include "alloc.h"
alloc.h: #include "syscfg.h"
syscfg.h: #include "config.h"

How can this fail?  (and how can the build succeed if it does?)

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: demos

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

>>>    if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"
>> No, that would mean not "way backward" compatible because "image.dem"
>> would still be run on older versions of gnuplot...
>
> Not a problem.  Here's a variant that checks for version compatibility:
>
> if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
>     load 'image.dem'
>
> Of course, this requires that string variables are configure in
> (now the default). But it you want it even more foolproof then use
>
> if (defined(GPVAL_COMPILE_OPTIONS)) \
> if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
>     load 'image.dem'

Unfortunately, this is not portable. I've just tried a windows version 
compiled with all of the "default" #defines in makefile&config.mgw, 
including IMAGE; but its "show version long" reports only:

Compile options:
+READLINE -LIBREADLINE +GD_PNG +GD_TTF -NOCWDRC +USE_MOUSE

and thus it is not updated to options set from within config.h.
Cannot the string for the "compiled options" be concanated according to 
#define's?

---
PM

Re: demos

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

On Thursday 03 August 2006 12:56 pm, Daniel J Sebald wrote:
> >    if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"
> No, that would mean not "way backward" compatible because "image.dem" 
> would still be run on older versions of gnuplot... 

Not a problem.  Here's a variant that checks for version compatibility:

 if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
     load 'image.dem'

Of course, this requires that string variables are configure in
(now the default). But it you want it even more foolproof then use

 if (defined(GPVAL_COMPILE_OPTIONS)) \
 if (GPVAL_VERSION == 4.1 && strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) \
     load 'image.dem'
 
That is safe even in the absence of string variables (although
it doesn't actually run the demo).

I've put such on SourceForge.  Please have a look.
It's pretty non-intrusive (all it does is add a new GPVAL_*** variable),
and it will allow us to protect all the configuration-dependent demos
in all.dem that are run by "make check".

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: demos

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

> So that means we'd want to condition on the "negative presence" of an option?  I.e.
> 
>    if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"
> 
> I think (?)

No, that would mean not "way backward" compatible because "image.dem" would still be run on older versions of gnuplot... which maybe isn't a concern.  Whatever; so long as the CVS version of the demos works with the same CVS version of gnuplot.

Dan

Re: demos

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

Ethan Merritt wrote:
> On Thursday 03 August 2006 12:10 pm, Daniel J Sebald  wrote:
> 
>>>Better yet would be to figure out a way to make all.dem itself
>>>recognize and skip unsupported demos, but to my recollection past
>>>discussions never came up with a reasonable way to do that.
>>
>>I think a function that allows executing a command without falling
>>back to the command line would be nice.  Say "attempt"
> 
> 
> Maybe, but it wouldn't actually help in the case of all.dem.
> Falling back to the command line would leave you in the middle of
> a sequence of now-useless commands.  What we need for the demo
> case is some way of skipping the demo altogether.

Well, that sort of is the limitation.  I mean,

 if attempt("plot 'foo.dat' with foos") load 'foo.dem' : print "no foo"

would be sort of like putting the first line of your demo inside "all.dem", which is a bit silly.  But if there were some way of calling a command that would verify the existence of the support, i.e., "set style"...  eh, still nothing elegant.

> 
> Hmm.  I've got an idea that wouldn't have been possible before.
> 
> Now that we have all these GPVAL_***  variables, maybe
> we should load one with the conditional compilation flags as
> reported by "show version long".
> 
> gnuplot> print GPVAL_COMPILE_OPTIONS
> -READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  
> +BINARY_DATA  +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION -NOCWDRC  
> +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE 
> +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE
> 
> 
> Then we could do
> 
>   if (strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) load "image.dem"
> 
> Anyone see anything wrong with this approach?

Sounds alright to me.  This would be a variable the user can't alter, right?  I like it.

Would you want to specifically require the + and - settings?  I'm thinking of "backward" and "forward" compatibility here.  In later versions of gnuplot, some of these options may no longer be present because they are no longer options... So that means we'd want to condition on the "negative presence" of an option?  I.e.

   if (!strstrt(GPVAL_COMPILE_OPTIONS,"-IMAGE")) load "image.dem"

I think (?)

Dan