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

Re: Pre-release testing version of gnuplot 6.0.4

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

Dear Ethan,

This compiles properly on macOS. I placed a universal binary here (all
libraries statically linked):
https://csml.northwestern.edu/Download/Gnuplot/gnuplot-6.0.4-qt5-universal.pkg,
so that others can test it as well.

I did not compile without mouse support, so I cannot speak to the issue
Achim identified.

Regards,

Erik


On Fri, Dec 5, 2025 at 8:14 PM Ethan A Merritt <me...@uw...> wrote:

> I have placed a testing version of the source release
> package for gnuplot 6.0.4 on the "testing" section of the
> SourceForge download site.
>
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> Nothing major to look for in this release, but it does include a number
> of recent bug fixes. The configure script and various header files
> have been modified to allow use with C compilers that enforce c23
> syntax by default. This should not affect use with older compilers.
>
> My tentative plan is to announce the actual release in about
> two weeks (the week of 15 December).  That can be pushed back
> if you find any problems or want to suggest inclusion
> of a bug-fix from the development version that was not yet
> backported.
>
> Brief release notes below, or see
>      gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html
>
>
>
> %%%%%%%%%%    6.0.4 Release Notes 01-December-2025    %%%%%%%%%%%%%%%%
>
> NEW (back-ported from development version)
> ------------------------------------------
> * variable Inf is pre-set to floating point INFINITY
> * "sharpen" filter handles vertical edges in a step function
> * gprintf format specifiers %C and %Ci
>   - %C  formats a complex value as {a, b}
>       This is the format used by the gnuplot "print" command
>   - %Ci formats a complex value as a + bi
>       Both the real and imaginary parts are printed using libc format %g
>       with optional width and precision
> * Support for Windows on ARM 64-bit architectures
>   - mingw: optionally use the MSYS2/CLANG64 environment
>   - Cross-compilation for Windows on ARM is possible using
> MSYS2/CLANG64/CLANGARM64
>
> CHANGES
> -------
> * better adherence to c23 standard
> * splot with pm3d fillcolor <x> generates a matching key sample
> * gprintf %H format is distinct from %h in utf8 context
>   - %H uses dot operator between mantissa and exponent
> * kitty, sixel: default size to 100% width, 75% height of terminal window
> * Partially deprecate the "sample" keyword for plot commands.
>   The plot command accepts axis ranges as the first thing after "plot".
>   If present, they update the primary axis ranges x y x2 y2.
>   However if this is preced by the keyword "sample" it refers to a
> sampling range
>   rather than an axis range.  If a second colon is found in the range,
>   as in [t=min:max:increment], this is unambiguously a sample range so the
>   "sample" keyword is not required.
> * Do not break contour lines into 100-segment fragments.
>   - This fixes a bug when saved contour lines are used as polygons.
>   - To maintain previous placement of contour labels along long contours,
> use
>   "set cntrlabl interval 100".
>
> FIXES
> -----
> * sixel: improved support for a transparent background
> * kitty: support animation on a transparent background
> * webp:  support animation on a transparent background
> * backport fixes for color assignment to pm3d surfaces
>   - "set pm3d implicit" + "with lines" treated the same as "with pm3d"
>   - adds support for "fc background"
>   - pm3d interpolate > 1 inherits rgb color assignments from the parent
> tile
> * fill style of colorbox should match fill style of pm3d surface
> * svg: fillstyle solid <frac> was incorrectly treated as transparent
> * transparent fill color in 3D boxes and polygons
> * alpha channel colors on ARM platforms
> * resolve ambiguous syntax in "set dashtype i (n,m)"
> * svg: font size changes within a text fragment could be lost
> * "reset session" must terminate multiplot mode
> * determination of above/below in polar mode filledcurves
> * always flush cached lines from hidden3d if any are present
> * incorrect evaluation of a**b for integer a, integer b < 0
>   in the case that overflow handling has been set to "NaN" or "undefined"
> * loss of precision in some ranges for asin acos asinh acosh
>
>
> --
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Pre-release testing version of gnuplot 6.0.4

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

Ethan A Merritt writes:
> I have placed a testing version of the source release
> package for gnuplot 6.0.4 on the "testing" section of the
> SourceForge download site.

There's a missing conditional in unset.c which prevents successful
compilation when mouse support is not enabled.

--8<---------------cut here---------------start------------->8---
--- origsrc/gnuplot-6.0.4/src/unset.c
+++ src/gnuplot-6.0.4/src/unset.c
@@ -2068,8 +2068,10 @@
 	    multiplot_end();
 	init_constants();
 	init_session();
+#ifdef USE_MOUSE
 	reset_mouse();
 	reset_since_last_plot = TRUE;
+#endif
 	return;
     }

@@ -2116,7 +2118,9 @@
      * suppress some of the commentary output by the individual
      * unset_...() routines. */
     interactive = FALSE;
+#ifdef USE_MOUSE
     reset_since_last_plot = TRUE;
+#endif
 
     unset_samples();
     unset_isosamples();

--- origsrc/gnuplot-6.0.4/src/plot2d.c
+++ src/gnuplot-6.0.4/src/plot2d.c
@@ -225,7 +225,9 @@
 	int_error(c_token, "use 'set term' to set terminal type first");
 
     is_3d_plot = FALSE;
+#ifdef USE_MOUSE
     reset_since_last_plot = FALSE;
+#endif
 
     if (parametric && strcmp(set_dummy_var[0], "u") == 0)
 	strcpy(set_dummy_var[0], "t");

--- origsrc/gnuplot-6.0.4/src/plot3d.c
+++ src/gnuplot-6.0.4/src/plot3d.c
@@ -312,7 +312,9 @@
     AXIS_INDEX axis, u_axis, v_axis;
 
     is_3d_plot = TRUE;
+#ifdef USE_MOUSE
     reset_since_last_plot = FALSE;
