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

CVS repo unaccessible

[Stefan H. <ste...@t-...>]

Hello,

is it just me? I cannot access the cvs repo of gnuplot.

cvs update: [18:37:12] waiting for anoncvs_gnuplot's lock in /cvsroot/gnuplot/gnuplot

Best Regards

Stefan Husmann

Missing colon in Changelog

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

Attached is a diff for missing colon that affects gvim highlighting.

Dan

Re: country borders on 2d-world

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

On 10/23/2015 06:13 AM, Juhász Péter wrote:
> On Thu, 2015-10-22 at 12:37 -0700, Ethan A Merritt wrote:
>> On Thursday, 22 October, 2015 20:47:37 Juhász Péter wrote:
>>> On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote:
>>>>
>>>> Although it isn't a type of plot I'd use in my field, it would be a
>>>> really nice feature given how common this type of geographical "plot"
>>>> with data points is today.  A command syntax is going to be the
>>>> difficult part.  Defining the maps is another issue.  What if boundaries
>>>> change?  Is there some type of universally accepted data format or
>>>> descriptive language for map boundaries these days?
>>>>
>>>> Dan
>>>>
>>>
>>> Two more issues that count against including high-resolution map data
>>> into gnuplot itself:
>>>
>>> - licensing
>>> - data size
>>
>> You may be responding to a message I haven't seen yet, but...
>> I don't think Dan's comment implied incorporating the map data itself
>> into gnuplot.  The idea, I think, is that if there are standard formats
>> for map data we might provide support for these to make it easier to
>> read from external files.  Analogous to the way we handle image formats:
>>     plot 'foo.png' binary filetype=png
>>
>> I don't know whether this would be useful or not.  The external files
>> might require so much pre-processing that the syntax of the final plot
>> command is not an issue.
>>
>> 	Ethan
>>
>
> Well, he didn't imply that, however, the OP wanted a simple way to
> produce geographical plots that include country borders. To do that
> reliably, you have to have a proven, known dataset. What you are saying
> (adding support for one or more of the de facto standard GIS formats) is
> only halfway there - and even that raises the question of which
> format(s) to support, and to what extent.
>
> IMHO that alone doesn't worth the effort, as it doesn't provide real
> benefits compared to the situation that we have now, that is, if you
> want to produce nice, detailed maps, you get the data from wherever you
> can, in any format you can, you convert it with some external tools to a
> format that gnuplot can use, then plot it yourself.
>
> We might turn to systems such as R for inspiration: there the creation
> of maps is supported in the form of add-on packages, e.g.
> https://cran.r-project.org/web/packages/maps/index.html
> https://cran.r-project.org/web/packages/mapdata/index.html
>
> However, gnuplot does not support add-on packages like that and I think
> that's a can of worms we don't want to open right now.

There is an R manual associated with the package:

https://cran.r-project.org/web/packages/maps/maps.pdf

but I'm not going to take the time to read it right now.  But this R 
package has gone all out as far as databases with intriguing names like 
"spacetime", etc.

As I see it, gnuplot should bring the benefit of easily overlaying data 
on a geospatial map in order to convey statistical, survey, or other 
types of data.  For example, someone may want to use the size of a dot 
(which gnuplot has) to illustrate the number of museums in major U.S. 
cities.  Or perhaps the user wants to show registered voters by state 
using color variation to illustrate party affiliation.  That sort of thing.

I could imagine a special plot mode "geospatial" akin to something like 
"polar" that changes the underlying coordinate system to, say, latitude 
and longitude or whatever.  Given a database, gnuplot might figure out 
the lat/long data or vector boundary data behind the scenes, making the 
task of plotting easy for the user.  So it might be:

