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

Re: Release 6.0.2

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

I have uploaded windows binary packages for 6.0.2.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnuplot beta list" <gnu...@li...>
> Date: 2024/12/21 土 14:37
> Subject: Release 6.0.2
> 
> 
> 
> A release tarball for version 6.0.2 is now available on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.2/gnuplot-6.0.2.tar.gz
> 
> Release Notes here:
>    Gnuplot 6.0.2
> 
> The release version differs from the testing version by one bug fix and a warning in the Release Notes about difficulties in rebuilding the documentation using pdflatex from TeXLive2024 (use luatex instead).
> 
> In addition to the usual minor bug fixes, 6.0.2 contains several new features from the development version of gnuplot that didn't quite make it into the initial version 6 release. See the release notes for more detail.
> 
> Notably, gnuplot 6.0.2 now handles UTF-8 characters in terminal input when linked against the BSD editline library. UTF-8 input has always worked with configuration options readline=gnu or readline=builtin; now it also works for
>    ./configure --with-readline=bsd
> 
> happy gnuplotting
>   Ethan
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Release 6.0.2

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

A release tarball for version 6.0.2 is now available on SourceForge

https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.2/gnuplot-6.0.2.tar.gz

Release Notes here:
    Gnuplot 6.0.2 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_2.html>

The release version differs from the testing version by one bug fix and a
warning in the Release Notes about difficulties in rebuilding the
documentation using pdflatex from TeXLive2024 (use luatex instead).

In addition to the usual minor bug fixes, 6.0.2 contains several new
features from the development version of gnuplot that didn't quite make it
into the initial version 6 release.  See the release notes for more detail.

Notably, gnuplot 6.0.2 now handles UTF-8 characters in terminal input when
linked against the BSD editline library.  UTF-8 input has always worked
with configuration options readline=gnu or readline=builtin; now it also
works for
      ./configure --with-readline=bsd

happy gnuplotting
    Ethan

Re: Testing version of gnuplot 6.0.2

[Jun. T <tak...@kb...>]

Although I can build gnuplot.pdf either by TeXLive2023/pdflatex or
by TeXLive2024/lualatex, both method give the pdf with minor problems:
at around page 79 (or 78 or 80?), in the description of the Ellipses
style, the text does not wrap the figure correctly. It seems "picins"
is not working well (there may be a few more figures that have
similar problems). Does this happens only for me?

I also tried "make tikz" in docs/ directory (hoping it may give better
pdf), but the build failed at the target tikz_figures, with the following
error:
---------------
"./plotstyles.gnu" line 1142: /usr/local/share/gnuplot/6.1/lua/gnuplot-tikz.lua:395: attempt to concatenate a nil value (local 'color')
stack tracebac

line 0: Missing Lua context! No script?
(this message repeats endlessly)
---------------
The error occurs at the "splot" in the "Fence plot" in plotstyles.gnu,
but I don't know how to fix it.

Re: Testing version of gnuplot 6.0.2

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

On Monday, 9 December 2024 00:13:35 PST Henri Menke via gnuplot-beta wrote:
> > 
> > With the newest TeXLive (20240312 on Cygwin) gnuplot documentation
> > can no
> > longer be created since
> > 
> >     \usepackage{ucs}
> >     \usepackage[utf8x]{inputenc}
> > 
> > produces errors in internal TeX packages down the line.  I have not
> > found an invocation that circumvents this problem yet…
> 
> Could you please try simply replacing these two lines by
> 
>     \usepackage[utf8]{inputenc}
> 
> The ucs package (which is what provides the utf8x definition file) is
> basically unmaintained. Also since 2018 UTF-8 is the default encoding
> in LaTeX, so none of these packages should be necessary anymore.
> 
> Cheers, Henri

Is there a replacement for the ucs option \SetUnicodeOption{mathletters} ?
Without it the pdflatex build fails with message

    Error: Unicode character ∞ (U+221E) not set up for use with LaTeX

and equivalent messages for bullet (U+2219), square (U+25A1), en dash (U+2212) etc.
I tried adding additional commands

    \DeclareUnicodeCharacter{2212}{\ensuremath{\textendash}}
    ... and so on for each character it complained about ...

That allowed pdflatex to proceed further, but it still failed in the end
with fatal errors complaining about missing font maps for font grxn1000 and

    Warning: command \textendash invalid in math mode

