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

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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

www.gnuplot.info lagging

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

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

Re: gnuplot bad-dat parsing bug?

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

Right. OK. Thanks for pointing this out. It looked very strange before
lookin at the source, and I suppose gnuplot has to decide to do
SOMETHING with funky data.

Thanks much.

Re: gnuplot bad-dat parsing bug?

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

On Saturday, 27 January 2024 16:26:09 PST Dima Kogan wrote:
> 
> Hi. I'm observing a data-parsing problem that I think is a bug... but
> looking at the code, maybe it isn't? This has been an issue for a long
> time; it's not something new in 6.0.
> 
> To reproduce, I have this script:
> 
>   set terminal dumb 80,40
>   unset grid
>   plot '-' with linespoints
>   1  -
>   2  10
>   3  5
>   4  13
>   5  4
>   6  13
>   7  7
>   8  15
>   e
> 
> Note the bad-data line "1 -". This produces this plot:
> 
[snip] 
> 
> Note that I would expect an up/down zigzag, which ignores the whole
> bad-data line. Removing that line produces the expected output:

Not a bug.

It would be more obvious what is happening if you replace the
first column of values with some other range that doesn't start at 1.
For instance:

 set terminal dumb 80,10
  unset grid
  plot '-' with linespoints
  11  -
  12  10
  13  5
  14  13
  15  4
  16  13
  17  7
  18  15
  e

  18 +----------------------------------------------------------------------+   
  17 |-+       +         +         +          +         +    *****G****   +-|   
  16 |-+                                           *****G****   '-' ***G***-|   
  15 |-+                      *****G**********G****                       +-|   
  13 |-+            *****G****                                            +-|   
  12 |-+  *****G****     +         +          +         +         +       +-|   
  11 +----------------------------------------------------------------------+   
     0         1         2         3          4         5         6         7   

Note that the x range runs from 0 to 7 rather than from 11 to 18.

That is because the program found only a single number of the first line
of data, so it assumed you implicitly wanted "plot foo using 0:1 with lp".
I.e. if only a single column of data is given it is used as a y value and
the corresponding x value is taken from the row number, a.k.a. column 0.

The same data plotted with the command
plot '-' using 1:2 with linespoints
gives

  16 +----------------------------------------------------------------------+   
  14 |-+         +          *G*          +         *G*          +       ***-|   
  12 |-+                 ***   **                **   ****using 1:2 ***G***-|   
  10 |**              ***        **            **         ****    ***     +-|   
   8 |-+******     ***             ***       **               **G*        +-|   
   6 |-+      ***G*          +        ** + **       +           +         +-|   
   4 +----------------------------------------------------------------------+   
     12          13          14          15         16          17          18  

Both the x range and the shape of the plot is as expected.

> 
> So the first row of data has one valid column, and we then expect
> exactly one valid column from every subsequent row of data as well.
> Checked here:
> 
>   https://urldefense.com/v3/__https://github.com/gnuplot/gnuplot/blob/fbeb88eadedf927a4d778b41dd118e373f33eacb/src/datafile.c*L742__;Iw!!K-Hz7m0Vt54!me4XQdEz6ddDkXcDlBCDA3x0Nh-puPO6RfaqP9afG6Z-DMAiShcRiRh2zLMlBLfTzAetVK89V0o9M82vM3Azbm7y31YbKA$ 
> 
> Is this what we want?

It has always been that way.

If you know what columns you want to take the data from,
that's what "using" is for.
Otherwise the program has to guess, and it uses the first
row of data to make that guess.

	Ethan

gnuplot bad-dat parsing bug?

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

Hi. I'm observing a data-parsing problem that I think is a bug... but
looking at the code, maybe it isn't? This has been an issue for a long
time; it's not something new in 6.0.

To reproduce, I have this script:

  set terminal dumb 80,40
  unset grid
  plot '-' with linespoints
  1  -
  2  10
  3  5
  4  13
  5  4
  6  13
  7  7
  8  15
  e

