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

Re: Version 5.2.5 Release

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

Hi Ethan (and others),

Just to let you know that the OSX binary is available now from
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
For the first time, I compiled with the libgd library, so that the GIF,
JPEG and PNG terminals are available as well. (As is the PDF terminal, like
in prior versions.)

A small note: Can you update http://gnuplot.info/download.html#OSX (at the
top, it says "The most recent release was 5.2.3 (May 2018)").

Regards,

Erik


On Sun, Oct 7, 2018 at 12:02 AM sfeam via gnuplot-beta <
gnu...@li...> wrote:

> I have uploaded a tarball of version 5.2.5 to SourceForge
> for immediate release.
>
>   https://sf.net/projects/gnuplot/files/gnuplot/5.2.5/
>
> Many thanks to everyone who tested the pre-release 5.2.5a and reported
> back success on Windows and OSX.  The final version has two minor fixes
> that were not in the testing version.
>
>         cheers,
>
>                 Ethan
>
>
>                  GNUPLOT Version 5.2.5 Release Notes
>                 ===================================
>
> These release notes are for version 5.2 patchlevel 5 (5.2.5).
> This release contains bug-fixes, a few changes back-ported from the
> development version, and a few new features.  The most notable fixes are
> (1) improved clipping of lines or other plot elements that would otherwise
> extend beyond the edges of the plot.
> (2) in versions 5.2.0 through 5.2.4 function plots in parametric and polar
> modes did not work with logscale x axis.
>
> Please see the ChangeLog file for a complete list of changes made during
> the
> course of development from 5.0 to 5.2.
>
> Release Notes date: 06-October-2018
>
> CHANGES IN 5.2.5
> ================
>
> * NEW "set pm3d depthorder base" sorts pm3d quadrangles by projecting to
> z=0
> * NEW "set jitter vertical" displaces y coordinate rather than x coordinate
> * NEW array size can be determined automatically from the initializer
> * CHANGE place titles along x axis in plots with columnstacked histograms
> * CHANGE equivalent slope constraint for mcs splines at both ends of the
> range
> * CHANGE treat imaginary values plotted from a using spec as UNDEFINED
> (NaN)
> * CHANGE allow "reset" between plots in a multiplot layout
> * CHANGE Deprecate linux and vgagl terminals (to be removed in 5.3)
> * CHANGE placement of axis and tic labels in 3D projections on to xz or yz
> plane
> * CHANGE default to ./configure --without-wx-multithreading
> * FIX parametric function plots did not work with logscale x (regression
> in 5.2.0-4)
> * FIX polar mode "set trange" was assumed to use radians, now it tracks
> "set angle"
> * FIX clip polar grid lines and ticks to x/y range limits
> * FIX clipping of plot "with lines" when axes are nonlinear (regression
> from 5.0)
> * FIX clipping of all elements in finanacebars/candlesticks/boxplots
> * FIX clipping of 3D splot "with labels"
> * FIX strange interaction of "noautoscale" with blank data lines
> * FIX alignment of boxed text to center for eps/cairolatex
> * FIX incompatibility of "pm3d depthorder" and rgb color taken from data
> column
> * FIX aqua terminal font changes in enhanced text mode
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Version 5.2.5 Release

[sfeam <sf...@us...>]

I have uploaded a tarball of version 5.2.5 to SourceForge 
for immediate release.

  https://sf.net/projects/gnuplot/files/gnuplot/5.2.5/

Many thanks to everyone who tested the pre-release 5.2.5a and reported
back success on Windows and OSX.  The final version has two minor fixes
that were not in the testing version.

	cheers,

		Ethan
	

                 GNUPLOT Version 5.2.5 Release Notes
                ===================================

These release notes are for version 5.2 patchlevel 5 (5.2.5).
This release contains bug-fixes, a few changes back-ported from the
development version, and a few new features.  The most notable fixes are
(1) improved clipping of lines or other plot elements that would otherwise
extend beyond the edges of the plot. 
(2) in versions 5.2.0 through 5.2.4 function plots in parametric and polar
modes did not work with logscale x axis.

Please see the ChangeLog file for a complete list of changes made during the
course of development from 5.0 to 5.2.

Release Notes date: 06-October-2018

CHANGES IN 5.2.5
================

* NEW "set pm3d depthorder base" sorts pm3d quadrangles by projecting to z=0
* NEW "set jitter vertical" displaces y coordinate rather than x coordinate
* NEW array size can be determined automatically from the initializer
* CHANGE place titles along x axis in plots with columnstacked histograms
* CHANGE equivalent slope constraint for mcs splines at both ends of the range
* CHANGE treat imaginary values plotted from a using spec as UNDEFINED (NaN)
* CHANGE allow "reset" between plots in a multiplot layout
* CHANGE Deprecate linux and vgagl terminals (to be removed in 5.3)
* CHANGE placement of axis and tic labels in 3D projections on to xz or yz plane
* CHANGE default to ./configure --without-wx-multithreading
* FIX parametric function plots did not work with logscale x (regression in 5.2.0-4)
* FIX polar mode "set trange" was assumed to use radians, now it tracks "set angle"
* FIX clip polar grid lines and ticks to x/y range limits
* FIX clipping of plot "with lines" when axes are nonlinear (regression from 5.0)
* FIX clipping of all elements in finanacebars/candlesticks/boxplots
* FIX clipping of 3D splot "with labels"
* FIX strange interaction of "noautoscale" with blank data lines
* FIX alignment of boxed text to center for eps/cairolatex
* FIX incompatibility of "pm3d depthorder" and rgb color taken from data column
* FIX aqua terminal font changes in enhanced text mode

