gnuplot-beta Mailing List for gnuplot (Page 33)

I noticed the following change in git repository for branch-5-2-stable.

Bump version to 5.2.6 in preparation for release

Will 5.2.6 be released soon?

Tatsuro

sfeam <me...@uw...> writes:

> Right now the code is
>
>   if (too-big)
> 	warn
>   else
> 	apply the correcion
>
> I suppose the alternative is to remove the "else". I.e. warn on the
> extreme case so that if there is a divide-by-zero or other bad outcome
> at least you have some hint as to what went wrong.
>
> Would you prefer that?

Maybe? The wide images that previously would be rejected appear to work
just fine after your patch (i.e. they're expectedly illegible, but you
can interactively zoom in as expected). So yeah. This logic probably is
what I favor (until we find something that breaks):

    if (too-big)
         warn
    do-the-thing;

Thanks much

sfeam <me...@uw...> writes:

> Ah, I understand now. Yes there is a sanity check on the aspect ratio
> that limits it to a ratio of 1:100. That code dates waayyy back and I
> don't know what logic went into deciding this was the limit. You could
> try changing it to, say, 1:1000.

Hi Ethan. I just went to look at this, and it looks like you applied a
patch already. Thanks! I don't quite understand why this limit is there
at all. As long as the aspect ratio is > 0 and < infinity, I think we
should accept it. I hit this through normal usage, and I can imagine
hitting even the more extreme limit at some point later.

My use case is this:

- I'm plotting an image with annotations plotted on top (points, lines,
  etc).

- The initial plot indeed has a crazy aspect ratio, and isn't very
  useful. But I can clearly see the annotations, and I can then
  interactively zoom into the area with the annotations, producing a
  useful plot. The square aspect ratio is preserved by the zoom
  operation

Unless something predictable will break, maybe the limit should go away,
or become much larger?