Note the bad-data line "1 -". This produces this plot:


  8 +-----------------------------------------------------------------------+
    |         +          +         +         +         +          +      ** |
    |                                                           '-' ***A*** |
    |                                                                **     |
    |                                                              **       |
  7 |-+                                                          *A       +-|
    |                                                          **           |
    |                                                        **             |
    |                                                      **               |
    |                                                    **                 |
  6 |-+                                               *A*                 +-|
    |                                               **                      |
    |                                             **                        |
    |                                           **                          |
    |                                         **                            |
  5 |-+                                      A                            +-|
    |                                      **                               |
    |                                    **                                 |
    |                                   *                                   |
    |                                 **                                    |
    |                               **                                      |
  4 |-+                           *A                                      +-|
    |                           **                                          |
    |                         **                                            |
    |                       **                                              |
    |                     **                                                |
  3 |-+                 *A                                                +-|
    |                 **                                                    |
    |               **                                                      |
    |             **                                                        |
    |           **                                                          |
  2 |-+      *A*                                                          +-|
    |      **                                                               |
    |    **                                                                 |
    |  **                                                                   |
    |**       +          +         +         +         +          +         |
  1 +-----------------------------------------------------------------------+
    0         1          2         3         4         5          6         7

Note that I would expect an up/down zigzag, which ignores the whole
bad-data line. Removing that line produces the expected output:


  16 +----------------------------------------------------------------------+
     |           +           +           +          +           +           |
     |                                                          '-' ***A*** |
     |                                                                      |
     |                                                                      |
     |                                                                     *|
  14 |-+                                                                  +*|
     |                                                                    * |
     |                                                                    * |
     |                       A                      A                    *  |
     |                       *                      **                   *  |
     |                      * *                    * *                  *   |
  12 |-+                    * *                    *  *                 * +-|
     |                     *   *                  *    *               *    |
     |                     *   *                  *    *               *    |
     |                    *     *                 *     *             *     |
     |                    *     *                *       *            *     |
     |                   *       *               *       *           *      |
  10 |-+                 *       *              *         *          *    +-|
     |*                 *        *              *          *        *       |
     | *                *         *             *          *        *       |
     | *               *          *            *            *      *        |
     |  *              *           *           *             *     *        |
     |   *            *            *          *              *    *         |
   8 |-+  *           *             *         *               *   *       +-|
     |     *         *              *        *                 * *          |
     |     *         *               *       *                 * *          |
     |      *       *                *       *                  A           |
     |       *      *                *      *                               |
     |        *    *                  *     *                               |
   6 |-+       *   *                  *    *                              +-|
     |         *  *                    *   *                                |
     |          * *                    *   *                                |
     |           A                      * *                                 |
     |                                  * *                                 |
     |           +           +           *          +           +           |
   4 +----------------------------------------------------------------------+
     2           3           4           5          6           7           8

I can also "fix" it by adding to the script:

  set datafile missing "-"

What should the default behavior be? Should it not be ignoring the
bad-data line entirely? The block of code that handles this is here:

  https://github.com/gnuplot/gnuplot/blob/fbeb88eadedf927a4d778b41dd118e373f33eacb/src/datafile.c#L2380

With this data we have df_column[1].good == DF_BAD. The code checks for
DF_MISSING and DF_UNDEFINED, but not DF_BAD. We end up exiting the loop here:

  https://github.com/gnuplot/gnuplot/blob/fbeb88eadedf927a4d778b41dd118e373f33eacb/src/datafile.c#L2425

which leaves output==1. And then we set df_no_use_specs = output = 1 a
bit later:

  https://github.com/gnuplot/gnuplot/blob/fbeb88eadedf927a4d778b41dd118e373f33eacb/src/datafile.c#L2458

So the first row of data has one valid column, and we then expect
exactly one valid column from every subsequent row of data as well.
Checked here:

  https://github.com/gnuplot/gnuplot/blob/fbeb88eadedf927a4d778b41dd118e373f33eacb/src/datafile.c#L742

Is this what we want?

Thanks much

Re: Gnuplot 6.0 Release Announcement

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

Ethan A Merritt writes:
> Backward compatibility is given high priority in gnuplot development,
> so users should find no significant changes required for techniques or code
> they are currently using with gnuplot 5.

The documentation of the deprecations is missing at least the removal of
"set clabel" in favor of "set cntrlabel".  Can this be corrected,
please?


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

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

Gnuplot 6.0 Release Announcement

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

Gnuplot version 6.0 is now available for download.

The source tarball is here

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

The Release Notes start with a long bullet-point list of new features

     https://gnuplot.sourceforge.net/ReleaseNotes_6_0_0.html

Gnuplot is a portable command-line driven graphing utility for Linux,
MacOS, Windows, and many other platforms.   It was originally created
to allow scientists and students to visualize mathematical functions and
data interactively, but has grown to support many non-interactive uses
such as web scripting. 