Re: Pre-release testing version of 5.2.5

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

----- Original Message -----

> From: sfeam via gnuplot-beta 
> To: gnuplot-beta
> Cc: 
> Date: 2018/10/2, Tue 13:33
> Subject: Pre-release testing version of 5.2.5
> 
> I have uploaded a tarball of a testing version of 5.2.5 to
> the "testing" folder on SourceForge.  The source and the executable
> built from it identify as 5.2.5a  (note the "a").
> 
>   
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.2.5a.tar.gz
> 
> Please test build on your favorite platform and report any problems here.
> If all goes well, I will prepare a new tarball for the official 5.2.5
> release.
> 
>     cheers,
> 
>         Ethan
>     
> 
>                  GNUPLOT Version 5.2.5 Release Notes
>                 ===================================
> 
> These release notes are for version 5.2 patchlevel 5 (5.2.5).
> This release contains bug-fixes, a few changes back-ported from the
> development version, and a few new features.  The most notable fixes are
> (1) improved clipping of lines or other plot elements that would otherwise
> extend beyond the edges of the plot. 
> (2) in versions 5.2.0 through 5.2.4 function plots in parametric and polar
> modes did not work with logscale x axis.
> 
> Please see the ChangeLog file for a complete list of changes made during the
> course of development from 5.0 to 5.2.
> 
> Release Notes date: 01-October-2018
> 
> 
> CHANGES IN 5.2.5
> ================
> 
> * NEW "set pm3d depthorder base" sorts pm3d quadrangles by projecting 
> to z=0
> * NEW "set jitter vertical" displaces y coordinate rather than x 
> coordinate
> * NEW array size can be determined automatically from the initializer
> * CHANGE equivalent slope constraint for mcs splines at both ends of the range
> * CHANGE treat imaginary values plotted from a using spec as UNDEFINED (NaN)
> * CHANGE allow "reset" between plots in a multiplot layout
> * CHANGE Deprecate linux and vgagl terminals (to be removed in 5.3)
> * CHANGE placement of axis and tic labels in 3D projections on to xz or yz plane
> * CHANGE default to ./configure --without-wx-multithreading
> * FIX parametric function plots did not work with logscale x (regression in 
> 5.2.0-4)
> * FIX polar mode "set trange" was assumed to use radians, now it 
> tracks "set angle"
> * FIX clip polar grid lines and ticks to x/y range limits
> * FIX clipping of plot "with lines" when axes are nonlinear 
> (regression from 5.0)
> * FIX clipping of all elements in finanacebars/candlesticks/boxplots
> * FIX clipping of 3D splot "with labels"
> * FIX strange interaction of "noautoscale" with blank data lines
> * FIX alignment of boxed text to center for eps/cairolatex
> * FIX incompatibility of "pm3d depthorder" and rgb color taken from 
> data column
> * FIX aqua terminal font changes in enhanced text mode
> 


I succuessfully built windows binaries for 32 and 64 bit.
all.dem also went well.

Tatsuro

Pre-release testing version of 5.2.5

[sfeam <sf...@us...>]

I have uploaded a tarball of a testing version of 5.2.5 to
the "testing" folder on SourceForge.  The source and the executable
built from it identify as 5.2.5a  (note the "a").

  https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.2.5a.tar.gz

Please test build on your favorite platform and report any problems here.
If all goes well, I will prepare a new tarball for the official 5.2.5
release.

	cheers,

		Ethan
	

                 GNUPLOT Version 5.2.5 Release Notes
                ===================================

These release notes are for version 5.2 patchlevel 5 (5.2.5).
This release contains bug-fixes, a few changes back-ported from the
development version, and a few new features.  The most notable fixes are
(1) improved clipping of lines or other plot elements that would otherwise
extend beyond the edges of the plot. 
(2) in versions 5.2.0 through 5.2.4 function plots in parametric and polar
modes did not work with logscale x axis.

Please see the ChangeLog file for a complete list of changes made during the
course of development from 5.0 to 5.2.

Release Notes date: 01-October-2018


CHANGES IN 5.2.5
================

* NEW "set pm3d depthorder base" sorts pm3d quadrangles by projecting to z=0
* NEW "set jitter vertical" displaces y coordinate rather than x coordinate
* NEW array size can be determined automatically from the initializer
* CHANGE equivalent slope constraint for mcs splines at both ends of the range
* CHANGE treat imaginary values plotted from a using spec as UNDEFINED (NaN)
* CHANGE allow "reset" between plots in a multiplot layout
* CHANGE Deprecate linux and vgagl terminals (to be removed in 5.3)
* CHANGE placement of axis and tic labels in 3D projections on to xz or yz plane
* CHANGE default to ./configure --without-wx-multithreading
* FIX parametric function plots did not work with logscale x (regression in 5.2.0-4)
* FIX polar mode "set trange" was assumed to use radians, now it tracks "set angle"
* FIX clip polar grid lines and ticks to x/y range limits
* FIX clipping of plot "with lines" when axes are nonlinear (regression from 5.0)
* FIX clipping of all elements in finanacebars/candlesticks/boxplots
* FIX clipping of 3D splot "with labels"
* FIX strange interaction of "noautoscale" with blank data lines
* FIX alignment of boxed text to center for eps/cairolatex
* FIX incompatibility of "pm3d depthorder" and rgb color taken from data column
* FIX aqua terminal font changes in enhanced text mode

Re: libconfig problem in Windows binary packages

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