So I have not yet managed to rebuild the gnuplot manual using
pdflatex or plain latex under TeXLive2024.

I'm happy enough using luatex instead;  we're already doing that for the
Japanese documentation.  And the distribution does include a pre-built copy
of gnuplot.pdf so most users would not need to rebuild it anyhow.

    Ethan

Re: Testing version of gnuplot 6.0.2

[Henri M. <he...@he...>]

On Sat, 2024-12-07 at 16:26 +0100, ASSI wrote:
> Ethan A Merritt writes:
> > I have placed a test package for release 6.0.2 in the "testing"
> > folder on SourceForge
> >     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> > 
> > The bug tracker has been pretty quiet lately so I hope most of the
> > issues in the 6.0
> > releases have been reported and now are fixed in 6.0.2.
> > 
> > Please report any build problems or other issues you find with the
> > test package.
> > If no problems arise I plan to use the same source files for a
> > release announcement
> > in a couple of weeks.
> 
> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation
> can no
> longer be created since
> 
>     \usepackage{ucs}
>     \usepackage[utf8x]{inputenc}
> 
> produces errors in internal TeX packages down the line.  I have not
> found an invocation that circumvents this problem yet…

Could you please try simply replacing these two lines by

    \usepackage[utf8]{inputenc}

The ucs package (which is what provides the utf8x definition file) is
basically unmaintained. Also since 2018 UTF-8 is the default encoding
in LaTeX, so none of these packages should be necessary anymore.

Cheers, Henri

> 
> 
> Regards,
> Achim.

Re: Testing version of gnuplot 6.0.2

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

ASSI writes:
>> Simplest work-around is to replace
>> 	PDFLATEX = pdflatex
>> with
>> 	PDFLATEX=luatex
>> in the .../docs/Makefile
>>
>> or do the same in the environment as part of the configuration process.
>
> OK, that should work, I'll report how that turns out.

OK, so that should be

 PDFLATEX=lualatex
 LATEX=dvilualatex

(I think), but then I get stuck with this wierd error when trying to create the PS file:

--8<---------------cut here---------------start------------->8---
' LuaTeX output 2024.12.08:2105' -> gnuplot.ps
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerifBold.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerifBold.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: ! [scanpage] invalid char 185 from font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
make: *** [Makefile:1140: gnuplot.ps] Error 1
--8<---------------cut here---------------end--------------->8---

and this one for the PDF:

--8<---------------cut here---------------start------------->8---
GNUPLOT_LIB=/mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.2/demo ../src/gnuplot.exe /mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.2/docs/plotstyles.gnu
*** buffer overflow detected ***: terminated
make: *** [Makefile:1065: pdf_figures] Error 127
--8<---------------cut here---------------end--------------->8---

Additionally, the parallel build is somehow broken again and I need to
compile in serial mode.


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

Re: Testing version of gnuplot 6.0.2

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

Ethan A Merritt writes:
>> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
>> longer be created since
>> 
>>     \usepackage{ucs}
>>     \usepackage[utf8x]{inputenc}
>> 
>> produces errors in internal TeX packages down the line.  I have not
>> found an invocation that circumvents this problem yet…
>
> Yes, I found that also. I reported it upstream.
> I believe the error in is the utf8x module but I haven't been able to figure
> out what changed from TeXLive2023 (which does work).

There was a specific ugly workaround to make some things in utf8x work (
especially in conjunction with ucs) even though development of that
package has apparently ceased.

> Simplest work-around is to replace
> 	PDFLATEX = pdflatex
> with
> 	PDFLATEX=luatex
> in the .../docs/Makefile
>
> or do the same in the environment as part of the configuration process.

OK, that should work, I'll report how that turns out.


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

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

Re: Testing version of gnuplot 6.0.2

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

On Saturday, 7 December 2024 07:26:48 PST ASSI wrote:

> Ethan A Merritt writes:
> > I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
> >
> > The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
> > releases have been reported and now are fixed in 6.0.2.
> >w
> > Please report any build problems or other issues you find with the test package.
> > If no problems arise I plan to use the same source files for a release announcement
> > in a couple of weeks.
> 
> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
> longer be created since
> 
>     \usepackage{ucs}
>     \usepackage[utf8x]{inputenc}
> 
> produces errors in internal TeX packages down the line.  I have not
> found an invocation that circumvents this problem yet…