(Data I'm making up...)

set geospatial bigdatabasefile.esri
plot '-' using 1:2 with filledcircles title "Museum Count"
"Los Angeles" 123
"New York" 217
"Philadelphia" 132
"Chicago" 194
"Washington D.C." 732
end

Dan

Re: country borders on 2d-world

[Juhász P. <pet...@gm...>]

On Thu, 2015-10-22 at 12:37 -0700, Ethan A Merritt wrote:
> On Thursday, 22 October, 2015 20:47:37 Juhász Péter wrote:
> > On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote:
> > > 
> > > Although it isn't a type of plot I'd use in my field, it would be a 
> > > really nice feature given how common this type of geographical "plot" 
> > > with data points is today.  A command syntax is going to be the 
> > > difficult part.  Defining the maps is another issue.  What if boundaries 
> > > change?  Is there some type of universally accepted data format or 
> > > descriptive language for map boundaries these days?
> > > 
> > > Dan
> > > 
> > 
> > Two more issues that count against including high-resolution map data
> > into gnuplot itself:
> > 
> > - licensing
> > - data size
> 
> You may be responding to a message I haven't seen yet, but...
> I don't think Dan's comment implied incorporating the map data itself
> into gnuplot.  The idea, I think, is that if there are standard formats
> for map data we might provide support for these to make it easier to
> read from external files.  Analogous to the way we handle image formats:
>    plot 'foo.png' binary filetype=png
> 
> I don't know whether this would be useful or not.  The external files
> might require so much pre-processing that the syntax of the final plot
> command is not an issue.
> 
> 	Ethan
> 

Well, he didn't imply that, however, the OP wanted a simple way to
produce geographical plots that include country borders. To do that
reliably, you have to have a proven, known dataset. What you are saying
(adding support for one or more of the de facto standard GIS formats) is
only halfway there - and even that raises the question of which
format(s) to support, and to what extent.

IMHO that alone doesn't worth the effort, as it doesn't provide real
benefits compared to the situation that we have now, that is, if you
want to produce nice, detailed maps, you get the data from wherever you
can, in any format you can, you convert it with some external tools to a
format that gnuplot can use, then plot it yourself.

We might turn to systems such as R for inspiration: there the creation
of maps is supported in the form of add-on packages, e.g.
https://cran.r-project.org/web/packages/maps/index.html
https://cran.r-project.org/web/packages/mapdata/index.html

However, gnuplot does not support add-on packages like that and I think
that's a can of worms we don't want to open right now.

Peter

Re: country borders on 2d-world

[Ethan A M. <sf...@us...>]

On Thursday, 22 October, 2015 20:47:37 Juhász Péter wrote:
> On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote:
> > 
> > Although it isn't a type of plot I'd use in my field, it would be a 
> > really nice feature given how common this type of geographical "plot" 
> > with data points is today.  A command syntax is going to be the 
> > difficult part.  Defining the maps is another issue.  What if boundaries 
> > change?  Is there some type of universally accepted data format or 
> > descriptive language for map boundaries these days?
> > 
> > Dan
> > 
> 
> Two more issues that count against including high-resolution map data
> into gnuplot itself:
> 
> - licensing
> - data size

You may be responding to a message I haven't seen yet, but...
I don't think Dan's comment implied incorporating the map data itself
into gnuplot.  The idea, I think, is that if there are standard formats
for map data we might provide support for these to make it easier to
read from external files.  Analogous to the way we handle image formats:
   plot 'foo.png' binary filetype=png

I don't know whether this would be useful or not.  The external files
might require so much pre-processing that the syntax of the final plot
command is not an issue.

	Ethan

 
> In more detail:
> 
> The first link in the OP refers to
> http://www.naturalearthdata.com/downloads/ , where you can eventually
> download datasets for continent, lake and country boundaries in three
> different resolutions. It says that the dataset is in the public domain,
> which means that it's fine if you want to produce maps with it on your
> own, and it may be fine for inclusion into gnuplot (but IANAL).
> The highest resolution dataset that includes country borders is >5 MB
> compressed, which is comparable to the current size of gnuplot's binary
> package.
> 
> There is also GSHHG, http://www.soest.hawaii.edu/pwessel/gshhg/ , which
> is used by software packages such as GMT or IDL, however, its license is
> LGPL, which is not compatible with gnuplot's license - or is it?
> The entire package is above 100 MB which precludes its inclusion (but it
> contains lower resolution datasets that are likely smaller).
> 
> 
> > "Is there some type of universally accepted data format or descriptive
> > language for map boundaries these days?"
> 
> Universally accepted? I don't think so. 
> However, there are many competing, widely recognized formats, ESRI
> Shapefile being perhaps the most used.
> 
> 
> Peter
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: country borders on 2d-world

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

On 10/22/2015 01:47 PM, Juhász Péter wrote:
> On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote:
>> On 10/21/2015 07:02 PM, Valerio Schiavoni wrote:
>>> Hello,
>>> it is known that drawing a 2D map of the world is possible:
>>> - http://www.gnuplotting.org/plotting-the-world-revisited/
>>> - http://gnuplot.sourceforge.net/demo/world.html
>>>
>>> But, suppose that I want to:
>>> - also show the country/nation/state borders and
>>> - some of the country/nation/states need to be highlighted somehow (a
>>> different filling color than plain white would be ideal)
>>>
>>> Ideally there would be several groups of country/nation/states sharing
>>> the same filling colours
>>>
>>> Has anyone ever attempted at this ?
>>> Suggestions ?
>>
>> I've thought of doing such a thing:
>>
>> http://sourceforge.net/p/gnuplot/mailman/message/26788631/
>>
>> Although it isn't a type of plot I'd use in my field, it would be a
>> really nice feature given how common this type of geographical "plot"
>> with data points is today.  A command syntax is going to be the
>> difficult part.  Defining the maps is another issue.  What if boundaries
>> change?  Is there some type of universally accepted data format or
>> descriptive language for map boundaries these days?
>>
>> Dan
>>
>
> Two more issues that count against including high-resolution map data
> into gnuplot itself:
>
> - licensing
> - data size
>
> In more detail:
>
> The first link in the OP refers to
> http://www.naturalearthdata.com/downloads/ , where you can eventually
> download datasets for continent, lake and country boundaries in three
> different resolutions. It says that the dataset is in the public domain,
> which means that it's fine if you want to produce maps with it on your
> own, and it may be fine for inclusion into gnuplot (but IANAL).
> The highest resolution dataset that includes country borders is>5 MB
> compressed, which is comparable to the current size of gnuplot's binary
> package.

Well, I would think including the data itself would be out of the 
question.  Having it accessible is the important thing.  But judging the 
contents of that website parts of it seem relevant.  The "cultural" maps 
(i.e., vector outlines of countries) seem most pertinent.  In the zip 
files I see DBF files as the largest component.  The ESRI you pointed 
out below uses DBF.


> There is also GSHHG, http://www.soest.hawaii.edu/pwessel/gshhg/ , which
> is used by software packages such as GMT or IDL, however, its license is
> LGPL, which is not compatible with gnuplot's license - or is it?
> The entire package is above 100 MB which precludes its inclusion (but it
> contains lower resolution datasets that are likely smaller).

Here it looks like the World Vector Shorelines data is most useful.


>> "Is there some type of universally accepted data format or descriptive
>> language for map boundaries these days?"
>
> Universally accepted? I don't think so.
> However, there are many competing, widely recognized formats, ESRI
> Shapefile being perhaps the most used.

I wasn't aware of ESRI; interesting stuff.  Thanks.

It would be a big project, and I still wonder about combining the map 
data with a 1) plot and 2) statistical data in a way that is easy to use.