----- Original Message -----
> From: Tatsuro MATSUOKA >
> To: Merritt Ethan < gnuplot-beta@t
> Cc: 
> Date: 2018/9/8, Sat 10:25
> Subject: Re: libconfig problem in Windows binary packages
> 
> ----- Original Message -----
> 
>>  From: Ethan A Merritt via gnuplot-beta 
> 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2018/9/8, Sat 04:18
>>  Subject: libconfig problem in Windows binary packages
>> 
>>  Bug report #2069 describes a gnuplot failure that I believe I have traced 
> to
>>  a bad (buggy) version of libconfig in the WIndows packages.
>> 
>>  Gnuplot bug tracker:
>>      https://sourceforge.net/p/gnuplot/bugs/2069/
>> 
>>  libconfig bug reports elsewhere
>>      https://bugs.gentoo.org/650332
>>      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895470
>>      https://bugs.freedesktop.org/show_bug.cgi?id=105492
>> 
>>  As I understand the upstream descriptions, libconfig version 2.13.0
>>  incorrectly resets the locale to the system default.  This overwrites
>>  whatever the program has set.  In gnuplot's case this means that
>>  after a call to libconfig the working LC_NUMERIC environment is
>>  no longer "C".  If the default environment uses comma rather than
>>  period for a decimal point, tbad things happen.
>> 
>>  So far as I can tell, this error is still present in the current git 
> repository
>>  for libfontconfig, so you must downgrade (rather than upgrade) to get
>>  a working library.  There is an item in the README for version 2.13.1
>>  that says this has been fixed, but when I look at the source that 
> doesn't
>>  seem to be true. 
>> 
>>  I recall that there was discussion earlier this year about whether
>>  the fontconfig library and tools should be included in the Windows
>>  gnuplot packages.  At the time there was no strong argument 
>>  against including it.    But if the current libconfig is not reliable,
>>  maybe the discussion should be re-opened?
>> 
>>      Ethan
>> 
> I made reply to the bug #2069 before seeing this post
> 
> In my enviroment, it works as expected.
> Perhaps it is environmetal dependent.
> 
> At 5.2.4 build, I used dependency libraries distribiuted by Msys2.
> At that time version of libfonfconfig is 2.13.1.
> 
> 
> I have updated libraries on Msys2 system.
> Now Version of fontconfig is 2.13.1.
> 
> I will re-packge windows binaries for 5.2.4 on this weekend.
> 
Done!

Tatsuro

Re: libconfig problem in Windows binary packages

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

----- Original Message -----

> From: Ethan A Merritt via gnuplot-beta 

> To: gnuplot-beta
> Cc: 
> Date: 2018/9/8, Sat 04:18
> Subject: libconfig problem in Windows binary packages
> 
> Bug report #2069 describes a gnuplot failure that I believe I have traced to
> a bad (buggy) version of libconfig in the WIndows packages.
> 
> Gnuplot bug tracker:
>     https://sourceforge.net/p/gnuplot/bugs/2069/
> 
> libconfig bug reports elsewhere
>     https://bugs.gentoo.org/650332
>     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895470
>     https://bugs.freedesktop.org/show_bug.cgi?id=105492
> 
> As I understand the upstream descriptions, libconfig version 2.13.0
> incorrectly resets the locale to the system default.  This overwrites
> whatever the program has set.  In gnuplot's case this means that
> after a call to libconfig the working LC_NUMERIC environment is
> no longer "C".  If the default environment uses comma rather than
> period for a decimal point, tbad things happen.
> 
> So far as I can tell, this error is still present in the current git repository
> for libfontconfig, so you must downgrade (rather than upgrade) to get
> a working library.  There is an item in the README for version 2.13.1
> that says this has been fixed, but when I look at the source that doesn't
> seem to be true. 
> 
> I recall that there was discussion earlier this year about whether
> the fontconfig library and tools should be included in the Windows
> gnuplot packages.  At the time there was no strong argument 
> against including it.    But if the current libconfig is not reliable,
> maybe the discussion should be re-opened?
> 
>     Ethan
> 
I made reply to the bug #2069 before seeing this post

In my enviroment, it works as expected.
Perhaps it is environmetal dependent.

At 5.2.4 build, I used dependency libraries distribiuted by Msys2.
At that time version of libfonfconfig is 2.13.1.


I have updated libraries on Msys2 system.
Now Version of fontconfig is 2.13.1.

I will re-packge windows binaries for 5.2.4 on this weekend.

Tatsuro

> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

libconfig problem in Windows binary packages

[Ethan A M. <sf...@us...>]

Bug report #2069 describes a gnuplot failure that I believe I have traced to
a bad (buggy) version of libconfig in the WIndows packages.

Gnuplot bug tracker:
    https://sourceforge.net/p/gnuplot/bugs/2069/

libconfig bug reports elsewhere
    https://bugs.gentoo.org/650332
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895470
    https://bugs.freedesktop.org/show_bug.cgi?id=105492

As I understand the upstream descriptions, libconfig version 2.13.0
incorrectly resets the locale to the system default.  This overwrites
whatever the program has set.  In gnuplot's case this means that
after a call to libconfig the working LC_NUMERIC environment is
no longer "C".  If the default environment uses comma rather than
period for a decimal point, tbad things happen.

So far as I can tell, this error is still present in the current git repository
for libfontconfig, so you must downgrade (rather than upgrade) to get
a working library.  There is an item in the README for version 2.13.1
that says this has been fixed, but when I look at the source that doesn't
seem to be true. 

