gnuplot-beta Mailing List for gnuplot (Page 29)

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.

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
>

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).
> 
>

> 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

Hello,

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

Best regards,

Thomas

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/ 
> 

(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/

I have placed a testing package for version 5.2.8 on SourceForge

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

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

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

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

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.

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

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.

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 :)

On Sunday, November 3, 2019 8:15:15 PM PST Marcus Calhoun-Lopez wrote:
> Greetings.
> 
> My name is Marcus Calhoun-Lopez, and Mojca was kind enough to include me in this discussion.
> I originally raised this issue.
> 
> 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.
> 
> If -I$(top_builddir) is replaced with -idirafter$(top_builddir), the problem goes away.
> 
> I am sorry if this is a little long winded.
> Please let me know if I can clarify.
> I can create a simple test program if that would help.

Thank you for the explanation Marcus.

(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"     ????

That would be weird, as it introduces a possible collision any time a local
directory contains a file that has the same name as a system file.

(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.
Furthermore neither the gcc nor the clang installation brought with it a
system file named "version".   So there is more to it than just the compiler version.

Mojca's error message refers to 
>    /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
>   ../version:1:1: error: expected unqualified-id
Does this indicate that the problem is an include statement in a file 
"cstddef" provided by a OSX-specific llvm?

The cstddef file provided by gcc-9.2.1 does not contain any such statement. 
I do not find a separate cstddef file associated with clang.

(3)
Is it certain that this whole issue would go away if we were to delete  the
"VERSION" file altogether from the gnuplot source?
It really seems to me that Mojca has encountered a deeper problem with
the compiler toolchain.

(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.

	Ethan


> 
> Thank you,
> Marcus
> 
> > On Nov 3, 2019, at 8:45 PM, Ethan Merritt (UW) <me...@uw...> wrote:
> > 
> > On Sunday, 03 November 2019 18:56:09 Ethan Merritt wrote:
> > > > /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> > > > ../version:1:1: error: expected unqualified-id
> > > > 5.2
> > > > ^
> > > > 
> > > > > And frankly, I cannot believe any tool vendor nor standardization body
> > > > > would be so daft as to assume that <version.h> is a suitable name for a
> > > > > new standard header.  There must be roughly several million pre-existing
> > > > > user header files by that name out there that this would trample on.
> > > > 
> > > > Well ... the fact is that the build breaks when using the latest clang
> > > > compiler. And on old OS versions this is now the default behaviour in
> > > > MacPorts, so gnuplot build is currently broken for many of our users.
> > >  
> > > I can build from current git head using clang 9.0.0 without any problem.
> > > My wxgtk version is 3.1
> > >  
> > > On my system cstddef.h does not refer to VERSION anywhere.
> > > However that file came from gcc, not from llvm.
> > > I don't know where that gets us in debugging your problem,
> > > but it seems not to be a problem with clang per se.
> > >  
> > > Note that the syntax
> > >    #include <FILENAME>
> > > should only look in "a standard list of system directories".
> > > I do not know where that standard list is defined, but in any
> > > case it should not include the current working directory.
> > > So a local file named VERSION would not conflict.
> > >  
> > > 	Ethan
> > >  
> > >  
> > > > 
> > > > It hardly makes sense to start pointing fingers about who was supposed
> > > > to figure out that VERSION would be loaded first when one of the
> > > > compiler's own files says "#include <version>" ...
> > > > 
> > > > Mojca


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

Am 04.11.2019 um 05:15 schrieb Marcus Calhoun-Lopez:

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

Unfortunately that's easier said than done, as

a) this line is part of the automatic mechanisms of GNU automake, which
we have little to no control over (that's why it appears in generated
Makefile.in, but not in the hand-written Makefile.am)
b) -idirafter is a non-standard feature, so we cannot blindly assume it
would be usable
c) because of a), we also cannot solve issue b) by making the fix depend
on the result of some configuration test

What all this means is that the solution almost certainly will have to
be to rename our VERSION file, or remove it altogether.  Both approaches
require a modification of all the places that currently use it (which
are quite a few).

Greetings.

My name is Marcus Calhoun-Lopez, and Mojca was kind enough to include me in this discussion.
I originally raised this issue.

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.

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

I am sorry if this is a little long winded.
Please let me know if I can clarify.
I can create a simple test program if that would help.

Thank you,
Marcus

