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

pre-release testing version of gnuplot 5.2.4

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

I have uploaded a 5.2.4 tarball to the "testing" section of the
gnuplot files folder on SourceForge.
   
    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
    gnuplot-5.2.4-testing.tar.gz


This release contains
- a fix for a serious regression reported against 5.2.3 (spurious
  evaluation of logscale coordinates as UNDEFINED)
- re-implementation of the "refresh" command to correct regressions in
  5.2.0 through 5.2.3
- sanity checks for several invalid command sequences found by fuzzing
- several minor bug-fixes
- two recent minor changes back-ported from the development version

Yes it's only been a month since 5.2.3 but I think the regression
in plotting logscale axes is serious enough to warrant an immediate fix.
If you want to test before/after here is a simple trigger for the error:
    set log y
    plot [1:100] x**2, 1/0

Please use the testing tarball to confirm a successful build or
report build errors.  If no problems are found I expect to make a
regular release of 5.2.4 next week.

	Ethan

Planned release of 5.2.4 to correct serious regression in 5.2.3

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

Dave Horsfall has reported a serious regression in gnuplot 5.2.3 that,
when triggered, causes all logscale coordinates to evaluate as undefined.
This results in empty plots.
Simple reproducer:

    set log y
    plot [1:100] x**2,   1/0 

The underlying error is that the internal flag indicating evaluation of an 
undefined quantity (undefined = TRUE) fails to be reset before the
first plot is drawn.   In the example this is triggered by evaluation
of  "1/0"  as the last thing on the command line but I am sure there
are other ways to trigger it.

I have commited a one-line fix  (undefined=FALSE) to git tip and
to branch-5-2-stable.

The same bug has been in the development version since a year ago
(commit  d7211e24) without being reported, so it doesn't make
logscale axes totally unusable.  Nevertheless it clearly causes a
serious regression so I plan to prepare a 5.2.4 release package this
weekend to correct it.

Several other fixes have been applied since 5.2.3, so the new release
will contain
- a fix for a serious regression in 5.2.3 (spurious evaluation of logscale
  coordinates as UNDEFINED)
- re-implementation of the "refresh" command to correct regressions in
  5.2.0 through 5.2.3
- sanity checks for several invalid command sequences found by fuzzing
- several minor bug-fixes
- two recent minor changes back-ported from the development version


			Ethan

Re: GLib version requirement

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

On Thursday, 10 May 2018 09:31:32 Allin Cottrell wrote:
> I see that since 2017-02-09 gnuplot requires version 2.28 or higher of 
> GLib, on account of use of the macro g_clear_object.
> 
> Unfortunately it can be difficult to build GLib on (or for) some older 
> systems, such as OS X <= 10.4, but older GLib versions are easier 
> (e.g. 2.18). I'd like to suggest pushing the GLib dependency back to 
> 2.18 and adding a simple compatibility macro in gp_cairo.c. Here's an
> illustrative diff relative to 5.2.3:
> 
> --- gp_cairo.c.orig 2018-05-09 16:46:59.510301745 -0400
> +++ gp_cairo.c 2018-05-10 08:32:07.378541918 -0400
> @@ -77,6 +77,13 @@
>   #define rint(x) floor((x)+0.5L)
>   #endif
> 
> +#if GLIB_MAJOR_VERSION == 2 && GLIB_MINOR_VERSION < 28
> +#define g_clear_object(op) \
> +    { gpointer *_p = (gpointer) (op); \
> +    if (_p && *_p) { g_object_unref(*_p); *_p = NULL; } \
> +    }
> +#endif
> +
>   /* undef this to see what happens without the Symbol-to-unicode processing */
>   #define MAP_SYMBOL
> 
> Any thoughts?

The change to use g_clear_object fixed detectable use-after-free errors.
Your proposed macro goes back to calling g_object_unref without any
separate reference counting, so I imagine it would reintroduce the
use-after-free errors.  Have you checked?  Or maybe the need for
reference counting was introduced in some later version of glib?

	Ethan

GLib version requirement

[Allin C. <cot...@wf...>]

I see that since 2017-02-09 gnuplot requires version 2.28 or higher of 
GLib, on account of use of the macro g_clear_object.

Unfortunately it can be difficult to build GLib on (or for) some older 
systems, such as OS X <= 10.4, but older GLib versions are easier 
(e.g. 2.18). I'd like to suggest pushing the GLib dependency back to 
2.18 and adding a simple compatibility macro in gp_cairo.c. Here's an
illustrative diff relative to 5.2.3:

--- gp_cairo.c.orig 2018-05-09 16:46:59.510301745 -0400
+++ gp_cairo.c 2018-05-10 08:32:07.378541918 -0400
@@ -77,6 +77,13 @@
  #define rint(x) floor((x)+0.5L)
  #endif

+#if GLIB_MAJOR_VERSION == 2 && GLIB_MINOR_VERSION < 28
+#define g_clear_object(op) \
+    { gpointer *_p = (gpointer) (op); \
+    if (_p && *_p) { g_object_unref(*_p); *_p = NULL; } \
+    }
+#endif
+
  /* undef this to see what happens without the Symbol-to-unicode processing */
  #define MAP_SYMBOL

Any thoughts?

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: 5.2-stable regression for log axes still not fixed completely

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

sfeam via gnuplot-beta writes:
>> > This happens because the timestamp position changes in 5.2.x from
>> > inbetween the axis labeling and a key box in the bottom margin to the
>> > actual bottom of the margin.  I've confirmed that the position was
>> > inbetween the two parts from at least 4.0 onwards to 5.0.7. 
>
> Indeed. But was that ever intended or was it a long-standing bug?

I have no opinion on that.  I think I've already said that based on the
documentation it would make sense for the timestamp to be always at the
bottom of the page.

> Consistent placement of the timestamp at the bottom of the page was
> an intentional change.  The bug is overlap with some key placements.

Indeed.  I would suggest that the space taken up be the timestamp should
be taken away from the canvas size so that no element of the plot area
will ever even attempt to encroach.  I also think that this area should
be given back to the plot if no timestamp is present, but maybe that
decision would depend on what terminal is used.

> I propose that the timestamp should always be at the bottom of the page,
> and for 5.2.x when the key box is underneath the plot it should move up
> in concert with the plot itself if space is added to accommodate the
> timestamp.  I acknowledge that behavior does not match any previous
> version of gnuplot. 

That'd work for me.