I recall that there was discussion earlier this year about whether
the fontconfig library and tools should be included in the Windows
gnuplot packages.  At the time there was no strong argument 
against including it.    But if the current libconfig is not reliable,
maybe the discussion should be re-opened?

	Ethan

Re: commit [edccc6] perhaps breaks caca term build

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

----- Original Message -----

>>  In file included from ../../gnuplot-gnuplot-main/src/term.h:227:0,
>>                   from ../../gnuplot-gnuplot-main/src/term.c:1189:
>>  ../../gnuplot-gnuplot-main/term/caca.trm: In function 
> 'CACA_init_display':
>>  ../../gnuplot-gnuplot-main/term/caca.trm:771:23: error: 
> 'current_locale' undeclared (first use in this function); did you mean 
> 'surface_lscale'?
>>      setlocale(LC_TIME, current_locale != NULL ? current_locale : 
> "C");
>>                         ^~~~~~~~~~~~~~
>>                         surface_lscale
>>  ../../gnuplot-gnuplot-main/term/caca.trm:771:23: note: each undeclared 
> identifier is reported only once for each function it appears in
>>  make[4]: *** [Makefile:910: term.o] Error 1
>> 
>> 
>>  Tatsuro
> 
> My bad.  I missed that one.
> I am starting to think that all this locale fixup should be done by the 
> "set term"
> command rather than by individual terminal drivers.
> 
>     Ethan
> 


Thanks for quick fix.

> I am starting to think that all this locale fixup should be done by the 
> "set term"
> command rather than by individual terminal drivers.

It's a nice change. 

Tatsuro

Re: commit [edccc6] perhaps breaks caca term build

[Ethan A M. <sf...@us...>]

On Thursday, September 6, 2018 4:11:53 PM PDT Tatsuro MATSUOKA wrote:
> In file included from ../../gnuplot-gnuplot-main/src/term.h:227:0,
>                  from ../../gnuplot-gnuplot-main/src/term.c:1189:
> ../../gnuplot-gnuplot-main/term/caca.trm: In function 'CACA_init_display':
> ../../gnuplot-gnuplot-main/term/caca.trm:771:23: error: 'current_locale' undeclared (first use in this function); did you mean 'surface_lscale'?
>     setlocale(LC_TIME, current_locale != NULL ? current_locale : "C");
>                        ^~~~~~~~~~~~~~
>                        surface_lscale
> ../../gnuplot-gnuplot-main/term/caca.trm:771:23: note: each undeclared identifier is reported only once for each function it appears in
> make[4]: *** [Makefile:910: term.o] Error 1
> 
> 
> Tatsuro

My bad.  I missed that one.
I am starting to think that all this locale fixup should be done by the "set term"
command rather than by individual terminal drivers.

	Ethan

commit [edccc6] perhaps breaks caca term build

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

In file included from ../../gnuplot-gnuplot-main/src/term.h:227:0,
                 from ../../gnuplot-gnuplot-main/src/term.c:1189:
../../gnuplot-gnuplot-main/term/caca.trm: In function 'CACA_init_display':
../../gnuplot-gnuplot-main/term/caca.trm:771:23: error: 'current_locale' undeclared (first use in this function); did you mean 'surface_lscale'?
    setlocale(LC_TIME, current_locale != NULL ? current_locale : "C");
                       ^~~~~~~~~~~~~~
                       surface_lscale
../../gnuplot-gnuplot-main/term/caca.trm:771:23: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [Makefile:910: term.o] Error 1


Tatsuro

Re: By default do not use multithreaded wxtgtk （commit [8fc9b3]）

[Ethan A M. <sf...@us...>]

On Thursday, September 6, 2018 3:28:24 PM PDT Tatsuro MATSUOKA wrote:
> In development source,
> commit [8fc9b3]
> 
> By default do not use multithreaded wxtgtk 
> 
> I have been using --with-wx-single-threaded for Unixy build for a long time.
> 
> Is there any plan that this commit will be back-ported to stable source?

Yes.

I have not caught up with back-porting recent changes to 5.3 for inclusion in
the stable branch also, but this change is definitely on the list.

I can no longer build a working wxt terminal for linux with multithreading
enabled, and that is true for both the stable and development versions.

	Ethan

By default do not use multithreaded wxtgtk （commit [8fc9b3]）

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

In development source,
commit [8fc9b3]

By default do not use multithreaded wxtgtk 

I have been using --with-wx-single-threaded for Unixy build for a long time.

Is there any plan that this commit will be back-ported to stable source?

Tatsuro

Re: Feature question: waiting on a plot window

[sfeam <sf...@us...>]

On Sunday, 19 August 2018 23:52:05 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Sunday, 19 August 2018 20:25:24 Dima Kogan wrote:
> >> Dima Kogan <gn...@di...> writes:
> >>
> >> > Ethan A Merritt <sf...@us...> writes:
> >> >
> >> >> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
> >> >>>
> >> >>> I'm looking for a feature that (I think) doesn't exist currently. Want
> >> >>> to ask first, in case something DOES exist that I'm not seeing.
> >> >>
> >> >> The command you are looking for is
> >> >> 	pause mouse close
> >>
> >> This works in its most basic form, which is awesome. Thanks! But I'm now
> >> going to be a pain in the butt. For a gnuplot-using application to work
> >> reasonably, this needs to only wait for a window-close event when one is
> >> coming: i.e. when a window is open. Scenarios that could happen:
> >>
> >> 1. User already closed the window before I send my "pause mouse close"
> >
> > That sounds like a case of "well then don't do that".
> > If the parent program sends the plot command and the pause command
> > in immediate succession the time window in which that race could happen
> > would be very small.  If the commands do not come in immediate
> > succession then maybe the program logic needs re-thinking.
> > Can you give a more complete example of the flow of events?
> >
> >> 2. We're using a non-interactive terminal (dumb, pdf, etc etc)
> >> Ideas on handling that?
> >
> > So far as I know, in that case the next <\n> in the input stream
> > will terminal the "pause" command.  Does that not work for you?
> 
> I played with it a bit more just now, and it's good-enough. It would be
> NICE if "pause mouse close" could know if there's anything to
> potentially wait for, but I guess I don't strictly need it.

