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

fit does not accept same range parameters as plot for time data

[<pl...@pi...>]

Hi

I have subset of a datafile that I can plot with plot command by 
defining a range.
The same range parameter is refused by fit:

     f(x)=a*exp(-(x-t0)/b)+c
     format="%Y%m%d %H %M"
     set timefmt format
     set xdata time
     plot ["20150925 02 33": "20150925 07 14"] "valana.txt"  u 1:4 w l

     a=b=c=t0=1;   fit f(x)  ["20150925 02 33": "20150925 07 14"] 
"data.txt"  u 1:4 via a,b,c


data looks like this:

20150923 15 20 22.3 16.1
20150923 15 40 22.3 16.1
20150923 15 49 22.9 16.4

The fit command shows the following error:

   internal error: substring range specifiers must have integer values


I thought the intention was that the two commands functioned in a 
similar way. Why can't fit accept the range specifier in the same format 
as plot?

Regards, Peter.

Re: New plot capability: "bee swarm" plots

[<pl...@pi...>]

On 16/09/15 17:53, sfeam wrote:
> It may be that the R code suffers from the symptom you describe,
> where points are drawn unnecessarily far from the center because
> of a nearest-neighbor effect.  I have not found a rigorous
> description of how it works.

Which is fairly typical of a lot of things R does.  :(

Probably why it's more of a hit with business and econometrics that 
science.

Peter.

Re: New plot capability: "bee swarm" plots

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

On Wednesday, 16 September 2015 10:29:20 AM Tait wrote:
> > Here is a direct comparison of the output using the swarm jitter
> > and a random (normal distribution) displacement about x.
> > 
> >   http://skuld.bmsc.washington.edu/~merritt/gnuplot/violin.html
> 
> At that zoom, the swarm jitter looks reasonable. There are two kinds
> of "random" jitter, and I was not clear even with myself about which
> one I meant where. A random offset indiscriminately applied to every
> point, as you've shown in your example above, is still useful, but I
> agree not as helpful as the swarm plot.

I have updated that example to show uniform and Gaussian random
jitter, and to show a kernel density plot for the same data.

> 
> But going back to the zoom levels in
> http://www.cbs.dtu.dk/~eklund/beeswarm/, what I'd want from a jitter
> algorithm is that each point's offset from its original coordinate
> is strictly the minimum offset necessary for that point to not
> overlap its neighbors. That would eliminate the strings of points
> getting increasingly large offsets just because the
> immediately-preceeding point overlaps, when there's an open spot
> closer to the central axis.

It may be that the R code suffers from the symptom you describe,
where points are drawn unnecessarily far from the center because
of a nearest-neighbor effect.  I have not found a rigorous 
description of how it works.

The criterion I used for the gnuplot code is different.
It is not "the immediately-preceding point overlaps".  Rather it is 
1) draw point N on the center line
2) count off how many of the subsequent points would overlap N
   if not jittered.  Call this number j.
3) point N+1 is offset by 1 width, point N+2 is offset by -1 width
   point N+3 is offset by 2 widths, ... up to point N+j
4) N = N + J + 1
   This new point is guaranteed not to overlap if drawn on the
   center line, so return to (1). 

A complicating factor is that the exact diameter of the point
symbol in terms of plot x coordinates is dependent on the 
point symbol used, the terminal type, and the current zoom or plot
scale.  That is the motivation for the "spread" multiplier,
which allows you to decrease the spacing if the program
overestimates the point width or if the point shape permits
closer spacing.  E.g. if the delta-y value is greater than zero,
an x-offset less than the circle radius can be sufficient to
remove overlapping circles, but not squares.

	Ethan

Re: New plot capability: "bee swarm" plots

[Tait <gnu...@t4...>]

> Here is a direct comparison of the output using the swarm jitter
> and a random (normal distribution) displacement about x.
> 
>   http://skuld.bmsc.washington.edu/~merritt/gnuplot/violin.html

At that zoom, the swarm jitter looks reasonable. There are two kinds
of "random" jitter, and I was not clear even with myself about which
one I meant where. A random offset indiscriminately applied to every
point, as you've shown in your example above, is still useful, but I
agree not as helpful as the swarm plot.

But going back to the zoom levels in
http://www.cbs.dtu.dk/~eklund/beeswarm/, what I'd want from a jitter
algorithm is that each point's offset from its original coordinate
is strictly the minimum offset necessary for that point to not
overlap its neighbors. That would eliminate the strings of points
getting increasingly large offsets just because the
immediately-preceeding point overlaps, when there's an open spot
closer to the central axis. I expect the outcome might look closer
to the "priority=random" plot near the bottom of the beeswarm page.

Re: New plot capability: "bee swarm" plots

[<pl...@pi...>]

Hi,