Gnuplot has been supported and under active development since 1986.
This is the first new major version of gnuplot since the release of version 5
in January 2015.  It introduces extensions to the gnuplot command language,
an expanded collection of special and complex-valued functions,
additional 2D and 3D plotting styles, and support for new output protocols.

Backward compatibility is given high priority in gnuplot development,
so users should find no significant changes required for techniques or code
they are currently using with gnuplot 5.

If you are curious about what changed during the past eight years of
incremental development, you might compare the on-line demo pages
for the initial version 5 release
    https://gnuplot.sourceforge.net/demo_5.0
and the current version 6 release
    https://gnuplot.sourceforge.net/demo_6.0

Many thanks to everyone who contributed to the development,
documentation, and testing of gnuplot 6.

Happy gnuplotting in 2024 and beyond!

-- 
Ethan A Merritt
on behalf of the gnuplot development team

Pre-release source tarball for gnuplot version 6.0

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

I have placed a pre-release tarball in the testing area on SourceForge

     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-6.0.0-prerelease-test.tar.gz

Please use this to confirm successful builds or report any problems that might
hit during packaging.

There are three changes to the source since -rc3

- Replotting and mousing multiplots
        o now working much more comprehensively
        o revert "set mouse multiplot" as a separate command; it's now always in effect
- "plot with polygons" now guarantees that the border of each polygon is a closed curve
- pdf output from the cairo terminals now conforms to %PDF-1.5

My thought is that if no problems are reported, I will use the same tarball for the
full release in about 10 days.

happy gnuplotting

	Ethan

Re: Third release candidate for gnuplot 6

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

Ethan A Merritt writes:
> This is a third release candidate for version 6.0.
> Your feedback from testing of this release candidate will contribute to
> the success of a full 6.0 release by the end of the year.

The build on Cygwin is successful.  I could remove two of the patches
that were previously required.  I also found a workaround for the
problem with the missing gpinsetfigure.tex when building the
documentation: Prepend "no_figure" to the makefile targets, apparently
the dependencies are not complete and make is not picking this
requirement up automatically.  Speaking of dependencies, I still cannot
build the documentation in parallel mode, although that works for the
actual compilation thankfully.



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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Third release candidate for gnuplot 6

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

Ethan A Merritt <me...@uw...> writes:

> After a resize, the terminal requests a replot. But if the most recent
> previous plot command was part of a multiplot, the "replot" is
> supposedly replaced by "remultiplot". That "most recent previous plot"
> test could fail if you have done other things ("clear" "test palette"
> "set term" ...) since the multiplot was displayed. If so, you can
> recover with an explicit "remultiplot" from the command line.

OK. From what I see, this sequence works ONLY if "set mouse multiplot".
So if I do this:

  set mouse multiplot
  set multiplot layout 2,1
  plot x
  plot x*x
  unset multiplot

Then I can resize the window, and the multiplot is resized with it. If I
don't "set mouse multiplot" then the plots are NOT resized.

Re: Third release candidate for gnuplot 6

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

On Wednesday, 15 November 2023 20:04:31 PST Dima Kogan wrote:
> Ah yes. I don't multiplot very often, and clearly missed this important
> detail of its operation (that you need to "unset multiplot").
> 
> This new logic is great. Thank you very much for implementing that. Two
> notes:
> 
> - Should we remultiplot when a window is resized? Currently we replot
>   when it is resized, so the whole multiplot is replaced with one of the
>   subplots. They all come back during a remultiplot, but that seems like
>   an extra step.

After a resize, the terminal requests a replot.  But if the most recent
previous plot command was part of a multiplot, the "replot" is supposedly
replaced by "remultiplot".   That "most recent previous plot" test could fail
if you have done other things ("clear" "test palette" "set term" ...) since the
multiplot was displayed.  If so, you can recover with an explicit
"remultiplot" from the command line.  

There may well be other corner cases where the resize operation
fails to substitute "remultiplot" but for me it is working in -rc3 already. 
If you have a reproducible example where it fails, please provide the details.
Maybe it's terminal-dependent?  I think a volatile data source
(e.g. reading from '-') might also bypass the normal replot processing.

> - Can/should we allow independent panning/zooming in each subplot? I
>   imagine this would be a lot of work, but I don't know.

That's a whole other can of worms.  Nothing in the remultiplot code
makes it any easier than it was before to achieve this.