> On Nov 3, 2019, at 8:45 PM, Ethan Merritt (UW) <me...@uw...> wrote:
> 
> On Sunday, 03 November 2019 18:56:09 Ethan Merritt wrote:
> > > /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> > > ../version:1:1: error: expected unqualified-id
> > > 5.2
> > > ^
> > > 
> > > > And frankly, I cannot believe any tool vendor nor standardization body
> > > > would be so daft as to assume that <version.h> is a suitable name for a
> > > > new standard header.  There must be roughly several million pre-existing
> > > > user header files by that name out there that this would trample on.
> > > 
> > > Well ... the fact is that the build breaks when using the latest clang
> > > compiler. And on old OS versions this is now the default behaviour in
> > > MacPorts, so gnuplot build is currently broken for many of our users.
> >  
> > I can build from current git head using clang 9.0.0 without any problem.
> > My wxgtk version is 3.1
> >  
> > On my system cstddef.h does not refer to VERSION anywhere.
> > However that file came from gcc, not from llvm.
> > I don't know where that gets us in debugging your problem,
> > but it seems not to be a problem with clang per se.
> >  
> > Note that the syntax
> >    #include <FILENAME>
> > should only look in "a standard list of system directories".
> > I do not know where that standard list is defined, but in any
> > case it should not include the current working directory.
> > So a local file named VERSION would not conflict.
> >  
> > 	Ethan
> >  
> >  
> > > 
> > > It hardly makes sense to start pointing fingers about who was supposed
> > > to figure out that VERSION would be loaded first when one of the
> > > compiler's own files says "#include <version>" ...
> > > 
> > > Mojca
>  
> Upon further reflection...
> Your error message cannot be coming from a filename.
> It is the VERSION symbol itself that may be an issue.
> Can you compile a junk program?
>  
>     clang -o helloworld -DVERSION="6.7" helloworld.cpp
>  
> If defining VERSION breaks your compile chain that is clearly
> a problem, but it has nothing to do with gnuplot file names.
>  
> 	Ethan
>  
> -- 
> Ethan A Merritt, Dept of Biochemistry
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> MS 357742,   University of Washington, Seattle 98195-7742

On Sunday, 03 November 2019 18:56:09 Ethan Merritt wrote:
> > /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> > ../version:1:1: error: expected unqualified-id
> > 5.2
> > ^
> > 
> > > And frankly, I cannot believe any tool vendor nor standardization body
> > > would be so daft as to assume that <version.h> is a suitable name for a
> > > new standard header.  There must be roughly several million pre-existing
> > > user header files by that name out there that this would trample on.
> > 
> > Well ... the fact is that the build breaks when using the latest clang
> > compiler. And on old OS versions this is now the default behaviour in
> > MacPorts, so gnuplot build is currently broken for many of our users.
>  
> I can build from current git head using clang 9.0.0 without any problem.
> My wxgtk version is 3.1
>  
> On my system cstddef.h does not refer to VERSION anywhere.
> However that file came from gcc, not from llvm.
> I don't know where that gets us in debugging your problem,
> but it seems not to be a problem with clang per se.
>  
> Note that the syntax
>    #include <FILENAME>
> should only look in "a standard list of system directories".
> I do not know where that standard list is defined, but in any
> case it should not include the current working directory.
> So a local file named VERSION would not conflict.
>  
> 	Ethan
>  
>  
> > 
> > It hardly makes sense to start pointing fingers about who was supposed
> > to figure out that VERSION would be loaded first when one of the
> > compiler's own files says "#include <version>" ...
> > 
> > Mojca

Upon further reflection...
Your error message cannot be coming from a filename.
It is the VERSION symbol itself that may be an issue.
Can you compile a junk program?

    clang -o helloworld -DVERSION="6.7" helloworld.cpp

If defining VERSION breaks your compile chain that is clearly
a problem, but it has nothing to do with gnuplot file names.

	Ethan

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

On Sunday, 03 November 2019 22:57:19 Mojca Miklavec wrote:
> On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> > Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > > Dear developers,
> > >
> > > I would like to request renaming the file version.h (and potentially
> > > version.c) to something else, for example gnuplot_version.h.
> > >
> > > The problem is that C++20 introduced a standard header version.h:
> > >     https://en.cppreference.com/w/cpp/header/version
> >
> > That's not actually what that reference says.  That header is called
> > <version>, not <version.h>.
> 
> I'm sorry, I misread the error report.
> 
> The problem is in fact not with version.h, but with VERSION (please
> note that files are case insensitive on macOS).
> 
> 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
> ^
> 
> > And frankly, I cannot believe any tool vendor nor standardization body
> > would be so daft as to assume that <version.h> is a suitable name for a
> > new standard header.  There must be roughly several million pre-existing
> > user header files by that name out there that this would trample on.
> 
> Well ... the fact is that the build breaks when using the latest clang
> compiler. And on old OS versions this is now the default behaviour in
> MacPorts, so gnuplot build is currently broken for many of our users.