Dan

Re: country borders on 2d-world

[Juhász P. <pet...@gm...>]

On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote:
> On 10/21/2015 07:02 PM, Valerio Schiavoni wrote:
> > Hello,
> > it is known that drawing a 2D map of the world is possible:
> > - http://www.gnuplotting.org/plotting-the-world-revisited/
> > - http://gnuplot.sourceforge.net/demo/world.html
> >
> > But, suppose that I want to:
> > - also show the country/nation/state borders and
> > - some of the country/nation/states need to be highlighted somehow (a
> > different filling color than plain white would be ideal)
> >
> > Ideally there would be several groups of country/nation/states sharing
> > the same filling colours
> >
> > Has anyone ever attempted at this ?
> > Suggestions ?
> 
> I've thought of doing such a thing:
> 
> http://sourceforge.net/p/gnuplot/mailman/message/26788631/
> 
> Although it isn't a type of plot I'd use in my field, it would be a 
> really nice feature given how common this type of geographical "plot" 
> with data points is today.  A command syntax is going to be the 
> difficult part.  Defining the maps is another issue.  What if boundaries 
> change?  Is there some type of universally accepted data format or 
> descriptive language for map boundaries these days?
> 
> Dan
> 

Two more issues that count against including high-resolution map data
into gnuplot itself:

- licensing
- data size

In more detail:

The first link in the OP refers to
http://www.naturalearthdata.com/downloads/ , where you can eventually
download datasets for continent, lake and country boundaries in three
different resolutions. It says that the dataset is in the public domain,
which means that it's fine if you want to produce maps with it on your
own, and it may be fine for inclusion into gnuplot (but IANAL).
The highest resolution dataset that includes country borders is >5 MB
compressed, which is comparable to the current size of gnuplot's binary
package.

There is also GSHHG, http://www.soest.hawaii.edu/pwessel/gshhg/ , which
is used by software packages such as GMT or IDL, however, its license is
LGPL, which is not compatible with gnuplot's license - or is it?
The entire package is above 100 MB which precludes its inclusion (but it
contains lower resolution datasets that are likely smaller).


> "Is there some type of universally accepted data format or descriptive
> language for map boundaries these days?"

Universally accepted? I don't think so. 
However, there are many competing, widely recognized formats, ESRI
Shapefile being perhaps the most used.


Peter

