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

Re: Odd behavior of "set border" and "splot"

[Ethan A M. <me...@uw...>]

On Monday, 20 January 2020 18:18:57 PST Dima Kogan wrote:
> Thanks for the explanation. That sounds very suprising to the user. Can
> we at the least document this behavior in "help border"? Ideally it'd be
> controllable in "set border" somewhere too. Is this something that
> wasn't done on purpose, or has nobody gotten around to it?

These lines are drawn unconditionally in the routine draw_3d_graphbox()
graph3d.c:2450ff

I have no objection to adding a corresonding flag bit (for all of them) in the
"set border" command or even four flag bits (matching the four vertical edges 
of the full graph box).
But the flag bit[s] would have to default to "on" for backwards compatibility. 

On the other hand, looking up the bits one by one is inconvenient.
It might be more user-friendly to add a keyword
    set border <bitmask> {{no} somethingdescriptive}

I can't think what to call these lines, however, so I have no good suggestion
for what that "somethingdescriptive" keyword might be.
"surface anchors"?   "drop lines"?   "partial edges"?
Ideas?

> 
> dima

-- 
Ethan A Merritt

Re: Odd behavior of "set border" and "splot"

[Dima K. <gn...@di...>]

Thanks for the explanation. That sounds very suprising to the user. Can
we at the least document this behavior in "help border"? Ideally it'd be
controllable in "set border" somewhere too. Is this something that
wasn't done on purpose, or has nobody gotten around to it?

dima

Re: Odd behavior of "set border" and "splot"

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

Am 17.01.2020 um 21:58 schrieb Dima Kogan:
> Hi. I found something odd. Not entirely sure it's a bug.
> 
> I'm running the latest gnuplot from git (as of today), but this behavior
> isn't new.

Far from it, actually.  This behaviour has been in gnuplot essentially
forever.

These short verticals are not the ones controlled by "set border".  The
easiest way to visualize this is actually not to try and _disable_ them,
but to turn them all _on_, and compare what you get:

	set xrange [-10:10] ; set yrange [-10:10]
	set zrange [-100:150]
	set multiplot layout 2,1
	set border 15 ; splot x*y
	set border 255 ; splot x*y
	unset multiplot

Note how the activated border verticals reach up all the way up to
z=150, whereas the default ones get only as far up as the surface
itself.  Which, coincidentally, is exactly how those are controlled: if
the corners of a plotted surface mesh lie point exactly in the corners
of the x-y range rectangle, splot draws verticals from the corners of
the xyplane up to those points.

To turn off these shorter verticals while keeping any borders on, you
have to bend them out of the vertical, i.e. make the x-y-plane corners
differ from the corner positions of the dataset.  For data splots, you
can grow out the axis ranges a bit; function splots may have to be
switched into parameteric mode (or pseudo data plots) to allow the same
change, e.g.:

	set parametric
	set urange [-9:9]; set vrange [-9:9]
	set border 15 ; splot u,v,u*v

Odd behavior of "set border" and "splot"

[Dima K. <gn...@di...>]

Hi. I found something odd. Not entirely sure it's a bug.

I'm running the latest gnuplot from git (as of today), but this behavior
isn't new.

I can do this:

  splot x

I then get a plane, with the 4 borders of the xy plane drawn, and the
full-length left vertical axis, and for the other vertical axes, I get
lines from the xyplane up to where the data is.

I can do this:

  set border 0
  splot x

I then get just my plane, with none of the borders drawn at all. Works
with "unset border" too.

But let's say I just want the xy plane, with none of the vertical lines.
"help border" tells me I need to do this:

  set border 15
  splot x

This does NOT work to get rid of all the vertical lines. It removed the
full-length left vertical axis, but the lines from the xyplane up to the
data are still there. Why are those lines there? They aren't described
in "help border", even though "set border 0" does get rid of them. Is
there some other knob that lets you control that? If not, there should
probably be? Is it possible today to draw just the 4 xyplane borders?

Thanks!

RE: Checksums for gnuplot

[Ali G. <ag...@gm...>]

Thanks!


-----Original Message-----
From: Ethan A Merritt <me...@uw...> 
Sent: Monday, January 13, 2020 7:02 PM
To: gnu...@li...
Cc: Ali Golkar <ag...@gm...>
Subject: Re: Checksums for gnuplot