[…]
> Starting in gnuplot version 5 (I'm not sure exactly which point release)
> the key title and the key contents can use separate fonts.
> Your test script sets the key font but probably intended to set 
> the title font:
>
>     set key font "LiberationSansNarrow,11"
> vs.      
>     set key title font "LiberationSansNarrow,11"

I'm in the fortunate position of being able to change the script that
produces the plots, so as long as I can obtain consistent behaviour
that's OK with me.  There already have been extensive changes when
switching over from 4.x, so a few more changes to get from 5.0 to 5.2
don't scare me.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: 5.2-stable regression for log axes still not fixed completely

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

On Tuesday, 08 May 2018 20:38:20 Achim Gratz wrote:
> Achim Gratz writes:
> > Achim Gratz writes:
> >>>> I have to get to the bottom of it later.  The only other difference to
> >>>> 5.0.7 I've noticed is that the key box in some cases overlaps with some
> >>>> labeling outside the main plot area.  Again, I don't know exactly when
> >>>> and why that happens, but I will eventually try to find out.
> >>>
> >>> Are these 3D plots?
> >>
> >> No, distribution plots, sometimes with reversed and/or logarithmic axes.
> >>
> >>> Have a look at the documentation for "set key fixed".
> >>
> >> I'll have to trace the same steps as outlined above, then I can be back
> >> with more questions (unless it's already obvious by then).
> >
> > This happens because the timestamp position changes in 5.2.x from
> > inbetween the axis labeling and a key box in the bottom margin to the
> > actual bottom of the margin.  I've confirmed that the position was
> > inbetween the two parts from at least 4.0 onwards to 5.0.7. 

Indeed. But was that ever intended or was it a long-standing bug?

Consistent placement of the timestamp at the bottom of the page was
an intentional change.  The bug is overlap with some key placements.
I propose that the timestamp should always be at the bottom of the page,
and for 5.2.x when the key box is underneath the plot it should move up
in concert with the plot itself if space is added to accommodate the
timestamp.  I acknowledge that behavior does not match any previous
version of gnuplot. 

Placement of the key in 3D plots is even more complicated but
the combination of timestamp and "set key outside bottom center"
suffers from the same overlap problem as 2D plots in the current code.
Some fix is needed there also.

> > There is
> > some space inbetween the axis labeling and the key box title that looks
> > like a leftover from the previous behaviour.
> 
> I've tried this again with 5.2.3 and the problem is still there.  I'm
> attaching an input file and PDF output from both 5.0.7 and 5.2.3 that
> hopefully clearly demonstrates what I'm talking about.  Nota that
> besides the position of the timestamp the key box title also changes
> font size.

Starting in gnuplot version 5 (I'm not sure exactly which point release)
the key title and the key contents can use separate fonts.
Your test script sets the key font but probably intended to set 
the title font:

    set key font "LiberationSansNarrow,11"
vs.      
    set key title font "LiberationSansNarrow,11"


			Ethan

Re: 5.2-stable regression for log axes still not fixed completely

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

Achim Gratz writes:
> Achim Gratz writes:
>>>> I have to get to the bottom of it later.  The only other difference to
>>>> 5.0.7 I've noticed is that the key box in some cases overlaps with some
>>>> labeling outside the main plot area.  Again, I don't know exactly when
>>>> and why that happens, but I will eventually try to find out.
>>>
>>> Are these 3D plots?
>>
>> No, distribution plots, sometimes with reversed and/or logarithmic axes.
>>
>>> Have a look at the documentation for "set key fixed".
>>
>> I'll have to trace the same steps as outlined above, then I can be back
>> with more questions (unless it's already obvious by then).
>
> This happens because the timestamp position changes in 5.2.x from
> inbetween the axis labeling and a key box in the bottom margin to the
> actual bottom of the margin.  I've confirmed that the position was
> inbetween the two parts from at least 4.0 onwards to 5.0.7.  There is
> some space inbetween the axis labeling and the key box title that looks
> like a leftover from the previous behaviour.

I've tried this again with 5.2.3 and the problem is still there.  I'm
attaching an input file and PDF output from both 5.0.7 and 5.2.3 that
hopefully clearly demonstrates what I'm talking about.  Nota that
besides the position of the timestamp the key box title also changes
font size.

Re: Alternate version of Gnuplot 5.2.3 for OS X

[Allin C. <cot...@wf...>]

On Sun, 6 May 2018, Erik Luijten wrote:

> Hello,
>
> Here is an alternative version of Gnuplot 5.2.3 compiled for OS X:
>
> https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
>
> It includes the GNU readline functionality and also has the PDF terminal
> (which, even though deprecated, works very well and is widely used).

For anyone who's "shopping" for gnuplot on OS X I might mention a 
couple of other differences between the Erik's builds and mine: mine 
do not require X11/XQuartz (they include the aqua and wxt interactive 
terminals but not x11), and they are compatible with OS X 10.6.6 and 
higher.

Erik mentions that his builds were made on 10.11.6; I don't know what 
the minimum compatible OS X version is.

Allin Cottrell

Alternate version of Gnuplot 5.2.3 for OS X

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

Hello,

Here is an alternative version of Gnuplot 5.2.3 compiled for OS X:

https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X

It includes the GNU readline functionality and also has the PDF terminal
(which, even though deprecated, works very well and is widely used).

Regards,

Erik Luijten

gnuplot 5.2.3 for OS X

[Allin C. <cot...@wf...>]

There's now a build of gnuplot 5.2.3 for Mac OS X at
http://ricardo.ecn.wfu.edu/pub/gnuplot/

It's available in both pkg and dmg form.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: Release 5.2.3

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

I have uploaded windows binary packages on the 5.2.3 on File tag on the SourceForge.

I included renamed fontconfig utilities (e.g. fc-cache-gp)  in bin directory.

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2018/5/6, Sun 07:17
> Subject: Re: Release 5.2.3
> 
> Sorry for the noise.
> 
> Perhaps I mis-operate 7zip FileManger for extracting tar.gz.
> 
> I re-operate and build is now going.
> 
> Thanks.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam 
>>  To: gnuplot-beta Tatsuro MATSUOKA 
>>  Cc: 
>>  Date: 2018/5/6, Sun 00:49
>>  Subject: Re: Release 5.2.3
>> 
>>  On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
>>>   I cannot build the source of 5.2.3 (that could be build on testing).
>>> 
>>>   gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
>>  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> 
>>  -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows 
> -DHAVE_CONFIG_H 
>>  -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
>>  -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
>>  -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
>>  Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
>>  -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
>>  -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
>>  -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP 
> -DREADLINE  
>>  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
>>>   In file included from ../../src/eval.h:43:0,
>>>                    from ../../src/eval.c:41:
>>>   ../../src/gp_types.h:188:5: error: unknown type name 
> 'coordval'
>>>        coordval x, y, z;
>>>        ^~~~~~~~
>>>   ../../src/gp_types.h:189:5: error: unknown type name 
> 'coordval'
>>>        coordval ylow, yhigh; /* ignored in 3d */
>>>        ^~~~~~~~
>>>    many errors
>> 
>>  Have you checked the md5sum after downloading?
>>  Maybe there was file corruption.
>> 
>>>   This might happen due to fixes after testing and 5.2.3.
>> 
>>  The only changes to source files between the testing version 
>>  and the release are these:
>> 
>>  diff --git a/term/post.trm b/term/post.trm
>>  index 25efcd8..e1628af 100644
>>  --- a/term/post.trm
>>  +++ b/term/post.trm
>>  @@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, 
> int 
>>  y0, int dx, int
>>  dy));
>>  static void PS_dump_header_to_file __PROTO((char *name));
>>  #endif
>> 
>>  -static float ps_fontsize;
>>  -static float ps_fontsize_previous;
>>  +static float ps_fontsize = 14.;
>>  +static float ps_fontsize_previous = 0.;
>> 
>>  /* for enhanced mode, we keep a separate font name and size, which
>>    * is restored to the default value on font of ""
>>  -- 
>>  diff --git a/src/version.c b/src/version.c
>>  index 476efe3..6cbbe8c 100644
>>  --- a/src/version.c
>>  +++ b/src/version.c
>>  @@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
>>  #ifdef DEVELOPMENT_VERSION
>>  #include "timestamp.h"
>>  #else
>>  -const char gnuplot_date[] = "2018-04-21 ";
>>  +const char gnuplot_date[] = "2018-05-04 ";
>>  #endif
>>  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
> 
>>  2007-2018";
>> 
>>  -- 
>> 
>>      Ethan
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Release 5.2.3

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

Sorry for the noise.

Perhaps I mis-operate 7zip FileManger for extracting tar.gz.

I re-operate and build is now going.

Thanks.

Tatsuro



----- Original Message -----
> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2018/5/6, Sun 00:49
> Subject: Re: Release 5.2.3
> 
> On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
>>  I cannot build the source of 5.2.3 (that could be build on testing).
>> 
>>  gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
> -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H 
> -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
> -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
> -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
> Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
> -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
> -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
> -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  
> -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
>>  In file included from ../../src/eval.h:43:0,
>>                   from ../../src/eval.c:41:
>>  ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>>       coordval x, y, z;
>>       ^~~~~~~~
>>  ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>>       coordval ylow, yhigh; /* ignored in 3d */
>>       ^~~~~~~~
>>   many errors
> 
> Have you checked the md5sum after downloading?
> Maybe there was file corruption.
> 
>>  This might happen due to fixes after testing and 5.2.3.
> 
> The only changes to source files between the testing version 
> and the release are these:
> 
> diff --git a/term/post.trm b/term/post.trm
> index 25efcd8..e1628af 100644
> --- a/term/post.trm
> +++ b/term/post.trm
> @@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, int 
> y0, int dx, int
> dy));
> static void PS_dump_header_to_file __PROTO((char *name));
> #endif
> 
> -static float ps_fontsize;
> -static float ps_fontsize_previous;
> +static float ps_fontsize = 14.;
> +static float ps_fontsize_previous = 0.;
> 
> /* for enhanced mode, we keep a separate font name and size, which
>   * is restored to the default value on font of ""
> -- 
> diff --git a/src/version.c b/src/version.c
> index 476efe3..6cbbe8c 100644
> --- a/src/version.c
> +++ b/src/version.c
> @@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
> #ifdef DEVELOPMENT_VERSION
> #include "timestamp.h"
> #else
> -const char gnuplot_date[] = "2018-04-21 ";
> +const char gnuplot_date[] = "2018-05-04 ";
> #endif
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
> 2007-2018";
> 
> -- 
> 
>     Ethan
> 

Re: Release 5.2.3

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

On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
> I cannot build the source of 5.2.3 (that could be build on testing).
> 
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors

Have you checked the md5sum after downloading?
Maybe there was file corruption.

> This might happen due to fixes after testing and 5.2.3.

The only changes to source files between the testing version 
and the release are these:

diff --git a/term/post.trm b/term/post.trm
index 25efcd8..e1628af 100644
--- a/term/post.trm
+++ b/term/post.trm
@@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, int y0, int dx, int
 dy));
 static void PS_dump_header_to_file __PROTO((char *name));
 #endif
 
-static float ps_fontsize;
-static float ps_fontsize_previous;
+static float ps_fontsize = 14.;
+static float ps_fontsize_previous = 0.;
 
 /* for enhanced mode, we keep a separate font name and size, which
  * is restored to the default value on font of ""
-- 
diff --git a/src/version.c b/src/version.c
index 476efe3..6cbbe8c 100644
--- a/src/version.c
+++ b/src/version.c
@@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
 #ifdef DEVELOPMENT_VERSION
 #include "timestamp.h"
 #else
-const char gnuplot_date[] = "2018-04-21 ";
+const char gnuplot_date[] = "2018-05-04 ";
 #endif
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 2007-2018";
 
-- 

	Ethan

Re: Release 5.2.3

[Cottrell, A. <cot...@wf...>]

On Sat, May 5, 2018 at 5:41 AM, Tatsuro MATSUOKA <tma...@ya...> wrote:
> I cannot build the source of 5.2.3 (that could be build on testing).
>
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors

I'm not seeing this problem, cross-building gnuplot 5.2.3 with mingw64
on Linux. And it seems
surprising: gp_types.h includes syscfg.h at the top, and syscfg.h
contains, unconditionally,

typedef double coordval;

Allin Cottrell

Re: Release 5.2.3 (build fails on native winodws

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

Ah I forgot to mention build platform.

Native windows Msys2 + mingw w64 (gcc 7.1.0)

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Merritt Ethan <sf...@us...>; gnu...@li...
> Cc: 
> Date: 2018/5/5, Sat 18:41
> Subject: Re: Release 5.2.3
> 
> I cannot build the source of 5.2.3 (that could be build on testing).
> 
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
> -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H 
> -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
> -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
> -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
> Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
> -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
> -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
> -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  
> -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors
> 
> This might happen due to fixes after testing and 5.2.3.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam via gnuplot-beta 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2018/5/5, Sat 13:54
>>  Subject: Release 5.2.3
>> 
>>  Source tarball for gnuplot 5.2.3 uploaded to SourceForge.
>> 
>>  One trivial fix to initialization of postscript terminal added since
>>  last week's 5.2.3-testing source.
>> 
>>  This is the first gnuplot release prepared from git rather than cvs.
>>  The release corresponds to git commit 
> 77a494497d6beb9d09e71643c186e8ab891bbe7e
>>  Should this be captured somewhere in the release source?
>>  Where?
>> 
>>  CHANGES IN 5.2.3
>>  ================
>>  * NEW "set grid {no}vertical" adds grid lines in the xz and xz 
> planes
>>  * NEW "set cntrparam {firstlinetype N} {{un}sorted}"
>>  * CHANGE drop non-working support for YIQ color space
>>  * CHANGE expand \n characters when printing into a datablock
>>  * CHANGE allow contour plots to opt out of hidden3d processing
>>  * CHANGE special-case code to speed up handling of logscale axes
>>  * CHANGE do not write GPFUN_* variables to "save" output file
>>  * CHANGE default to density 100 for "set fs solid", 50 for 
> "set 
>>  fs transparent"
>>  * FIX potential buffer overflow in gprintf formats containing %%
>>  * FIX immediate response to ctrl-Z when libreadline is used for input
>>  * FIX warning messages inside a bracketed clause could trigger early exit
>>  * FIX tweak logscale tic range limits and minor tic generation intervals
>>  * FIX stats FOO using 'namedcolumn' name columnhead
>>  * FIX clipping of INRANGE->UNDEFINED line segments
>>  * FIX use of logscale y axis in "set view map" or "set pm3d 
>>  map" modes
>>  * FIX placement of colorbox in "set view map" mode
>>  * FIX autoscaled axis range of logscale axes in "set view map" 
> mode
>>  * FIX polar mode "with yerrorbars" error bars are radial, not 
> vertical
>>  * FIX clipping of circles whose center is offscreen to the left or bottom
>>  * FIX canvas terminal: apply both color and alpha channel to points and 
> lines
>>  * FIX svg terminal: apply current color to dots
>>  * FIX qt terminal: include "notitle" plots in accounting for 
> toggle 
>>  operations
>>  * FIX svg terminal: point plot empty title produced spurious mousing 
> directive
>>  * FIX tikz terminal: failed to recognize dashtype 1
>> 
>> 
>>      Ethan
>> 
>> 
> ------------------------------------------------------------------------------
>>  Check out the vibrant tech community on one of the world's most
>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via: 
>>  https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Release 5.2.3

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

I cannot build the source of 5.2.3 (that could be build on testing).

gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
In file included from ../../src/eval.h:43:0,
                 from ../../src/eval.c:41:
../../src/gp_types.h:188:5: error: unknown type name 'coordval'
     coordval x, y, z;
     ^~~~~~~~
../../src/gp_types.h:189:5: error: unknown type name 'coordval'
     coordval ylow, yhigh; /* ignored in 3d */
     ^~~~~~~~
 many errors