Re: country borders on 2d-world

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

On 10/21/2015 07:02 PM, Valerio Schiavoni wrote:
> Hello,
> it is known that drawing a 2D map of the world is possible:
> - http://www.gnuplotting.org/plotting-the-world-revisited/
> - http://gnuplot.sourceforge.net/demo/world.html
>
> But, suppose that I want to:
> - also show the country/nation/state borders and
> - some of the country/nation/states need to be highlighted somehow (a
> different filling color than plain white would be ideal)
>
> Ideally there would be several groups of country/nation/states sharing
> the same filling colours
>
> Has anyone ever attempted at this ?
> Suggestions ?

I've thought of doing such a thing:

http://sourceforge.net/p/gnuplot/mailman/message/26788631/

Although it isn't a type of plot I'd use in my field, it would be a 
really nice feature given how common this type of geographical "plot" 
with data points is today.  A command syntax is going to be the 
difficult part.  Defining the maps is another issue.  What if boundaries 
change?  Is there some type of universally accepted data format or 
descriptive language for map boundaries these days?

Dan


> Thanks,
> --
> Valerio

country borders on 2d-world

[Valerio S. <val...@gm...>]

Hello,
it is known that drawing a 2D map of the world is possible:
- http://www.gnuplotting.org/plotting-the-world-revisited/
- http://gnuplot.sourceforge.net/demo/world.html

But, suppose that I want to:
- also show the country/nation/state borders and
- some of the country/nation/states need to be highlighted somehow (a
different filling color than plain white would be ideal)

Ideally there would be several groups of country/nation/states sharing the
same filling colours

Has anyone ever attempted at this ?
Suggestions ?

Thanks,
--
Valerio

Re: compiling on ubuntu 15.10

[Ethan A M. <sf...@us...>]

On Wednesday, 21 October, 2015 01:25:40 Karl-Friedrich Ratzsch wrote:
> I just updated my OS, and found the following problems with
> compiling gnuplot:
> 
> 5.0cvs:
> ./configure gives a warning
> 
> 	missing: Unknown `--is-lightweight` option
> 
> 	configure: WARNING: 'missing' script is too old or missing
> 
> seems some of the changes applied to HEAD on 2014-12-16 need to go
> in STABLE, too. Building runs fine afterwards.

But those are non-fatal warnings, right?
You can ignore them.
It probably also complains noisily about configure.in not being
named configure.ac.

> 5.1cvs:
> Building is tripped up by the new "jitter" feature, there are
> undefined references to `jitter`, `jitter_points`, `save_jitter`
> etc. I can provide the full log if necessary.

That sounds like you have not fully updated your cvs copy.
Try:
    cvs update -P 
 
> And, with 5.0 and also HEAD, building --with-qt=qt5 fails with a
> complaint "must build your code with position independent code if Qt
> was built with -reduce-relocations" " Compile your code with -fPIC
> (-fPIE is not enough)"

Again it sounds like your cvs copy is not up to date.
That change went into cvs for both 5.0 and 5.1 several
months ago.

	Ethan

 
> Here
> 
> https://launchpad.net/ubuntu/+source/gnuplot5/5.0.1+dfsg1-3
> 
> is ubuntus (i.e. debians) own fix for that.
> 
> 
> Best,
>   Karl
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

compiling on ubuntu 15.10

[Karl-Friedrich R. <ra...@un...>]

I just updated my OS, and found the following problems with
compiling gnuplot:

5.0cvs:
./configure gives a warning

	missing: Unknown `--is-lightweight` option

	configure: WARNING: 'missing' script is too old or missing

seems some of the changes applied to HEAD on 2014-12-16 need to go
in STABLE, too. Building runs fine afterwards.



5.1cvs:
Building is tripped up by the new "jitter" feature, there are
undefined references to `jitter`, `jitter_points`, `save_jitter`
etc. I can provide the full log if necessary.



And, with 5.0 and also HEAD, building --with-qt=qt5 fails with a
complaint "must build your code with position independent code if Qt
was built with -reduce-relocations" " Compile your code with -fPIC
(-fPIE is not enough)"

Here

https://launchpad.net/ubuntu/+source/gnuplot5/5.0.1+dfsg1-3

is ubuntus (i.e. debians) own fix for that.


Best,
  Karl

Re: problem with fill style and term postscript

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

On Wednesday, 14 October, 2015 00:20:00 Valerio Schiavoni wrote:
> Hello,
> i have a problem with the terminal postscript under Gnuplot 5.0. It now
> seems to ignore the filling colours.

You selected   "set term post eps monochrome"
so all the colors became black.