+#endif
 
     if (parametric && strcmp(set_dummy_var[0], "t") == 0) {
 	strcpy(set_dummy_var[0], "u");

--8<---------------cut here---------------end--------------->8---


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Pre-release testing version of gnuplot 6.0.4

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

I have placed a testing version of the source release
package for gnuplot 6.0.4 on the "testing" section of the
SourceForge download site.

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

Nothing major to look for in this release, but it does include a number
of recent bug fixes.　The configure script and various header files
have been modified to allow use with C compilers that enforce c23
syntax by default. This should not affect use with older compilers.

My tentative plan is to announce the actual release in about
two weeks (the week of 15 December).  That can be pushed back
if you find any problems or want to suggest inclusion
of a bug-fix from the development version that was not yet
backported.

Brief release notes below, or see 
     gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html



%%%%%%%%%%    6.0.4 Release Notes 01-December-2025    %%%%%%%%%%%%%%%%

NEW (back-ported from development version)
------------------------------------------
* variable Inf is pre-set to floating point INFINITY
* "sharpen" filter handles vertical edges in a step function
* gprintf format specifiers %C and %Ci
  - %C  formats a complex value as {a, b}
      This is the format used by the gnuplot "print" command
  - %Ci formats a complex value as a + bi
      Both the real and imaginary parts are printed using libc format %g
      with optional width and precision
* Support for Windows on ARM 64-bit architectures
  - mingw: optionally use the MSYS2/CLANG64 environment
  - Cross-compilation for Windows on ARM is possible using MSYS2/CLANG64/CLANGARM64

CHANGES
-------
* better adherence to c23 standard
* splot with pm3d fillcolor <x> generates a matching key sample
* gprintf %H format is distinct from %h in utf8 context
  - %H uses dot operator between mantissa and exponent
* kitty, sixel: default size to 100% width, 75% height of terminal window
* Partially deprecate the "sample" keyword for plot commands.
  The plot command accepts axis ranges as the first thing after "plot".
  If present, they update the primary axis ranges x y x2 y2.
  However if this is preced by the keyword "sample" it refers to a sampling range
  rather than an axis range.  If a second colon is found in the range,
  as in [t=min:max:increment], this is unambiguously a sample range so the
  "sample" keyword is not required.
* Do not break contour lines into 100-segment fragments.
  - This fixes a bug when saved contour lines are used as polygons.
  - To maintain previous placement of contour labels along long contours, use
  "set cntrlabl interval 100".

FIXES
-----
* sixel: improved support for a transparent background
* kitty: support animation on a transparent background
* webp:  support animation on a transparent background
* backport fixes for color assignment to pm3d surfaces
  - "set pm3d implicit" + "with lines" treated the same as "with pm3d"
  - adds support for "fc background"
  - pm3d interpolate > 1 inherits rgb color assignments from the parent tile
* fill style of colorbox should match fill style of pm3d surface
* svg: fillstyle solid <frac> was incorrectly treated as transparent
* transparent fill color in 3D boxes and polygons
* alpha channel colors on ARM platforms
* resolve ambiguous syntax in "set dashtype i (n,m)"
* svg: font size changes within a text fragment could be lost
* "reset session" must terminate multiplot mode
* determination of above/below in polar mode filledcurves
* always flush cached lines from hidden3d if any are present
* incorrect evaluation of a**b for integer a, integer b < 0
  in the case that overflow handling has been set to "NaN" or "undefined"
* loss of precision in some ranges for asin acos asinh acosh


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

Re: New warning about inline data and multiplots

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

On Thursday, 4 December 2025 00:12:07 PST Dima Kogan wrote:

> Thanks for the notes!
> 
> I'll try to make this change when I get the time. What would work better
> if I use the datablock? 

Well, multiplot would work :-)
Seiously, your script works fine either with input from '-' or from
a datablock so long as it isn't inside a multiplot.

> Does that work with older gnuplot also?

It works in version 5.   (5.0 5.2 5.4)

> > The output script, as attached, was also incorrect in that it did not
> > contain an "unset multiplot" command.
> 
> OK. It was never clear to me if that was required, and what, if
> anything, was broken by omitting it.

The multiplot is not fully defined until the "unset multiplot" is reached.

One major thing is that most multiplots change the plot boundaries and
screen layout.  The original boundaries are restored by "unset multiplot".

Another is that in version 6, when the program sees a  "set multiplot"
command it begins saving commands into a datablock of strings named
$GPVAL_LAST_MULTIPLOT.  It continues saving commands into that block
until the "unset multiplot" command is reached.  That allows the entire
multiplot to be reproduced by replaying the saved commands.
That in turn allows "replot" to work, and to some extent mousing/zoom/pan,
none of which was possible at all prior to version 6.  This is the change that
rules out supporting use of plot '-' inside a multiplot, since the data cannot
be parsed or executed as valid gnuplot commands.

[aside] According to the documentation another concern is that some
terminals do not produce any visible output until the "unset" command.
I don't think that is true for any current terminals, so that particular
warning may be out of date. 

> 
> > For that matter, I don't think the script should be using multiplot at
> > all. Why is it using multiplot? There was nothing in the input you
> > showed that requested multiplot.
> 
> I cut down the demo script, which ended up removing the actual
> "multiplot" part of this. The full script and plot are on the gnuplotlib
> demo page (towards the end):

Ah. And there is the polar mode plot you filed a bug report for.

- Ethan

Re: New warning about inline data and multiplots

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

Thanks for the notes!

I'll try to make this change when I get the time. What would work better
if I use the datablock? Does that work with older gnuplot also?

> The output script, as attached, was also incorrect in that it did not
> contain an "unset multiplot" command.

OK. It was never clear to me if that was required, and what, if
anything, was broken by omitting it.


> For that matter, I don't think the script should be using multiplot at
> all. Why is it using multiplot? There was nothing in the input you
> showed that requested multiplot.

I cut down the demo script, which ended up removing the actual
"multiplot" part of this. The full script and plot are on the gnuplotlib
demo page (towards the end):

  https://github.com/dkogan/gnuplotlib/blob/master/guide/guide.org

Thanks.

Re: Japanese help file on Windows

[Shigeharu T. <sh...@ie...>]

shige 12/04 2025
----------------

Thanks for your advice. Now I can see contents of the right part
correctly (in Japanese). I think the file wgnuplot-ja-utf8.chm 
has no problems on japanese windows pc.


bma...@we... wrote:
| Thank you for checking! I had the same experience with the file 
| downloaded from SF at first. I think the problem is related to Windows' 
| safety "feature" for files downloaded from the internet. You have to 
| make sure to mark the file as "trusted" permanently by (un)ticking the 
| box in the dialog which pops up when you open the file. If the UTF-8 
| encoding should not work on a Japanese PC, you should really see 
| "gibberish" on the panels on the right hand side.
| 
|   Bastian
| 
| 
| Am 04.12.2025 um 00:57 schrieb Shigeharu TAKENO:
| > shige 12/04 2025
| > ---------------
| >
| > I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11
| > PC (japanese environment). But the right part (help content) is
| > not displayed though the left part (section title) is displayed
| > correctly in Japanese.
| >
| > +========================================================+
| >   Shigeharu TAKENO     NIigata Institute of Technology
| >                         kashiwazaki,Niigata 945-1195 JAPAN
| >   sh...@ie...   TEL(&FAX): +81-257-22-8161
| > +========================================================+
| 

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Japanese help file on Windows

[Bastian M. <bma...@we...>]

Thank you for checking! I had the same experience with the file 
downloaded from SF at first. I think the problem is related to Windows' 
safety "feature" for files downloaded from the internet. You have to 
make sure to mark the file as "trusted" permanently by (un)ticking the 
box in the dialog which pops up when you open the file. If the UTF-8 
encoding should not work on a Japanese PC, you should really see 
"gibberish" on the panels on the right hand side.

   Bastian


Am 04.12.2025 um 00:57 schrieb Shigeharu TAKENO:
> shige 12/04 2025
> ---------------
>
> I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11
> PC (japanese environment). But the right part (help content) is
> not displayed though the left part (section title) is displayed
> correctly in Japanese.
>
> +========================================================+
>   Shigeharu TAKENO     NIigata Institute of Technology
>                         kashiwazaki,Niigata 945-1195 JAPAN
>   sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Japanese help file on Windows