On Tuesday, 06 November 2018 20:46:31 Dima Kogan wrote:
> 
> Ethan Merritt <me...@uw...> writes:
> 
> >> I have a very VERY non-square image file (attached). This is a 4000x20
> >> png. I want to use gnuplot to plot it with a square aspect ratio. (In my
> >> actual use case, I'd plot stuff on top of it). I do this:
> >>
> >>   set size ratio -1
> >>   plot "wide.png" binary filetype=auto with rgbimage
> >>
> >> Normally this works, but with such a wide image the "set size ratio -1"
> >> doesn't work: the image is scaled to fill the plot, and I get very tall
> >> and very skinny pixels.
> >
> > I do not understand the problem.
> > Of course the pixels are very tall and skinny, since there are 4000
> > of them in one direction and only 20 in the other.
> 
> Hi.
> 
> I want a square aspect ratio of the thing being plotted (size ratio -1).
> This means:
> 
> - square pixels
> - the image rendered by gnuplot should thus look like the input image:
>   it should be very wide; i.e. not square


Ah, I understand now.
Yes there is a sanity check on the aspect ratio that limits it to a 
ratio of 1:100.   That code dates waayyy back and I don't know what 
logic went into deciding this was the limit.
You could try changing it to, say, 1:1000. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/src/boundary.c b/src/boundary.c
index b096410..85a7f20 100644
--- a/src/boundary.c
+++ b/src/boundary.c
@@ -629,7 +629,7 @@ boundary(struct curve_points *plots, int count)
 
        /* Set aspect ratio if valid and sensible */
        /* EAM Mar 2008 - fixed borders take precedence over centering */
-   if (current_aspect_ratio >= 0.01 && current_aspect_ratio <= 100.0) {
+   if (current_aspect_ratio >= 0.001 && current_aspect_ratio <= 1000.0) {
            double current = ((double) (plot_bounds.ytop - plot_bounds.ybot))
                           / (plot_bounds.xright - plot_bounds.xleft);
            double required = (current_aspect_ratio * t->v_tic) / t->h_tic;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


	cheers,


		Ethan

> 
> The other mode is "size ratio 1" (or equivalently "size square"), which
> sets a square aspect ratio on the resulting image by making the pixels
> non-square.
> 
> I'm attaching a less skewed image, so that you can see that "size ratio
> -1" is indeed the right thing. The issue here is that gnuplot behaves
> differently with the extra-wide image.
> 
> 

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

>> I have a very VERY non-square image file (attached). This is a 4000x20
>> png. I want to use gnuplot to plot it with a square aspect ratio. (In my
>> actual use case, I'd plot stuff on top of it). I do this:
>>
>>   set size ratio -1
>>   plot "wide.png" binary filetype=auto with rgbimage
>>
>> Normally this works, but with such a wide image the "set size ratio -1"
>> doesn't work: the image is scaled to fill the plot, and I get very tall
>> and very skinny pixels.
>
> I do not understand the problem.
> Of course the pixels are very tall and skinny, since there are 4000
> of them in one direction and only 20 in the other.

Hi.

I want a square aspect ratio of the thing being plotted (size ratio -1).
This means:

- square pixels
- the image rendered by gnuplot should thus look like the input image:
  it should be very wide; i.e. not square

The other mode is "size ratio 1" (or equivalently "size square"), which
sets a square aspect ratio on the resulting image by making the pixels
non-square.

I'm attaching a less skewed image, so that you can see that "size ratio
-1" is indeed the right thing. The issue here is that gnuplot behaves
differently with the extra-wide image.

Hi.

I have a very VERY non-square image file (attached). This is a 4000x20
png. I want to use gnuplot to plot it with a square aspect ratio. (In my
actual use case, I'd plot stuff on top of it). I do this:

  set size ratio -1
  plot "wide.png" binary filetype=auto with rgbimage

Normally this works, but with such a wide image the "set size ratio -1"
doesn't work: the image is scaled to fill the plot, and I get very tall
and very skinny pixels. If I zoom in with

  Ctrl-Shift-MouseWheelUp

then it gets unconfused after a few cycles. I bet there's something
hardcoded in the scaling logic. Can somebody please take a look?

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

> If you can draw up another scheme using only select I'd be happy to
> revisit the code. Maybe the code in the qt terminal could be used as a
> guide.

OK, that would require actually understanding what waitforinput() is
supposed to do. Is there a description somewhere? qt terminal? Should I
just study the code?

> > I.e.
> > 
> > - we select(stdin, ipc_back_fd)
> > - select() returns immediately because there's data available on stdin
> > - we DON'T read this data
> > - we sleep a bit
> > - we select() again
> > - Since we never read the data select() said was available the first
> >   time, select() returns immediately again
> > - And we spin
> > 
> > Surely this can't be the intended behavior?
> 
> It is the intended behaviour.
> It may not be ideal but it works.
> If you can draw up another scheme using only select I'd be
> happy to revisit the code.  Maybe the code in the qt
> terminal could be used as a guide.
> 
> 	Ethan

Or maybe it is as simple as 
            FD_ZERO(&fds);
			if (!paused_for_mouse)
            	FD_SET(fd, &fds);
            FD_SET(ipc_back_fd, &fds);
			select()

I'll look at it some more tomorrow

	Ethan

On Sunday, 14 October 2018 22:41:04 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Sunday, 14 October 2018 18:25:31 Dima Kogan wrote:
> >> I just hit another bug in the same area; a more serious one this time.
> >>
> >> When I run gnuplot normally with 'pause mouse close', it blocks
> >> somewhere, and doesn't waste cycles while we're waiting. In my usage,
> >> however, I rarely run gnuplot directly. I almost always use either
> >> feedgnuplot (a shell frontend) or gnuplotlib (a plotting interface for
> >> numpy in python). At least in the latter case, the 'pause mouse close'
> >> works, but gnuplot spins instead of blocking, which wastes CPU
> >> resources.
> >>
> >> I'm attaching a tiny program in python that shows the issue. You should
> >> change the GNUPLOT_SRC_DIR definition in that program to point to your
> >> source tree. This test program
> >>
> >> - spawns gnuplot (as a child of the python)
> >> - asks it to plot something
> >> - "pause mouse close"
> >> - "print xxx"
> >> - reads gnuplot output until it sees "xxx". This is the most reliable
> >>   way I've found to let programs talk to gnuplot. If you know of a
> >>   better synchronization method, please tell me
> >>
> >> When I run this python program I see gnuplot repeatedly call usleep(10)
> >> in X11_waitforinput() in x11.trm. I haven't looked enough at this code
> >> path to understand what it's trying to accomplish. It feels like we
> >> should never be doing this: all waiting should happen in the select() or
> >> something like it.
> >
> > It is on purpose, wisely chosen or not.
> >
> >> I also don't understand why I'm hitting this code
> >> path in python, but not if I run gnuplot interactively ("gnuplot" and
> >> then type in the commands) and not if I run it as a script (put the
> >> "plot" and "pause mouse close" into tst.gp, and "gnuplot tst.gp").
> >
> > This is explained in the comments at x11.trm:894
> >         /* When taking input from the console, we are willing to wait here  */
> >         /* until the next character is typed. But if input is from a script */
> >         /* we just want to check for hotkeys or mouse input and then leave  */
> >         /*  again without waiting on stdin.                                 */
> >
> > When the input is from the console we can select on stdin and not spin.
> > But if input is from a pipe this will always return immediately unless the
> > other end of the pipe does something clever to interlock operations.
> 
> OK, I don't fully grok this, but it feels wrong. If I strace the gnuplot
> process when running inside python, the spin looks like this:
> 
>    2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
>    2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
>    2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
>    2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
>    2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
>    2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
>    ....
> 
> I.e.
> 
> - we select(stdin, ipc_back_fd)
> - select() returns immediately because there's data available on stdin
> - we DON'T read this data
> - we sleep a bit
> - we select() again
> - Since we never read the data select() said was available the first
>   time, select() returns immediately again
> - And we spin
> 
> Surely this can't be the intended behavior?

It is the intended behaviour.
It may not be ideal but it works.
If you can draw up another scheme using only select I'd be
happy to revisit the code.  Maybe the code in the qt
terminal could be used as a guide.

	Ethan

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

> On Sunday, 14 October 2018 18:25:31 Dima Kogan wrote:
>> I just hit another bug in the same area; a more serious one this time.
>>
>> When I run gnuplot normally with 'pause mouse close', it blocks
>> somewhere, and doesn't waste cycles while we're waiting. In my usage,
>> however, I rarely run gnuplot directly. I almost always use either
>> feedgnuplot (a shell frontend) or gnuplotlib (a plotting interface for
>> numpy in python). At least in the latter case, the 'pause mouse close'
>> works, but gnuplot spins instead of blocking, which wastes CPU
>> resources.
>>
>> I'm attaching a tiny program in python that shows the issue. You should
>> change the GNUPLOT_SRC_DIR definition in that program to point to your
>> source tree. This test program
>>
>> - spawns gnuplot (as a child of the python)
>> - asks it to plot something
>> - "pause mouse close"
>> - "print xxx"
>> - reads gnuplot output until it sees "xxx". This is the most reliable
>>   way I've found to let programs talk to gnuplot. If you know of a
>>   better synchronization method, please tell me
>>
>> When I run this python program I see gnuplot repeatedly call usleep(10)
>> in X11_waitforinput() in x11.trm. I haven't looked enough at this code
>> path to understand what it's trying to accomplish. It feels like we
>> should never be doing this: all waiting should happen in the select() or
>> something like it.
>
> It is on purpose, wisely chosen or not.
>
>> I also don't understand why I'm hitting this code
>> path in python, but not if I run gnuplot interactively ("gnuplot" and
>> then type in the commands) and not if I run it as a script (put the
>> "plot" and "pause mouse close" into tst.gp, and "gnuplot tst.gp").
>
> This is explained in the comments at x11.trm:894
>         /* When taking input from the console, we are willing to wait here  */
>         /* until the next character is typed. But if input is from a script */
>         /* we just want to check for hotkeys or mouse input and then leave  */
>         /*  again without waiting on stdin.                                 */
>
> When the input is from the console we can select on stdin and not spin.
> But if input is from a pipe this will always return immediately unless the
> other end of the pipe does something clever to interlock operations.

OK, I don't fully grok this, but it feels wrong. If I strace the gnuplot
process when running inside python, the spin looks like this:

   2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
   2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
   2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
   2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
   2482  select(5, [0 4], NULL, NULL, NULL) = 1 (in [0])
   2482  nanosleep({tv_sec=0, tv_nsec=10000}, NULL) = 0
   ....

I.e.

- we select(stdin, ipc_back_fd)
- select() returns immediately because there's data available on stdin
- we DON'T read this data
- we sleep a bit
- we select() again
- Since we never read the data select() said was available the first
  time, select() returns immediately again
- And we spin

Surely this can't be the intended behavior?

On Sunday, 14 October 2018 18:25:31 Dima Kogan wrote:
> I just hit another bug in the same area; a more serious one this time.
> 
> When I run gnuplot normally with 'pause mouse close', it blocks
> somewhere, and doesn't waste cycles while we're waiting. In my usage,
> however, I rarely run gnuplot directly. I almost always use either
> feedgnuplot (a shell frontend) or gnuplotlib (a plotting interface for
> numpy in python). At least in the latter case, the 'pause mouse close'
> works, but gnuplot spins instead of blocking, which wastes CPU
> resources.
> 
> I'm attaching a tiny program in python that shows the issue. You should
> change the GNUPLOT_SRC_DIR definition in that program to point to your
> source tree. This test program
> 
> - spawns gnuplot (as a child of the python)
> - asks it to plot something
> - "pause mouse close"
> - "print xxx"
> - reads gnuplot output until it sees "xxx". This is the most reliable
>   way I've found to let programs talk to gnuplot. If you know of a
>   better synchronization method, please tell me
> 
> When I run this python program I see gnuplot repeatedly call usleep(10)
> in X11_waitforinput() in x11.trm. I haven't looked enough at this code
> path to understand what it's trying to accomplish. It feels like we
> should never be doing this: all waiting should happen in the select() or
> something like it. 

It is on purpose, wisely chosen or not.

> I also don't understand why I'm hitting this code
> path in python, but not if I run gnuplot interactively ("gnuplot" and
> then type in the commands) and not if I run it as a script (put the
> "plot" and "pause mouse close" into tst.gp, and "gnuplot tst.gp").

This is explained in the comments at x11.trm:894
        /* When taking input from the console, we are willing to wait here  */
        /* until the next character is typed. But if input is from a script */
        /* we just want to check for hotkeys or mouse input and then leave  */
        /*  again without waiting on stdin.                                 */

When the input is from the console we can select on stdin and not spin.
But if input is from a pipe this will always return immediately unless the
other end of the pipe does something clever to interlock operations.
That would make "pause mouse"  useless.  So if the input is from a pipe then
it spins at line 991  as you found.  If you find the cost of spinning too
severe you could bump the usleep to a higher value:

%%%%%
diff --git a/term/x11.trm b/term/x11.trm
index 11556f1..364d4b4 100644
--- a/term/x11.trm
+++ b/term/x11.trm
@@ -988,7 +988,7 @@ AGAIN:
     /* Same sort of thing if we are specifically waiting for mouse input. */
     if (paused_for_mouse) {
 #ifdef HAVE_USLEEP
-   usleep(10);
+ usleep(10000);
 #endif
        goto AGAIN;
     }
%%%%%

As shown by "top" on my desktop machine that reduces the cost of spinning
from about 10% cpu to <1% cpu.
The downside is that this adds a 10msec delay in response to keystrokes.
That may well be a good trade-off.  Or we could make the test more complicated
and use the shorter sleep for actual keystrokes (pause mouse key) and the
longer sleep when waiting for a close event (pause mouse close).

Let me know if that works for you.

Or maybe the whole loop can be written more cleverly so that the select
isn't useless when a pipe is involved.

	Ethan

I just hit another bug in the same area; a more serious one this time.

When I run gnuplot normally with 'pause mouse close', it blocks
somewhere, and doesn't waste cycles while we're waiting. In my usage,
however, I rarely run gnuplot directly. I almost always use either
feedgnuplot (a shell frontend) or gnuplotlib (a plotting interface for
numpy in python). At least in the latter case, the 'pause mouse close'
works, but gnuplot spins instead of blocking, which wastes CPU
resources.

I'm attaching a tiny program in python that shows the issue. You should
change the GNUPLOT_SRC_DIR definition in that program to point to your
source tree. This test program

- spawns gnuplot (as a child of the python)
- asks it to plot something
- "pause mouse close"
- "print xxx"
- reads gnuplot output until it sees "xxx". This is the most reliable
  way I've found to let programs talk to gnuplot. If you know of a
  better synchronization method, please tell me

When I run this python program I see gnuplot repeatedly call usleep(10)
in X11_waitforinput() in x11.trm. I haven't looked enough at this code
path to understand what it's trying to accomplish. It feels like we
should never be doing this: all waiting should happen in the select() or
something like it. I also don't understand why I'm hitting this code
path in python, but not if I run gnuplot interactively ("gnuplot" and
then type in the commands) and not if I run it as a script (put the
"plot" and "pause mouse close" into tst.gp, and "gnuplot tst.gp").

Ideas?

Thanks

On Sunday, 14 October 2018 14:46:40 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > x11:  In theory a terminal driver can see the window close event either
> >       as a GE_keypress event with the 1st parameter set to GP_Cancel
> >       or as a GE_reset event.  x11 handled the first case but failed to
> >       catch the second case.  Patch below.
> 
> Thank you very much. This patch fixes the bulk of the problem. There's
> still a small vestige of the previous incorrect behavior that maybe is
> unimportant, but I'll mention it anyway.
> 
> 1. Run gnuplot
> 2. plot x
> 3. pause mouse close
> 4. 'q' in the popped-up terminal window. This gets us back to a
>    "gnuplot>" prompt
> 5. If you start typing into THIS new prompt, you get a SECOND gnuplot>
>    prompt to type into. Presumably the select() in the gnuplot process
>    is still waiting for some data from the gnuplot_x11 helper that
>    doesn't exist anymore

That is a consequence of a fix/hack/work-around that was added to mouse.c
a long time ago.  See lines starting with 2323 in mouse.c.

The original problem was that if you used the "pause mouse key" command
from a script, i.e. gnuplot was taking input from a pipe, then the first
character of the subsequent command was lost.  This generated an error
because usually losing the first character of a valid command leaves
an invalid command.  One fix is to add an extra blank line or at least
and extra blank character in the script file.  The cleaner fix seemed
to be to add back a harmless character '\n' in the mouse handling, which
could then be lost or not lost with no harm done.

It is possible that this recent set of fixes may have had the side effect
of also fixing the original lose-the-next-character bug.  So what you are
seeing is the added '\n' that was the work-around for a bug that may no
longer be present.

Commenting out the code block as mouse.c:2323 will get rid of the extra
prompt you are seeing.  That may or may not restore the problem of losing
character with piped input - it needs to be tested.

	Ethan

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

> x11:  In theory a terminal driver can see the window close event either
>       as a GE_keypress event with the 1st parameter set to GP_Cancel
>       or as a GE_reset event.  x11 handled the first case but failed to
>       catch the second case.  Patch below.

Thank you very much. This patch fixes the bulk of the problem. There's
still a small vestige of the previous incorrect behavior that maybe is
unimportant, but I'll mention it anyway.

1. Run gnuplot
2. plot x
3. pause mouse close
4. 'q' in the popped-up terminal window. This gets us back to a
   "gnuplot>" prompt
5. If you start typing into THIS new prompt, you get a SECOND gnuplot>
   prompt to type into. Presumably the select() in the gnuplot process
   is still waiting for some data from the gnuplot_x11 helper that
   doesn't exist anymore

Thanks again.

On Saturday, 13 October 2018 17:01:03 Dima Kogan wrote:
> Hi.
> 
> A debugging question. I have a trivial gnuplot script; the specific
> script doesn't matter. For instance this in tst.gp:
> 
>   plot x
>   pause mouse close
> 
> What I'd like to happen is to run
> 
>   load "tst.gp"
> 
> then an interactive plot pops up (x11 or qt or wxt terminals in my
> case). When I close the interactive plot (by pressing 'q' for instance)
> I'd like the 'pause mouse close' command to exit, and I'd like to get
> back to the "gnuplot>" prompt. In my case this doesn't happen. With 'q'
> the interactive plot window does go away, but gnuplot doesn't go back to
> looking for input. I can press "enter", and I get the prompt back then.

I have been chasing a similar problem with the wxt terminal built in
"monothreaded" mode.  The code sequence after receiving a  "window closed"
event is confusing and may not be the same for different terminal types.  

wxt:  I think I found and fixed this yesterday for 5.3.
      If it works for everyone this should be back-ported to 5.2

x11:  In theory a terminal driver can see the window close event either
      as a GE_keypress event with the 1st parameter set to GP_Cancel
      or as a GE_reset event.  x11 handled the first case but failed to
      catch the second case.  Patch below.

qt:   May need a similar addition fix


	Ethan

%%%%%
diff --git a/term/x11.trm b/term/x11.trm
index 366cc0c..11556f1 100644
--- a/term/x11.trm
+++ b/term/x11.trm
@@ -954,6 +954,11 @@ AGAIN:
 			    return '\0';
 			}
 		    }
+		    if (ge.type == GE_reset) {
+			/* Error or window close */
+			paused_for_mouse = 0;
+			return '\0';
+		    }
 		}
 	    } else if (options == TERM_ONLY_CHECK_MOUSING) {
 		return '\0';
%%%%%


> 
> Some minor debugging tells me that after 'q' I still have a gnuplot_x11
> helper process. Both gnuplot_x11 and gnuplot are sitting in select()
> waiting for input, and I need to kick the selects with another "enter"
> to get a prompt back. My gnuplot comes vanilla from Debian. Is this what
> people are observing? Any obvious causes? I'd like to ask before diving
> into a debugging session.
>
> dima

Hi.

A debugging question. I have a trivial gnuplot script; the specific
script doesn't matter. For instance this in tst.gp:

  plot x
  pause mouse close

What I'd like to happen is to run

  load "tst.gp"

then an interactive plot pops up (x11 or qt or wxt terminals in my
case). When I close the interactive plot (by pressing 'q' for instance)
I'd like the 'pause mouse close' command to exit, and I'd like to get
back to the "gnuplot>" prompt. In my case this doesn't happen. With 'q'
the interactive plot window does go away, but gnuplot doesn't go back to
looking for input. I can press "enter", and I get the prompt back then.

Some minor debugging tells me that after 'q' I still have a gnuplot_x11
helper process. Both gnuplot_x11 and gnuplot are sitting in select()
waiting for input, and I need to kick the selects with another "enter"
to get a prompt back. My gnuplot comes vanilla from Debian. Is this what
people are observing? Any obvious causes? I'd like to ask before diving
into a debugging session.

dima

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

> From: sfeam via gnuplot-beta
> To: gnuplot-beta
> Cc: 
> Date: 2018/10/7, Sun 13:45
> Subject: Version 5.2.5 Release
> 
> 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
> 

I have uploaded windows binary packages on the SF site.


Tatsuro

On Monday, 08 October 2018 00:50:08 Erik Luijten wrote:
> 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)").

	Got it.

		thanks,
				Ethan

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

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
>

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

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

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

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

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

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