If you instead say "set term post eps color" the result
may be closer to what you intended.

The fact that postscript/eps defaults to monochrome is an
unfortunate historical artifact.  Version 5 left it that way
for backwards compatibility, but at least for me it is _always_
correct to say "set term post color" - even if I want grayscale as 
it seems you want for your plot.

	Ethan


> 
> This is the gnuplot script:
> 
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-gp
> 
> The input file is this:
> 
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-tput_norm-txt
> 
> Currently, the scalability.eps I get as output is this:
> 
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps
> 
> 
> Some very savvy user on the #gnuplot IIRC channel pointed out that some
> issue might be in the /Lca, LCb definitions (see
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps-L89
> and around)
> 
> 
> My installation:
> G N U P L O T
> Version 5.0 patchlevel 1    last modified 2015-06-07
> 
> 
> Can anyone shed some light on this ?
> Thanks,
> 
> --
> Valerio
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: problem with fill style and term postscript

[Valerio S. <val...@gm...>]

Dear Ethan,
you were right on spot !
Thanks !

--
Valerio


On Wed, Oct 14, 2015 at 1:03 AM, Ethan A Merritt <merritt@u.washington.edu>
wrote:

> On Wednesday, 14 October, 2015 00:20:00 Valerio Schiavoni wrote:
>
> > Hello,
>
> > i have a problem with the terminal postscript under Gnuplot 5.0. It now
>
> > seems to ignore the filling colours.
>
>
>
> You selected "set term post eps monochrome"
>
> so all the colors became black.
>
>
>
> If you instead say "set term post eps color" the result
>
> may be closer to what you intended.
>
>
>
> The fact that postscript/eps defaults to monochrome is an
>
> unfortunate historical artifact. Version 5 left it that way
>
> for backwards compatibility, but at least for me it is _always_
>
> correct to say "set term post color" - even if I want grayscale as
>
> it seems you want for your plot.
>
>
>
> Ethan
>
>
>
>
>
> >
>
> > This is the gnuplot script:
>
> >
>
> >
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-gp
>
> >
>
> > The input file is this:
>
> >
>
> >
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-tput_norm-txt
>
> >
>
> > Currently, the scalability.eps I get as output is this:
>
> >
>
> >
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps
>
> >
>
> >
>
> > Some very savvy user on the #gnuplot IIRC channel pointed out that some
>
> > issue might be in the /Lca, LCb definitions (see
>
> >
> https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps-L89
>
> > and around)
>
> >
>
> >
>
> > My installation:
>
> > G N U P L O T
>
> > Version 5.0 patchlevel 1 last modified 2015-06-07
>
> >
>
> >
>
> > Can anyone shed some light on this ?
>
> > Thanks,
>
> >
>
> > --
>
> > Valerio
>
> --
>
> Ethan A Merritt
>
> Biomolecular Structure Center, K-428 Health Sciences Bldg
>
> MS 357742, University of Washington, Seattle 98195-7742
>
>
>

problem with fill style and term postscript

[Valerio S. <val...@gm...>]

Hello,
i have a problem with the terminal postscript under Gnuplot 5.0. It now
seems to ignore the filling colours.

This is the gnuplot script:

https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-gp

The input file is this:

https://gist.github.com/vschiavoni/97918d379377a69cf911#file-tput_norm-txt

Currently, the scalability.eps I get as output is this:

https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps


Some very savvy user on the #gnuplot IIRC channel pointed out that some
issue might be in the /Lca, LCb definitions (see
https://gist.github.com/vschiavoni/97918d379377a69cf911#file-scalability-eps-L89
and around)


My installation:
G N U P L O T
Version 5.0 patchlevel 1    last modified 2015-06-07


Can anyone shed some light on this ?
Thanks,

--
Valerio

ChangeLog colon typo

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

There's a semicolon where a colon should be (see attached) which affects 
gvim highlighting.

Dan

Re: Is this a bug in "smooth cnorm" ?

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