I can build from current git head using clang 9.0.0 without any problem.
My wxgtk version is 3.1

On my system cstddef.h does not refer to VERSION anywhere.
However that file came from gcc, not from llvm.
I don't know where that gets us in debugging your problem,
but it seems not to be a problem with clang per se.

Note that the syntax
   #include <FILENAME>
should only look in "a standard list of system directories".
I do not know where that standard list is defined, but in any
case it should not include the current working directory.
So a local file named VERSION would not conflict.

	Ethan


> 
> It hardly makes sense to start pointing fingers about who was supposed
> to figure out that VERSION would be loaded first when one of the
> compiler's own files says "#include <version>" ...
> 
> 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

On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > Dear developers,
> >
> > I would like to request renaming the file version.h (and potentially
> > version.c) to something else, for example gnuplot_version.h.
> >
> > The problem is that C++20 introduced a standard header version.h:
> >     https://en.cppreference.com/w/cpp/header/version
>
> That's not actually what that reference says.  That header is called
> <version>, not <version.h>.

I'm sorry, I misread the error report.

The problem is in fact not with version.h, but with VERSION (please
note that files are case insensitive on macOS).

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
^

> And frankly, I cannot believe any tool vendor nor standardization body
> would be so daft as to assume that <version.h> is a suitable name for a
> new standard header.  There must be roughly several million pre-existing
> user header files by that name out there that this would trample on.

Well ... the fact is that the build breaks when using the latest clang
compiler. And on old OS versions this is now the default behaviour in
MacPorts, so gnuplot build is currently broken for many of our users.

It hardly makes sense to start pointing fingers about who was supposed
to figure out that VERSION would be loaded first when one of the
compiler's own files says "#include <version>" ...

Mojca

Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> Dear developers,
> 
> I would like to request renaming the file version.h (and potentially
> version.c) to something else, for example gnuplot_version.h.
> 
> The problem is that C++20 introduced a standard header version.h:
>     https://en.cppreference.com/w/cpp/header/version

That's not actually what that reference says.  That header is called
<version>, not <version.h>.

And frankly, I cannot believe any tool vendor nor standardization body
would be so daft as to assume that <version.h> is a suitable name for a
new standard header.  There must be roughly several million pre-existing
user header files by that name out there that this would trample on.

Dear developers,

I would like to request renaming the file version.h (and potentially
version.c) to something else, for example gnuplot_version.h.

The problem is that C++20 introduced a standard header version.h:
    https://en.cppreference.com/w/cpp/header/version
which is now causing issues when using a C++20-compliant compiler for gnuplot.

We need to patch gnuplot we ship inside a package manager as soon as
possible, but ideally I would like to use the same patch as upstream.

Thank you very much,
    Mojca

On Wednesday, 18 September 2019 12:06:09 Dima Kogan wrote:
> Thanks for the comments. Notes inline
> 
> Ethan Merritt (UW) <me...@uw...> writes:
> 
> > On Wednesday, 18 September 2019 10:37:15 Dima Kogan wrote:
> >
> > Are you saying that you have two sets of data, each with its own range
> > on z? That is a separate problem I will come back to at the end [*].
> > For now I assume the two data sets are on the same scale.
> 
> Yes, they're different: the z used for the contours is unrelated in what
> I want plotted on the z.
> 
> What I'm REALLY trying to do is to visualize a 4D function that maps
> (x,y,a) -> b. There's no clear "right" way to do this in any plotting
> tool. I'd like to do this with several stacked contours, at some preset
> values of a: a0,a1,a2, .... So in each a = a* slice I'd have a 3D
> function (x,y) -> b. And for each such slice I want to generate a
> contour on the xy plane, rendering the contour at z = a*. Multiplot is
> needed for the multiple contours, but that's a whole other issue. As you
> can see, the contours are generated by looking at the value of b, while
> the plot shows values of a on the z axis. Any other suggestions for
> visualizing such 4D functions welcome.

That sounds very close to the new voxel-based options in 5.3.
One such visualization is the animation in "voxel.dem"
The on-line collection has a static image of the end point, but
if you run the demo locally you'll see that it steps through the
volumne one plane at a time.
    http://gnuplot.sourceforge.net/demo_5.3/voxel.html

Your description sounds like the same thing with contours rather
than a heatmap.

