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

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

Re: Request to rename version.h

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

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

Re: Request to rename version.h

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

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

Re: Request to rename version.h

[Marcus Calhoun-L. <mca...@ma...>]

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