http://skuld.bmsc.washington.edu/~merritt/gnuplot/violin.html
swarm jitter with a large number of small points approximates a violin plot


the plot of dataset B has all key characteristics of a mature amanite 
mushroom in cross-section. Maybe it should be called a mushroom plot 
instead ;)

Peter.

Re: New plot capability: "bee swarm" plots

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

On Tuesday, 15 September, 2015 21:32:17 Tait wrote:
> >   http://www.jmp.com/support/help/images/students.gif
> > ...
> > I found those random jitter plots to be ugly so I never pursued it.
> > I find the beeswarm plots to be much nicer visually and they also
> > convey more information.  ...
> 
> Random jitter may not be very pretty, but within the bounds of what
> it's meant to do, it doesn't distort the data. 

But it does distort!  It gives the visual impression of a uniform scatter
at every y value, which hides the very feature that it is intended 
to convey.  What you want (or at least what I would want :-) is
to leave singleton points unperturbed but separate overlapped points
so you can see how many there are.  That is what the beeswarm plots
do, but not what random jitter does.

> In the limit of
> enough data points, a random jitter would also approach a 2-D
> boxplot or "violin" plot. 

That is not correct.  The distribution of points at each y value
will approach the randomization function, not the PDF envelope
of the data.  And not a standard box plot either.

Here is a direct comparison of the output using the swarm jitter
and a random (normal distribution) displacement about x.

  http://skuld.bmsc.washington.edu/~merritt/gnuplot/violin.html

The random jitter is better than I might have predicted,
but is strictly worse than a violin plot IMHO.  

A uniform random jitter would convey almost no information.
Note that a standard box plot is even worse.

> Pretty graphs are nice, but the plotting
> tool should not encourage them at the expense of accuracy.

Yeah, but in my experience random jitter is not a good way to convey
the desired information.  I played with it a fair amount a couple
of years ago as a possible gnuplot option for version 5 before giving up.

At that same time I tried to work out how to implement violin
plots, and failed to find a good solution.

For both of these reasons I was very pleased when Kevin Rattigan's
question made me aware of beeswarm plots.

	Ethan

Re: New plot capability: "bee swarm" plots

[Tait <gnu...@t4...>]

>   http://www.jmp.com/support/help/images/students.gif
> ...
> I found those random jitter plots to be ugly so I never pursued it.
> I find the beeswarm plots to be much nicer visually and they also
> convey more information.  ...

Random jitter may not be very pretty, but within the bounds of what
it's meant to do, it doesn't distort the data. In the limit of
enough data points, a random jitter would also approach a 2-D
boxplot or "violin" plot. Pretty graphs are nice, but the plotting
tool should not encourage them at the expense of accuracy.

> > Jitter means applying a "small" (definition of which is open to
> > debate) offset to the specified dimension of a data set. I have
> > implemented it before within the "... using ..." directive to plot,
> > and that is where I believe it makes the most sense, e.g.
> >     plot 'data.dat' using (jitter($1)):2
> > As used this way, the jitter offsets don't alter the non-jittered
> > dimension, which the R examples appear to do.
> 
> That confused me at first also, but it turns out that the visual
> appearance of the "bee swarm" plots is a result of applying a pure
> x displacement sequentially to points that have been sorted on y.
> The jitter is applied only to points that would otherwise overlap.
> Since successive points have a larger sorted y value
> and also receive a larger +/- x displacement, you get the
> upward-sweeping lines of points that are so distinctive.

This does not appear to be what's happening in the "method=swarm"
plot from the R package, at least. There are points where the
greater x-displacement point's y-coordinate clearly overlaps with
another point who's x-displacement puts it on or nearer to the
central x-axis. There seems to be some chunking function applied to
the points before they're sorted, and this distorts the data in a
way similar to how histogram binning distorts data. (The solution to
that distortion is to use kernel density plots instead, and for the
same reason, I'd take a density contour plot* or a heat map any day
in preference to a beeswarm plot.)

* gnuplot doesn't have very good support for density plots or any
sort of plot that requires an aggregate view of the input data. Some
of this is done via the "smooth" options, but it's limited.

> The opposite is true for the "square" option.  Although at first
> glance it looks like this results from applying no displacement on y,
> in fact the only reason the displaced points line up in horizontal
> layers is that a y displacement is added to remove the incremental y
> from successive overlapping points.

The R "square" and "hex" methods are probably the clearest examples
of what not to do, namely grid the data and draw points onto the
grid. As you note, this does produce pretty-looking plots and I'm
not averse to having such a feature in gnuplot, but it should be
named in accordance to what it is -- resampling the data (ala
dgrid3d), not "jitter".

> > The extension to higher-dimension plots seems straightforward. One
> > might jitter in x AND y, or in u and t,
> 
> Sure. I was just wondering if anyone had an example of real-world
> data that would benefit from this form of display. ...