This might happen due to fixes after testing and 5.2.3.

Tatsuro



----- Original Message -----
> From: sfeam via gnuplot-beta 
> To: gnuplot-beta
> Cc: 
> Date: 2018/5/5, Sat 13:54
> Subject: Release 5.2.3
> 
> Source tarball for gnuplot 5.2.3 uploaded to SourceForge.
> 
> One trivial fix to initialization of postscript terminal added since
> last week's 5.2.3-testing source.
> 
> This is the first gnuplot release prepared from git rather than cvs.
> The release corresponds to git commit 77a494497d6beb9d09e71643c186e8ab891bbe7e
> Should this be captured somewhere in the release source?
> Where?
> 
> CHANGES IN 5.2.3
> ================
> * NEW "set grid {no}vertical" adds grid lines in the xz and xz planes
> * NEW "set cntrparam {firstlinetype N} {{un}sorted}"
> * CHANGE drop non-working support for YIQ color space
> * CHANGE expand \n characters when printing into a datablock
> * CHANGE allow contour plots to opt out of hidden3d processing
> * CHANGE special-case code to speed up handling of logscale axes
> * CHANGE do not write GPFUN_* variables to "save" output file
> * CHANGE default to density 100 for "set fs solid", 50 for "set 
> fs transparent"
> * FIX potential buffer overflow in gprintf formats containing %%
> * FIX immediate response to ctrl-Z when libreadline is used for input
> * FIX warning messages inside a bracketed clause could trigger early exit
> * FIX tweak logscale tic range limits and minor tic generation intervals
> * FIX stats FOO using 'namedcolumn' name columnhead
> * FIX clipping of INRANGE->UNDEFINED line segments
> * FIX use of logscale y axis in "set view map" or "set pm3d 
> map" modes
> * FIX placement of colorbox in "set view map" mode
> * FIX autoscaled axis range of logscale axes in "set view map" mode
> * FIX polar mode "with yerrorbars" error bars are radial, not vertical
> * FIX clipping of circles whose center is offscreen to the left or bottom
> * FIX canvas terminal: apply both color and alpha channel to points and lines
> * FIX svg terminal: apply current color to dots
> * FIX qt terminal: include "notitle" plots in accounting for toggle 
> operations
> * FIX svg terminal: point plot empty title produced spurious mousing directive
> * FIX tikz terminal: failed to recognize dashtype 1
> 
> 
>     Ethan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Release 5.2.3

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