Yes, I found that also. I reported it upstream.
I believe the error in is the utf8x module but I haven't been able to figure
out what changed from TeXLive2023 (which does work).

Simplest work-around is to replace
	PDFLATEX = pdflatex
with
	PDFLATEX=luatex
in the .../docs/Makefile

or do the same in the environment as part of the configuration process.

bash$     PDFLATEX=luatex ./configure

  Ethan
> 
> Regards,
> Achim.
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: Testing version of gnuplot 6.0.2

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

Ethan A Merritt writes:
> I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
> releases have been reported and now are fixed in 6.0.2.
>
> Please report any build problems or other issues you find with the test package.
> If no problems arise I plan to use the same source files for a release announcement
> in a couple of weeks.

With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
longer be created since

    \usepackage{ucs}
    \usepackage[utf8x]{inputenc}

produces errors in internal TeX packages down the line.  I have not
found an invocation that circumvents this problem yet…


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

Testing version of gnuplot 6.0.2

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

I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
releases have been reported and now are fixed in 6.0.2.

Please report any build problems or other issues you find with the test package.
If no problems arise I plan to use the same source files for a release announcement
in a couple of weeks.

Release notes appended below, or see

	gnuplot.sourceforge.net/ReleaseNotes_6_0_2.html

- Ethan


		Gnuplot Version 6.0.2 Release Notes
		===================================

This is the second incremental release for gnuplot stable version 6.0.
In addition to the usual minor bug fixes, it contains several new features
from the development version of gnuplot that didn't quite make it into
the initial version 6 release.

NEW (backported from development version)
-----------------------------------------
- plot style "with hsteps" enables a variety of new plot types
  For examples, see
	* https://gnuplot.info/demo_6.0/hsteps.html
	* https://gnuplot.info/demo_6.0/logic_timing.html
	* https://gnuplot.info/demo_6.0/rank_sequence.html

- 3D plot style "with filledcurves" provides additional flexibility in creating
  the family of plot styles that includes waterfall plots and fence plots.
  See
	* https://gnuplot.info/demo_6.0/waterfallplot.html

- Terminal input when gnuplot is linked against the BSD editline library
  now correctly handles UTF-8 characters.  UTF-8 input has always worked
  for configuration options readline=gnu or readline=builtin; now it also
  works for
      ./configure --with-readline=bsd

  This change should in particular benefit users of Debian and MacOS
  binaries, which are typically linked against the editline library.

- Polygons in a 3D plot ("splot ... with polygons") can use palette coloring
  and pm3d lighting.

- General binary keyword option "blank=NaN" facilitates using binary input
  data for plot styles that would require blank lines in a text input data
  stream. See
	* https://gnuplot.info/demo_6.0/binary_polygon.html

- "linestyle variable" is accepted as a color specifier in plot commands.
  The primary distinction between this as "linecolor variable" is that
  linestyle properties are cleared by the next "reset" command.
  This allows definition of a temporary color sequence affected only one plot.

CHANGES
-------
- Local variables are reimplemented to provide a better-defined scope
  and faster evaluation of function blocks.
- Existing plot styles steps, histeps, fsteps, and fillsteps are
  reimplemented to use the new hsteps code.
- Boxplot outlier position (horizontal displacement) is controlled by "set jitter".
- The content of $GPVAL_LAST_MULTIPLOT is appended to the output from "save"
  so that loading the saved file regenerates a full multiplot rather than
  only the final component.

FIXES
-----
- reworked generation of logscale axis tic marks                 (Bugs 2372 2717)
- Do not save extraneous commands to $GPVAL_LAST_MULTIPLOT       (Bug 2714)
- svg: modify gnuplot_svg.js to work in local standalone mode    (Bug 2715)
- wxt: release per-thread font data before entering "persist"    (Bug 2693)
- "set table": honor "nosurface" keyword in splot
- "set table": honor "set format z" when z is printed from plot
- better contouring near the edge of a z-clipped surface
- handle mousing of logscale axes in inactive plot windows       (Bug 2723)
- "set tics scale" does not change other axis tick properties    (Bug 2724)
- points with variable color value NaN should not be drawn       (Bug 2737)
- "set term tikz nostandalone" should suppress the latex wrapper (Bug 2740)
- handle unusual case of intersecting pm3d surfaces              (Bug 2744)