Anything that you do in 1D, someone might do in 2D. So the first
example that comes to mind is any sort of location-based incidence
data. Rainfall is an easily-understood example. Each collection
station has its own x and y location, and reports the amount of
water collected. A map of collection stations with "at least N"
rainfall could be represented as points on an xy plane, and if the
density of such collection stations were high enough for the desired
zoom level, it might be represented using jitter in both x and y.

A highly directional receiver antenna array might sweep around a
360-degree circle, saving a record of some relevant signal received,
each record having "longitude" of the antenna array's angular
position as it rotates, and a "lattitude" corresponding to one of
the N lobes in the array. A plot of record count vs. direction would
tend to draw multiple points on top of each other, and this jitter
in both lattitude and longitude might be desirable to better show
number of records.

I'm the wrong person to defend use of jitter plots, because in these
examples (and any other I can imagine), there's at least one other
way to plot the data that is more clear and more accurate  And were
I the presenter, I'd be using those other plots, not jitter. Even
supposing I couldn't find a better plot type, I'd still prefer to
plot the points -- without jitter -- using partial transparency, so
that as the points/lines stack the color becomes more intense,
thereby showing density through color saturation without needing to
introduce artificial jitter. And indeed, I frequently use the
partial transparency approach when doing exploratory scatter plots.

> >or jitter the size and/or color with "ps variable" or "lc variable".
> 
> When would that ever be useful?
> Spatial jitter removes  overlap so that you can see how many
> points there are. What would perturbing the color or size accomplish?

I am not sure jitter in color would really be useful, since the
peturbation would almost certainly be too small for a person to
usefully distinguish. I just threw it in for the sake of
completeness. But jitter in point size would definitely be useful.
The variable pointsize demo that's already online (using world.cor)
is case in point. If the data were real and discrete, rather than
"(5.*rand(0))", it would be necessary to jitter the pointsize to
distinguish one point from another.

Re: New plot capability: "bee swarm" plots

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

On Tuesday, 15 September, 2015 18:16:53 Tait wrote:
> 
> I find the implementation in R to be confusing. There are several
> "types" of jitter, which appear to confound jitter in two
> dimensions. JMP also offers jitter, if you want another
> implementation to look at for a constrasting approach.

I have not looked at the JMP code, but the appearance of the example
  http://www.jmp.com/support/help/images/students.gif
looks similar to what my previous attempt at jitter code produced by
replacing x = x + scale*rand(0)  for all points.

I found those random jitter plots to be ugly so I never pursued it.
I find the beeswarm plots to be much nicer visually and they also
convey more information.  In particular they have the very nice property
that as the number of points becomes large and the point size becomes
small the result converges to a violin plot rather than to a solid rectangle.
I.e. the envelope of the distribution remains informative, whereas random
jitter conveys no information about the distribution once the points get
dense enough to saturate the allowed width.   

I did not find a rigorous description of what the R package is doing,
but the results I get are sufficiently similar in appearance that
I guess they are doing something very like what my code does.

> Jitter means applying a "small" (definition of which is open to
> debate) offset to the specified dimension of a data set. I have
> implemented it before within the "... using ..." directive to plot,
> and that is where I believe it makes the most sense, e.g.
>     plot 'data.dat' using (jitter($1)):2
> As used this way, the jitter offsets don't alter the non-jittered
> dimension, which the R examples appear to do.

That confused me at first also, but it turns out that the visual
appearance of the "bee swarm" plots is a result of applying a pure
x displacement sequentially to points that have been sorted on y.
The jitter is applied only to points that would otherwise overlap.
Since successive points have a larger sorted y value
and also receive a larger +/- x displacement, you get the
upward-sweeping lines of points that are so distinctive.

The opposite is true for the "square" option.  Although at first
glance it looks like this results from applying no displacement on y,
in fact the only reason the displaced points line up in horizontal
layers is that a y displacement is added to remove the incremental y
from successive overlapping points.

If the y values are discrete rather than continuous and their
separation is greater than the overlap criterion, then both
the swarm and square modes produce the same result.

> The extension to higher-dimension plots seems straightforward. One
> might jitter in x AND y, or in u and t,

Sure. I was just wondering if anyone had an example of real-world
data that would benefit from this form of display.
The only thing I could think of was displaying the energy spread 
of individual photons striking a 2D pixel array, but I'm not 
sure that such an energy-sensitive pixel device actually exists.

>or jitter the size and/or color with "ps variable" or "lc variable".

When would that ever be useful?
Spatial jitter removes  overlap so that you can see how many
points there are. What would perturbing the color or size accomplish?

	Ethan

> 
> > ...
> >   http://www.cbs.dtu.dk/~eklund/beeswarm/
> > ...
> >     Syntax:
> >          set jitter {overlap <yposition>} {spread <factor>} {wrap <limit>}
> >                     {swarm|square}
> > ...
> > Would it make sense to apply the jitter to other plot styles
> > in addition to "with points"?
> > Is there a logical 3D counterpart?