If you have identified a sequence of reasonable events that causes gnuplot
to lock up entirely, I would consider that a bug.  In the case of 
"pause mouse" I agree that if you issue this command in the state that
the current terminal is mouseable but the most recent plot window has
been closed then you have a potential lock-up.  

I say "potential" because from a normal terminal session you can break the
lock by typing Ctrl-C.  This resets error and pause conditions and returns
you to the gnuplot command line.   

However, if gnuplot is being run from some non-terminal controlling process
I am not entirely clear on who would have to send SIGINT (Ctrl-C) to whom.
I don't understand you usage scenario well enough to guess.
Does the user who is operating the mouse also have a terminal window open?
If Ctrl-C is typed in that window, what process receives the signal?

	Ethan
  

> Thanks much. This will fix a long-standing annoyance with gnuplotlib

Re: Feature question: waiting on a plot window

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

sfeam <sf...@us...> writes:

> On Sunday, 19 August 2018 20:25:24 Dima Kogan wrote:
>> Dima Kogan <gn...@di...> writes:
>>
>> > Ethan A Merritt <sf...@us...> writes:
>> >
>> >> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
>> >>>
>> >>> I'm looking for a feature that (I think) doesn't exist currently. Want
>> >>> to ask first, in case something DOES exist that I'm not seeing.
>> >>
>> >> The command you are looking for is
>> >> 	pause mouse close
>>
>> This works in its most basic form, which is awesome. Thanks! But I'm now
>> going to be a pain in the butt. For a gnuplot-using application to work
>> reasonably, this needs to only wait for a window-close event when one is
>> coming: i.e. when a window is open. Scenarios that could happen:
>>
>> 1. User already closed the window before I send my "pause mouse close"
>
> That sounds like a case of "well then don't do that".
> If the parent program sends the plot command and the pause command
> in immediate succession the time window in which that race could happen
> would be very small.  If the commands do not come in immediate
> succession then maybe the program logic needs re-thinking.
> Can you give a more complete example of the flow of events?
>
>> 2. We're using a non-interactive terminal (dumb, pdf, etc etc)
>> Ideas on handling that?
>
> So far as I know, in that case the next <\n> in the input stream
> will terminal the "pause" command.  Does that not work for you?

I played with it a bit more just now, and it's good-enough. It would be
NICE if "pause mouse close" could know if there's anything to
potentially wait for, but I guess I don't strictly need it.

Thanks much. This will fix a long-standing annoyance with gnuplotlib

Re: Feature question: waiting on a plot window

[sfeam <sf...@us...>]

On Sunday, 19 August 2018 20:25:24 Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > Ethan A Merritt <sf...@us...> writes:
> >
> >> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
> >>>
> >>> I'm looking for a feature that (I think) doesn't exist currently. Want
> >>> to ask first, in case something DOES exist that I'm not seeing.
> >>
> >> The command you are looking for is
> >> 	pause mouse close
> 
> This works in its most basic form, which is awesome. Thanks! But I'm now
> going to be a pain in the butt. For a gnuplot-using application to work
> reasonably, this needs to only wait for a window-close event when one is
> coming: i.e. when a window is open. Scenarios that could happen:
> 
> 1. User already closed the window before I send my "pause mouse close"

That sounds like a case of "well then don't do that".
If the parent program sends the plot command and the pause command
in immediate succession the time window in which that race could happen
would be very small.  If the commands do not come in immediate
succession then maybe the program logic needs re-thinking.
Can you give a more complete example of the flow of events?

> 2. We're using a non-interactive terminal (dumb, pdf, etc etc)
> Ideas on handling that?

So far as I know, in that case the next <\n> in the input stream
will terminal the "pause" command.  Does that not work for you?

	Ethan

Re: Feature question: waiting on a plot window

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

Dima Kogan <gn...@di...> writes:

> Ethan A Merritt <sf...@us...> writes:
>
>> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
>>>
>>> I'm looking for a feature that (I think) doesn't exist currently. Want
>>> to ask first, in case something DOES exist that I'm not seeing.
>>
>> The command you are looking for is
>> 	pause mouse close

This works in its most basic form, which is awesome. Thanks! But I'm now
going to be a pain in the butt. For a gnuplot-using application to work
reasonably, this needs to only wait for a window-close event when one is
coming: i.e. when a window is open. Scenarios that could happen:

1. User already closed the window before I send my "pause mouse close"

2. We're using a non-interactive terminal (dumb, pdf, etc etc)

Ideas on handling that?

Re: Feature question: waiting on a plot window

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

Ethan A Merritt <sf...@us...> writes:

> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
>>
>> I'm looking for a feature that (I think) doesn't exist currently. Want
>> to ask first, in case something DOES exist that I'm not seeing.
>
> The command you are looking for is
> 	pause mouse close
>
> Recent discussion has indicated that on some systems in may also be
> necessary add a bind command
> 	bind "Close" "exit gnuplot"
> 	pause mouse close
>
> gnuplot will exit when the user closes the plot window.
>
> If you want gnuplot to signal the parent application via some side channel
> rather rather than exiting , that's a bit trickier.
> There are several options but the details are OS dependent.
> For example (not necessary the best option)
>
> 	bind "Close" "system('kill -SIGCONT $PARENTID')"

Ooh, that looks like what I want. Thanks! Will try it out at some point.
Daniel: --persist isn't quite what I want. I'd like gnuplot to stay
alive, and to tell me when the client window has gone away.

For the record, it's for this: https://github.com/dkogan/gnuplotlib

Re: Feature question: waiting on a plot window

[Daniel J S. <dan...@ie...>]

On 08/17/2018 03:15 PM, Dima Kogan wrote:
> Hi.
> 
> I'm looking for a feature that (I think) doesn't exist currently. Want
> to ask first, in case something DOES exist that I'm not seeing.
> 
> A number of applications that make plots use gnuplot as a backend. The
> sequence you want there is:
> 
> 1. User says "make a plot"
> 
> 2. Application tells gnuplot to make a plot
> 
> 3. gnuplot does its thing using an interactive terminal (x11, qt, wxt,
>     ...) and a plot window pops up
> 
> 4. user looks at the plot, then closes the window when they're done, and
>     wants to continue using the application
> 
> The issue here is that currently the application (parent of the
> "gnuplot" process) has no way of knowing when the user finished looking
> at the plot, which necessitates ugly workarounds. For instance with
> gnuplotlib I can write a script that just makes a plot. If I just call
> gnuplotlib.plot(), then the application will make a plot and then exit
> immediately. As a workaround I put a sleep(10000) after the plot() call.
> I'd like to have some sort of gnuplotlib.wait() that blocks until
> gnuplot is done. Maybe gnuplot can be asked to print something on the
> console when the client window is closed, or something? Thoughts?

Does "gnuplot --persist" work for your needs?  In the following, the 
gnuplot_qt process hangs around until the window is closed:

@linux ~ $ gnuplot --persist

	G N U P L O T
	Version 5.3 patchlevel 0    last modified 2018-04-26

	Copyright (C) 1986-1993, 1998, 2004, 2007-2018
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')

Terminal type is now 'qt'
Options are '0 font "Sans,9"'
gnuplot> system "ps -e | grep gnuplot"
  6680 pts/1    00:00:00 gnuplot
gnuplot> plot 1/x
gnuplot> system "ps -e | grep gnuplot"
  6680 pts/1    00:00:00 gnuplot
  6690 ?        00:00:00 gnuplot_qt
gnuplot> exit
@linux ~ $ ps -e | grep gnuplot
  6690 ?        00:00:00 gnuplot_qt
@linux ~ $ (manually close window)
manually: command not found
@linux ~ $ ps -e | grep gnuplot
@linux ~ $

Re: Feature question: waiting on a plot window

[Ethan A M. <sf...@us...>]

On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
> Hi.
> 
> I'm looking for a feature that (I think) doesn't exist currently. Want
> to ask first, in case something DOES exist that I'm not seeing.

This ought to be a FAQ or something.

The command you are looking for is
	pause mouse close

Recent discussion has indicated that on some systems in may also be
necessary add a bind command
	bind "Close" "exit gnuplot"
	pause mouse close

gnuplot will exit when the user closes the plot window.

If you want gnuplot to signal the parent application via some side channel
rather rather than exiting , that's a bit trickier.
There are several options but the details are OS dependent.
For example (not necessary the best option)

	bind "Close" "system('kill -SIGCONT $PARENTID')"

	Ethan

> A number of applications that make plots use gnuplot as a backend. The
> sequence you want there is:
> 
> 1. User says "make a plot"
> 
> 2. Application tells gnuplot to make a plot
> 
> 3. gnuplot does its thing using an interactive terminal (x11, qt, wxt,
>    ...) and a plot window pops up
> 
> 4. user looks at the plot, then closes the window when they're done, and
>    wants to continue using the application
> 
> The issue here is that currently the application (parent of the
> "gnuplot" process) has no way of knowing when the user finished looking
> at the plot, which necessitates ugly workarounds. For instance with
> gnuplotlib I can write a script that just makes a plot. If I just call
> gnuplotlib.plot(), then the application will make a plot and then exit
> immediately. As a workaround I put a sleep(10000) after the plot() call.
> I'd like to have some sort of gnuplotlib.wait() that blocks until
> gnuplot is done. Maybe gnuplot can be asked to print something on the
> console when the client window is closed, or something? Thoughts?

Feature question: waiting on a plot window

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

Hi.

I'm looking for a feature that (I think) doesn't exist currently. Want
to ask first, in case something DOES exist that I'm not seeing.

A number of applications that make plots use gnuplot as a backend. The
sequence you want there is:

1. User says "make a plot"

2. Application tells gnuplot to make a plot

3. gnuplot does its thing using an interactive terminal (x11, qt, wxt,
   ...) and a plot window pops up

4. user looks at the plot, then closes the window when they're done, and
   wants to continue using the application

The issue here is that currently the application (parent of the
"gnuplot" process) has no way of knowing when the user finished looking
at the plot, which necessitates ugly workarounds. For instance with
gnuplotlib I can write a script that just makes a plot. If I just call
gnuplotlib.plot(), then the application will make a plot and then exit
immediately. As a workaround I put a sleep(10000) after the plot() call.
I'd like to have some sort of gnuplotlib.wait() that blocks until
gnuplot is done. Maybe gnuplot can be asked to print something on the
console when the client window is closed, or something? Thoughts?