[Shigeharu T. <sh...@ie...>]

shige 12/04 2025
---------------

I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11 
PC (japanese environment). But the right part (help content) is
not displayed though the left part (section title) is displayed
correctly in Japanese.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: New warning about inline data and multiplots

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

On Wed, Dec 3, 2025 at 9:02 AM Dima Kogan <gn...@di...>
wrote:

>
> I just ran the gnuplotlib unit test, and I see lots of warnings with one
> of the tests. The plots are still made, but there's A LOT of console
> chatter now:
>
>   "/tmp/tst.gp" line 17: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 18: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 19: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 20: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 21: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>
> This keeps repeating many times.

The resulting gnuplot script is attached. It clearly shows the warnings.
>
> What isn't supported here?


Exactly what it says.  The current (since version 6.0) implementation of
multiplot does not support placing inline data inside a multiplot block.
This is because the full set of commands inside `set multiplot .... unset
multiplot` is saved for replay during mousing or by a replot command, and
inline data would mess that up badly.


> I've been doing this for years with great
> success, and it appears to still work today.


It does not work today.  What you see is the first execution, with a
warning, while it is reading in the multiplot block. But it does not become
part of the multiplot and the program fails to exit the block cleanly.


> Should I be doing something different?

Yes.

$DATA << EOD
line 1
line 2
...
line N
EOD

set multiplot
plot $DATA with lp
unset multiplot


I use gnuplot constantly, every day. But 99% of my usage is
> either through feedgnuplot or gnuplotlib, both of which use inline data.
> Should those tools be using a datablock? Can they?
>

For use with gnuplot version 6 they should.

The output script, as attached, was also incorrect in that it did not
contain an "unset multiplot" command.  For that matter, I don't think the
script should be using multiplot at all.  Why is it using multiplot?  There
was nothing in the input you showed that requested multiplot.  If "set
multiplot" appears in the output gnuplot script I think that must be a bug
in the program that generated the script.

   Ethan

New warning about inline data and multiplots

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

Hello.

I just ran the gnuplotlib unit test, and I see lots of warnings with one
of the tests. The plots are still made, but there's A LOT of console
chatter now:

  "/tmp/tst.gp" line 17: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 18: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 19: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 20: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 21: warning: Reading from '-' inside a multiplot not supported; use a datablock instead

This keeps repeating many times. Cut-down python script:

  import numpy as np
  import gnuplotlib as gp

  xx,yy = np.meshgrid(np.linspace(-5,5,20),
                      np.linspace(-5,5,20))
  zz0 = np.sin(xx) + yy*yy/8.
  gp.plot3d( (zz0,
              dict(_set = ( 'origin 0,0',
                            'size 1,1',
                            'view 60,20,1,1',
                            'xrange [0:20]',
                            'yrange [0:20]',
                            'zrange [0:10]',
                            'contour base',
                            'xyplane at 10',))),
             tuplesize=3,
             _with = 'lines nosurface',
             square=1,
             wait=True,
             hardcopy='/tmp/tst.gp',
             ascii=True,
             multiplot=True)

The resulting gnuplot script is attached. It clearly shows the warnings.

What isn't supported here? I've been doing this for years with great
success, and it appears to still work today. Should I be doing something
different? I use gnuplot constantly, every day. But 99% of my usage is
either through feedgnuplot or gnuplotlib, both of which use inline data.
Should those tools be using a datablock? Can they?

Thanks.

Japanese help file on Windows

[Bastian M. <bma...@we...>]

Hi,

Currently the CHM windows help file in Japanese is encoded in SHIFT-JIS. 
Since the English version is using UTF-8 on the other hand, this should 
also be fine for the Japanese variant. I would appreciate feedback, if 
the wgnuplot-ja-utf8.chm file on SF in the testing/ directory also works 
fine for others.

   Bastian

Re: Request for official gnuplot support on Windows ARM64

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

Dear Ethan,

Apologies for overlooking this message! I am not an expert on Windows /
ARM64; my focus is on macOS binaries (although indeed for both x86-64 and
ARM64).

Sorry that I cannot be of help.

Kind regards,

Erik


On Fri, Oct 3, 2025 at 2:28 PM Ethan A Merritt <me...@uw...> wrote:

> I am forwarding a offer to help add  ARM64 + Windows support to gnuplot.
> Since those are not areas I deal with, perhaps someone else on the
> developers
> list  (Bastian? Tatsuro? Erik?) can respond to this or suggest how to
> proceed.
>
> If "official support" from our side is out of the question, but they are
> willing
> to prepare and host a contributed binary for public download, we could
> offer
> to add a link on the "Downloads offered by others" section of the gnuplot
> web site.
>
> - Ethan
>
> ----------  Forwarded Message  ----------
>
> Subject: Request for official gnuplot support on Windows ARM64
> Date: Monday, 29 September 2025, 01:52:42 PDT
> From: Mugunthan Selvanayagam <mug...@mu...>
> To: merritt@u.washington.edu <merritt@u.washington.edu>
> CC: Gaurav Goel <gg...@qt...>, Vishnu Vardhan Kasiliya
> Sudarsan <vka...@qt...>, Sumit Sharma <
> ss...@qt...>, Mayank Agrawal <ma...@qt...>, Vinod
> Kumar Sukumar <vin...@mu...>, Thirumalai Nagalingam
> <thi...@mu...>
>
> Hi Merritt
>
> I am Mugundan from MulticoreWare https://multicorewareinc.com, India. We
> are collaborating with Qualcomm on enabling native applications and
> libraries for the Snapdragon X Elite Windows on ARM (WoA) platform.
> During our initial testing, we observed that the x64 Windows GNU Plot
> installer fails on Windows ARM64 due to x64-only restrictions. By making a
> minor modification to the Inno Setup installer script, we were able to
> rebuild the installer to function correctly under x64 emulation on Windows
> ARM devices. We would like to upstream this change so that users on Windows
> on ARM can run GNU Plot via emulation. This would immediately make GNU Plot
> accessible to a broader set of Windows ARM64 users and benefit the user
> community.
>
> We also noticed the availability of initial ARM64 test binaries, and we
> would like to know if there is any information regarding the estimated
> timeline for an official release. If there are any blockers, our team would
> be happy to assist and contribute patches to support both the installer and
> native ARM64 builds. Having an official Windows ARM64 support for GNU Plot
> would be a valuable addition for this growing platform, and we would be
> glad to contribute toward making it possible.
>
> Best regards,
>
> Mugundan
>
> MulticoreWare, India
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Fwd: Request for official gnuplot support on Windows ARM64

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

I am forwarding a offer to help add  ARM64 + Windows support to gnuplot.
Since those are not areas I deal with, perhaps someone else on the developers
list  (Bastian? Tatsuro? Erik?) can respond to this or suggest how to proceed.

If "official support" from our side is out of the question, but they are willing
to prepare and host a contributed binary for public download, we could offer
to add a link on the "Downloads offered by others" section of the gnuplot web site.

- Ethan

----------  Forwarded Message  ----------