Re: New plot capability: "bee swarm" plots

[Tait <gnu...@t4...>]

I find the implementation in R to be confusing. There are several
"types" of jitter, which appear to confound jitter in two
dimensions. JMP also offers jitter, if you want another
implementation to look at for a constrasting approach.

Jitter means applying a "small" (definition of which is open to
debate) offset to the specified dimension of a data set. I have
implemented it before within the "... using ..." directive to plot,
and that is where I believe it makes the most sense, e.g.
    plot 'data.dat' using (jitter($1)):2
As used this way, the jitter offsets don't alter the non-jittered
dimension, which the R examples appear to do.

The extension to higher-dimension plots seems straightforward. One
might jitter in x AND y, or in u and t, or jitter the size and/or
color with "ps variable" or "lc variable".


> ...
>   http://www.cbs.dtu.dk/~eklund/beeswarm/
> ...
>     Syntax:
>          set jitter {overlap <yposition>} {spread <factor>} {wrap <limit>}
>                     {swarm|square}
> ...
> Would it make sense to apply the jitter to other plot styles
> in addition to "with points"?
> Is there a logical 3D counterpart?

New plot capability: "bee swarm" plots

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

On the discussion board <https://sourceforge.net/p/gnuplot/discussion/5924>
Kevin Rattigan asked if there is a gnuplot equivalent to the types of
plot provided by the "beeswarm" module for R.  He provided this link
to examples:

  http://www.cbs.dtu.dk/~eklund/beeswarm/

It turns out that these plots arise naturally from a simple jitter
offset applied to overlapping points in a scatter plot.  Since I already
had a jitter patch lying around, I modified it to apply a sequential
linear jitter rather than a random jitter, and here you go:

>From the ChangeLog

    Syntax:
         set jitter {overlap <yposition>} {spread <factor>} {wrap <limit>}
                    {swarm|square}
     When the x coordinates of a data set are restricted to discrete values
     then many points may lie exactly on top of each other.  Jittering
     introduces an offset to the coordinates of these superimposed points
     that spreads them into a cluster.  This type of plot is called a 
     "bee swarm" plot in R and other packages.

Online copy of the new demo

	 http://gnuplot.sourceforge.net/demo_5.1/jitter.html

Please try it out and offer suggestions.

Would it make sense to apply the jitter to other plot styles
in addition to "with points"?
Is there a logical 3D counterpart?


	Ethan

Re: wxt term + osx

[Jun T. <tak...@kb...>]

Sorry, the line 'yield = 0' must be protected:

Index: src/wxterminal/wxt_gui.cpp
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp,v
retrieving revision 1.150
diff -u -r1.150 wxt_gui.cpp
--- src/wxterminal/wxt_gui.cpp	31 Aug 2015 17:34:32 -0000	1.150
+++ src/wxterminal/wxt_gui.cpp	31 Aug 2015 23:48:17 -0000
@@ -2079,7 +2079,9 @@
 	/* sent when gnuplot exits and when the terminal or the output change.*/
 	FPRINTF((stderr,"wxt_reset\n"));
 
+#if defined(WXT_MONOTHREADED) && !defined(_Windows)
 	yield = 0;
+#endif
 
 	if (wxt_status == STATUS_UNINITIALIZED)
 		return;

Re: wxt term + osx

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

On Monday, 31 August, 2015 22:41:07 Jun T. wrote:
> As I wrote before, on my Mac, If I start gnuplot by
> 
> $ echo 'set term wxt;plot sin(x);pause mouse close' | gnuplot -d
> 
> do something on the wxt plot window (by mouse or keyboard),
> go back to the console and hit ^C, then the gnuplot hangs
> (actually it is not a hang but an infinite loop with 100% cpu usage).
> 
> I haven't tried building a mono-threaded wxt on Linux, but at least
> on Mac what happening is the following:
> 
> Lines 3870-3872 in wxt_gui.cpp:
>       yield = 1;
>       wxTheApp->Yield();
>       yield = 0;
> 
> if ^C is hit during the gui loop Yield(), then the variable yield
> remais 1 (the line 'yield = 0' is not executed). After the signal
> handler returns, it seems wxt_waitforinput() is called, but 
> at lines 3852-3853:
>     if (yield)
>         return '\0';
> so it returns immediately without checking the keyboard input.
> This causes that the function do_line() is called repeatedly with
> a null string as an input.
> 
> The following patch seems to fix this problem, but I'm not confident
> that this is the correct fix, and yes, it is rather ugly.

Looks reasonable to me.  Applied to CVS.

I suspect that wxt itself provides some interlock that should be
used instead of declaring our own  "static int yield", but I don't
know what it is.  

	thanks

		Ethan