KNOWN ISSUES
------------
- Support for replot and pan/zoom mouse operations in multiplot mode
  is still incomplete. Expect further improvement in subsequent releases.
 

Re: possible overrun in wxt_gui.c

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

On Monday, 2 December 2024 03:43:01 PST Jun T wrote:
> When compiling wxt_gui.cpp, clang (on my Mac) gives warnings,
> in function wxt_update_mousecoords_in_window(), that strongly
> recommend using nsprintf() instead of sprintf().

Applied. Thanks

> 
> While trying to silence this warning, I've found that there
> is a possibility of overrun.
> 
> The format "%10g" (equivalent to "%10.6g") may use up to 13
> characters: "-1.23456e+123". So the buffer mouse_format[]
> may be overrun by the last sprintf(m, "y2=...",...).
> 
> In the patch below I removed some extra spaces in the format
> so that the string would look like (but not exactly the same
> as) the one in the status bar of the active window.
> 
> The condition 'left > 0' is added just in case "%10g" occupies
> more than 13 characters (I guess this should never happen).
> 
> 
> diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
> index 2cd096f01..d5249df58 100644
> --- a/src/wxterminal/wxt_gui.cpp
> +++ b/src/wxterminal/wxt_gui.cpp
> @@ -129,6 +129,9 @@ extern "C" {
>  #ifdef HAVE_SYS_SELECT_H
>  # include <sys/select.h>
>  #endif
> +#ifdef HAVE_WORKING_FORK
> +# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
> +#endif
>  }
>  
>  /* Interactive toggle control variables
> @@ -3272,29 +3275,17 @@ static void wxt_update_mousecoords_in_window(int number, int mx, int my)
>  	if ((window = wxt_findwindowbyid(number))) {
>  
>  		/* TODO: rescale mx and my using stored per-plot scale info */
> -		char mouse_format[66];
> +		char mouse_format[67]; // %10g may use at most 13 chars
>  		char *m = mouse_format;
> -		double x, y, x2, y2;
> -
> -		if (window->axis_mask & (1<<0)) {
> -			x = mouse_to_axis(mx, &window->axis_state[0]);
> -			sprintf(m, "x=  %10g   %c", x, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<1)) {
> -			y = mouse_to_axis(my, &window->axis_state[1]);
> -			sprintf(m, "y=  %10g   %c", y, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<2)) {
> -			x2 = mouse_to_axis(mx, &window->axis_state[2]);
> -			sprintf(m, "x2=  %10g   %c", x2, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<3)) {
> -			y2 = mouse_to_axis(my, &window->axis_state[3]);
> -			sprintf(m, "y2=  %10g %c", y2, '\0');
> -			m += 15;
> +		int left = sizeof(mouse_format);
> +		const char *name[4] = { "x", "y", "x2", "y2" };
> +		for (int i=0; i<4 && left > 0; ++i) {
> +			if (window->axis_mask & (1<<i)) {
> +				int n = snprintf(m, left, "%s=% -10g ", name[i],
> +							mouse_to_axis(mx, &window->axis_state[i]));
> +				m += n;
> +				left -= n;	// left<=0 if truncated (should not happen)
> +			}
>  		}
>  
>  		FPRINTF((stderr,"wxt : update mouse coords in window %d\n",number));

possible overrun in wxt_gui.c

[Jun T <tak...@kb...>]

When compiling wxt_gui.cpp, clang (on my Mac) gives warnings,
in function wxt_update_mousecoords_in_window(), that strongly
recommend using nsprintf() instead of sprintf().

While trying to silence this warning, I've found that there
is a possibility of overrun.

The format "%10g" (equivalent to "%10.6g") may use up to 13
characters: "-1.23456e+123". So the buffer mouse_format[]
may be overrun by the last sprintf(m, "y2=...",...).

In the patch below I removed some extra spaces in the format
so that the string would look like (but not exactly the same
as) the one in the status bar of the active window.

The condition 'left > 0' is added just in case "%10g" occupies
more than 13 characters (I guess this should never happen).


diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
index 2cd096f01..d5249df58 100644
--- a/src/wxterminal/wxt_gui.cpp
+++ b/src/wxterminal/wxt_gui.cpp
@@ -129,6 +129,9 @@ extern "C" {
 #ifdef HAVE_SYS_SELECT_H
 # include <sys/select.h>
 #endif
+#ifdef HAVE_WORKING_FORK
+# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
+#endif
 }
 
 /* Interactive toggle control variables
@@ -3272,29 +3275,17 @@ static void wxt_update_mousecoords_in_window(int number, int mx, int my)
 	if ((window = wxt_findwindowbyid(number))) {
 
 		/* TODO: rescale mx and my using stored per-plot scale info */
-		char mouse_format[66];
+		char mouse_format[67]; // %10g may use at most 13 chars
 		char *m = mouse_format;
-		double x, y, x2, y2;
-
-		if (window->axis_mask & (1<<0)) {
-			x = mouse_to_axis(mx, &window->axis_state[0]);
-			sprintf(m, "x=  %10g   %c", x, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<1)) {
-			y = mouse_to_axis(my, &window->axis_state[1]);
-			sprintf(m, "y=  %10g   %c", y, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<2)) {
-			x2 = mouse_to_axis(mx, &window->axis_state[2]);
-			sprintf(m, "x2=  %10g   %c", x2, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<3)) {
-			y2 = mouse_to_axis(my, &window->axis_state[3]);
-			sprintf(m, "y2=  %10g %c", y2, '\0');
-			m += 15;
+		int left = sizeof(mouse_format);
+		const char *name[4] = { "x", "y", "x2", "y2" };
+		for (int i=0; i<4 && left > 0; ++i) {
+			if (window->axis_mask & (1<<i)) {
+				int n = snprintf(m, left, "%s=% -10g ", name[i],
+							mouse_to_axis(mx, &window->axis_state[i]));
+				m += n;
+				left -= n;	// left<=0 if truncated (should not happen)
+			}
 		}
 
 		FPRINTF((stderr,"wxt : update mouse coords in window %d\n",number));

Re: build fails: pango_cairo_font_map_set_default() not declared

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

On Sunday, 1 December 2024 20:39:05 PST Jun T wrote:

Applied. Thanks.

> After the commit:
> 
> commit 35643d86af5f41011723c7363172628283c0b96d
>     wxt: release per-thread font data structures before forking
> 
> build fails on my Mac (with clang) as:
> wxterminal/wxt_gui.cpp:3868:3: error: use of undeclared identifier 'pango_cairo_font_map_set_default'
> 
> We need to include <pango/pangocairo.h> either in wxt_gui.cpp (as in
> the patch below) or in wxt_gui.h (whichever you prefer).
> 
> 
> diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
> index 2cd096f01..35528e2cb 100644
> --- a/src/wxterminal/wxt_gui.cpp
> +++ b/src/wxterminal/wxt_gui.cpp
> @@ -129,6 +129,9 @@ extern "C" {
>  #ifdef HAVE_SYS_SELECT_H
>  # include <sys/select.h>
>  #endif
> +#ifdef HAVE_WORKING_FORK
> +# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
> +#endif
>  }
>  
>  /* Interactive toggle control variables
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!mxrckcjoWwlBc2lLsGWcarM6eKyjY6vbi-He9_m62jldT9Pg9v11CzSDtz6mjPaFe22f7UtYjVkhwYoF3CX69bAJJWo$ 
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

build fails: pango_cairo_font_map_set_default() not declared

[Jun T <tak...@kb...>]

After the commit:

commit 35643d86af5f41011723c7363172628283c0b96d
    wxt: release per-thread font data structures before forking

build fails on my Mac (with clang) as:
wxterminal/wxt_gui.cpp:3868:3: error: use of undeclared identifier 'pango_cairo_font_map_set_default'

We need to include <pango/pangocairo.h> either in wxt_gui.cpp (as in
the patch below) or in wxt_gui.h (whichever you prefer).


diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
index 2cd096f01..35528e2cb 100644
--- a/src/wxterminal/wxt_gui.cpp
+++ b/src/wxterminal/wxt_gui.cpp
@@ -129,6 +129,9 @@ extern "C" {
 #ifdef HAVE_SYS_SELECT_H
 # include <sys/select.h>
 #endif
+#ifdef HAVE_WORKING_FORK
+# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
+#endif
 }
 
 /* Interactive toggle control variables

Re: update x-y ranges?

[Leo B. <leo...@um...>]

On Thu, Nov 28 2024, Hans-Bernhard Bröker <HBB...@t-...> wrote:

> Am 28.11.2024 um 21:05 schrieb Leo Butler:
>
>> w filledcurves~a xy=~a,~a lc ~a axis ~a
>> (the ~a are place holder for values, like %s in a printf template).
>> 1. Was this syntax ever supported by gnuplot? If so, what did it do
>> and
>>     how can the same effect be achieved in more recent gnuplots?
>
> I think that would depend on what the very first of those ~a thingies
> expands to.
>
> The documented syntax and the existing demos both suggest the 'xy='
> part to come rather immediately after "filledcurves".  The syntax only
> allows keywords like 'above' or 'below' in that place.  See "help with
> filledcurves" on current git head:
>
>> Syntax for 2D:
>>      plot f(x) with filledcurves [option]
>>      plot DATA using 1:2    with filledcurves [option]
>>      plot DATA using 1:2:3  with filledcurves [option]
>>  where the option can be one of the following
>>      closed
>>      {above|below} x1 x2  y r=<a> xy=<x>,<y>
>>      between

Ahhh, thank you. I did not understand that the 'xy=' clause was an
option for 'filledcurves'.

After looking at the git log more carefully, the error was introduced a
couple years. I have done as you suggested and corrected the error.

Thanks, Hans-Bernhard and Evan, for your help.

Best regards,
Leo

Re: update x-y ranges?

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

On Thursday, 28 November 2024 12:05:39 PST Leo Butler wrote:
> Hi,
> 
> I am not sure if this is the right venue, please re-direct me if it is not.
> 
> In the Maxima package draw [1], one finds a snippet of gnuplot code that
> goes like this:
> 
> w filledcurves~a xy=~a,~a lc ~a axis ~a
> 
> (the ~a are place holder for values, like %s in a printf template).
> 
> According to git, this line was checked in on the first commit of the
> package 18 years ago. We got a bug report yesterday [2] that the part
> 
> xy=....
> 
> is causing an error.
> 
> I have attached the Gnuplot file generated by a trimmed down example
> extracted from that bug report.
> 
> My questions are:
> 
> 1. Was this syntax ever supported by gnuplot? If so, what did it do and
>    how can the same effect be achieved in more recent gnuplots?

It is still supported.  See "help filledcurves".

The error is that this option must immediately follow the "with filledcurves".
Your script sticks an unrelated option (fillstyle solid 0.1) in between the
plot style and the plotstyle-specific options.

After swapping the position of "fillstyle solid 0.1" and "xy=-1.0,0.0" in the
plot command, the script runs without error in both gnuplot 5 and gnuplot 6.

Eighteen years ago  would have been early gnuplot version 4, I think, and 
many of the options in your script did not exist, including "fillstyle solid 0.1".

	Ethan

> 2. Assuming the syntax was supported, when was support removed?
> TIA,
> Leo
> 
> 
> [1] - https://urldefense.com/v3/__https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp*l902__;Iw!!K-Hz7m0Vt54!lkzvVp1SpWsUImWc4fB3wG8IS2eDAXgREdoZNLaZ-T2LJ0Qf3VWTarY4SQx8aNSFweyKiYY_3BJzMmM2ggZ5KTkdl_MsIA$ 
> 
> [2] - https://urldefense.com/v3/__https://sourceforge.net/p/maxima/bugs/4424/__;!!K-Hz7m0Vt54!lkzvVp1SpWsUImWc4fB3wG8IS2eDAXgREdoZNLaZ-T2LJ0Qf3VWTarY4SQx8aNSFweyKiYY_3BJzMmM2ggZ5KTnC6B_VdA$ 
> 
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: update x-y ranges?

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

Am 28.11.2024 um 21:05 schrieb Leo Butler:

> w filledcurves~a xy=~a,~a lc ~a axis ~a
> 
> (the ~a are place holder for values, like %s in a printf template).
> 
> 
> 1. Was this syntax ever supported by gnuplot? If so, what did it do and
>     how can the same effect be achieved in more recent gnuplots?

I think that would depend on what the very first of those ~a thingies 
expands to.

The documented syntax and the existing demos both suggest the 'xy=' part 
to come rather immediately after "filledcurves".  The syntax only allows 
keywords like 'above' or 'below' in that place.  See "help with 
filledcurves" on current git head:

> Syntax for 2D:
> 
>      plot f(x) with filledcurves [option]
>      plot DATA using 1:2    with filledcurves [option]
>      plot DATA using 1:2:3  with filledcurves [option]
> 
>  where the option can be one of the following
> 
>      closed
>      {above|below} x1 x2  y r=<a> xy=<x>,<y>
>      between

That would indicate this fraction of the command line rejected by 
gnuplot (from [1])

	w filledcurves fillstyle solid 0.1 xy=-1.0,0.0

would probably still work if it hat been

	w filledcurves xy=-1.0,0.0 fillstyle solid 0.1

instead.

> 2. Assuming the syntax was supported, when was support removed?

That particular syntax was never explicitly supported.  It may just have 
happened to work anyway.  And now it doesn't.

> [1] - https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp#l902

update x-y ranges?

[Leo B. <leo...@um...>]

Hi,

I am not sure if this is the right venue, please re-direct me if it is
not.

In the Maxima package draw [1], one finds a snippet of gnuplot code that
goes like this:

w filledcurves~a xy=~a,~a lc ~a axis ~a

(the ~a are place holder for values, like %s in a printf template).

According to git, this line was checked in on the first commit of the
package 18 years ago. We got a bug report yesterday [2] that the part

xy=....

is causing an error.

I have attached the Gnuplot file generated by a trimmed down example
extracted from that bug report.

My questions are:

1. Was this syntax ever supported by gnuplot? If so, what did it do and
   how can the same effect be achieved in more recent gnuplots?
2. Assuming the syntax was supported, when was support removed?

TIA,
Leo


[1] - https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp#l902

[2] - https://sourceforge.net/p/maxima/bugs/4424/

Re: format of win/README-Windows-jp.txt

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

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2024/08/08 木 04:34
> Subject: Re: format of win/README-Windows-jp.txt
> 
> 
> On Sunday, 4 August 2024 17:05:32 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > 
> > README-Windows-ja.txt is for users to read and for the binary distribution.
> > README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
> > Only README-Windows-ja.txt is needed and README.win-ja is not necessary.
> > 
> > 
> > > All three files have been converted to UTF-8 in the development branch.
> > > Should they be reverted to Shift-JIS?
> > 
> > It is better to be reverted. Sorry for my previous incorrect writing.
> > 
> > Tatsuro
> 
> I have converted  README-Windows-ja.txt from UTF-8 back to Shift-JIS
> in branch-6-0-stable.
> 
> Please check that this worked correctly, since I cannot read Shift-JIS files here.
> 
> thanks,
> 
> 	Ethan
> 
Ethan

Thanks for your treatment.
I  have confirmed that it will fix the glitch.

Tatsuro

Re: format of win/README-Windows-jp.txt

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

On Sunday, 4 August 2024 17:05:32 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> 
> README-Windows-ja.txt is for users to read and for the binary distribution.
> README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
> Only README-Windows-ja.txt is needed and README.win-ja is not necessary.
> 
> 
> > All three files have been converted to UTF-8 in the development branch.
> > Should they be reverted to Shift-JIS?
> 
> It is better to be reverted. Sorry for my previous incorrect writing.
> 
> Tatsuro

I have converted  README-Windows-ja.txt from UTF-8 back to Shift-JIS
in branch-6-0-stable.

Please check that this worked correctly, since I cannot read Shift-JIS files here.

thanks,

	Ethan

Re: Re: format of win/README-Windows-jp.txt

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

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2024/08/04 日 03:37
> Subject: Re: format of win/README-Windows-jp.txt
> 
> 
> On Thursday, 1 August 2024 22:01:46 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > 
> > When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
> > The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
> > After converting the file to Shift_JIS, the characters are no longer garbled.
> > If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
> > it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.
> > 
> > Tatsuro
> 
> I received advice, perhaps incorrect, that the Japanese localization of
> Windows can now read UTF-8 files.
> Please help me to understand exactly when, and for which files,
> it is still necessary to provide Shift-JIS encoding.
> 
> As of December 2023 there were 3 files in the repository using Shift-JIS
>     ./win/README-Windows-ja.txt
>     ./src/win/README.win-ja
>     ./win/Copyright-ja.txt
> 
> I thought that the first file (README-Windows-ja.txt) was for users to read.
> I thought that the second file (README.win-ja) was for the binary distribution.
> Is this wrong?
> Are both README files needed?
> Do both of them need to be in Shift-JIS for the installer to work?
> 
> All three files have been converted to UTF-8 in the development branch.
> Should they be reverted to Shift-JIS?
> 
>     Ethan   
> 

> I thought that the first file (README-Windows-ja.txt) was for users to read.
> I thought that the second file (README.win-ja) was for the binary distribution.
> Is this wrong?
> Are both README files needed?

README-Windows-ja.txt is for users to read and for the binary distribution.
README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
Only README-Windows-ja.txt is needed and README.win-ja is not necessary.


> All three files have been converted to UTF-8 in the development branch.
> Should they be reverted to Shift-JIS?

It is better to be reverted. Sorry for my previous incorrect writing.

Tatsuro

Re: format of win/README-Windows-jp.txt

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

On Thursday, 1 August 2024 22:01:46 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> 
> When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
> The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
> After converting the file to Shift_JIS, the characters are no longer garbled.
> If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
> it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.
> 
> Tatsuro

I received advice, perhaps incorrect, that the Japanese localization of
Windows can now read UTF-8 files.
Please help me to understand exactly when, and for which files,
it is still necessary to provide Shift-JIS encoding.

As of December 2023 there were 3 files in the repository using Shift-JIS
    ./win/README-Windows-ja.txt
    ./src/win/README.win-ja
    ./win/Copyright-ja.txt

I thought that the first file (README-Windows-ja.txt) was for users to read.
I thought that the second file (README.win-ja) was for the binary distribution.
Is this wrong?
Are both README files needed?
Do both of them need to be in Shift-JIS for the installer to work?

All three files have been converted to UTF-8 in the development branch.
Should they be reverted to Shift-JIS?

    Ethan   


-- 
Ethan A Merritt

format of win/README-Windows-jp.txt

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

When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
After converting the file to Shift_JIS, the characters are no longer garbled.
If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.

Tatsuro

Typo in gnuplot-6.0.1/docs/gnuplot.pdf

[Chris M. <mo...@nc...>]

Sorry if this is wrong address, but...

On page 52 of that doc, there's a very novel new word: "declaragion."

Is that how you declare a contagion?

Just thought someone ought to know...

Gnuplot 6.0.1 release

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

The gnuplot version 6.0.1 release is now available as a source tarball
for download from SourceForge

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

                Gnuplot Version 6.0.1 Release Notes
                ===================================

Version 6 introduced extensions to the gnuplot command language,
support for new output protocols, and additional plotting styles.
Backward compatibility is given high priority in gnuplot development,
so users should find no significant changes required for techniques or
code that written for gnuplot version 5.

Patchlevel release 6.0.1 repairs several bugs found in the initial release
of version 6, most notably related to error handling by the wxt terminal.

Gnuplot development is tracked in a git repository on SourceForge.
You can generate a complete history of changes using "git log"
after downloading:

    git clone -b branch-6-0-stable git://git.code.sf.net/p/gnuplot/gnuplot-main
    git log

Release Notes date:  18-May-2024

                        Changes in 6.0.1
                        ================

* CHANGE Use of data source '-' inside a multiplot is an error; use a local datablock instead
* CHANGE gd: scale "dot" (pointtype 0) by current linewidth             Bug 2690
* FIX    configure script modified to accommodate Fedora dependencies   Bug 2706
* FIX    mp: configure --with-metapost failed to include mp terminal
* FIX    empty field in csv file should not generate a tic label        Bug 2667 2672
* FIX    Do not autoscale or extend axis ranges while zooming           Bug 2679 2680
* FIX    svg: set default fill properties for depth-sorted pm3d objects
* FIX    x11: Empirical correction for bad rotation of enhanced text    Bug 2661
* FIX    wxt: Add exception handler for mouse event processing          Bug 2680 2683
* FIX    wxt: make right-mouse zoom box independent of terminal scaling Bug 2578
* FIX    regression: border color of objects with fillstyle "empty"     Bug 2686
* FIX    "set colorbox border {<lt>}" parsing error
* FIX    gd x11:  very short arrows were not drawn at all               Bug 2690
* FIX    qt wxt x11: "set term" from a script causes next pause to fail Bug 2703
* FIX    tikz: fix use of palettes with a fixed number of colors        Bug 2706
* FIX    "stats ... name FOO" Do not delete existing variables FOO_*    Bug 2695
* FIX    order-dependent parsing of 2D plots with "fs solid fc variable"


    Ethan