Source tarball for gnuplot 5.2.3 uploaded to SourceForge.

One trivial fix to initialization of postscript terminal added since
last week's 5.2.3-testing source.

This is the first gnuplot release prepared from git rather than cvs.
The release corresponds to git commit 77a494497d6beb9d09e71643c186e8ab891bbe7e
Should this be captured somewhere in the release source?
Where?

CHANGES IN 5.2.3
================
* NEW "set grid {no}vertical" adds grid lines in the xz and xz planes
* NEW "set cntrparam {firstlinetype N} {{un}sorted}"
* CHANGE drop non-working support for YIQ color space
* CHANGE expand \n characters when printing into a datablock
* CHANGE allow contour plots to opt out of hidden3d processing
* CHANGE special-case code to speed up handling of logscale axes
* CHANGE do not write GPFUN_* variables to "save" output file
* CHANGE default to density 100 for "set fs solid", 50 for "set fs transparent"
* FIX potential buffer overflow in gprintf formats containing %%
* FIX immediate response to ctrl-Z when libreadline is used for input
* FIX warning messages inside a bracketed clause could trigger early exit
* FIX tweak logscale tic range limits and minor tic generation intervals
* FIX stats FOO using 'namedcolumn' name columnhead
* FIX clipping of INRANGE->UNDEFINED line segments
* FIX use of logscale y axis in "set view map" or "set pm3d map" modes
* FIX placement of colorbox in "set view map" mode
* FIX autoscaled axis range of logscale axes in "set view map" mode
* FIX polar mode "with yerrorbars" error bars are radial, not vertical
* FIX clipping of circles whose center is offscreen to the left or bottom
* FIX canvas terminal: apply both color and alpha channel to points and lines
* FIX svg terminal: apply current color to dots
* FIX qt terminal: include "notitle" plots in accounting for toggle operations
* FIX svg terminal: point plot empty title produced spurious mousing directive
* FIX tikz terminal: failed to recognize dashtype 1


	Ethan