glitch in "missing" doc?

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

It seems there's a small inaccuracy in the current (5.2.4) help for 
"missing". Here's the relevant part of the text:

<quote>
Gnuplot makes a distinction between missing data and invalid data 
(e.g. "NaN", 1/0.).  For example invalid data causes a gap in a line 
drawn through sequential data points; missing data does not.

Non-numeric characters found in a numeric field will usually be 
interpreted as invalid rather than as a missing data point unless they 
happen to match the `missing` string.
</quote>

In fact it seems that in a data block anything other than "NaN" (on a 
case-insensitive comparison) is treated as "missing" (in the 
operational sense that it does not produce a gap in a line plot), not 
invalid. Here's a little test script:

set term pngcairo
set output 'test.png'
set nokey
plot '-' using 1:2 w lines
2000 1
2001 2
2002 TEST_HERE
2003 2
2004 3
e

The plot is drawn with a line from (2001,2) to 2003,2), and that 
remains the case if I put "?", ".", "NA" or "foo" in place of 
"TEST_HERE". A gap appears only if I substitute "nan" or equivalent.

There's a practical consequence: if I'm in the habit of writing "?" 
for missing values in gnuplot input data, the doc would give me the 
idea that I could toggle "gaps in lines" behavior by inserting or
removing

set datafile missing "?"

With this set I should get no gaps, without it I should get gaps.
But get no gaps regardless.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: glitch in "missing" doc?

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

Sorry, just noticed something. The statement in the doc, "Non-numeric 
characters found in a numeric field will usually be interpreted as 
invalid rather than as a missing data point unless they happen to 
match the `missing` string" is borne out if I substitute

   plot '-' using 1:($2) w lines

for

   plot '-' using 1:2 w lines

The doc further states, "Old gnuplot versions handled NaN differently 
depending of the form of the `using` clause", but it doesn't mention 
that the form of the `using` clause matters currently too.

Allin Cottrell

On Sun, 12 Aug 2018, Allin Cottrell wrote:

> It seems there's a small inaccuracy in the current (5.2.4) help for 
> "missing". Here's the relevant part of the text:
>
> <quote>
> Gnuplot makes a distinction between missing data and invalid data (e.g. 
> "NaN", 1/0.).  For example invalid data causes a gap in a line drawn through 
> sequential data points; missing data does not.
>
> Non-numeric characters found in a numeric field will usually be interpreted 
> as invalid rather than as a missing data point unless they happen to match 
> the `missing` string.
> </quote>
>
> In fact it seems that in a data block anything other than "NaN" (on a 
> case-insensitive comparison) is treated as "missing" (in the operational 
> sense that it does not produce a gap in a line plot), not invalid. Here's a 
> little test script:
>
> set term pngcairo
> set output 'test.png'
> set nokey
> plot '-' using 1:2 w lines
> 2000 1
> 2001 2
> 2002 TEST_HERE
> 2003 2
> 2004 3
> e
>
> The plot is drawn with a line from (2001,2) to 2003,2), and that remains the 
> case if I put "?", ".", "NA" or "foo" in place of "TEST_HERE". A gap appears 
> only if I substitute "nan" or equivalent.
>
> There's a practical consequence: if I'm in the habit of writing "?" for 
> missing values in gnuplot input data, the doc would give me the idea that I 
> could toggle "gaps in lines" behavior by inserting or
> removing
>
> set datafile missing "?"
>
> With this set I should get no gaps, without it I should get gaps.
> But get no gaps regardless.

Deprecate and remove terminals linux and linux vgagl

[sfeam <sf...@us...>]

This proposed action is triggered by a recent support request for use of
gnuplot from the linux console command line (no X11 present).

Please contribute any comments or anecdotes about using gnuplot from the
linux console.  


Proposed action
===============

Version 5.2: Mark both terminals DEPRECATED
Version 5.3: Remove the configuration option --with-linux-vga
             Remove linux.trm and vgagl.trm from the current source

Background
==========

Both the "linux" and "vgagl" terminals rely on gnuplot being able to
write directly to the system graphics device (/dev/vga or /dev/svga or
/dev/console or various other synonyms).  This is accomplished by calling
into libraries libvga or libsvga (both are provided by the svgalib
source). The gnuplot executable must be installed suid root so that it
has sufficient privilege for this to work.  A corresponding linux
kernel module svgalib_helper must be available and loaded into the kernel.

This was reasonable 20 years ago; now, not so much.  

Nothing in a typical modern linux system requires or uses svgalib and
most distros do not include it by default.  It is not clear that it
is even possible to build it from existing source to work with current
linux kernels.  I have not been able to get it to work since gnuplot
version 4.2 ten years ago, although I have not really tried very hard. 

The gnuplot core routines supporting pm3d color had an alternative
code path controlled by #ifdef EXTENDED_COLOR_SPECS that affected all
terminals if the linux vgagl terminal was configured.  This code path
has not been maintained and no longer works in 5.3 so I removed it.
That means currently the vgagl terminal would not compile even if a
working svgalib were available. 


Replacement
===========

"set term dumb" is an option of course, but we can do better.

