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

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

Re: Third release candidate for gnuplot 6

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

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

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.

Thanks!

Third release candidate for gnuplot 6

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

The "testing" directory on SourceForge now has a tarball for gnuplot-6-0-rc3

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-6.0.rc3.tar.gz

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 most visible addition since rc2 is preliminary support for redrawing
or mousing complete multiplots.  The mousing part still has a lot of rough edges
so it is off by default but can be enabled by
	set mouse multiplot
The redraw previous multiplot part works well.  If gnuplot knows that the
immediately previous plot command was part of a multiplot, then "replot"
will redraw the full mulitplot.  If some other plot has intervened, then the
previous multiplot can still be recreated by "remultiplot".

Release Notes date:  13-Nov-2023

                Changes between 6.0-rc2 and -rc3
                ================================

- Replotting and mousing multiplots
        o new commands "remultiplot", "set mouse multiplot"
        o command sequence to regenerate full multiplot is saved to a datablock
- Additional keyentry options to construct custom keys
        o keyentry "text" can be used to place a secondary title in the key
- Minor fixes
        o correct build of postscript terminal when libgd and cairo are not present
        o strip trailing CR from function blocks read from a dos file
        o use 64-bit integers for iteration
        o "unset pointintervalbox" disables the box rather than setting it to default size
        o setting minitic scale to 0 does not disable the corresponding grid lines
        o use of stacked histograms with variable number of data columns

        Features introduced in version 6
        ================================
For a detailed list of new features, with illustrations, see
  http://gnuplot.info/docs_6.0/NewFeatures.html

For more example plots see
  http://gnuplot.info/demo_6.0/

  - Function blocks and scoped variables
  - Larger collection of special and complex-valued functions
  - New plot styles
        o 2D plot style `with surface` works in 2D polar coordinates to produce a
          solid-fill gridded representation of the plane. This is analogous to the
          use of dgrid3d and pm3d to produce a 3D gridded surface.
        o 2D plot style `with sectors` renders one annular segment ("sector") for
          each line of input data. This style can generate pie and donut charts,
          windrose charts, and a polar equivalent to sparse-matrix heatmaps.
        o 2D plot style `with lines` now has a filter option `sharpen`.
          This filter detects spikes in a function plot that would be missed or
          under-represented due to coarse sampling.  It adds an additional
          sampling point at the location of each such peak.
        o 3D plot style `with contourfill` produces 2D or 3D surfaces with
          distinct z-ranges indicated by solid color fill.
  - Hulls, masks, and smoothing
        o A cluster of 2D points can be replaced by a bounding polygon ("hull").
          Both convex hulls and concave hulls (χ-shapes) are supported.
        o Any hull or other closed path can be used as a mask to display only
          selected regions of a pm3d surface or image plot.
        o New smoothing option "smooth path" can be used on 2D and 3D curves
          that are not monotonic on x or y.  This allows smoothing of hulls.
  - Named palettes
        o The current palette can be saved to a named colormap for future us.
        o A predefined palette named "viridis" is provided.
        o Plots can specify a previously saved palette by name.
          This permits the use of multiple palettes in a single plot command.
        o Named palettes can be edited to contain an alpha channel.
  - New built-in functions and array operations
        o palette(z) returns the current RGB palette color mapping for z.
        o rgbcolor("name") returns the 32bit ARGB value for a named color.
        o index(Array, element) returns the first index i for which Array[i]
          is equal to element.
        o split("string", "separator") unpacks the fields in a string into
          an array of strings.
        o join(array, "separator") is the complement to split().
          It concatenates the elements of a string array into a single string.
        o `stats <non-existent file>` yields a testable value with no error;
          useful to avoid errors or warnings in scripts.
  - Program control flow
        o New syntax if {...} else if {...} else {...}
        o XDG base directory conventions for configuration files are supported.
        o `unset warnings` suppresses output of warning messages to the console.
        o The `fit` command is protected by exception handling. Control always
          returns to the next line of input even in the case of fit errors.
          On return FIT_ERROR is non-zero if an error occurred.
        o "Watchpoints"  are target values associated with individual plots
          in a graph. As that plot is drawn, each component line segment is
          monitored to see if its endpoints bracket the target value of a
          watchpoint coordinate (x, y, or z) or function f(x,y).
          If a match is found, the [x,y] coordinates of the match point are
          saved for later use.  Possible uses include
                - find the intersection points of two curves
                - find zeros of a function
                - find and notate where a dependent variable or function f(x,y)
                  crosses a threshold value
                - use the mouse to track values along multiple plots simultaneously
  - New terminals and terminal options
        o Terminals that display graphics in the same window as text entry now
          support pseudo-mousing; i.e. they respond to arrow keys and other
          hot-key bindings during "pause mouse".
        o New terminals kittygd and kittycairo provide in-window graphics for
          terminal emulators that support the kitty protocol.
        o New terminal webp generates a single frame or an animation sequence
          using webp encoding. Frames are generated using pngcairo,
          then encoded through the WebPAnimEncoder API.
        o New terminal block for text-mode pseudo-graphics uses Unicode block
          or Braille characters to offer improved resolution compared to the
          dumb or caca terminals.
        o latex terminals standalone mode updated to work with texlive2023
  - Miscellaneous other new features
        o Time unit settings for major and minor axis tics.  For example,
          minor tic marks can be placed at exactly one month intervals.
        o The character sequence $# in a using specifier evaluates to the total
          number of columns available in the current line of data.
          "plot FOO using 0:(column($# - 1))" plots the last-but-one field of each row.
        o keyword binvalue=avg plots the average, rather than the sum, of binned data.
        o "set colorbox bottom" places the color box underneath the plot.
        o "set pm3d spotlight" adds a user-controlled spotlight to the lighting model.
        o New key layout options to force specific width or number of columns.
          Automatic positioning of the key on the page can be manually tweaked
          by giving an offset.
        o "set isotropic" adjusts the axis scaling in both 2D and 3D plots such
          that x, y, and z axes all have the same scale.
        o Text rotation angles are not limited to integral degree values.
        o Data-driven color assignments in plot style "histograms".

	happy gnuplotting,

		Ethan