Re: including fontconfig utilities to windows binary packages

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

----- Original Message -----

> From: Allin Cottrell
> To: Tatsuro MATSUOKA 
> Cc: Merritt Ethan ; gnuplot-beta ; bmaerkisch
> Date: 2018/5/3, Thu 11:45
> Subject: Re: including fontconfig utilities to windows binary packages
> 
> On Thu, 3 May 2018, Tatsuro MATSUOKA wrote, in response to my posting:
> 
>>>  [I]insofar as we're talking about terminals based on the 
> pango/cairo/glib stack on Windows, there's no need to involve fontconfig (or 
> freetype) at all. The pango backends that are needed are just Cairo and Win32 
> (the Win32 backend being an alternative to freetype + fontconfig that taps into 
> native Windows font management).
>> 
>>  gd also requires fontconfig/freetype if one use standard syntax for fonts 
> for current gnuplot.
> 
> True. Opinions may differ, but personally I see no need to build the gd terminal 
> for gnuplot if the pango/cairo terminals are available.
> 
>>  If one compiles libraries of pango/cairo/glib in standard way on windows or 
> use libraries supplied by Msys2 + MinGW w64, freetype and fontconfig is linked 
> and gnuplot uses fontconfig/freetype libraries.
> 
> A build of pango, on any system, will by default utilize whatever backends are 
> available for managing fonts. If you have freetype and fontconfig on your system 
> the associated pango backend will be built unless you specify otherwise via the 
> configure script. But my point is that this backend is redundant on MS Windows, 
> since pango is able to utilize native Windows font management. (The same is true 
> on Mac OS X.)
> 
> There's no harm in enabling freetype and fontconfig for pango on Windows 
> (other than bloat), but so far as I can tell there's also no advantage.
> 
> Allin Cottrell
>