> 
> Jun (Jun-ichi Takimoto)
> 
> Index: src/wxterminal/wxt_gui.cpp
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp,v
> retrieving revision 1.149
> diff -u -r1.149 wxt_gui.cpp
> --- src/wxterminal/wxt_gui.cpp	31 Aug 2015 01:47:20 -0000	1.149
> +++ src/wxterminal/wxt_gui.cpp	31 Aug 2015 13:26:03 -0000
> @@ -2070,11 +2070,17 @@
>  	wxt_sigint_restore();
>  }
>  
> +#if defined(WXT_MONOTHREADED) && !defined(_Windows)
> +static int yield = 0;	/* used in wxt_waitforinput() */
> +#endif
> +
>  void wxt_reset()
>  {
>  	/* sent when gnuplot exits and when the terminal or the output change.*/
>  	FPRINTF((stderr,"wxt_reset\n"));
>  
> +	yield = 0;
> +
>  	if (wxt_status == STATUS_UNINITIALIZED)
>  		return;
>  
> @@ -3848,7 +3854,6 @@
>  #else /* !_Windows */
>  	/* Generic hybrid GUI & console message loop */
>  	/* (used mainly on MacOSX - still single threaded) */
> -	static int yield = 0;
>  	if (yield)
>  		return '\0';
>  
> 
> 

Re: wxt term + osx

[Jun T. <tak...@kb...>]

As I wrote before, on my Mac, If I start gnuplot by

$ echo 'set term wxt;plot sin(x);pause mouse close' | gnuplot -d

do something on the wxt plot window (by mouse or keyboard),
go back to the console and hit ^C, then the gnuplot hangs
(actually it is not a hang but an infinite loop with 100% cpu usage).

I haven't tried building a mono-threaded wxt on Linux, but at least
on Mac what happening is the following:

Lines 3870-3872 in wxt_gui.cpp:
      yield = 1;
      wxTheApp->Yield();
      yield = 0;

if ^C is hit during the gui loop Yield(), then the variable yield
remais 1 (the line 'yield = 0' is not executed). After the signal
handler returns, it seems wxt_waitforinput() is called, but 
at lines 3852-3853:
    if (yield)
        return '\0';
so it returns immediately without checking the keyboard input.
This causes that the function do_line() is called repeatedly with
a null string as an input.

The following patch seems to fix this problem, but I'm not confident
that this is the correct fix, and yes, it is rather ugly.

Jun (Jun-ichi Takimoto)

Index: src/wxterminal/wxt_gui.cpp
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp,v
retrieving revision 1.149
diff -u -r1.149 wxt_gui.cpp
--- src/wxterminal/wxt_gui.cpp	31 Aug 2015 01:47:20 -0000	1.149
+++ src/wxterminal/wxt_gui.cpp	31 Aug 2015 13:26:03 -0000
@@ -2070,11 +2070,17 @@
 	wxt_sigint_restore();
 }
 
+#if defined(WXT_MONOTHREADED) && !defined(_Windows)
+static int yield = 0;	/* used in wxt_waitforinput() */
+#endif
+
 void wxt_reset()
 {
 	/* sent when gnuplot exits and when the terminal or the output change.*/
 	FPRINTF((stderr,"wxt_reset\n"));
 
+	yield = 0;
+
 	if (wxt_status == STATUS_UNINITIALIZED)
 		return;
 
@@ -3848,7 +3854,6 @@
 #else /* !_Windows */
 	/* Generic hybrid GUI & console message loop */
 	/* (used mainly on MacOSX - still single threaded) */
-	static int yield = 0;
 	if (yield)
 		return '\0';
 

Re: build fails with -DDEBUG

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

On Monday, 31 August 2015 10:01:31 AM Jun T. wrote:
> With CPPFLAGS='-DDEBUG', build fails as
> 
> wxterminal/wxt_gui.cpp:2027:3: error: use of undeclared identifier 'sw'
>                 sw.Time(), term->xmax, term->ymax, term->v_char, term->h_char));
>                 ^
> 
> and a few more similar errors.
> The stop watch "sw" seems to be not defined (constructed) anywhere.

True. 
The debug statements must be left over from some long-ago version
that included a timer for debugging.  Let's just delete those FPRINTF
references.

	Ethan

build fails with -DDEBUG

[Jun T. <tak...@kb...>]

With CPPFLAGS='-DDEBUG', build fails as

wxterminal/wxt_gui.cpp:2027:3: error: use of undeclared identifier 'sw'
                sw.Time(), term->xmax, term->ymax, term->v_char, term->h_char));
                ^

and a few more similar errors.
The stop watch "sw" seems to be not defined (constructed) anywhere.

Re: wxt term + osx

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

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

