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

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

Bug #2704

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

For #bug 2704 ( outdated info in readme_windows.txt), 
I submitted small modifications to README-windows.txt and README-windows-ja.txt.

Tatsuro

Re: Information on a Gnuplot version

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

Am 23.04.2024 um 23:53 schrieb Spencer Delorenzo:
> Hello,

> Per the subject, I wanted to ask about an early version of Gnuplot. I tried 3.7.3 on my IBM 5150, and it hangs. 

Did you just run an existing binary, or build your own?  I ask because 
at least my 3.7.3 binary package we still provide on SourceForge is 
built for 286 or higher, and expects a floating-point coprocessor.  Most 
binaries of that era did.

> Might be the 8088, 

Those are of course things which that machine does not have.

So at the minimum you would have to build your own.  Compilers that can 
do it are out there.  E.g. OpenWatcom

> but I wanted to ask which version is the latest that supports it, and if you’d have a copy of it.

I see no particularly strong reason why gnuplot versions of the 1990s 
should not work on a 5150 with 64 KiB RAM.  Newer ones will run into 
memory size problems, but the old ones worked just fine under MS-DOS, 
even on 16-bit machines.

Old version can still be found in several sites archiving such things. 
Funet.fi, e.g. still has source tarballs of versions 3.2 to 3.5.

Re: Information on a Gnuplot version

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

Gnuplot 3.7 is the first one I ever used!

I suspect that there isn't any reason why all gnuplot versions shouldn't
work on your old hardware. It's more a question of where you got the
binary and/or how you're building it. So... where did the binary you're
running come from? And I would try out simple gnuplot terminals first.
Do "set terminal dumb 80 40", and then make your plot. Does that work?
If so, try out the more complex terminals, and go from there.

Information on a Gnuplot version

[Spencer D. <aut...@gm...>]

Hello,
Per the subject, I wanted to ask about an early version of Gnuplot. I tried 3.7.3 on my IBM 5150, and it hangs. Might be the 8088, but I wanted to ask which version is the latest that supports it, and if you’d have a copy of it.

Thanks

New plotting style 'marks', 'linesmarks' and new object 'mark'

[本吉 弘岐 <him...@ic...>]

Hello,

I have created a ticket in "Patches" to add a new plotting style, 'marks'. This is a 2D plotting style that draws marks represented by user-defined polygons or polylines at specified coordinates. The 'linesmarks' style corresponding to linespoints and the 'mark' object for placing individual marks are also proposed in it. For more information, please see the proposal documentation attached to the "Patches" ticket page.

https://sourceforge.net/p/gnuplot/patches/815/

I would appreciate your input on its implementation.

Re: mp term missing in gnuplot 6.0?

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

On Saturday, 6 April 2024 05:57:00 PDT Allin Cottrell wrote:
> I just built gnuplot 6.0 on Linux, passing --with-metapost to 
> configure. In the output from configure I see "metapost : yes", but 
> on running the program after "make install" there's no mp terminal 
> available:
> 
> gnuplot> set term mp
> 
> Terminal type is now 'unknown'

Stupid typo in term.h
#ifdef WITH_METAPOST  should be #ifdef HAVE_METAPOST

Fixed now

    Ethan

Re: mp term missing in gnuplot 6.0?

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

On Sat, Apr 6, 2024 at 6:24 PM Ethan Merritt <me...@uw...> wrote:
>
> On Saturday, 6 April 2024 05:57:00 PDT Allin Cottrell wrote:
> > I just built gnuplot 6.0 on Linux, passing --with-metapost to
> > configure. In the output from configure I see "metapost : yes", but
> > on running the program after "make install" there's no mp terminal
> > available:
> >
> > gnuplot> set term mp
> >
> > Terminal type is now 'unknown'
>
> Stupid typo in term.h
> #ifdef WITH_METAPOST  should be #ifdef HAVE_METAPOST
>
> Fixed now

Thanks, Ethan. I was beginning to think that mp term might not just be
deprecated but actually removed altogether in 6.0. Which would have
meant there was a bug of sorts in the configure script, since it says
to pass --with-metapost if you want mp term.

Allin Cottrell

mp term missing in gnuplot 6.0?

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

I just built gnuplot 6.0 on Linux, passing --with-metapost to 
configure. In the output from configure I see "metapost : yes", but 
on running the program after "make install" there's no mp terminal 
available:

gnuplot> set term mp

Terminal type is now 'unknown'

-- 
Allin Cottrell
Professor Emeritus
Wake Forest University

Re: IPv6 access to gnuplot.info is broken [was Re: www.gnuplot.info lagging]

[Philipp K. J. <ja...@ie...>]

On Tue, 20 Feb 2024 00:28:02 +0000
Tait <gnu...@t4...> wrote:

I reached out to Clark on LinkedIn, and heard 
back from him.. He seems to understand what's
going on; I expect he will be looking into it.

Best,

		Ph.