Various terminal interfaces can be run at the linux console level.
At least one of these (yaft) supports sixel graphics.
Therefore one way to run gnuplot from the linux console is to
run yaft (https://github.com/uobikiemukot/yaft) as your console
interface, run gnuplot from the yaft command line, and select
"set term sixel" for output.  I was able to do this successfully
on a laptop running linux kernel 4.17 and no special configuration
of either yaft or gnuplot. This seems an adequate replacement
for the original vgagl terminal, although neither of the current
gnuplot sixel output modes supports mousing.

Re: plot using cbticlabels: an unfinished and undocumented feature

[Ethan A M. <sf...@us...>]

On Sunday, July 29, 2018 10:37:49 PM PDT sfeam via gnuplot-beta wrote:
> On Saturday, 28 July 2018 22:35:00 Juhász Péter wrote:
> > Hello,
> > 
> > I wanted to create a graph where tics on the colorbox are dynamically
> > generated from data. I vaguely recalled that there was a feature for
> > that, and it seemed logical that if there is {x|y}[2]ticlabels() to
> > place tics on the main axes, there should be a cbticlabels to do the
> > same for the colorbox.
> > 
> > It seems that this is valid syntax, as the parser accepts it, and I've
> > found the code responsible for it in the source, but it appears to be
> > undocumented, and there are no demos for it either.
> > 
> > It also appears to be either half-finished or buggy. 
> 
> All true.  "cbticlabels" was added for completeness when the other
> ticlabels variants were introduced, but it was never fully thought
> out or documented. 
> 
> [snip]
> > See the attached data file and gnuplot script for a self-contained
> > example.
> > 
> > The fix, at least from the user's perspective, seems simple: make
> > cbticlabels use the same column that is used for the color data itself.
> > From the developer's perspective, I realize that this might be hard,
> > because we don't yet know which column to use at the time of parsing
> > the using spec, because an unknown number of `xxx variable` statements
> > may come later.
> > 
> > Or - `help pointsize variable` states that variable color is alwasy
> > taken from the last additional column. That we do know.
> 
> Yes.  I think that would be sufficient to cover all your test cases
> in 2D plots. Like this:
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> diff --git a/src/datafile.c b/src/datafile.c
> index 8baf1d5..208ca3a 100644
> --- a/src/datafile.c
> +++ b/src/datafile.c
> @@ -2059,7 +2059,7 @@ df_readascii(double v[], int max)
>                             break;
>                         case CT_CBTICLABEL:
>                             axis = COLOR_AXIS;
> -                       axcol = 3;
> +                     axcol = df_no_use_specs - 1;
>                             break;
>                     }
>                     /* Trap special case of only a single 'using' column */
> @@ -5315,7 +5315,7 @@ df_readbinary(double v[], int max)
>                         break;
>                     case CT_CBTICLABEL:
>                         axis = COLOR_AXIS;
> -                   axcol = 2;
> +                 axcol = df_no_use_specs - 1;
>                         break;
>                 }
>                 if (a.type == STRING) {
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> However that fix doesn't work so well for 3D plots, where there is always
> a z coordinate and that is usually (but not always) where the color comes
> from.  The code in datafile.c is shared by both 2D and 3D plots so it 
> would be tricky to make it work for both.
> 
> 	Ethan

I commited that change for 5.3 and added a documentation section noting
that it is EXPERIMENTAL and that the 3D heat map case does not work as it
probably should.    

	Ethan

Re: plot using cbticlabels: an unfinished and undocumented feature

[sfeam <sf...@us...>]

On Saturday, 28 July 2018 22:35:00 Juhász Péter wrote:
> Hello,
> 
> I wanted to create a graph where tics on the colorbox are dynamically
> generated from data. I vaguely recalled that there was a feature for
> that, and it seemed logical that if there is {x|y}[2]ticlabels() to
> place tics on the main axes, there should be a cbticlabels to do the
> same for the colorbox.
> 
> It seems that this is valid syntax, as the parser accepts it, and I've
> found the code responsible for it in the source, but it appears to be
> undocumented, and there are no demos for it either.
> 
> It also appears to be either half-finished or buggy. 

All true.  "cbticlabels" was added for completeness when the other
ticlabels variants were introduced, but it was never fully thought
out or documented. 

[snip]
> See the attached data file and gnuplot script for a self-contained
> example.
> 
> The fix, at least from the user's perspective, seems simple: make
> cbticlabels use the same column that is used for the color data itself.
> From the developer's perspective, I realize that this might be hard,
> because we don't yet know which column to use at the time of parsing
> the using spec, because an unknown number of `xxx variable` statements
> may come later.
> 
> Or - `help pointsize variable` states that variable color is alwasy
> taken from the last additional column. That we do know.

Yes.  I think that would be sufficient to cover all your test cases
in 2D plots. Like this:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/src/datafile.c b/src/datafile.c
index 8baf1d5..208ca3a 100644
--- a/src/datafile.c
+++ b/src/datafile.c
@@ -2059,7 +2059,7 @@ df_readascii(double v[], int max)
                            break;
                        case CT_CBTICLABEL:
                            axis = COLOR_AXIS;
-                       axcol = 3;
+                     axcol = df_no_use_specs - 1;
                            break;
                    }
                    /* Trap special case of only a single 'using' column */
@@ -5315,7 +5315,7 @@ df_readbinary(double v[], int max)
                        break;
                    case CT_CBTICLABEL:
                        axis = COLOR_AXIS;
-                   axcol = 2;
+                 axcol = df_no_use_specs - 1;
                        break;
                }
                if (a.type == STRING) {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

However that fix doesn't work so well for 3D plots, where there is always
a z coordinate and that is usually (but not always) where the color comes
from.  The code in datafile.c is shared by both 2D and 3D plots so it 
would be tricky to make it work for both.

	Ethan


> Best regards,
> Peter Juhasz