Thank for your explanations. 
I have misled about pango/cairo/glib.

But as a window version gnuplot builder, I cannot drop gd terminals with fontconfig/freetype because we have to provide full featured gnuplot as possible.

In addition, the easiest way to set-up build environments on native windows to install Msys2 with MinGW w64. The way of build on native windows is documented by Bastian.
  Build instructions using MSYS2/Mingw-w64
https://sourceforge.net/p/gnuplot/support-requests/199/

In that build system pango/cairo/glib libraries are prepared with linking fontconfig/freetype and
I do not think that there is no reason not to use fontconfig/freetype in the system.

Tatsuro

Re: including fontconfig utilities to windows binary packages

[Allin C. <cot...@wf...>]

On Thu, 3 May 2018, Tatsuro MATSUOKA wrote, in response to my 
posting:

>> [I]insofar as we're talking about terminals based on the 
>> pango/cairo/glib stack on Windows, there's no need to involve 
>> fontconfig (or freetype) at all. The pango backends that are 
>> needed are just Cairo and Win32 (the Win32 backend being an 
>> alternative to freetype + fontconfig that taps into native 
>> Windows font management).
>
> gd also requires fontconfig/freetype if one use standard syntax 
> for fonts for current gnuplot.

True. Opinions may differ, but personally I see no need to build the 
gd terminal for gnuplot if the pango/cairo terminals are available.

> If one compiles libraries of pango/cairo/glib in standard way on 
> windows or use libraries supplied by Msys2 + MinGW w64, freetype 
> and fontconfig is linked and gnuplot uses fontconfig/freetype 
> libraries.

A build of pango, on any system, will by default utilize whatever 
backends are available for managing fonts. If you have freetype and 
fontconfig on your system the associated pango backend will be built 
unless you specify otherwise via the configure script. But my point 
is that this backend is redundant on MS Windows, since pango is able 
to utilize native Windows font management. (The same is true on Mac 
OS X.)

There's no harm in enabling freetype and fontconfig for pango on 
Windows (other than bloat), but so far as I can tell there's also no 
advantage.

Allin Cottrell

Re: including fontconfig utilities to windows binary packages

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

----- Original Message -----