> From: sfeam 
> To: gnuplot-beta
> Cc: Allin Cottrell  Tatsuro MATSUOKA 
> Date: 2015/8/29, Sat 00:34
> Subject: Re: wxt term + osx
> 
> On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
>>  On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
>> 
>>  >> Patch 2 prevents loss of a character from the input stream after
>>  >> waiting for a mouse click.
>>  >> I am not sure if this is needed or even safe on Windows.
>>  >>  
>>  >> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 
> -0700
>>  >> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 
> 12:26:12.000000000 -0700
>>  >> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>>  >> event.winid = id;
>>  >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>>  >> -       wxt_process_one_event(&event);
>>  >> +       if (wxt_process_one_event(&event))
>>  >> +           ungetc('\n',stdin); /* FIXME: OK on 
> Windows? */
>>  >> return true;
>>  >> #else
>>  >> if (!wxt_handling_persist)
>>  >  
>>  > I have complied patch 2 attached wxt_gui.cpp.
>>  > Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>>  >
>>  > However 
>>  >
>>  > ungetc('\n',stdin);
>>  >
>>  > perhaps only works on console mode (gnuplot.exe) (untested.)
>>  >
>>  > The function ungetc is not redefined in wtext.h.
>> 
>>  It's defined in stdio.h.
> 
> Does the problem exist on Windows?
> Test case before patch:
> 
> gnuplot> plot sin(x)
> gnuplot> pause mouse
> print "type this before interacting with the plot"
> <now click on the plot>
> gnuplot>rint "type this before interacting with the plot"
>                  ^
>          invalid command
> gnuplot> 
> 
> On linux + single-thread option the 'p' of the "print"
> is lost. The patch fixes this.  But is it lost on OSX
> and Windows also?  If not, they do not need the patch.
> 
I have checked out the source (ChangeLog 2015-08-28).
The second patch is not applied for windows. (ungetc)

gnuplot> plot sin(x)
gnuplot> pause mouse
print "type this before interacting with the plot"
<now click on the plot>
gnuplot>print "type this before interacting with the plot"


Therefore the second patch is not required for windows.

Tatsuro

Re: wxt term + osx

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

On Thu, 27 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
>>>
>>>>> The single- and multi- threaded versions use a different section of
>>>>> code in the routine wxt_gui.cpp: wxt_waitforinput()
>>>>> It sounds like there is some tweak needed for the single-threaded
>>>>> code block so that it doesn't exit if "pause mouse close" is active.
>>>>>
>>>>> You could try adding a check for
>>>>>  if (!paused_for_mouse)
>>>>> or maybe it would need to be
>>>>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>>>>>
>>>>> before breaking from the loop that starts at line 3869.
>>>>> But I'm not sure... that might cause it to hang in other
>>>>> circumstances.
>>>>
>>>> Thanks for the hint, I'll give it a try.
>
> I tried building the single-threaded option on linux.
> "pause mouse" commands did not work at all; the program
> resumed on the next keyboard input regardless of mousing.
> The following 2 patches fixed it:
>
> Patch 1 prevents "pause mouse" from returning prematurely
>
> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> @@ -3880,6 +3881,7 @@ int wxt_waitforinput(int options)
>          FD_ZERO(&read_fd);
>          FD_SET(0, &read_fd);
>          if (select(1, &read_fd, NULL, NULL, &tv) != -1 && FD_ISSET(0, &read_fd))
> +           if (!paused_for_mouse)
>                break;
>        }
>        return getchar();
>
>
>
> Patch 2 prevents loss of a character from the input stream after
>        waiting for a mouse click.
>        I am not sure if this is needed or even safe on Windows.
>
> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>        event.winid = id;
>
> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> -       wxt_process_one_event(&event);
> +       if (wxt_process_one_event(&event))
> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>        return true;
> #else
>        if (!wxt_handling_persist)

Thanks, Ethan. I can confirm that these patches work nicely for me 
with wxWidgets 3.0.2 on OS X 10.10.

On an unrelated cosmetic point: there's some comment in the gnuplot 
wxt* sources about "blurry" icons on cocoa, with a workaround to 
make the gnuplot-specific PNG-derived icons come out better. The 
workaround is effective, but that leaves the two icons on the left 
of the wxt terminal toolbar (Copy to clipboard and Save to disk), 
which are added via the wxArtProvider API. In my build, at any rate, 
these come out horrible (I think they must be bitmaps downsized from 
the cocoa default of 32x32). They are bigger than the other icons 
and also blurry.

In my build I have added a 16x16 "Save" icon (from GTK stock) in the 
same mode as the gnuplot-specific icons in wxterminal/bitmaps/png 
and I'm using this (plus the clipboard icon that's already present 
in that directory but not used currently) to replace the wxArt icons 
-- so that all items on the toolbar are of a uniform size and 
sharpness.