Gnuplot 5.4.10 release (fixes build regressions in 5.4.9)

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

I have placed a release tarball of 5.4.10 on SourceForge

    sourceforge.net/projects/gnuplot/files/gnuplot/5.4.10/gnuplot-5.4.10.tar.gz

The 5.4.10 patchlevel release repairs a regression in 5.4.9 that caused
a build failure in the postscript terminal if neither cairo nor libgd
support was configured.

This is probably the final update to version 5.4,
as a full release of version 6 is expected by the end of this year.

Changes in 5.4.10
=================
* FIX    postscript: build failed in 5.4.9 if neither gd nor cairo libraries present
* FIX    data-dependent variable point properties in polar plots
* FIX    configure script modified to work with macOS+Homebrew
* CHANGE use 64-bit integers for iteration (allows iteration over dates)

    Ethan

Gnuplot 5.4.10 release (fixes build regressions in 5.4.9)

[Ethan A M. <eam...@gm...>]

I have placed a release tarball of 5.4.10 on SourceForge

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

The 5.4.10 patchlevel release repairs a regression in 5.4.9 that caused
a build failure in the postscript terminal if neither cairo nor libgd
support was configured.

This is probably the final update to version 5.4,
as a full release of version 6 is expected by the end of this year.

Changes in 5.4.10
=================
* FIX    postscript: build failed in 5.4.9 if neither gd nor cairo libraries present
* FIX    data-dependent variable point properties in polar plots
* FIX    configure script modified to work with macOS+Homebrew
* CHANGE use 64-bit integers for iteration (allows iteration over dates)

    Ethan

Re: More build problems with rc2

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

[snip]

> 
> Let me actually say one more thing. You can ask apt to install
> everything needed to build a package:
> 
>   apt-get build-dep gnuplot
> 
> When that is done, you'll be guaranteed to be able to build the
> gnuplot Debian package. Granted, you're trying to build a later
> version, from source, with a possibly-different configuration, but it
> should still be largely the same.

Hah - that's pretty clever. I would never
have thought of that, but it makes total
sense.

Thanks!

Re: More build problems with rc2

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

"Philipp K. Janert via gnuplot-beta" <gnu...@li...> writes:

> Thank you, that's very helpful. Those pkgs do exist for my distro, no
> problem.

Let me actually say one more thing. You can ask apt to install
everything needed to build a package:

  apt-get build-dep gnuplot

When that is done, you'll be guaranteed to be able to build the gnuplot
Debian package. Granted, you're trying to build a later version, from
source, with a possibly-different configuration, but it should still be
largely the same.

Using a container as build environment

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

I recently compiled the gnuplot6 release 
candidate. (Thank you - exciting to see!)

I did not want to clutter my system with
all the required dev packages, and used a
Docker container for isolation. That worked
well, here are instructions if anyone wants
to try it as well:

https://janert.me/blog/2023/containers-as-build-environments/

(This was written over the weekend, and hence
does not yet take Dima's hints regarding Qt 
into account, but there is no doubt that, with
the right package names, the Qt terminal would
build as well.)

In any case, I thought it was a good experience,
and one that I can generally recommend.

Best,

		Ph.

-- 

Philipp K. Janert
www.janert.me