It would, however, be easy to provide a way to turn off pan/zoom
for individual plots.  That way you could use the mouse to pan/zoom
the one active (most recent) plot in the multiplot and the others would
be redrawn in their original state.  In some cases that would be better,
in other cases worse.  It just depends on whether the plots share a
consistent set of axis ranges and region of interest.

> Thank you very much. I'm now using the 6.0-rc3 tag for all my daily
> work, so hopefully I'll catch any regressions.

Great.  I am hoping that all regressions were caught in -rc1 and -rc2.
The multiplot stuff is new, so bug reports are welcome but I don't
think that counts as a regression.

	Ethan

Re: Third release candidate for gnuplot 6

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

Ah yes. I don't multiplot very often, and clearly missed this important
detail of its operation (that you need to "unset multiplot").

This new logic is great. Thank you very much for implementing that. Two
notes:

- Should we remultiplot when a window is resized? Currently we replot
  when it is resized, so the whole multiplot is replaced with one of the
  subplots. They all come back during a remultiplot, but that seems like
  an extra step.

- Can/should we allow independent panning/zooming in each subplot? I
  imagine this would be a lot of work, but I don't know.

Thank you very much. I'm now using the 6.0-rc3 tag for all my daily
work, so hopefully I'll catch any regressions.

Re: Third release candidate for gnuplot 6

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

On Wednesday, 15 November 2023 13:56:28 PST Dima Kogan wrote:
> !-------------------------------------------------------------------|
>   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.
> |-------------------------------------------------------------------!
> 
> Hi Ethan. Thanks for pushing this out. I'm trying the 6.0-rc3 tag from
> git.
> 
> A question below.
> 
> 
> Ethan A Merritt <me...@uw...> writes:
> 
> > - Replotting and mousing multiplots
> >         o new commands "remultiplot", "set mouse multiplot"
> >         o command sequence to regenerate full multiplot is saved to a datablock
> 
> Can you talk a bit more about this? I wrote a simple script (tst.gp):
> 
>   set multiplot layout 2,1
>   plot x
>   plot x*x
> 
> I run "gnuplot" and "load tst.gp". I see the plots come up, as expected.
> If I do a "replot" then I see the plots being redrawn, but without
> clearing what's behind them, so you get an unusable image. 

Right. That's because you are still at the stage of creating the multiplot.
That stage begins with the commands "set multiplot ..." and ends with
the command "unset multiplot".    The intervening commands are
stored to a temporary buffer and then moved to $GPVAL_LAST_MULTIPLOT
when the "unset multiplot" completes.   At that point the entire sequence
of commands is available to regenerate the original multiplot using the
"remuptiplot" command.

> remultiplot does this:
> 
>   multiplot> remultiplot
>              no datablock named $GPVAL_LAST_MULTIPLOT
> 
> I also tried to "set mouse multiplot", but that doesn't appear to do
> anything different: I can still use the right button to try to zoom, but
> it doesn't do anything. This is with the x11 and qt terminals.

Yeah, at this stage the support for "set mouse multiplot" is pretty rough.
I am in the process of smoothing it out in the master branch and will
merge the improved version back into 6.0 before the full release.

What does work already in 6.0rc3
	2D scroll/pan/zoom
	hot keys (replot toggle log-scale arrow keys ...)

Works in master branch but not in -rc3
	3D mouse rotations
	sanity check the commands inside  $GPVAL_LAST_MULTIPLOT
	multiplots containing 'load' commands
	multiplots using function blocks

Still not working but seems possible
	limit mouse coordinate readout to the single active plot in the multiplot

Not going to happen any time soon
	mouse readout for the non-active plots as well (this what everyone has
	wanted since forever, but the "remultiplot" work isn't going to get there).

> 
> I haven't checked if these are different from the behavior in previous
> releases. It would be great, though, if you could resize a multiplot
> window, and see all the plots be redrawn. Or if you could interactively
> zoom in multiplots.

That should work in rc3.
Try the following test script

####################################################
# demo script for multiplot mousing in 6.0.rc3
set mouse multiplot
set multiplot layout 1,3
plotno = 0.0
do for [i=1:3] {
    plotno = real(i)
    plot sin(x/plotno)/plotno title sprintf("Plot #%g",plotno)
}
unset multiplot
print "about to replot"
remultiplot
print "done, now you can pan/zoom/replot"
####################################################


thanks for testing

	Ethan