If there's interest in this I could submit a patch; I guess it's 
specific to __WXOSX_COCOA__.

Allin Cottrell

Re: wxt term + osx

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

On Saturday, 29 August, 2015 01:48:58 Jun T. wrote:
> 
> 2015/08/28 04:41, Ethan A Merritt <sf...@us...> wrote:
> 
> > Patch 1 prevents "pause mouse" from returning prematurely
> 
> With this patch "pause mouse" works now on my Mac. Thanks.

Thanks for confirming.  I will add the patches to CVS for 5.0 and 5.1

> But if I hit ^C in the console before closing the wxt window
> then gnuplot hangs. Is the SIGINT handler at the end of
> wxt_gui.cpp also used in the mono-threaded case?

During normal operation, yes.  
However there is some funny business at the top of the the wxt_atexit()
code that involves resetting sigint handling and is only executed in
multi-threaded mode. I do not know if this is relevant to what you are
seeing.

> And --persist (without pause mouse) still doesn't work, for example
> 
> $ echo 'set term wxt;plot sin(x)' | gnuplot -d -p
> 
> quits immediately after opening the plot window. This may be due to
> that the forked child (without exec) does not work well on Mac.
> I guess supporting --persist on Mac would be rather difficult.

I can't reproduce either of these problems on linux, so I think I
will have to leave exploration of possible fixes to someone with
an OSX system to experiment on.

	Ethan 

Re: wxt term + osx

[Jun T. <tak...@kb...>]

2015/08/28 04:41, Ethan A Merritt <sf...@us...> wrote:

> Patch 1 prevents "pause mouse" from returning prematurely

With this patch "pause mouse" works now on my Mac. Thanks.

But if I hit ^C in the console before closing the wxt window
then gnuplot hangs. Is the SIGINT handler at the end of
wxt_gui.cpp also used in the mono-threaded case?


And --persist (without pause mouse) still doesn't work, for example

$ echo 'set term wxt;plot sin(x)' | gnuplot -d -p

quits immediately after opening the plot window. This may be due to
that the forked child (without exec) does not work well on Mac.
I guess supporting --persist on Mac would be rather difficult.

Re: wxt term + osx

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

On Fri, 28 Aug 2015, sfeam wrote:

> On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
>> On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
>>
>>>> Patch 2 prevents loss of a character from the input stream after
>>>> waiting for a mouse click.
>>>> I am not sure if this is needed or even safe on Windows.
>>>>
>>>> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>>>> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>>>> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>>>> event.winid = id;
>>>> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>>>> -       wxt_process_one_event(&event);
>>>> +       if (wxt_process_one_event(&event))
>>>> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>>>> return true;
>>>> #else
>>>> if (!wxt_handling_persist)
>>>
>>> I have complied patch 2 attached wxt_gui.cpp.
>>> Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>>>
>>> However
>>>
>>> ungetc('\n',stdin);
>>>
>>> perhaps only works on console mode (gnuplot.exe) (untested.)
>>>
>>> The function ungetc is not redefined in wtext.h.
>>
>> It's defined in stdio.h.
>
> Does the problem exist on Windows?
> Test case before patch:
>
> gnuplot> plot sin(x)
> gnuplot> pause mouse
> print "type this before interacting with the plot"
> <now click on the plot>
> gnuplot>rint "type this before interacting with the plot"
>                 ^
>         invalid command
> gnuplot>
>
> On linux + single-thread option the 'p' of the "print"
> is lost. The patch fixes this.  But is it lost on OSX
> and Windows also?  If not, they do not need the patch.

I can't speak for Windows, but it is indeed lost on OS X so your patch 
is required there.

Allin Cottrell

Re: wxt term + osx

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

On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
> On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
> 
> >> Patch 2 prevents loss of a character from the input stream after
> >> waiting for a mouse click.
> >> I am not sure if this is needed or even safe on Windows.
> >>  
> >> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> >> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> >> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
> >> event.winid = id;
> >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> >> -       wxt_process_one_event(&event);
> >> +       if (wxt_process_one_event(&event))
> >> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
> >> return true;
> >> #else
> >> if (!wxt_handling_persist)
> >  
> > I have complied patch 2 attached wxt_gui.cpp.
> > Compile itself have passed on gnuplot.exe and wgnuplot.exe.
> >
> > However 
> >
> > ungetc('\n',stdin);
> >
> > perhaps only works on console mode (gnuplot.exe) (untested.)
> >
> > The function ungetc is not redefined in wtext.h.
> 
> It's defined in stdio.h.

Does the problem exist on Windows?
Test case before patch:

gnuplot> plot sin(x)
gnuplot> pause mouse
print "type this before interacting with the plot"
<now click on the plot>
gnuplot>rint "type this before interacting with the plot"
                 ^
         invalid command
gnuplot> 