> From: Allin Cottrell 
> To: Ethan A Merritt 
> Cc: gnuplot-beta Tatsuro MATSUOKA  bmaerkisch
 Date: 2018/5/3, Thu 02:57
> Subject: Re: including fontconfig utilities to windows binary packages
> 
> On Wed, 2 May 2018, Ethan A Merritt via gnuplot-beta wrote:
> 
>>  On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
>>>  I propose that we include fontconfig utilities to windows binary 
> packages.
>> 
>>  I do not know how fontconfig works on Windows.
>> 
>>  On linux fontconfig keeps track of all the fonts installed on the system,
>>  so installing it for only one program would not make sense.
>>  If you include fontconfig with a gnuplot binary for Windows, would you
>>  also have to include lots of fonts?  If so I don't think we want to do 
> that.
> 
> No, surely not. And insofar as we're talking about terminals based on the 
> pango/cairo/glib stack on Windows, there's no need to involve fontconfig (or 
> freetype) at all. The pango backends that are needed are just Cairo and Win32 
> (the Win32 backend being an alternative to freetype + fontconfig that taps into 
> native Windows font management).
> 
> Allin Cottrell

gd also requires fontconfig/freetype if one use standard syntax for fonts
for current gnuplot.

If one compiles libraries of pango/cairo/glib in standard way on windows or use libraries supplied by 
Msys2 + MinGW w64, freetype and  fontconfig is linked and 
gnuplot uses fontconfig/freetype libraries.

As I wrote, unlike unix system, each application has their on fontconfig setting like octave for windows and MiKTeX.

Therefore I had made proposal

Tatsuro

Re: including fontconfig utilities to windows binary packages

[Allin C. <cot...@wf...>]

On Wed, 2 May 2018, Ethan A Merritt via gnuplot-beta wrote:

> On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
>> I propose that we include fontconfig utilities to windows binary packages.
>
> I do not know how fontconfig works on Windows.
>
> On linux fontconfig keeps track of all the fonts installed on the system,
> so installing it for only one program would not make sense.
> If you include fontconfig with a gnuplot binary for Windows, would you
> also have to include lots of fonts?  If so I don't think we want to do that.

No, surely not. And insofar as we're talking about terminals based on 
the pango/cairo/glib stack on Windows, there's no need to involve 
fontconfig (or freetype) at all. The pango backends that are needed 
are just Cairo and Win32 (the Win32 backend being an alternative to 
freetype + fontconfig that taps into native Windows font management).

Allin Cottrell

Re: including fontconfig utilities to windows binary packages

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

On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
> I propose that we include fontconfig utilities to windows binary packages.

I do not know how fontconfig works on Windows.

On linux fontconfig keeps track of all the fonts installed on the system,
so installing it for only one program would not make sense.
If you include fontconfig with a gnuplot binary for Windows, would you
also have to include lots of fonts?  If so I don't think we want to do that.

	Ethan


> 
> That is done Kakuto's distribution of dev branch.
> http://ctan.ijs.si/mirror/w32tex/w32/
> 
> On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
> etcs. 
> I think that it is no reason that gnuplot for windows does not have them.
> Bastian. How do you think?
> 
> Tatsuro
> > 
> ----- Original Message -----
> > From: Tatsuro MATSUOKA <tma...@ya...>
> > To: gnu...@li...; Merritt Ethan <sf...@us...>; bma...@we...
> > Cc: 
> > Date: 2018/4/30, Mon 09:03
> > Subject: including fontconfig utilities to windows binary packages
> > 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Proposal : including fontconfig utilities to windows binary packages

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

I propose that we include fontconfig utilities to windows binary packages.


That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
etcs. 
I think that it is no reason that gnuplot for windows does not have them.
Bastian. How do you think?

Tatsuro

including fontconfig utilities to windows binary packages

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

I propose that we include fontconfig utilities to windows binary packages.


That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
etcs. 
I think that it is no reason that gnuplot for windows does not have them.
Bastian. How do you think?

Tatsuro
> 
----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: gnu...@li...; Merritt Ethan <sf...@us...>; bma...@we...
> Cc: 
> Date: 2018/4/30, Mon 09:03
> Subject: including fontconfig utilities to windows binary packages
> 

including fontconfig utilities to windows binary packages

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

I propose that we include fontconfig utilities to windows binary packages.

That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, etcs. 
I think that it is no reason that gnuplot for windows does not have them.

Bastian. How do you think?

Tatsuro