Subject: Request for official gnuplot support on Windows ARM64
Date: Monday, 29 September 2025, 01:52:42 PDT
From: Mugunthan Selvanayagam <mug...@mu...>
To: merritt@u.washington.edu <merritt@u.washington.edu>
CC: Gaurav Goel <gg...@qt...>, Vishnu Vardhan Kasiliya Sudarsan <vka...@qt...>, Sumit Sharma <ss...@qt...>, Mayank Agrawal <ma...@qt...>, Vinod Kumar Sukumar <vin...@mu...>, Thirumalai Nagalingam <thi...@mu...>

Hi Merritt

I am Mugundan from MulticoreWare https://multicorewareinc.com, India. We are collaborating with Qualcomm on enabling native applications and libraries for the Snapdragon X Elite Windows on ARM (WoA) platform.
During our initial testing, we observed that the x64 Windows GNU Plot installer fails on Windows ARM64 due to x64-only restrictions. By making a minor modification to the Inno Setup installer script, we were able to rebuild the installer to function correctly under x64 emulation on Windows ARM devices. We would like to upstream this change so that users on Windows on ARM can run GNU Plot via emulation. This would immediately make GNU Plot accessible to a broader set of Windows ARM64 users and benefit the user community.

We also noticed the availability of initial ARM64 test binaries, and we would like to know if there is any information regarding the estimated timeline for an official release. If there are any blockers, our team would be happy to assist and contribute patches to support both the installer and native ARM64 builds. Having an official Windows ARM64 support for GNU Plot would be a valuable addition for this growing platform, and we would be glad to contribute toward making it possible.

Best regards,

Mugundan

MulticoreWare, India

Re: gnuplot.info unreachable (test.gnuplot.info?)

[Clark G. <cla...@gm...>]

It does include subdomain 😁

I have DNS in Hover and I don't think I pay anything beyond the domains.
I'll have to look into what I did with test -- it's so long since I set it
up. I removed the AAAA record on the main domain for now. That shouldn't be
giving a cert error no matter what -- it'll either work or not.

Years ago I had this janky setup with the AAAA pointing to a server I had
at VT that got a daily rsync. Definitely not tls friendly, but it gave us
IPv6 and actually performed a lot better than SF. But that setup is long
gone. I was thinking SF had a legit IPv6 service and that's what I
configured, but that was at least a few years ago.

I think I'll have some time this weekend to unpack all that and remind
myself how this was supposed to work. SF not having IPv6 in 2025 is pretty
inexcusable, but then they're up there with GitHub.... Again, I seem to
recall they had an IPv6 approach a few years ago when I set it up but I'll
refresh my memory. In the meantime I've (begrudgingly) removed the AAAA.

But as far as the domain, yes I've prepaid 10 years (I think it's actually
renewed once)...

Cheers
--ckg

Clark Gaylord
cla...@gm...

On Thu, Sep 11, 2025, 14:12 Ethan A Merritt <me...@uw...> wrote:

> On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote:
> > The plot thickens.
> >
> > I wanted to check on crt.sh (a certificate search facility) what certs
> > were issued for gnuplot.info in the past. To my surprise, I didn't find
> > any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
> > for which a certificate was issued first on 2024-03-02 and renewed ever
> > since. And indeed, test.gnuplot.info does work with https.
> >
> > I did not know that this domain exists. Should it?
> > Peter
>
>
> I think Clark Gaylord may be the best, if not the only, person to answer
> this.
> (CC'ed on this reply).
>
> Clark said last month that the gnuplot.info domain was set up
> "on ten year pre payment with auto renew".
> I don't know whether that includes subdomains or not.
> Please excuse my ignorance.  I don't even know what a "certificate" means
> in this context, or how it fits in with domain registration.
>
> Anyhow, sourceforge supprt has acknowledged the request I made to
> them to enable https for gnuplot.info so that may yet take care of it.
> If there is something else I should ask them for, please let me know.
>
>  Ethan
>
>
> > On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> > > Thanks for the pointers.
> > >
> > > After poking around in the SourceForge admin pages I found a place to
> > > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> > > already listed there. That same page states that https access can be
> > > enabled by request, so I placed a support request with the
> > > SourceForge site itself to enable https access via gnuplot.info and
> > > www.gnuplot.info.  We'll see what happens.
> > >
> > > Support tracker:
> > >      https://sourceforge.net/p/forge/site-support/27031/
> > >  Ethan
>
>
> > >
> > > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> > > <moj...@gm...> wrote:
> > > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > > > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > > > the certificate required to serve the site over HTTPS
> > > > ZjQcmQRYFpfptBannerStart
> > > >
> > > >
> > > >
> > > > This Message Is From an Untrusted Sender
> > > >
> > > > You have not previously corresponded with this sender.
> > > >
> > > > See https://itconnect.uw.edu/email-tags  for additional information.
> > > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > > > for assistance.
> > > >
> > > >
> > > >
> > > >
> > > > ZjQcmQRYFpfptBannerEnd
> > > >
> > > >
> > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > > > wrote:
> > > > >
> > > > >
> > > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > > > <pet...@gm...> wrote:
> > > > > >
> > > > > > The error message means that the certificate required to serve
> > > > > > the site over HTTPS is not valid for the domain name
> > > > > > gnuplot.info [1] (nor
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$
> [2]). If you look at the
> > > > > > certificate (offered by Firefox next to the error message), you
> > > > > > can see that it was issued by Let's Encrypt to
> > > > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > > > selection of other domain names, presumably all projects hosted
> > > > > > by SF.
> > > > > >
> > > > >
> > > > >
> > > > > Thank you for your insights.
> > > > >
> > > > > I think you are addressing a different issue - whether the
> > > > > connection protocol is https or http.
> > > >
> > > > Yes, this is not about DNS failure. I don't experience DNS failure,
> > > > but see precisely the same errors/issues as Peter described.
> > > >
> > > > (Nowadays http should actually redirect to https. Modern browsers
> > > > also refuse to show http pages.)
> > > >
> > > > > It is not surprising that a certificate issued to SourceForge
> > > > > would not mention gnuplot.info [1] by name because that name is
> > > > > not connected to SourceForge except in that (as I understand it)
> > > > > it currently redirects queries to the actual gnuplot site
> > > > > gnuplot.sourceforge.net [4].
> > > >
> > > > Except that it does matter for https. The hosting site needs to
> > > > know that the certificate should also be for gnuplot.info [1]  and
> > > > it needs to be explicit whether that is with or without www (or
> > > > both).
> > > > Either a separate certificate is needed for that, or the
> > > > certificate used needs to be made aware that it needs to cover
> > > > gnuplot.info [1]. This really needs to be fixed on the hosting
> > > > site, and usually the person in charge of the DNS is also needed in
> > > > the process of making it work.
> > > >
> > > > Unless the administrators of gnuplot on SF have access to
> > > > certificate settings (means you would also need to create and
> > > > extend your own certificate), then SF support is really needed here
> > > > to set it up.
> > > >
> > > > > The current problem seems to be that the redirection itself fails
> > > > > in some cases, or fails to pass through sufficient information
> > > >
> > > > No. It's really a misconfigured site/certificate.
> > > >
> > > > > You still see the site, correct?
> > > >
> > > > Well ... yes and no, but the more correct answer is probably NO. By
> > > > default you don't see the site because the web browser is
> > > > protecting you from "the malicious site" until you approve an
> > > > exception and security risk, but that is "an advanced use" (it is
> > > > on purpose made difficult to do that).
> > > >
> > > > > For completeness I should mention that the issue of connection
> > > > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > > > relevant,
> > > >
> > > > It is possible that the site works correctly on IPv4 and fails with
> > > > IPv6. My network right now doesn't support IPv6, so it's hard for
> > > > me to check. It is unrelated to certificate issues, but it could
> > > > hypothetically explain why DNS works for others and not for you if
> > > > you have IPv6. (By correctly I mean resolving to the correct
> > > > website. It still doesn't serve a compliant certificate.)
> > > >
> > > > Mojca
> > > >
> > >
> > >
> >
> >
> > [1] gnuplot.info
> >
> https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
> > [2]
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$
> >
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
> > [3] secureprojects.sourceforge.net
> >
> https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
> > [4] gnuplot.sourceforge.net
> >
> https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$
> >
>
>
> --
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
>
>
>

Re: gnuplot.info unreachable (DNS failure)

[Jeremy N. - ml g. <jn....@wi...>]

On 2025-09-11 01:18, Mojca Miklavec Groenhuis wrote:

> (Nowadays http should actually redirect to https. Modern
> browsers also refuse to show http pages.)

While that is sensible for external websites, it needs to be
configurable, so that one can login to admin interfaces on
network routers etc.

-- 
Jeremy Nicoll - my opinions are my own

Re: gnuplot.info unreachable (test.gnuplot.info?)

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

On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote:
> The plot thickens.
> 
> I wanted to check on crt.sh (a certificate search facility) what certs
> were issued for gnuplot.info in the past. To my surprise, I didn't find
> any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
> for which a certificate was issued first on 2024-03-02 and renewed ever
> since. And indeed, test.gnuplot.info does work with https.
> 
> I did not know that this domain exists. Should it?
> Peter


I think Clark Gaylord may be the best, if not the only, person to answer this.
(CC'ed on this reply).

Clark said last month that the gnuplot.info domain was set up
"on ten year pre payment with auto renew".
I don't know whether that includes subdomains or not.
Please excuse my ignorance.  I don't even know what a "certificate" means
in this context, or how it fits in with domain registration.  

Anyhow, sourceforge supprt has acknowledged the request I made to
them to enable https for gnuplot.info so that may yet take care of it.
If there is something else I should ask them for, please let me know.

 Ethan


> On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> > Thanks for the pointers. 
> > 
> > After poking around in the SourceForge admin pages I found a place to
> > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> > already listed there. That same page states that https access can be
> > enabled by request, so I placed a support request with the
> > SourceForge site itself to enable https access via gnuplot.info and
> > www.gnuplot.info.  We'll see what happens.
> > 
> > Support tracker:
> >      https://sourceforge.net/p/forge/site-support/27031/
> >  Ethan


> > 
> > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> > <moj...@gm...> wrote:
> > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > > the certificate required to serve the site over HTTPS
> > > ZjQcmQRYFpfptBannerStart
> > > 
> > > 
> > > 
> > > This Message Is From an Untrusted Sender 
> > > 
> > > You have not previously corresponded with this sender. 
> > > 
> > > See https://itconnect.uw.edu/email-tags  for additional information.
> > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > > for assistance. 
> > > 
> > > 
> > >  
> > > 
> > > ZjQcmQRYFpfptBannerEnd
> > > 
> > > 
> > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > > wrote:
> > > > 
> > > > 
> > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > > <pet...@gm...> wrote:
> > > > > 
> > > > > The error message means that the certificate required to serve
> > > > > the site over HTTPS is not valid for the domain name
> > > > > gnuplot.info [1] (nor https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$  [2]). If you look at the
> > > > > certificate (offered by Firefox next to the error message), you
> > > > > can see that it was issued by Let's Encrypt to
> > > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > > selection of other domain names, presumably all projects hosted
> > > > > by SF. 
> > > > > 
> > > > 
> > > > 
> > > > Thank you for your insights.
> > > > 
> > > > I think you are addressing a different issue - whether the
> > > > connection protocol is https or http.
> > > 
> > > Yes, this is not about DNS failure. I don't experience DNS failure,
> > > but see precisely the same errors/issues as Peter described.
> > > 
> > > (Nowadays http should actually redirect to https. Modern browsers
> > > also refuse to show http pages.)
> > > 
> > > > It is not surprising that a certificate issued to SourceForge
> > > > would not mention gnuplot.info [1] by name because that name is
> > > > not connected to SourceForge except in that (as I understand it)
> > > > it currently redirects queries to the actual gnuplot site
> > > > gnuplot.sourceforge.net [4].
> > > 
> > > Except that it does matter for https. The hosting site needs to
> > > know that the certificate should also be for gnuplot.info [1]  and
> > > it needs to be explicit whether that is with or without www (or
> > > both).
> > > Either a separate certificate is needed for that, or the
> > > certificate used needs to be made aware that it needs to cover
> > > gnuplot.info [1]. This really needs to be fixed on the hosting
> > > site, and usually the person in charge of the DNS is also needed in
> > > the process of making it work.
> > > 
> > > Unless the administrators of gnuplot on SF have access to
> > > certificate settings (means you would also need to create and
> > > extend your own certificate), then SF support is really needed here
> > > to set it up. 
> > > 
> > > > The current problem seems to be that the redirection itself fails
> > > > in some cases, or fails to pass through sufficient information
> > > 
> > > No. It's really a misconfigured site/certificate.
> > > 
> > > > You still see the site, correct?
> > > 
> > > Well ... yes and no, but the more correct answer is probably NO. By
> > > default you don't see the site because the web browser is
> > > protecting you from "the malicious site" until you approve an
> > > exception and security risk, but that is "an advanced use" (it is
> > > on purpose made difficult to do that).
> > > 
> > > > For completeness I should mention that the issue of connection
> > > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > > relevant,
> > > 
> > > It is possible that the site works correctly on IPv4 and fails with
> > > IPv6. My network right now doesn't support IPv6, so it's hard for
> > > me to check. It is unrelated to certificate issues, but it could
> > > hypothetically explain why DNS works for others and not for you if
> > > you have IPv6. (By correctly I mean resolving to the correct
> > > website. It still doesn't serve a compliant certificate.)
> > > 
> > > Mojca
> > > 
> > 
> > 
> 
> 
> [1] gnuplot.info
>     https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
> [2] https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ 
>     https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
> [3] secureprojects.sourceforge.net
>     https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
> [4] gnuplot.sourceforge.net
>     https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$
> 


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

Re: gnuplot.info unreachable (test.gnuplot.info?)

[Juhász P. <pet...@gm...>]

The plot thickens.

I wanted to check on crt.sh (a certificate search facility) what certs
were issued for gnuplot.info in the past. To my surprise, I didn't find
any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
for which a certificate was issued first on 2024-03-02 and renewed ever
since. And indeed, test.gnuplot.info does work with https.

I did not know that this domain exists. Should it?

Peter

On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> Thanks for the pointers. 
> 
> After poking around in the SourceForge admin pages I found a place to
> set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> already listed there. That same page states that https access can be
> enabled by request, so I placed a support request with the
> SourceForge site itself to enable https access via gnuplot.info and
> www.gnuplot.info.  We'll see what happens.
> 
> https://sourceforge.net/p/forge/site-support/27031/
> 
>  Ethan
> 
> On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> <moj...@gm...> wrote:
> > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > the certificate required to serve the site over HTTPS
> > ZjQcmQRYFpfptBannerStart
> > 
> > 
> > 
> > This Message Is From an Untrusted Sender 
> > 
> > You have not previously corresponded with this sender. 
> > 
> > See https://itconnect.uw.edu/email-tags for additional information.
> > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > for assistance. 
> > 
> > 
> >  
> > 
> > ZjQcmQRYFpfptBannerEnd
> > 
> > 
> > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > wrote:
> > > 
> > > 
> > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > <pet...@gm...> wrote:
> > > > 
> > > > The error message means that the certificate required to serve
> > > > the site over HTTPS is not valid for the domain name
> > > > gnuplot.info [1] (nor www.gnuplot.info [2]). If you look at the
> > > > certificate (offered by Firefox next to the error message), you
> > > > can see that it was issued by Let's Encrypt to
> > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > selection of other domain names, presumably all projects hosted
> > > > by SF. 
> > > > 
> > > 
> > > 
> > > Thank you for your insights.
> > > 
> > > I think you are addressing a different issue - whether the
> > > connection protocol is https or http.
> > 
> > Yes, this is not about DNS failure. I don't experience DNS failure,
> > but see precisely the same errors/issues as Peter described.
> > 
> > (Nowadays http should actually redirect to https. Modern browsers
> > also refuse to show http pages.)
> > 
> > > It is not surprising that a certificate issued to SourceForge
> > > would not mention gnuplot.info [1] by name because that name is
> > > not connected to SourceForge except in that (as I understand it)
> > > it currently redirects queries to the actual gnuplot site
> > > gnuplot.sourceforge.net [4].
> > 
> > Except that it does matter for https. The hosting site needs to
> > know that the certificate should also be for gnuplot.info [1]  and
> > it needs to be explicit whether that is with or without www (or
> > both).
> > Either a separate certificate is needed for that, or the
> > certificate used needs to be made aware that it needs to cover
> > gnuplot.info [1]. This really needs to be fixed on the hosting
> > site, and usually the person in charge of the DNS is also needed in
> > the process of making it work.
> > 
> > Unless the administrators of gnuplot on SF have access to
> > certificate settings (means you would also need to create and
> > extend your own certificate), then SF support is really needed here
> > to set it up. 
> > 
> > > The current problem seems to be that the redirection itself fails
> > > in some cases, or fails to pass through sufficient information
> > 
> > No. It's really a misconfigured site/certificate.
> > 
> > > You still see the site, correct?
> > 
> > Well ... yes and no, but the more correct answer is probably NO. By
> > default you don't see the site because the web browser is
> > protecting you from "the malicious site" until you approve an
> > exception and security risk, but that is "an advanced use" (it is
> > on purpose made difficult to do that).
> > 
> > > For completeness I should mention that the issue of connection
> > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > relevant,
> > 
> > It is possible that the site works correctly on IPv4 and fails with
> > IPv6. My network right now doesn't support IPv6, so it's hard for
> > me to check. It is unrelated to certificate issues, but it could
> > hypothetically explain why DNS works for others and not for you if
> > you have IPv6. (By correctly I mean resolving to the correct
> > website. It still doesn't serve a compliant certificate.)
> > 
> > Mojca
> > 
> 
> 
> -- 
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


[1] gnuplot.info
    https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
[2] www.gnuplot.info
    https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
[3] secureprojects.sourceforge.net
    https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
[4] gnuplot.sourceforge.net
    https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$

Re: gnuplot.info unreachable (DNS failure)

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

Thanks for the pointers.

After poking around in the SourceForge admin pages I found a place to set
up "virtual domains". Both gnuplot.info and www.gnuplot.info are already
listed there. That same page states that https access can be enabled by
request, so I placed a support request with the SourceForge site itself to
enable https access via gnuplot.info and www.gnuplot.info.  We'll see what
happens.

https://sourceforge.net/p/forge/site-support/27031/

 Ethan

On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis <
moj...@gm...> wrote:

> On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu> wrote:
> On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter <peter. juhasz83@ gmail.
> com> wrote: The error message means that the certificate required to serve
> the site over HTTPS
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> See https://itconnect.uw.edu/email-tags for additional information.
> Please contact the UW-IT Service Center, he...@uw... 206.221.5000, for
> assistance.
>
> ZjQcmQRYFpfptBannerEnd
>
>
> On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> wrote:
>
>>
>>
>> On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...>
>> wrote:
>>
>>> The error message means that the certificate required to serve the site
>>> over HTTPS is not valid for the domain name gnuplot.info
>>> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
>>> (nor www.gnuplot.info
>>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
>>> If you look at the certificate (offered by Firefox next to the error
>>> message), you can see that it was issued by Let's Encrypt to
>>> secureprojects.sourceforge.net
>>> <https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$>,
>>> and it is valid for a large selection of other domain names, presumably all
>>> projects hosted by SF.
>>>
>>
>> Thank you for your insights.
>>
>> I think you are addressing a different issue - whether the connection
>> protocol is https or http.
>>
>
> Yes, this is not about DNS failure. I don't experience DNS failure, but
> see precisely the same errors/issues as Peter described.
>
> (Nowadays http should actually redirect to https. Modern browsers also
> refuse to show http pages.)
>
> It is not surprising that a certificate issued to SourceForge would not
>> mention gnuplot.info
>> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
>> by name because that name is not connected to SourceForge except in that
>> (as I understand it) it currently redirects queries to the actual gnuplot
>> site gnuplot.sourceforge.net
>> <https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$>
>> .
>>
>
> Except that it does matter for https. The hosting site needs to know that
> the certificate should also be for gnuplot.info
> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
> and it needs to be explicit whether that is with or without www (or both).
> Either a separate certificate is needed for that, or the certificate used
> needs to be made aware that it needs to cover gnuplot.info
> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>.
> This really needs to be fixed on the hosting site, and usually the person
> in charge of the DNS is also needed in the process of making it work.
>
> Unless the administrators of gnuplot on SF have access to certificate
> settings (means you would also need to create and extend your own
> certificate), then SF support is really needed here to set it up.
>
> The current problem seems to be that the redirection itself fails in some
>> cases, or fails to pass through sufficient information
>>
>
> No. It's really a misconfigured site/certificate.
>
> > You still see the site, correct?
>
> Well ... yes and no, but the more correct answer is probably NO. By
> default you don't see the site because the web browser is protecting you
> from "the malicious site" until you approve an exception and security risk,
> but that is "an advanced use" (it is on purpose made difficult to do that).
>
> For completeness I should mention that the issue of connection via IPv6 as
>> opposed to IPv4 was raised earlier, and might be relevant,
>>
>
> It is possible that the site works correctly on IPv4 and fails with IPv6.
> My network right now doesn't support IPv6, so it's hard for me to check. It
> is unrelated to certificate issues, but it could hypothetically explain why
> DNS works for others and not for you if you have IPv6. (By correctly I mean
> resolving to the correct website. It still doesn't serve a compliant
> certificate.)
>
> Mojca
>
>>

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

Re: gnuplot.info unreachable (DNS failure)

[Mojca M. G. <moj...@gm...>]

On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> wrote:

>
>
> On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...>
> wrote:
>
>> The error message means that the certificate required to serve the site
>> over HTTPS is not valid for the domain name gnuplot.info (nor
>> www.gnuplot.info
>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
>> If you look at the certificate (offered by Firefox next to the error
>> message), you can see that it was issued by Let's Encrypt to
>> secureprojects.sourceforge.net, and it is valid for a large selection of
>> other domain names, presumably all projects hosted by SF.
>>
>
> Thank you for your insights.
>
> I think you are addressing a different issue - whether the connection
> protocol is https or http.
>

Yes, this is not about DNS failure. I don't experience DNS failure, but see
precisely the same errors/issues as Peter described.

(Nowadays http should actually redirect to https. Modern browsers also
refuse to show http pages.)

It is not surprising that a certificate issued to SourceForge would not
> mention gnuplot.info by name because that name is not connected to
> SourceForge except in that (as I understand it) it currently redirects
> queries to the actual gnuplot site gnuplot.sourceforge.net.
>

Except that it does matter for https. The hosting site needs to know that
the certificate should also be for gnuplot.info  and it needs to be
explicit whether that is with or without www (or both).
Either a separate certificate is needed for that, or the certificate used
needs to be made aware that it needs to cover gnuplot.info. This really
needs to be fixed on the hosting site, and usually the person in charge of
the DNS is also needed in the process of making it work.

Unless the administrators of gnuplot on SF have access to certificate
settings (means you would also need to create and extend your own
certificate), then SF support is really needed here to set it up.

The current problem seems to be that the redirection itself fails in some
> cases, or fails to pass through sufficient information
>

No. It's really a misconfigured site/certificate.

> You still see the site, correct?

Well ... yes and no, but the more correct answer is probably NO. By default
you don't see the site because the web browser is protecting you from "the
malicious site" until you approve an exception and security risk, but that
is "an advanced use" (it is on purpose made difficult to do that).

For completeness I should mention that the issue of connection via IPv6 as
> opposed to IPv4 was raised earlier, and might be relevant,
>

It is possible that the site works correctly on IPv4 and fails with IPv6.
My network right now doesn't support IPv6, so it's hard for me to check. It
is unrelated to certificate issues, but it could hypothetically explain why
DNS works for others and not for you if you have IPv6. (By correctly I mean
resolving to the correct website. It still doesn't serve a compliant
certificate.)

Mojca

>

Re: gnuplot.info unreachable (DNS failure)

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

On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...>
wrote:

> On Wed, 2025-09-10 at 10: 51 -0700, Ethan A Merritt wrote: To the limited
> extent that I understand the error messages that I am seeing, it is not a
> matter of appropriate content on the server. The query is never getting to
> the server because
> ZjQcmQRYFpfptBannerStart
> On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote:
>
> To the limited extent that I understand the error messages that I am
> seeing,
> it is not a matter of appropriate content on the server.  The query is
> never
> getting to the server because some intermediate service provider is
> failing to
> deliver it.  If I am misunderstanding and there is some configuration
> thing I
> can change on the SourceForge end, please let me know.
>
>
> Hi,
>
> you've mentioned that the actual content is hosted on/by SourceForge.
>
> Under what kind of formal or informal arrangement or contract does this
> happen? Was any payment involved
>

No payment or formal contract with SourceForge that I know of.

The error message means that the certificate required to serve the site
> over HTTPS is not valid for the domain name gnuplot.info (nor
> www.gnuplot.info
> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
> If you look at the certificate (offered by Firefox next to the error
> message), you can see that it was issued by Let's Encrypt to
> secureprojects.sourceforge.net, and it is valid for a large selection of
> other domain names, presumably all projects hosted by SF.
>

Thank you for your insights.

I think you are addressing a different issue - whether the connection
protocol is https or http. It is not surprising that a certificate issued
to SourceForge would not mention gnuplot.info by name because that name is
not connected to SourceForge except in that (as I understand it) it
currently redirects queries to the actual gnuplot site
gnuplot.sourceforge.net.  The current problem seems to be that the
redirection itself fails in some cases, or fails to pass through sufficient
information (or credentials or something - I really really don't understand
this stuff).  If you are seeing an error message that refers to a
SourceForge certificate then I think in your case the redirection must have
succeeded. You still see the site, correct?  It's just that connection is
falling back to http rather that https.

I was getting an error from some intermediary network entity (Cloudflare)
that reports  "DNS resolution error 1001". As Hans-Bernhard noted, that's
rather odd because DNS does seem to work correctly when tested by command
line tools.

For completeness I should mention that the issue of connection via IPv6 as
opposed to IPv4 was raised earlier, and might be relevant, but that goes
way beyond my level of understanding.

   Ethan


> So the person who is responsible for renewing this certificate at SF
> either made a mistake by not including gnuplot.info (and in this case a
> gentle reminder may fix the issue in October at the very latest, possibly
> earlier), or deliberately removed gnuplot.info from the list of domains,
> because the afore-hypothesized contract has expired (in which case the
> gentle reminder may have to include money).
>
> As to whom that gentle reminder should be sent, I have no idea.
>
best regards,
>
> Peter Juhasz
>

Re: gnuplot.info unreachable (DNS failure)

[Juhász P. <pet...@gm...>]

On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote:
> To the limited extent that I understand the error messages that I am
> seeing,
> it is not a matter of appropriate content on the server.  The query
> is never
> getting to the server because some intermediate service provider is
> failing to
> deliver it.  If I am misunderstanding and there is some configuration
> thing I
> can change on the SourceForge end, please let me know.
> 

Hi,

you've mentioned that the actual content is hosted on/by SourceForge.

Under what kind of formal or informal arrangement or contract does this
happen? Was any payment involved?

The error message means that the certificate required to serve the site
over HTTPS is not valid for the domain name gnuplot.info (nor
www.gnuplot.info). If you look at the certificate (offered by Firefox
next to the error message), you can see that it was issued by Let's
Encrypt to secureprojects.sourceforge.net, and it is valid for a large
selection of other domain names, presumably all projects hosted by SF.
The certificate is valid between Tue, 29 Jul 2025 02:33:38 GMT and Mon,
27 Oct 2025 02:33:37 GMT.

So the person who is responsible for renewing this certificate at SF
either made a mistake by not including gnuplot.info (and in this case a
gentle reminder may fix the issue in October at the very latest,
possibly earlier), or deliberately removed gnuplot.info from the list
of domains, because the afore-hypothesized contract has expired (in
which case the gentle reminder may have to include money).

As to whom that gentle reminder should be sent, I have no idea.

best regards,

Peter Juhasz

Re: gnuplot.info unreachable (DNS failure)

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

On Wed, Sep 10, 2025 at 5:53 AM Philipp K. Janert via gnuplot-beta <
gnu...@li...> wrote:

> On Tue, 09 Sep 2025 16:19:58 -0700
> Ethan A Merritt <me...@uw...> wrote:
>
>
> I don't want to be a stickler, but I don't
> think changing the docs from "gnuplot.info"
> to "www.gnuplot.info" is really the right
> way to think about it.


[shrug]  That's the only part of it I can do myself, and it takes effect
immediately.
The on-line docs now work again (as seen from here), whereas access was
failing yesterday. I hope someone else can arrange a more global long-term
fix
or at least identify what that fix would be.


> The domain/server should be configured to
> accept both versions and serve the appropriate
> content. That's pretty standard issue, in my
> experience.


To the limited extent that I understand the error messages that I am seeing,
it is not a matter of appropriate content on the server.  The query is never
getting to the server because some intermediate service provider is failing
to
deliver it.  If I am misunderstanding and there is some configuration thing
I
can change on the SourceForge end, please let me know.

   Ethan



Best,
>
>                 Ph.
>



> > On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:
> >
> > > Ethan can't link to gnuplot.info (note: no leading www.).
> >
> > Good point.  I typed the address into the browser directly because
> > Phillipp's reported error message was
> >    "Firefox does not trust this site because it uses a certificate
> > that is not valid for gnuplot.info"
> >
> > > [...] also fails, with a
> > > "DNS resolution error 1001"  reported by Cloudflare.
> > > Which is strange, as tracert did get an IP,  i.e. DNS actually
> > > works.
> >
> > Yes.  That's the one I'm seeing.  It's an internal error message from
> > Cloudflare that I get when I request either
> https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxPgQ2mvA$
> or
> >
> https://urldefense.com/v3/__https://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxK_p5wIQ$
> >
> > It does work if I request
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$
>   (Chrome or
> > Firefox browsers).
> >
> > The hyperlink references in the pdf version of the user manual  use
> > the
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$
> form.    But the html versions of the manual use
> > the gnuplot.info form [no www] everywhere.
> >
> > That much I can fix.
> > I will modify the gnuplot.doc inline html tables and the code in
> > doc2web.c to always generate output with the www prefix in the URL.
> >
> > However it is probably a common "mistake" for users to omit the www
> > prefix in web queries since that is no longer as near-universal as it
> > once was.  For that matter Chrome actively hides the "www." prefix
> > when it shows the current site in the bar at the top, so a
> > cut-and-paste may fail to capture the full, working, address.
> >
> >    Ethan
> >
> >
> >
> >
> >
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via:
> >
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$
>


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

Re: gnuplot.info unreachable (DNS failure)

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

On Tue, 09 Sep 2025 16:19:58 -0700
Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:
> 

I don't want to be a stickler, but I don't 
think changing the docs from "gnuplot.info" 
to "www.gnuplot.info" is really the right
way to think about it. 

The domain/server should be configured to
accept both versions and serve the appropriate
content. That's pretty standard issue, in my
experience.

Best,

		Ph.

> 
> > Ethan can't link to gnuplot.info (note: no leading www.).  
> 
> Good point.  I typed the address into the browser directly because
> Phillipp's reported error message was 
>    "Firefox does not trust this site because it uses a certificate
> that is not valid for gnuplot.info"
>  
> > [...] also fails, with a
> > "DNS resolution error 1001"  reported by Cloudflare. 
> > Which is strange, as tracert did get an IP,  i.e. DNS actually
> > works.  
> 
> Yes.  That's the one I'm seeing.  It's an internal error message from
> Cloudflare that I get when I request either http://gnuplot.info or
> https://gnuplot.info
> 
> It does work if I request http://www.gnuplot.info   (Chrome or
> Firefox browsers).
> 
> The hyperlink references in the pdf version of the user manual  use
> the www.gnuplot.info form.    But the html versions of the manual use
> the gnuplot.info form [no www] everywhere.
> 
> That much I can fix.
> I will modify the gnuplot.doc inline html tables and the code in
> doc2web.c to always generate output with the www prefix in the URL. 
> 
> However it is probably a common "mistake" for users to omit the www
> prefix in web queries since that is no longer as near-universal as it
> once was.  For that matter Chrome actively hides the "www." prefix
> when it shows the current site in the bar at the top, so a
> cut-and-paste may fail to capture the full, working, address.
> 
>    Ethan
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: gnuplot.info unreachable (DNS failure)

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

On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:


> Ethan can't link to gnuplot.info (note: no leading www.).

Good point.  I typed the address into the browser directly because Phillipp's 
reported error message was 
   "Firefox does not trust this site because it uses a certificate that is not
     valid for gnuplot.info"
 
> [...] also fails, with a
> "DNS resolution error 1001"  reported by Cloudflare. 
> Which is strange, as tracert did get an IP,  i.e. DNS actually works.

Yes.  That's the one I'm seeing.  It's an internal error message from Cloudflare
that I get when I request either http://gnuplot.info or https://gnuplot.info

It does work if I request http://www.gnuplot.info   (Chrome or Firefox browsers).

The hyperlink references in the pdf version of the user manual  use the
www.gnuplot.info form.    But the html versions of the manual use
the gnuplot.info form [no www] everywhere.

That much I can fix.
I will modify the gnuplot.doc inline html tables and the code in
doc2web.c to always generate output with the www prefix in the URL. 

However it is probably a common "mistake" for users to omit the www prefix in web
queries since that is no longer as near-universal as it once was.  For that matter
Chrome actively hides the "www." prefix when it shows the current site in the bar
at the top, so a cut-and-paste may fail to capture the full, working, address.

   Ethan

Re: gnuplot.info unreachable (DNS failure)

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

Am 09.09.2025 um 19:10 schrieb Ethan A Merritt:
> As of this morning I can't seem to reach gnuplot.info <http:// 
> gnuplot.info> via either http or https.   

We have to be sticklers to detail here to avoid extra confusion.

Philipp had problems accessing www.gnuplot.info via https.

Ethan can't link to gnuplot.info (note: no leading www.).

So I went ahead and tracert'd to both names.  I get an IPv4 address for 
www.gnuplot.info (204.68.111.101), whereas gnuplot.info traces to an 
IPv6 address ([2606:4700:4400::ac40:9691]).

http://www.gnuplot.info via  just works.

https://www.gnuplot.info barfs because the site certificate does not 
report itself as matching the site name.  That kind-a figures, as the 
certificate is from SourceForge, which does host that actual site, but 
not the *.gnuplot.info redirects.

https://gnuplot.info fails with a _different_ problem: neither FireFox 
nor Edge could agree with the server on any cypher algorithm both sides 
allow/support.

http://gnuplot.info also fails, with a "DNS resolution error 1001" 
reported by Cloudflare.  Which is strange, as tracert did get an IP, 
i.e. DNS actually works.