> I understand how any of this works, but without administrative
> control of the webservers in question -- or failing that, at
> least the DNS or domain registration for gnuplot.info --
> there's not much that can be done.
> 
> Back in 2018, it appears gnuplot.info was a vhost to
> sourceforge, meaning there was no independent web server for
> gnuplot.info; it just pointed users to sourceforge by a
> different name. SourceForge has moved their public-facing
> addresses to CloudFlare (specifically,
> projects.sourceforge.net.cdn.cloudflare.net). And in fact,
> 216.105.38.10 is still that same IP from 2018, so SourceForge
> has moved on and apparently not told you (or anybody else).
> What would be ideal is to make gnuplot.info a CNAME to
> projects.sourceforge.net.cdn.cloudflare.net, but then
> SourceForge would have to have gnuplot.info as a SAN on their
> TLS certificates, and it appears they do not. Maybe someone
> could ask SourceForge if they still support CNAME redirection
> for giving projects a "friendly" DNS name, since they
> apparently did back in 2018. Make sure to mention TLS since
> changing DNS won't do any good unless SourceForge also
> updates their TLS certificates.
> 
> On the IPv6 side, 2001:468:c80:a202:0:b074:0:c082 belongs to
> Virginia Tech and seems to be part of some defunct "funnel"
> project on which I can't find any information. In fact all of
> https://www.vtti.vt.edu/ seems to be dead. That address is
> certainly outdated, and as with IPv4, the correct address
> should probably be projects.sourceforge.net.cdn.cloudflare.net
> but TLS gets in the way of the naive approach to that.
> 
> The domain (gnuplot.info that is) seems to be held through
> Hover(.com) who apparently resells Tucows registration.
> Administrative contact information is "redacted for privacy",
> but https://tieredaccess.
> com/contact/1f00f497-18bb-4578-95c4-43ff3950d7ba purports to be a way
> to contact the domain owner. (I've added a space in there so the link
> doesn't get auto-harvested.) It's common for domain registration
> contact info to be bogus or ignored though, so if you have any other
> ways to reach whoever owns/controls gnuplot.info, I'd try to pursue
> those. If there's no other response, you could plead with Hover
> support to try to get a hold of their customer and maybe
> they'd be sympathetic and try whatever contact information
> they have on file.
> 
> 
> 
> Ethan A Merritt <me...@uw...> said (on 2024/02/17):
> > On Friday, 16 February 2024 14:42:51 PST Cottrell, Allin wrote:  
> > > I noticed today that the "gnuplot homepage" seems to be more than
> > > a year out of date: the "latest release" there is 5.4.5 from
> > > October 2022. The "gnuplot download" page lags even more, with
> > > the "latest" being 5.4.2 (June 2021).
> > > 
> > > Allin Cottrell  
> 
> > ...
> > If anyone here understands how any of this works or how to fix it,
> > please speak up! 
> > 
> > I tried to forward it to the last Email address I had for Clark
> > Gaylord but it bounced.
> > 
> > 	Ethan  
> 
> ...
> 
> > It appears that the A and AAAA DNS records for "www.gnuplot.info"
> > are pointing to completely different webservers.
> > 
> > The server that's answering IPv4 requests seems to be up-to-date,
> > with information about Gnuplot 6.0. It reports a Server header of
> > "nginx", and a Last-Modified date for the front page of December
> > 29, 2023.
> > 
> > The server that's answering IPv6 requests, on the other hand, is
> > substantially out-of-date. The front page shows Gnuplot 5.4 as the
> > latest release, with a Last-Modified date of October 2, 2022. New
> > pages such as http://www.gnuplot.info/ReleaseNotes_6_0_0.html all
> > return 404 errors. The server also reports its version as Apache
> > 2.2.17, which is from 2010.
> > 
> > This affects everyone with a working IPv6 setup. If it's not
> > possible to find and update the server that's serving the v6
> > traffic, then I think it would be best to remove the AAAA DNS
> > record so that everyone can see the updated version of the site. v6
> > support isn't just limited to a few people anymore.
> > 
> > Thanks,
> > 
> > Andrew  
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: IPv6 access to gnuplot.info is broken [was Re: www.gnuplot.info lagging]

[Tait <gnu...@t4...>]

I understand how any of this works, but without administrative
control of the webservers in question -- or failing that, at
least the DNS or domain registration for gnuplot.info --
there's not much that can be done.

Back in 2018, it appears gnuplot.info was a vhost to
sourceforge, meaning there was no independent web server for
gnuplot.info; it just pointed users to sourceforge by a
different name. SourceForge has moved their public-facing
addresses to CloudFlare (specifically,
projects.sourceforge.net.cdn.cloudflare.net). And in fact,
216.105.38.10 is still that same IP from 2018, so SourceForge
has moved on and apparently not told you (or anybody else).
What would be ideal is to make gnuplot.info a CNAME to
projects.sourceforge.net.cdn.cloudflare.net, but then
SourceForge would have to have gnuplot.info as a SAN on their
TLS certificates, and it appears they do not. Maybe someone
could ask SourceForge if they still support CNAME redirection
for giving projects a "friendly" DNS name, since they
apparently did back in 2018. Make sure to mention TLS since
changing DNS won't do any good unless SourceForge also
updates their TLS certificates.

On the IPv6 side, 2001:468:c80:a202:0:b074:0:c082 belongs to
Virginia Tech and seems to be part of some defunct "funnel"
project on which I can't find any information. In fact all of
https://www.vtti.vt.edu/ seems to be dead. That address is
certainly outdated, and as with IPv4, the correct address
should probably be projects.sourceforge.net.cdn.cloudflare.net
but TLS gets in the way of the naive approach to that.

The domain (gnuplot.info that is) seems to be held through
Hover(.com) who apparently resells Tucows registration.
Administrative contact information is "redacted for privacy",
but https://tieredaccess. com/contact/1f00f497-18bb-4578-95c4-43ff3950d7ba
purports to be a way to contact the domain owner. (I've added
a space in there so the link doesn't get auto-harvested.)
It's common for domain registration contact info to be bogus
or ignored though, so if you have any other ways to reach
whoever owns/controls gnuplot.info, I'd try to pursue those.
If there's no other response, you could plead with Hover
support to try to get a hold of their customer and maybe
they'd be sympathetic and try whatever contact information
they have on file.



Ethan A Merritt <me...@uw...> said (on 2024/02/17):
> On Friday, 16 February 2024 14:42:51 PST Cottrell, Allin wrote:
> > I noticed today that the "gnuplot homepage" seems to be more than a
> > year out of date: the "latest release" there is 5.4.5 from October
> > 2022. The "gnuplot download" page lags even more, with the "latest"
> > being 5.4.2 (June 2021).
> > 
> > Allin Cottrell

> ...
> If anyone here understands how any of this works or how to fix it,
> please speak up! 
> 
> I tried to forward it to the last Email address I had for Clark Gaylord
> but it bounced.
> 
> 	Ethan

...

> It appears that the A and AAAA DNS records for "www.gnuplot.info" are
> pointing to completely different webservers.
> 
> The server that's answering IPv4 requests seems to be up-to-date, with
> information about Gnuplot 6.0. It reports a Server header of "nginx", and a
> Last-Modified date for the front page of December 29, 2023.
> 
> The server that's answering IPv6 requests, on the other hand, is
> substantially out-of-date. The front page shows Gnuplot 5.4 as the latest
> release, with a Last-Modified date of October 2, 2022. New pages such as
> http://www.gnuplot.info/ReleaseNotes_6_0_0.html all return 404 errors. The
> server also reports its version as Apache 2.2.17, which is from 2010.
> 
> This affects everyone with a working IPv6 setup. If it's not possible to
> find and update the server that's serving the v6 traffic, then I think it
> would be best to remove the AAAA DNS record so that everyone can see the
> updated version of the site. v6 support isn't just limited to a few people
> anymore.
> 
> Thanks,
> 
> Andrew

IPv6 access to gnuplot.info is broken [was Re: www.gnuplot.info lagging]

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

On Friday, 16 February 2024 14:42:51 PST Cottrell, Allin wrote:
> I noticed today that the "gnuplot homepage" seems to be more than a
> year out of date: the "latest release" there is 5.4.5 from October
> 2022. The "gnuplot download" page lags even more, with the "latest"
> being 5.4.2 (June 2021).
> 
> Allin Cottrell

I didn't realize the message appended below had reached only the info mailing list,
not gnuplot-beta.

If anyone here understands how any of this works or how to fix it,
please speak up! 

I tried to forward it to the last Email address I had for Clark Gaylord
but it bounced.

	Ethan

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Problem with gnuplot.info website on IPv6

From:	Andrew Rodland <an...@cl...>
To:	gnu...@li...
Date:	25/01/2024 19:31
Hi all,

It appears that the A and AAAA DNS records for "www.gnuplot.info" are
pointing to completely different webservers.

The server that's answering IPv4 requests seems to be up-to-date, with
information about Gnuplot 6.0. It reports a Server header of "nginx", and a
Last-Modified date for the front page of December 29, 2023.

The server that's answering IPv6 requests, on the other hand, is
substantially out-of-date. The front page shows Gnuplot 5.4 as the latest
release, with a Last-Modified date of October 2, 2022. New pages such as
http://www.gnuplot.info/ReleaseNotes_6_0_0.html all return 404 errors. The
server also reports its version as Apache 2.2.17, which is from 2010.

This affects everyone with a working IPv6 setup. If it's not possible to
find and update the server that's serving the v6 traffic, then I think it
would be best to remove the AAAA DNS record so that everyone can see the
updated version of the site. v6 support isn't just limited to a few people
anymore.

Thanks,

Andrew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%