On linux + single-thread option the 'p' of the "print"
is lost. The patch fixes this.  But is it lost on OSX
and Windows also?  If not, they do not need the patch.

	Ethan

Re: wxt term + osx

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

On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:

>> Patch 2 prevents loss of a character from the input stream after
>> waiting for a mouse click.
>> I am not sure if this is needed or even safe on Windows.
>>  
>> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>> event.winid = id;
>> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>> -       wxt_process_one_event(&event);
>> +       if (wxt_process_one_event(&event))
>> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>> return true;
>> #else
>> if (!wxt_handling_persist)
>  
> I have complied patch 2 attached wxt_gui.cpp.
> Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>
> However 
>
> ungetc('\n',stdin);
>
> perhaps only works on console mode (gnuplot.exe) (untested.)
>
> The function ungetc is not redefined in wtext.h.

It's defined in stdio.h.


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

Re: wxt term + osx

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

>Patch 2 prevents loss of a character from the input stream after
>waiting for a mouse click.
>I am not sure if this is needed or even safe on Windows.
> 
>--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>@@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>event.winid = id;
>#if defined(WXT_MONOTHREADED) || defined(_Windows)
>-       wxt_process_one_event(&event);
>+       if (wxt_process_one_event(&event))
>+           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>return true;
>#else
>if (!wxt_handling_persist)
> 


 
I have complied patch 2 attached wxt_gui.cpp.
Compile itself have passed on gnuplot.exe and wgnuplot.exe.

However 

ungetc('\n',stdin);


perhaps only works on console mode (gnuplot.exe) (untested.)

The function ungetc is not redefined in wtext.h.

For wgnuplot.exe, special treatment might be required but 
I do not have ability on this matter.

Tatsuro 

Re: wxt term + osx

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

On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
> >
> >>> The single- and multi- threaded versions use a different section of
> >>> code in the routine wxt_gui.cpp: wxt_waitforinput()
> >>> It sounds like there is some tweak needed for the single-threaded
> >>> code block so that it doesn't exit if "pause mouse close" is active.
> >>>
> >>> You could try adding a check for
> >>>  if (!paused_for_mouse)
> >>> or maybe it would need to be
> >>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
> >>>
> >>> before breaking from the loop that starts at line 3869.
> >>> But I'm not sure... that might cause it to hang in other
> >>> circumstances.
> >>
> >> Thanks for the hint, I'll give it a try.

I tried building the single-threaded option on linux.
"pause mouse" commands did not work at all; the program
resumed on the next keyboard input regardless of mousing.
The following 2 patches fixed it:

Patch 1 prevents "pause mouse" from returning prematurely

--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
@@ -3880,6 +3881,7 @@ int wxt_waitforinput(int options)
          FD_ZERO(&read_fd);
          FD_SET(0, &read_fd);
          if (select(1, &read_fd, NULL, NULL, &tv) != -1 && FD_ISSET(0, &read_fd))
+           if (!paused_for_mouse)
                break;
        }
        return getchar();



Patch 2 prevents loss of a character from the input stream after
        waiting for a mouse click.
        I am not sure if this is needed or even safe on Windows.

--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
@@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
        event.winid = id;
 
 #if defined(WXT_MONOTHREADED) || defined(_Windows)
-       wxt_process_one_event(&event);
+       if (wxt_process_one_event(&event))
+           ungetc('\n',stdin); /* FIXME: OK on Windows? */
        return true;
 #else
        if (!wxt_handling_persist)

Re: wxt term + osx

[Jun T. <tak...@kb...>]

The reason why the current wxt on Mac is single-threaded is
documented in the following:
http://sourceforge.net/p/gnuplot/patches/544/
In short, on Mac (or at least with Cocoa), the GUI loop
need be in the main thread.

A multi-threded wxt would be better, but "single-threaded"
does not necessarily mean that it does not work.

But there seems to be another problem.
At line 4022 and below in wxt_gui.cpp (in wxt_atexit()),
gnuplot fork() and the parent exits, while the child continues
running. But "fork() without exec()" is not recommended on Mac.
See, for example,
http://stackoverflow.com/questions/18854708/why-is-it-prohivited-to-use-fork-without-exec-in-mac

If I comment out the line 4041:

       freopen("/dev/null","w",stderr);

then I get lots of the following message:

 The process has forked and you cannot use this CoreFoundation \
 functionality safely. You MUST exec()

If I #undef HAVE_WORKING_FORK then the problem that the
wxt window is closed immediately after it is opened seeks
to be fixed. For example the followings work as expected:

$ cat test.plt | gnuplot -d
$ gnuplot -d test.plt < /dev/null
(where test.plot contains
 set term wxt; plot something; pause mouse close)

But then the plot window is not closed also at the end of

$ make check	# i.e., check-noninteractive

and I need to manually close it. So it's not the complete
solution.