On Monday, 13 January 2020 07:08:36 PST Ali Golkar wrote:
> Hello,
> 
> We have a researcher that is requesting to use gnuplot. As part of our 
> approval process we require a hash from the vendor/developer. Could 
> you provide the hash on the latest release of gnuplot? Md5,sha1,sha512 
> or really anything would work.

[~/gnuplot/tarballs] md5sum gnuplot-5.2.8.tar.gz 2df8767c7399bee57a96296d46b4d5fb  gnuplot-5.2.8.tar.gz [~/gnuplot/tarballs] sha512sum gnuplot-5.2.8.tar.gz 513dff15236dcb58c3c5471cdaa0713242787dbf30ef860c3f69152cb87c6392e4973caff5eb178707bbb84c78548e806b2920864a37686bce49425fbfdc4e8c
gnuplot-5.2.8.tar.gz

	Ethan


> 
> Thanks,
> Ali Golkar
> IT Security Analyst | ITSO
> Information Technology Services
> George Mason University
> 703-993-4970
> ag...@gm...<mailto:ag...@gm...>
> https://its.gmu.edu/


--
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Checksums for gnuplot

[Ethan A M. <me...@uw...>]

On Monday, 13 January 2020 07:08:36 PST Ali Golkar wrote:
> Hello,
> 
> We have a researcher that is requesting to use gnuplot. As part of our
> approval process we require a hash from the vendor/developer. Could you
> provide the hash on the latest release of gnuplot? Md5,sha1,sha512 or
> really anything would work.

[~/gnuplot/tarballs] md5sum gnuplot-5.2.8.tar.gz
2df8767c7399bee57a96296d46b4d5fb  gnuplot-5.2.8.tar.gz
[~/gnuplot/tarballs] sha512sum gnuplot-5.2.8.tar.gz
513dff15236dcb58c3c5471cdaa0713242787dbf30ef860c3f69152cb87c6392e4973caff5eb178707bbb84c78548e806b2920864a37686bce49425fbfdc4e8c  
gnuplot-5.2.8.tar.gz

	Ethan


> 
> Thanks,
> Ali Golkar
> IT Security Analyst | ITSO
> Information Technology Services
> George Mason University
> 703-993-4970
> ag...@gm...<mailto:ag...@gm...>
> https://its.gmu.edu/


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Checksums for gnuplot

[Ali G. <ag...@gm...>]

Hello,

We have a researcher that is requesting to use gnuplot. As part of our approval process we require a hash from the vendor/developer. Could you provide the hash on the latest release of gnuplot? Md5,sha1,sha512 or really anything would work.

Thanks,
Ali Golkar
IT Security Analyst | ITSO
Information Technology Services
George Mason University
703-993-4970
ag...@gm...<mailto:ag...@gm...>
https://its.gmu.edu/

Version bumps: 5.2 -> 5.4 5.3 -> 5.5

[Ethan A M. <me...@uw...>]

	gnuplot stable version
	_____________________

Version 5.2.8 went out earlier this month.

Initial release of 5.4 is projected for Spring 2020.
I have created branch-5-4-stable for staging of release candidates.

	gnuplot development
	____________________

Development continues in the main branch ("master") in the git repository.
The identifying version for the development branch has been bumped
from 5.3 to 5.5 so that it stays ahead of the stable branch.

	Ethan

Re: Release 5.2.8

[Erik L. <eri...@gm...>]

Dear Ethan et al.,

Thank you. The OSX (Mac) package for 5.2.8 is available in the usual place (
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
).
Side note: please update http://gnuplot.info/download.html (where it
mentions 5.2.7 and "May 2019", twice)

Regards,

Erik


On Sun, Dec 1, 2019 at 10:44 PM Ethan Merritt (UW) <me...@uw...> wrote:

> The gnuplot release 5.2.8 source tarball is ready and can be downloaded
> from
>
>
> https://sf.net/projects/gnuplot/files/gnuplot/5.2.8/gnuplot-5.2.8.tar.gz
>
> There is not much in this update other than minor bug fixes,
> mostly addressing individual terminal quirks.
>
> This is the final planned release for gnuplot version 5.2.
>
> I will create a new 5-4-stable branch of the git repository and
> re-label the development trunk as 5.5.
>
> Expect a 5.4.rc1 early next year, to be followed by however many
> -rcX iterations are necessary to get a solid 5.4 for Spring 2020.
>
>
> Changes in 5.2.8
> ================
> * CHANGE user-visible GPVAL_TERM_HCHAR GPVAL_TERM_VCHAR (help debug font
> issues)
> * CHANGE placement of ylabel (compromise 5.2.7 and earlier versions) (Bug
> #2181)
> * CHANGE make strstrt() aware of UTF8, e.g. strstrt("αβγ5", "5") returns 4
> * FIX "set timestamp" from "save" must not include a justification (Bug
> #2178)
> * FIX set cntrparam levels increment <base>, <factor> for logscale z (Bug
> #2183)
> * FIX character pointtypes should inherit plot coloring like normal
> pointtypes
> * FIX bad autoscaling of linked y2 axis (Bug #2186)
> * FIX prevent infinite loop from unbounded interation in a non-data plot
> command
> * FIX dimensions reported by "stats matrix every" (Bug #2189)
> * FIX extent of boxplot whiskers could be off by one point (Bug #2106)
> * FIX mix unbounded iteration and functions in a single plot command (Bug
> #2201)
> * FIX reverse history search with readline=builtin (Bug #2209)
> * FIX qt: suppress off-by-one ysize (Bug #1759)
> * FIX cairo: suppress off-by-one ysize (Bug #1759)
> * FIX gd: apply alpha to brushstroke lines (Bug #2117)
> * FIX tikz: fixes to accommodate lua 5.3 and newer pgf
> * FIX wxt: ExportToFile widget disabled in persist mode (Bug #2185)
> * FIX qt: handling of modifier keys (ctrl alt shift) for keyboard events
> * FIX wxt: handling of modifier keys (ctrl alt shift) for keyboard events
> * FIX fig: dashtype "solid" was not passed through correctly to transfig
> * FIX gd: incorrect line spacing of multiline label (Bug #2215)
>
> Note:
>   Windows binaries will be delayed; please be patient.
>
>         cheers, and happy plotting
>
>                 Ethan
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Release 5.2.8

[Ethan M. (UW) <me...@uw...>]

The gnuplot release 5.2.8 source tarball is ready and can be downloaded from

    https://sf.net/projects/gnuplot/files/gnuplot/5.2.8/gnuplot-5.2.8.tar.gz

There is not much in this update other than minor bug fixes,
mostly addressing individual terminal quirks.

This is the final planned release for gnuplot version 5.2.

I will create a new 5-4-stable branch of the git repository and
re-label the development trunk as 5.5.

Expect a 5.4.rc1 early next year, to be followed by however many
-rcX iterations are necessary to get a solid 5.4 for Spring 2020.


Changes in 5.2.8
================
* CHANGE user-visible GPVAL_TERM_HCHAR GPVAL_TERM_VCHAR (help debug font issues)
* CHANGE placement of ylabel (compromise 5.2.7 and earlier versions) (Bug #2181)
* CHANGE make strstrt() aware of UTF8, e.g. strstrt("αβγ5", "5") returns 4
* FIX "set timestamp" from "save" must not include a justification (Bug #2178)
* FIX set cntrparam levels increment <base>, <factor> for logscale z (Bug #2183)
* FIX character pointtypes should inherit plot coloring like normal pointtypes
* FIX bad autoscaling of linked y2 axis (Bug #2186)
* FIX prevent infinite loop from unbounded interation in a non-data plot command
* FIX dimensions reported by "stats matrix every" (Bug #2189)
* FIX extent of boxplot whiskers could be off by one point (Bug #2106)
* FIX mix unbounded iteration and functions in a single plot command (Bug #2201)
* FIX reverse history search with readline=builtin (Bug #2209)
* FIX qt: suppress off-by-one ysize (Bug #1759)
* FIX cairo: suppress off-by-one ysize (Bug #1759)
* FIX gd: apply alpha to brushstroke lines (Bug #2117)
* FIX tikz: fixes to accommodate lua 5.3 and newer pgf
* FIX wxt: ExportToFile widget disabled in persist mode (Bug #2185)
* FIX qt: handling of modifier keys (ctrl alt shift) for keyboard events
* FIX wxt: handling of modifier keys (ctrl alt shift) for keyboard events
* FIX fig: dashtype "solid" was not passed through correctly to transfig
* FIX gd: incorrect line spacing of multiline label (Bug #2215)

Note:
  Windows binaries will be delayed; please be patient.

	cheers, and happy plotting

		Ethan

Re: Version 5.2.8 / Development status / Release plans

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

Am 30.11.2019 um 07:16 schrieb "Bastian Märkisch":

> Selectively backporting all that stuff is a major undertaking.
> Wouldn't it be better to create a 5.4 branch from master and remove
> the incomplete features again?

Or better yet, encapsulate them into compiler switches, like we used to
do with all experimental features.

Re: Version 5.2.8 / Development status / Release plans

[Erik L. <eri...@gm...>]

Dear Ethan (and others),

I can report that compilation on OS X worked without problems.

Erik

On Wed, Nov 20, 2019 at 1:16 PM Ethan Merritt (UW) <me...@uw...> wrote:

> (sending again because the first attempt somehow got wrapped in HTML)
>
> I have placed a testing package for version 5.2.8 on SourceForge
>
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> If no build problems are reported, I expect a full 5.2.8 release
> later this month.
>
> I am thinking that this should be the last release planned for
> version 5.2.  I figure to create a 5.4 branch and aim for an
> initial 5.4 release some time next year (2020).
>
> However I don't think the current state of git tip is appropriate
> for a stable release.  There are a lot of changes; some of the new
> features have barely been tested, others have been blocked
> out but only partially implemented.  Therefore I propose to base
> the 5.4 branch off 5.2 rather than off the development branch.
> My thought is to back-port some of the better-tested features
> from the development branch into 5.4.  Some obvious ones are
>         Unicode escape sequences
>     "set table separator <char>"
>     2D plot style "with arrows"
>     3D plot styles "with boxes", "with circles"
>
> If back-porting individual features turns out to be too difficult,
> the fallback plan is be to re-label current git tip as "5.4"
> and start a new development branch as we have done in the past.
> But I am hopeful that the change to using git will make
> back-porting easier.
>
> Your thoughts?
>
>         Ethan
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Aw: Version 5.2.8 / Development status / Release plans

[Bastian M. <bma...@we...>]

Binaries for Windows 64bit are now available on SF.  Please test
as normally distribution builds are done by Tatsuro Matsuoka.
  
  Bastian


> 
> I have placed a testing package for version 5.2.8 on SourceForge
> 
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/�
> 
> If no build problems are reported, I expect a full 5.2.8 release
> later this month.
> 
> I am thinking that this should be the last release planned for
> version 5.2.  I figure to create a 5.4 branch and aim for an
> initial 5.4 release some time next year (2020).
> 
>

Aw: Version 5.2.8 / Development status / Release plans

[Bastian M. <bma...@we...>]

> Von: "Ethan Merritt (UW)" <me...@uw...>
(snip)
>
> However I don't think the current state of git tip is appropriate
> for a stable release.  There are a lot of changes; some of the new
> features have barely been tested, others have been blocked
> out but only partially implemented.  Therefore I propose to base
> the 5.4 branch off 5.2 rather than off the development branch.
> My thought is to back-port some of the better-tested features
> from the development branch into 5.4.  Some obvious ones are
> 	Unicode escape sequences
>     "set table separator <char>"
>     2D plot style "with arrows"
>     3D plot styles "with boxes", "with circles"

>
> If back-porting individual features turns out to be too difficult,
> the fallback plan is be to re-label current git tip as "5.4"
> and start a new development branch as we have done in the past.
> But I am hopeful that the change to using git will make
> back-porting easier.
>
> Your thoughts?
>
> 	Ethan
>

Changing the development model that late in the process is not
a good idea in my opinion. 5.2 and master have diverged very seriously.

Here's the diffstat summary between master and the 5.2 branchpoint:
 496 files changed, 53053 insertions(+), 34391 deletions(-)

And that between master and 5.2 tip:
 462 files changed, 39932 insertions(+), 26039 deletions(-)

Selectively backporting all that stuff is a major undertaking.
Wouldn't it be better to create a 5.4 branch from master and remove
the incomplete features again?

  Bastian

[gnuplot] : link broken

[Thomas B. <tho...@et...>]

Hello,

The following link is broken : http://www.duke.edu/~hpgavin/gnuplot.html

Best regards,

Thomas

Re: Version 5.2.8 / Development status / Release plans

[Tatsuro M. <tma...@ya...>]

Sorry my condition is not good so that I cannot commit windows binaries.

Tatsuro



----- Original Message -----
> From: Ethan Merritt (UW) <me...@uw...>
> To: gnuplot-beta <gnu...@li...>
> Cc: 
> Date: 2019/11/21, Thu 04:13
> Subject: Version 5.2.8 / Development status / Release plans
> 
>( sending again because the first attempt somehow got wrapped in HTML)
> 
> I have placed a testing package for version 5.2.8 on SourceForge
> 
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/ 
> 

Version 5.2.8 / Development status / Release plans

[Ethan M. (UW) <me...@uw...>]

(sending again because the first attempt somehow got wrapped in HTML)

I have placed a testing package for version 5.2.8 on SourceForge

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

Version 5.2.8 / Development status / Release plans

[Ethan M. (UW) <me...@uw...>]

I have placed a testing package for version 5.2.8 on SourceForge

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/[1]

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

On Monday, 11 November 2019 09:35:03 Mojca Miklavec wrote:
> Hi,
> 
> I just got a confirmation from one of the Apple developers working on
> the compiler that
>     "This is (unfortunately) correct behavior from the perspective of
> the toolchain"

I have extended the trial patch to include modification of the file
   config/mingw/Makefile

So far as I can see, the other config files mention by Hans-Bernard 
are fine once dependence on $(TOP)/VERSION is removed.  They only use
it to prepare the TeX/PDF build, which was already handled directly as
a modification to docs/titlepag.tex

Please confirm if this patch works for you.

	Ethan

> 
> On Tue, 5 Nov 2019 at 22:43, Hans-Bernhard Bröker wrote:
> > Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> > > The common file systems on Windows are case-preserving and
> > > case-insensitive, but not case-ignoring.  Would that explain the
> > > difference?
> >
> > I very much doubt it.
> >
> > 1) And as far as I'm aware, MacOS has the same features, and does
> > exhibit the problem.
> >
> > 2) Case-preservance only makes a difference when asking a file for its
> > name or listing the files in a directory, but not when searching for a
> > file by name, along a path list.  Rather that's where the insensitivity
> > hits.  A path search mechanism would have to go out of its way to read
> > back the actual file name of any file it found, to see if the case
> > matches, too.
> >
> > On inspection I did not find any mention of <version> in the dependency
> > information collected by my local compilations, though.  So possibly my
> > local, MinGW and Cygwin versions of the tools and libraries in question
> > (wxWindows, stdc++, ...) are not quite new enough to trigger the problem.
> 
> I tried to reproduce the problem on msys2 (MinGW64) on Windows. I
> could easily reproduce the problem with:
> 
> $ cat VERSION
> 1.0
> 
> $ cat test.cpp
> #include <version>
> int main() { return 0 }
> 
> $ clang++ test.cpp -I.
> 
> but on macOS I also get the problem with as trivial minimal example as
> 
> $ cat test.cpp
> #include <memory>
> int main() { return 0 }
> 
> The main difference is that the included file <memory> on MSYS2
> apparently comes from FSF (the header mentions the licence GPL v3),
> it's thus a completely different header and as a consequence one
> doesn't immediately see the same behaviour. But if I edit the "memory"
> file and only add
>     #include <version>
> there, then the local VERSION file is picked up, so it's basically the
> same behaviour as on macOS.
> 
> $ clang++ test.cpp -I.
> In file included from test.cpp:1:
> In file included from
> C:\Programs\MSYS\msys64\mingw64\include\c++\9.2.0\memory:3:
> .\version:1:1: error: expected unqualified-id
> 1.0
> ^
> 1 error generated.
> 
> So all in all, I would be really grateful if VERSION file could be renamed.
> 
> (According to our limited opt-in installation statistics, gnuplot seem
> to be the 21st most popular explicitly installed package, and having
> it broken is not really the best option. We monkey-patched it for now,
> but it would be great to have a proper solution in place.)
> 
> Mojca
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Ethan A Merritt, Dept of Biochemistry
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Request to rename version.h

[Mojca M. <moj...@gm...>]

Hi,

I just got a confirmation from one of the Apple developers working on
the compiler that
    "This is (unfortunately) correct behavior from the perspective of
the toolchain"

On Tue, 5 Nov 2019 at 22:43, Hans-Bernhard Bröker wrote:
> Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> > The common file systems on Windows are case-preserving and
> > case-insensitive, but not case-ignoring.  Would that explain the
> > difference?
>
> I very much doubt it.
>
> 1) And as far as I'm aware, MacOS has the same features, and does
> exhibit the problem.
>
> 2) Case-preservance only makes a difference when asking a file for its
> name or listing the files in a directory, but not when searching for a
> file by name, along a path list.  Rather that's where the insensitivity
> hits.  A path search mechanism would have to go out of its way to read
> back the actual file name of any file it found, to see if the case
> matches, too.
>
> On inspection I did not find any mention of <version> in the dependency
> information collected by my local compilations, though.  So possibly my
> local, MinGW and Cygwin versions of the tools and libraries in question
> (wxWindows, stdc++, ...) are not quite new enough to trigger the problem.

I tried to reproduce the problem on msys2 (MinGW64) on Windows. I
could easily reproduce the problem with:

$ cat VERSION
1.0

$ cat test.cpp
#include <version>
int main() { return 0 }

$ clang++ test.cpp -I.

but on macOS I also get the problem with as trivial minimal example as

$ cat test.cpp
#include <memory>
int main() { return 0 }

The main difference is that the included file <memory> on MSYS2
apparently comes from FSF (the header mentions the licence GPL v3),
it's thus a completely different header and as a consequence one
doesn't immediately see the same behaviour. But if I edit the "memory"
file and only add
    #include <version>
there, then the local VERSION file is picked up, so it's basically the
same behaviour as on macOS.

$ clang++ test.cpp -I.
In file included from test.cpp:1:
In file included from
C:\Programs\MSYS\msys64\mingw64\include\c++\9.2.0\memory:3:
.\version:1:1: error: expected unqualified-id
1.0
^
1 error generated.

So all in all, I would be really grateful if VERSION file could be renamed.

(According to our limited opt-in installation statistics, gnuplot seem
to be the 21st most popular explicitly installed package, and having
it broken is not really the best option. We monkey-patched it for now,
but it would be great to have a proper solution in place.)

Mojca

Re: Request to rename version.h

[ASSI <Str...@ne...>]

Marcus Calhoun-Lopez writes:
> The source of the error is as follows:
> *) In the file gnuplot-5.2.7/src/Makefile.in, there is the line of code
>        DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
> *) The -I switch means that Clang (and GCC) search $(top_builddir) before the default include directions.
> *) Clang (and GCC) have a file called version in the default included directories (likely to be part of the C++20 standard).
> *) On case-insensitive file systems (like the the default macOS file system), the files version and VERSION are the same.
> *) In $(top_builddir), there is a file called VERSION.
> *) gnuplot indirectly has an #include <version>.
> *) Instead of finding version in the default include directories, it finds the file VERSION in $(top_builddir).
> *) This causes an error.

So this is likely only a problem if you do an in-tree build, can you try
to build out-of-tree instead and see if that error goes away?

> If -I$(top_builddir) is replaced with -idirafter$(top_builddir), the problem goes away.

That's changing the search order which may have different problems.

Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Request to rename version.h

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

Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> The common file systems on Windows are case-preserving and
> case-insensitive, but not case-ignoring.  Would that explain the
> difference?

I very much doubt it.

1) And as far as I'm aware, MacOS has the same features, and does
exhibit the problem.

2) Case-preservance only makes a difference when asking a file for its
name or listing the files in a directory, but not when searching for a
file by name, along a path list.  Rather that's where the insensitivity
hits.  A path search mechanism would have to go out of its way to read
back the actual file name of any file it found, to see if the case
matches, too.

On inspection I did not find any mention of <version> in the dependency
information collected by my local compilations, though.  So possibly my
local, MinGW and Cygwin versions of the tools and libraries in question
(wxWindows, stdc++, ...) are not quite new enough to trigger the problem.

Re: Request to rename version.h

[Achim G. <Str...@ne...>]

Hans-Bernhard Bröker writes:
> No.  The change is that the C++ standard library (and not just for
> C++20, but also in already existing implementations) now contains a
> standard header named <version>, which it did not use to do.
>
> That new header gets mixed up with our VERSION file on case-ignorant
> file systems, and so strangeness ensues.
>
> I'm actually surprised I'm not seeing the same issue on Windows, too, as
> all the preconditions seem to be fulfilled there, too. Maybe the Windows
> compilers try harder to overcome their host system's case-blindness, and
> thus manage to avoid this trap.

The common file systems on Windows are case-preserving and
case-insensitive, but not case-ignoring.  Would that explain the
difference?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Request to rename version.h

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

Am 04.11.2019 um 20:20 schrieb Ethan A Merritt:

[I'll take the liberty to answer on Marcus' behalf...

> (1)
> Are you saying that the issue is a pending (c++20) change to clang's
> implementation-specific definition of the forms:
> 	#include <foo>
> vs	#include "foo"     ????

No.  The change is that the C++ standard library (and not just for
C++20, but also in already existing implementations) now contains a
standard header named <version>, which it did not use to do.

That new header gets mixed up with our VERSION file on case-ignorant
file systems, and so strangeness ensues.

I'm actually surprised I'm not seeing the same issue on Windows, too, as
all the preconditions seem to be fulfilled there, too. Maybe the Windows
compilers try harder to overcome their host system's case-blindness, and
thus manage to avoid this trap.

> (2)
> I cannot reproduce the problem on linux using either gcc 9.2.1 or clang 9.0.0.
> In the case of gcc, I tried both with and without  compiler option -std=c2x.

The applicable switch would have to be -std=c++2x, as this is a C++
issue; it does not affect C.  To inject it into the autoconf process one
would have to specifically override the CXXFLAGS, not CLAGS.

> (4)
> The attached patch removes VERSION from current git head for the
> development branch.  It works on linux in my initial tests but I will hold off
> commiting it pending further confirmation.

We need to be rather careful here.  The VERSION file is used in several
places; distributed over many build platforms.

Just throwing the file away increases the number of places you would
have to remember to put the new version number into, on every release.
The whole point of the current construct of course is to limit that
number to exactly one: the VERSION file itself.  Without the VERSION
file, to get the same effect we would have to export the version number
from configure.ac (the AC_INIT call) to quite a number of places, most
of which live resolutely outside the autoconf world.

I believe the better short-term solution would be to rename the existing
file, and carry that rename through into all the affected files.  Unless
I missed some, those would be:

	config/cygwin/Makefile
	config/makefile.cyg
	config/makefile.os2
	config/mingw/Makefile
	configure.ac
	docs/titlepag.tex
	Makefile.maint
	src/Makefile.maint

And I suspect some of the other config/* files could benefit from an
update in this direction as well --- primarily those currently
hard-coding it into their config.* files or Makefiles.

Re: Request to rename version.h

[Dima K. <gn...@di...>]

Mojca Miklavec <moj...@gm...> writes:

> I tried to reproduce the problem locally, and here's what I get:
>
> /opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
> -arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names
> -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
> -framework Foundation -framework AquaTerm -L/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
> bf_test bf_test.o -lm
> In file included from wxterminal/wxt_gui.cpp:93:
> In file included from wxterminal/wxt_gui.h:75:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
> In file included from /usr/include/assert.h:44:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> ../version:1:1: error: expected unqualified-id
> 5.2

If I'm reading this correctly, then this is not gnuplot-related
specifically, but rather a bug in wxt. What if you run the above command
to build just

  #include <wx/wxprec.h>

If you get the same issue, then wxt is interacting poorly with whatever
the mac people are doing. Probably should report the issue to them too.

But that build command looks really suspicious; are we sure we're
understanding the issue correctly?

What is -ObjC ? Are we compiling using the language we think we are? Can
we split the compile and the link into separate commands to simplify the
test case?

/opt/local??? Do you also have stuff in /opt and in /usr and in
/usr/local? If so, are we 100% sure you're not accidentally picking up
some incompatible combination?

It'd be interesting to run with -save-temps, and then look at the .ii
you get to see what the prepreprocessor ends up doing.

Or if you're sure you understand the problem, then nobody needs to do
any of these :)