On 10/07/2015 11:42 PM, sfeam wrote:
> In the file interpol.c is this chunk of code starting at line 1264:
>
> %%%%
>
> if (k) {
>
> cp->points[j].x = x;
>
> if ( cp->plot_smooth == SMOOTH_FREQUENCY ||
>
> cp->plot_smooth == SMOOTH_CUMULATIVE ||
>
> cp->plot_smooth == SMOOTH_CUMULATIVE)
>
> k = 1;
>
> cp->points[j].y = y /= (double) k;
>
> %%%%
>
> This is clearly not correct, but I cannot figure out if the
>
> error is a duplicate test for SMOOTH_CUMULATIVE or a missing
>
> test for SMOOTH_CUMULATIVE_NORMALISED.
>
> The code was added in Apr 2010 as part of the new smooth option
>
> "smooth cnormal". Because this was clearly intended as part
>
> of the new option, my first thought is that it's a typo and
>
> the 3rd test should be for SMOOTH_CUMULATIVE_NORMALISED.
>
> But I cannot find any test case where the current code produces
>
> an error, so maybe the test is not really needed at all?
>
> Can someone figure out what the intent was, and whether there
>
> has always been a bug in "smooth cnormal"?

My guess would be that it should be SMOOTH_CUMULATIVE_NORMALISED.  In 
plot2d.c

		/* create new data set by evaluation of
		 * interpolation routines */
[snip]
		case SMOOTH_FREQUENCY:
		case SMOOTH_CUMULATIVE:
		case SMOOTH_CUMULATIVE_NORMALISED:
		    gen_interp_frequency(this_plot);
		    break;

so it seems these three go together.

Even if there is a "cnormal" smoothing example in the demos, it might 
not fail because there is a possibility that k is already 1 for some 
reason or another.  Look at the conditional statement in interpol.c and 
k starts out as 0.  In the first pass if !k then k is set to 1 along 
with some other code.  So at that point k is 1 and if there is another 
pass and the middle condition is not met then k is already 1 for the 
SMOOTH_CUMULATIVE_NORMALISED test.  So, the bug doesn't manifest in that 
scenario.

What needs to happen is that middle condition occurs so that k++ 
increments past 1 and then "case SMOOTH_CUMULATIVE_NORMALISED:" occurs 
on the next pass.  That might be an unlikely scenario, don't know.

Dan

Is this a bug in "smooth cnorm" ?

[sfeam <sf...@us...>]

In the file interpol.c is this chunk of code starting at line 1264:
%%%%
        if (k) {
            cp->points[j].x = x;
            if ( cp->plot_smooth == SMOOTH_FREQUENCY ||
                 cp->plot_smooth == SMOOTH_CUMULATIVE ||
                 cp->plot_smooth == SMOOTH_CUMULATIVE)
                k = 1;
            cp->points[j].y = y /= (double) k;
%%%%

This is clearly not correct, but I cannot figure out if the
error is a duplicate test for SMOOTH_CUMULATIVE or a missing
test for SMOOTH_CUMULATIVE_NORMALISED.

The code was added in Apr 2010 as part of the new smooth option
"smooth cnormal".  Because this was clearly intended as part
of the new option, my first thought is that it's a typo and
the 3rd test should be for SMOOTH_CUMULATIVE_NORMALISED.

But I cannot find any test case where the current code produces
an error, so maybe the test is not really needed at all?

Can someone figure out what the intent was, and whether there
has always been a bug in "smooth cnormal"?

	Ethan

Re: reread doesn't

[<pl...@pi...>]

Le 29.09.2015 18:14, sfeam a écrit :
> On Tuesday, 29 September 2015 12:04:04 PM pl...@pi... wrote:
> 
>> Hi
> 
>> 
> 
>> I am producing a graph ( SVG ) by using load command.
> 
>> 
> 
>> To refresh it periodically, I have a pause and a reread at the end.
> 
> You can only have one plot in an svg output file, "refresh it" is
> 
> not an option. You would have to close it, reopen another file
> 
> with the same name, and write a new plot into it.
> 
> Is that what your script does?
> 
> "reread" only resets the input file, not the output file.
> 
> It is possible you misunderstand where the "reload" command
> 
> needs to go. Is there an "unset output" before it?
> 
>> The problem is the reread does NOT reread the file. I seems to have
> an
> 
>> internal buffer and just pretends to reread.
> 
> Not sure who you mean by "I".


sorry, typo, I meant "it" ie gnuplot as you surmised.


> 
> If you mean gnuplot, then no.
> 
> But if you mean the operating system, then probably yes.
> 
> Gnuplot's "reread" command tells the system to go back to the
> 
> beginning of the file. That is a "rewind" operation, not a
> 
> "close and re-open for reading" operation.
> 
>> I can not find anything that would force an actual reread of the
> file.
> 
>> 
> 
>> It would be extremely useful if it did really reread the file on
> disk
> 
>> since this would allow another process to modify it.
> 
> No, sorry. File systems don't work that way. If somebody else
> 
> writes on top of a file you already have open for reading, that
> 
> is probably not going to do what you seem to expect.
> 
>  > I seem to recall that there was some complication with this same
> 
>> functionality needing to support pipes or direct input.
> 
>> 
> 
>> Is there not a way to force a actual reload of the file? Maybe a '
> 
>> reread really ' option.
> 
>  Ethan


Thanks, reread is basically doing a seek(0), not a close and open which 
I what I was looking for, which is why I was looking for "reread really" 
type solution. Reread does what it says, in fact.

  What I was needing was a 'reload'.  That would indeed require closing 
the output file before using it.


Yes, I do close the svg by unset output;

regard, Peter.

Re: reread doesn't

[Karl-Friedrich R. <ra...@un...>]

Am 29.09.2015 um 12:04 schrieb pl...@pi...:
> I am producing a graph ( SVG ) by using load command.
>
> To refresh it periodically, I have a pause and a reread at the end.
>
> The problem is the reread does NOT reread the file. I seems to have an 
> internal buffer and just pretends to reread.
>
> I can not find anything that would force an actual reread of the file.
>
>
> It would be extremely useful if it did really reread the file on disk 
> since this would allow another process to modify it.
>
> I seem to recall that there was some complication with this same 
> functionality needing to support pipes or direct input.
>
> Is there not a way to force a actual reload of the file? Maybe a ' 
> reread really ' option.

How about

     gnuplot -e  "while (1) {call 'plot.gp'; pause 10}"

?

Re: reread doesn't

[sfeam <sf...@us...>]

On Tuesday, 29 September 2015 12:04:04 PM pl...@pi... wrote:
> Hi
> 
> I am producing a graph ( SVG ) by using load command.
> 
> To refresh it periodically, I have a pause and a reread at the end.

You can only have one plot in an svg output file, "refresh it" is
not an option.  You would have to close it, reopen another file
with the same name, and write a new plot into it.
Is that what your script does?

"reread" only resets the input file, not the output file.
It is possible you misunderstand where the "reload" command
needs to go.  Is there an "unset output" before it?


> The problem is the reread does NOT reread the file. I seems to have an 
> internal buffer and just pretends to reread.

Not sure who you mean by "I".
If you mean gnuplot, then no.
But if you mean the operating system, then probably yes.
Gnuplot's "reread" command tells the system to go back to the
beginning of the file.  That is a "rewind" operation, not a
"close and re-open for reading" operation.

> I can not find anything that would force an actual reread of the file.
> 
> It would be extremely useful if it did really reread the file on disk 
> since this would allow another process to modify it.

No, sorry.  File systems don't work that way.  If somebody else
writes on top of a file you already have open for reading, that 
is probably not going to do what you seem to expect.

 > I seem to recall that there was some complication with this same 
> functionality needing to support pipes or direct input.
> 
> Is there not a way to force a actual reload of the file? Maybe a ' 
> reread really ' option.


	Ethan

Re: ./configure dependencies

[<pl...@pi...>]

Le 29.09.2015 09:51, Mojca Miklavec a écrit :
>> Also C++ compiler is installed and stdc++ and its source are present:
>> Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
>> Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed,
>> skipping.
>> 
>> # which cpp
>> /bin/cpp
> 
> cpp is not a C++ compiler. The C++ compiler is either "g++" or "cc" or
> something along those lines.
> 
> But do send the logs as Ethan suggested.
> 
> Mojca


duh, of course, it's the pre-processor. Thanks.

however, symlinking /bin/cc does not fix it

I'll send a full log to Ethan off list

Peter

reread doesn't

[<pl...@pi...>]

Hi

I am producing a graph ( SVG ) by using load command.

To refresh it periodically, I have a pause and a reread at the end.

The problem is the reread does NOT reread the file. I seems to have an 
internal buffer and just pretends to reread.

I can not find anything that would force an actual reread of the file.


It would be extremely useful if it did really reread the file on disk 
since this would allow another process to modify it.

I seem to recall that there was some complication with this same 
functionality needing to support pipes or direct input.

Is there not a way to force a actual reload of the file? Maybe a ' 
reread really ' option.

regards, Peter.

Re: ./configure dependencies

[sfeam <sf...@us...>]

On Tuesday, 29 September 2015 01:32:40 AM pl...@pi... wrote:
> Hi,
> 
> I'm trying to configure a CVS build on 64bit Fed22 but I'm finding some 
> inconsistencies:
> 
> wxt terminal: no (requires C++, wxWidgets>2.6, cairo>0.9, pango>1.10)
>    Qt terminal: no (use --with-qt or --with-qt=qt4 to enable
> 
> in order find out exactly what is missing I look further up and see:
> 
> 
> checking whether c++ accepts -g... no
> checking dependency style of c++... none
> configure: WARNING: No C++ compiler found. The wxWidgets terminal will 
> not be compiled.

I'd need to see the contents of config.log to figure out what went
wrong there. 

> checking for wx-config... /bin/wx-config
> checking for CAIROPANGO... yes
> checking for PANGO_1_10_2... no
> checking for CAIROPDF... yes
> checking for CAIROEPS... yes
> configure: WARNING: No C++ compiler found. The Qt terminal will not be 
> compiled.
> checking for QT... yes
> 
> 
> Pango detections seems broken since :
> 
> dnf install pango
> Package pango-1.36.8-6.fc22.x86_64 is already installed, skipping.

The build dependencies are for the *-devel package, not the library
itself.  Do you have pango-devel ?


> 
> 
> 
> 
> 
> 
> Also C++ compiler is installed and stdc++ and its source are present:
> Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
> Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed, 
> skipping.
> 
> # which cpp
> /bin/cpp
> [root@localhost gnuplot]# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
> Target: x86_64-redhat-linux
> Configured with: ../configure --enable-bootstrap 
> --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr 
> --mandir=/usr/share/man --infodir=/usr/share/info 
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
> --enable-threads=posix --enable-checking=release --enable-multilib 
> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
> --enable-gnu-unique-object --enable-linker-build-id 
> --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array 
> --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl 
> --enable-libmpx --enable-gnu-indirect-function --with-tune=generic 
> --with-arch_32=i686 --build=x86_64-redhat-linux
> Thread model: posix
> gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
> 
> 
> Why is it not detecting c++ and getting the wrong idea about pango 
> versions?
> 
> TIA, Peter.
> 
> 

./configure dependencies

[<pl...@pi...>]

Hi,

I'm trying to configure a CVS build on 64bit Fed22 but I'm finding some 
inconsistencies:

wxt terminal: no (requires C++, wxWidgets>2.6, cairo>0.9, pango>1.10)
   Qt terminal: no (use --with-qt or --with-qt=qt4 to enable

in order find out exactly what is missing I look further up and see:


checking whether c++ accepts -g... no
checking dependency style of c++... none
configure: WARNING: No C++ compiler found. The wxWidgets terminal will 
not be compiled.
checking for wx-config... /bin/wx-config
checking for CAIROPANGO... yes
checking for PANGO_1_10_2... no
checking for CAIROPDF... yes
checking for CAIROEPS... yes
configure: WARNING: No C++ compiler found. The Qt terminal will not be 
compiled.
checking for QT... yes


Pango detections seems broken since :

dnf install pango
Package pango-1.36.8-6.fc22.x86_64 is already installed, skipping.







Also C++ compiler is installed and stdc++ and its source are present:
Package libstdc++-5.1.1-4.fc22.x86_64 is already installed, skipping.
Package libstdc++-devel-5.1.1-4.fc22.x86_64 is already installed, 
skipping.

# which cpp
/bin/cpp
[root@localhost gnuplot]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array 
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl 
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic 
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)


Why is it not detecting c++ and getting the wrong idea about pango 
versions?

TIA, Peter.

Re: fit does not accept same range parameters as plot for time data

[sfeam <sf...@us...>]

On Sunday, 27 September 2015 08:50:54 AM pl...@pi... wrote:
> Hi
> 
> I have subset of a datafile that I can plot with plot command by 
> defining a range.
> The same range parameter is refused by fit:
> 
>      f(x)=a*exp(-(x-t0)/b)+c
>      format="%Y%m%d %H %M"
>      set timefmt format
>      set xdata time
>      plot ["20150925 02 33": "20150925 07 14"] "valana.txt"  u 1:4 w l
> 
>      a=b=c=t0=1;   fit f(x)  ["20150925 02 33": "20150925 07 14"] 
> "data.txt"  u 1:4 via a,b,c
> 
> 
> data looks like this:
> 
> 20150923 15 20 22.3 16.1
> 20150923 15 40 22.3 16.1
> 20150923 15 49 22.9 16.4
> 
> The fit command shows the following error:
> 
>    internal error: substring range specifiers must have integer values
> 
> 
> I thought the intention was that the two commands functioned in a 
> similar way. Why can't fit accept the range specifier in the same format 
> as plot?

This doesn't answer your question of why that particular command fails,
but ...

As always, I recommend never placing a range specifier inside the
plot (or fit) command.

Instead use:

   set xrange ["20150925 02 33": "20150925 07 14"]
   plot  "valana.txt"  u 1:4 w l
   a=b=c=t0=1;   
   fit f(x) "data.txt"  u 1:4 via a,b,c

Does that work better?

	Ethan