I would do it by precalculating the contour slices one by one and
then either stepping through them or superimposing them.
Something like this:
    set contour
    set cntrparam levels increment -1, .1, 1
    unset surface
    f1(x,y) = sin(x)*cos(y)
    f2(x,y) = sin(x+.1)*cos(y-.1)
    f3(x,y) = sin(x+.2)*cos(y-.2)
    set table $slice1
    splot [-5:5][-5:5] '++' using 1:2:(f1($1,$2)) with lines
    set table $slice2
    splot [-5:5][-5:5] '++' using 1:2:(f2($1,$2)) with lines
    set table $slice3
    splot [-5:5][-5:5] '++' using 1:2:(f3($1,$2)) with lines
    unset table

    unset contour
    set surface
    splot $slice1 using 1:2:(0.0):3 with lines lc palette, \
          $slice2 using 1:2:(0.1):3 with lines lc palette, \
          $slice3 using 1:2:(0.2):3 with lines lc palette


There's something odd about one of those contours but you get the idea.


> > The contour plot is generated by contouring the data. If you restrict
> > the data to the subset in a particular range then you get contours of
> > only that subset.
> 
> Yes. But the expectation was that zrange restricts the visualization,
> not the data. So the full set of data would be used in the contouring,
> and the zrange would only control how stuff is drawn.

[shrug] I guess it depends on how you think about it.
Consider the 9th plot (3rd from the end) in this demo:
    http://gnuplot.sourceforge.net/demo_5.2/sampling.html
    
Limiting the axis range of each plot controls which data is plotted
where, but the overall axis ranges on x y z for the plot as a whole
encompass all the pieces.

	Ethan

Thanks for the comments. Notes inline

Ethan Merritt (UW) <me...@uw...> writes:

> On Wednesday, 18 September 2019 10:37:15 Dima Kogan wrote:
>
> Are you saying that you have two sets of data, each with its own range
> on z? That is a separate problem I will come back to at the end [*].
> For now I assume the two data sets are on the same scale.

Yes, they're different: the z used for the contours is unrelated in what
I want plotted on the z.

What I'm REALLY trying to do is to visualize a 4D function that maps
(x,y,a) -> b. There's no clear "right" way to do this in any plotting
tool. I'd like to do this with several stacked contours, at some preset
values of a: a0,a1,a2, .... So in each a = a* slice I'd have a 3D
function (x,y) -> b. And for each such slice I want to generate a
contour on the xy plane, rendering the contour at z = a*. Multiplot is
needed for the multiple contours, but that's a whole other issue. As you
can see, the contours are generated by looking at the value of b, while
the plot shows values of a on the z axis. Any other suggestions for
visualizing such 4D functions welcome.


> The contour plot is generated by contouring the data. If you restrict
> the data to the subset in a particular range then you get contours of
> only that subset.

Yes. But the expectation was that zrange restricts the visualization,
not the data. So the full set of data would be used in the contouring,
and the zrange would only control how stuff is drawn.


> [*] If the two data sets are not on the same scale then a different
> approach is needed.  Gnuplot does not currently have a separate z2
> axis analogous to x2 or y2.  You can, however, introduce a scaling
> function into the plot command:
>
>   splot $data1 using 1:2:3 with lines nosurface title "contours", \
>         $data2 using 1:2:(scale($3)) with points nocontour
>
> However the commands as shown would leave you with the wrong labels
> along z.  If you apply the scale to the contoured data instead then
> the z axis labels would be correct but the contour labels would be
> wrong.  Either way you would have to manually correct the values in
> the labels.
>
> Modifying gnuplot to support a z2 axis would be possible, but we'd
> have to agree on the desired representation.  x2 and y2 are drawn
> on the opposite side of the plot from x1 and y1 respectively.
> Would z2 be drawn on a separate [new] vertical line from z1?
> Or would z2 consist only of a second set of z-axis tic labels,
> presumably in a distinct color?

Hmmm. A separate z2 axis would solve this, and maybe supporting that
eventually would be nice, but for THIS particular issue it feels like a
workaround.

Presumably in the gnuplot guts we have some for of this logic:

1. ingest data
2. throw away all data outside the xrange, yrange, zrange
3. make contours
4. draw

Can it be updated to

1. ingest data
2. make contours
3. throw away all data outside the xrange, yrange, zrange
4. draw

Or maybe

1.   ingest data
1.5. throw away all data outside the xrange, yrange
2.   make contours
3.   throw away all data outside the zrange
4.   draw

Here when looking at contours in step 3, we'd use the z of where the
contours are drawn, not the data used to generate them. So for contours
on the xyplane we'd use the z coordinate of the xyplane.

It's very possible that I'm oversimplifying everything here, and that
there're lots of details that make such a change impossible. But it
feels a lot more like what I (as a user) thinks zrange should do: act on
what I see rendered against the z axis.

Thanks