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

Re: bug in 5.4rc2 X11 terminal

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

Pieter-Tjerk de Boer <p.t...@ut...> writes:

> So, somehow, Debian's native gnuplot sets encoding to default even in
> the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
>
> Thanks for the help; this provides me with sufficient ways to
> circumvent the problem.

For what it's worth, my local environment is set to use C instead of
UTF-8, which is probably why things consistently work here.

I tried to set the locale environment in various ways to reproduce the
issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
terminal (requiring the user to explicitly turn off unicode), then I
think we should fix it in some way.

But I can't reproduce the problem, so maybe there isn't anything to fix?
Can anybody else see this issue?

Re: bug in 5.4rc2 X11 terminal

[Pieter-Tjerk de B. <p.t...@ut...>]

On Tue, Jun 23, 2020 at 10:43:32PM -0700, Dima Kogan wrote:
> I use Debian and the x11 terminal routinely, and have never seen this
> issue.
> 
> Ethan: if there's some sort of utf-8 issue as you suspect, would it show
> up in "show encoding"? I see this on my machine:
> 
>   gnuplot> show encoding
> 
>           nominal character encoding is default
>           however LC_CTYPE in current locale is C

In Debian's native gnuplot 5.2pl6 I get:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C.UTF-8

while in 5.4rc2 I get:

  gnuplot> show encoding
          nominal character encoding is utf8
          however LC_CTYPE in current locale is C.UTF-8

Setting encoding to "default" rather than "utf8" indeed fixes the problem
I had in the x11 terminal on 5.4rc2.

> I guess the locale being "C" means I'm not doing unicode, and that's why
> things work for me?

Ah, interesting: if I start gnuplot 5.4rc2 with LC_CTYPE set to C, I get
the same as you:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C

So, somehow, Debian's native gnuplot sets encoding to default even in
the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.

Thanks for the help; this provides me with sufficient ways to circumvent
the problem.

Regards,
  Pieter-Tjerk

Re: bug in 5.4rc2 X11 terminal

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

I use Debian and the x11 terminal routinely, and have never seen this
issue.

Ethan: if there's some sort of utf-8 issue as you suspect, would it show
up in "show encoding"? I see this on my machine:

  gnuplot> show encoding

          nominal character encoding is default
          however LC_CTYPE in current locale is C

I guess the locale being "C" means I'm not doing unicode, and that's why
things work for me?

Re: bug in 5.4rc2 X11 terminal

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

On Tuesday, 23 June 2020 13:17:19 PDT Pieter-Tjerk de Boer wrote:
> Hello,
> 
> Something goes wrong with fonts or character encodings on the x11 terminal.
> See the attached which is the result of simply  
>   plot 1e6
> The vertical labels have a few unintended characters instead of multiplication
> signs (crosses).
> 
> Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
> correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.
> 
> Any idea what this could be? Any test I could do to help debug it?

Most likely your gnuplot session is operating with encoding utf8,
but your x11 terminal font handling is not set up to handle it.
It is possible to set it up, but it's a horrible pain and depends on exactly
what fonts you have available.   Either switch to
     set encoding iso_8859_15    (probably)
or switch to another terminal that has kept up with the modern world
and knows how to handle utf8.  I long ago switched to from x11 to qt
for daily use, but wxt or even sixel might fit your environment better.

If you stick with x11  and iso_8859_15, remember to switch the
encoding back to utf8 for output to pdf or TeX.

	Ethan

> 
> Regards,
>   Pieter-Tjerk
> 

Re: Bug in 5.4.rc2

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

On Tuesday, 23 June 2020 11:24:24 PDT Dima Kogan wrote:
> I finished a patch just as you wrote this. The patch is attached. I
> tried several operations, and it appears to do what I want, and not
> break anything. The code has a lot of confusion about the meaning of
> xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
> *cp structure this function fills. The previous code was passing the x,y
> extents to store2d_point(), but if you do that, you run out of
> arguments, and can't pass the y extents even if you wanted to. This
> patch computes the extents inside store2d_point(), so there are
> arguments left over. 

That won't work.
The eventual extent of a cicle along the y axis will not be known
until after the scaling on both x and y is complete.  For an auto-scaled
plot that will not be true until all the plot components, including functions,
have been processed.  There is not enough information yet at the time
store2d_point() is called.

"with circles" is not the only plot style for which autoscaling must
be delayed till later.  That is the reason for the extra routines
box_range_fiddling()  impulse_range_fiddling() histogram_range_fiddling()
and so on.   However for those plot styles the extra routine can
be called following the individual plot component "with <whatever>".
To handle circles you'd have to wait until _all_ plot components had
contributed to the autoscaling.  That could be done, but it would introduce
a new stage of processing that has not been needed before this.
And even so it would be imprecise, because if you must increase
the y range to fit the circles that will itself increase the y-radius of
the circles so you would need to iterate or estimate the asymptote.

So not impossible, but more difficult than autoscaling other plot styles.

	Ethan

Re: Bug in 5.4.rc2

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

On Tuesday, 23 June 2020 11:33:13 PDT Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > I finished a patch just as you wrote this.
> 
> So I just played with the patched code a bit more, and it's plotting the
> circles as circles even if the aspect ratio is not square. So it's
> clearly insufficient. Hmm

Indeed. That is the purpose of the style.  It _always_ draws circles,
regardless of aspect ratio and regardless of y scaling.

Sounds like your plot wants to use  "with ellipses".

	Ethan

bug in 5.4rc2 X11 terminal

[Pieter-Tjerk de B. <p.t...@ut...>]

Hello,

Something goes wrong with fonts or character encodings on the x11 terminal.
See the attached which is the result of simply  
  plot 1e6
The vertical labels have a few unintended characters instead of multiplication
signs (crosses).

Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.

Any idea what this could be? Any test I could do to help debug it?

Regards,
  Pieter-Tjerk

Re: set nonlinear for secondary axis

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> Good idea.  Done.

Thank you very much.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Bug in 5.4.rc2

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

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

> I finished a patch just as you wrote this.

So I just played with the patched code a bit more, and it's plotting the
circles as circles even if the aspect ratio is not square. So it's
clearly insufficient. Hmm

Re: Bug in 5.4.rc2

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

I finished a patch just as you wrote this. The patch is attached. I
tried several operations, and it appears to do what I want, and not
break anything. The code has a lot of confusion about the meaning of
xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
*cp structure this function fills. The previous code was passing the x,y
extents to store2d_point(), but if you do that, you run out of
arguments, and can't pass the y extents even if you wanted to. This
patch computes the extents inside store2d_point(), so there are
arguments left over. This patch also documents the meanings of
xlow/xhigh/ylow/yhigh.



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

> On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
>
> Autoscaling on y for "with circles" is not a well-defined operation.
> The whole point of the style is that the circle radius depends only on
> x. It will accommodate any yrange by adjusting the extent on y taking
> into account the aspect ratio of the plot.

Maybe I'm abusing the intent of the style here, but in my intended
usage, the meaning is well-defined, and the existing behavior highly
surprising. I want a circle in the x and y coordinates of the plot. If
the aspect ratio is square, it will look like a circle. If the aspect
ratio isn't square, it will look like an ellipse. Is "with circles" not
the proper style? Do I want "with ellipses"? I do see that what you're
saying is spelled-out in the "with circles" documentation; I guess I
thought the meaning of "circle" was clear-enough such that I didn't need
to read that page :)

And regardless of the answer to that question, the user expectation is
that the autoscaling would cause everything in the plot to be visible.
So given that, we shouldn't be cutting off any of the plotted circle.

Thanks

Re: Bug in 5.4.rc2

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

On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
> I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
> be nice to fix it before the release. To reproduce:
> 
>   set size ratio -1
>   plot '-'   using 1:2:3 notitle with circles lw 2
>   0 0 2.5
>   e
> 
> It looks like when "with circles" data is used for autoscaling, the
> edges of the circles are used for the x-axis autoscaling, but only the
> centers for the y-axis autoscaling. So in the plot above, most of the
> one circle gets cut off.

Autoscaling on y for "with circles" is not a well-defined operation.
The whole point of the style is that the circle radius depends only on x.
It will accommodate any yrange by adjusting the extent on y taking
into account the aspect ratio of the plot.

	Ethan  


> 
> I can debug and come up with a patch, but some of you can do that MUCH
> faster than me.
> 
> If yall are busy, let me know, and I can produce a patch.
> 
> Thanks!

Bug in 5.4.rc2

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

I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
be nice to fix it before the release. To reproduce:

  set size ratio -1
  plot '-'   using 1:2:3 notitle with circles lw 2
  0 0 2.5
  e

It looks like when "with circles" data is used for autoscaling, the
edges of the circles are used for the x-axis autoscaling, but only the
centers for the y-axis autoscaling. So in the plot above, most of the
one circle gets cut off.

I can debug and come up with a patch, but some of you can do that MUCH
faster than me.

If yall are busy, let me know, and I can produce a patch.

Thanks!

Re: set nonlinear for secondary axis

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

On Monday, 22 June 2020 11:32:27 PDT Achim Gratz wrote:
> 
> I've recently started using "set nonlinear" more and more and finally
> got to the point where I wanted to have both the primary and secondary
> axis nonlinear.  I promptly fell into the trap that the axis is now
> called x2 (or y2 or z2), but the dummy variable still needs to be given
> as plain x, y, z for the dummy variable in the function setup.  Could
> the documentation be augmented to have at least one example of using a
> secondary axis so that this becomes more clear?
> 
> Regards,
> Achim.

Good idea.  Done.

	Ethan

set nonlinear for secondary axis

[Achim G. <Str...@ne...>]

I've recently started using "set nonlinear" more and more and finally
got to the point where I wanted to have both the primary and secondary
axis nonlinear.  I promptly fell into the trap that the axis is now
called x2 (or y2 or z2), but the dummy variable still needs to be given
as plain x, y, z for the dummy variable in the function setup.  Could
the documentation be augmented to have at least one example of using a
secondary axis so that this becomes more clear?


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: palette plus extra color?

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

On Sat, 13 Jun 2020, Ethan Merritt wrote:

> On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
>> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
>>> The following doesn't work (not surprising) but I'm wondering if
>>> there's any real gnuplot syntax that'll do what it's trying to do:
>>>
>>> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>>>   fc ($3 < 0 ? 'gray' : palette)
>>>
>>> The datafile contains several datasets representing polygons; the
>>> first 2 columns hold the coordinates of vertices and the third a
>>> value to be colorized (if >= 0) or shown as missing (gray) if
>>> negative.
>>
>> Define the palette such that cb=0 is gray, the rest whatever you want.
>>
>>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>>      set cbrange [0:*]
>
> Ah, sorry. I missed the normal color for ( >= 0) requirement.
>         set cbrange [-0.001:*]

Thanks, Ethan. I'd actually tried "set palette defined" plus "set 
cbrange" but I failed to get it right.

Allin

Re: palette plus extra color?

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

On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> > The following doesn't work (not surprising) but I'm wondering if 
> > there's any real gnuplot syntax that'll do what it's trying to do:
> > 
> > plot for [i=0:*] 'polygons.dat' index i with filledcurves \
> >   fc ($3 < 0 ? 'gray' : palette)
> > 
> > The datafile contains several datasets representing polygons; the 
> > first 2 columns hold the coordinates of vertices and the third a 
> > value to be colorized (if >= 0) or shown as missing (gray) if 
> > negative.
> 
> Define the palette such that cb=0 is gray, the rest whatever you want.
> 
>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>      set cbrange [0:*]

Ah, sorry. I missed the normal color for ( >= 0) requirement.
         set cbrange [-0.001:*]

	Ethan

Re: palette plus extra color?

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

On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> The following doesn't work (not surprising) but I'm wondering if 
> there's any real gnuplot syntax that'll do what it's trying to do:
> 
> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>   fc ($3 < 0 ? 'gray' : palette)
> 
> The datafile contains several datasets representing polygons; the 
> first 2 columns hold the coordinates of vertices and the third a 
> value to be colorized (if >= 0) or shown as missing (gray) if 
> negative.

Define the palette such that cb=0 is gray, the rest whatever you want.

     set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
     set cbrange [0:*]
 

	Ethan

palette plus extra color?

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

The following doesn't work (not surprising) but I'm wondering if 
there's any real gnuplot syntax that'll do what it's trying to do:

plot for [i=0:*] 'polygons.dat' index i with filledcurves \
  fc ($3 < 0 ? 'gray' : palette)

The datafile contains several datasets representing polygons; the 
first 2 columns hold the coordinates of vertices and the third a 
value to be colorized (if >= 0) or shown as missing (gray) if 
negative.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

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

I ran gp54rc1-win64-mingw.exe downloaded from SF.

The wxt, qt, libgd-png, and libcairo-png terminal output is not
affected by the text display scaling in my test. The 100% and
225% plots are identical to each other. The mouse coordinate
display and the Window title -- where it says "Gnuplot (window
id : 0)" do change based on text display scaling. Perhaps it's
an optional configuration in cairo's build? On one of the two
machines I tested (but not the other) there is a significant
difference in the default text size between pngcairo and
(gd)png.

As an aside, the gnuplot console text is unaffected, although
the menus, etc. are affected. That will make gnuplot difficult
to use (i.e. tiny) on high-resolution displays.

There are at least two other scaling options available in
Windows that I did not adjust (Scale and Layout in Display, Text
Display in Ease-of-Access, and Make Everything Bigger in
Ease-of-Access). I'm running this in Windows Sandbox to ensure a
pristine default install, and Sandbox won't let me adjust those
other settings.

I wanted to try the Windows terminal, too, but it hangs for a
few seconds and then crashes, seemingly no matter what I try to
plot.


Ethan A Merritt <me...@uw...> said (on 2020/06/06):
> I have placed a tarball for 5.4.rc2 on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
> 
>  Release Notes date: 04-Jun-2020
> ...
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
> 
> Any other known issues?

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> If you can spare the time...

I'll see if I get to it on the weekend or so…

> Here is a small diagnostic patch for the qt terminal.
> It tests the hypothesis that qt connection failure on Cygwin is due to
> horribly slow font initialization.  With the patch in place font handling
> is disabled until the first plot has completed.

Font initialization _is_ slow, I usually even get a warning that tells
me exactly that.


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

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

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

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

On Sunday, 7 June 2020 00:48:14 PDT Achim Gratz wrote:
> 
> The thing is that the call _should_ work and since this is deep inside a
> Qt library that is happily used by other Qt applications without any
> reported problems indicates that there is some other condition that
> makes it not work work for gnuplot_qt specifically (an initialization
> that's missing or something like that).
> 
> Regards,
> Achim.

If you can spare the time...

Here is a small diagnostic patch for the qt terminal.
It tests the hypothesis that qt connection failure on Cygwin is due to
horribly slow font initialization.  With the patch in place font handling
is disabled until the first plot has completed.

This is guaranteed to mess up layout of the first plot, but if it makes
the connection succeed we can sort out font initialization later.

	Ethan

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

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

Hi Ethan,

Just to report that compilation of 5.4.rc2 on OS X works fine. Note that I
use the x11 terminal (and in addition to the standard terminals I also
include the pdf, gif, jpg, and png terminals), as described here
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
(one
day I will find time for cairo, but x11 serves my purposes).

Best,

Erik


On Sat, Jun 6, 2020 at 12:16 AM Ethan A Merritt <me...@uw...> wrote:

> I have placed a tarball for 5.4.rc2 on SourceForge
>
>
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
>
>  Release Notes date: 04-Jun-2020
>
> * Changes between -rc1 and -rc2
>         o faster response to piped input on Windows (Bug #2204)
>         o "splot with boxes" failed to recognize "fc palette" in -rc1
>         o repair several problems with parallel axis plots (Bug #2294)
>         o minor changes to dumb.trm, pixmap handling
>         o -rc1 failed to act on "with labels rotate by <ang>" (Bug #2264)
>         o \n _not_ stripped from string returned by backquoted shell
> command
>         o fix autoscaling of boxplots
>         o new function palette(z) returns packed RGB representation
>         o lua/tikz terminal applies alpha channel to point symbols
>
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
>
> Any other known issues?
>
>         Ethan
>
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> I suppose. But the work involved to disentangle the code in
> wxt_gui.cpp from the core to make it a loadable module would be pretty
> much the same work needed to make it an outboard driver.

Probably yes.  I was thinking that once this has been done for one
driver iot would providew an easier model to follow for others and then
allow the "expensive" drivers (in terms of dependencies) split out into
their own modules (Cairo/Pango, etc. pp.).

> Honestly I think it would be less work to get the Qt terminal
> working.

I think we'll get there eventually, it's just that the Cygwin devs don't
have a small enough reproducer yet.

> But I have never worked on Windows at all and have no particular
> desire to start now.  So I can't really debug or try much myself, only make
> suggestions and point to possible problem points.   
> Is the problem with O_NONBLOCK absolute, i.e. Cygwin will never
> accept such a call, or is it just that making this particular connection
> non-blocking reveals an unacceptable latency in the initialization?
> The former I can't do much about, but the latter we could maybe
> work around by having gnuplot_qt return SUCCESS immediately
> even though initialization is not complete.

The thing is that the call _should_ work and since this is deep inside a
Qt library that is happily used by other Qt applications without any
reported problems indicates that there is some other condition that
makes it not work work for gnuplot_qt specifically (an initialization
that's missing or something like that).


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

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

On Saturday, 6 June 2020 23:11:30 PDT Achim Gratz wrote:
> Ethan A Merritt writes:
 
> > No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
> > driver.   About 10 years ago there was some work to create one because at the
> > time the inboard driver did not work on OSX, but it never reached completion
> > and also I think the OSX problem resolved itself.
> >    https://sourceforge.net/p/gnuplot/patches/380/
>
> [snip]
> 
> Instead of having outboard drivers running a s a separate process as you
> use for X11 and Qt may driver modules could work?  The problem for
> packagers really is that e.g. wx pulls in about half of the GNOME stack
> as a dependency and it's linked to the executable.  Having that
> dependency chain in a separate library that could be dynlinked if and
> when the driver was actually used would alleviate that problem.

I suppose. But the work involved to disentangle the code in  wxt_gui.cpp
from the core to make it a loadable module would be pretty
much  the same work needed to make it an outboard driver.

Honestly I think it would be less work to get the Qt terminal working. 
But I have never worked on Windows at all and have no particular
desire to start now.  So I can't really debug or try much myself, only make
suggestions and point to possible problem points.   
Is the problem with O_NONBLOCK absolute, i.e. Cygwin will never
accept such a call, or is it just that making this particular connection
non-blocking reveals an unacceptable latency in the initialization?
The former I can't do much about, but the latter we could maybe
work around by having gnuplot_qt return SUCCESS immediately
even though initialization is not complete.

	Ethan

> 
> 
> Regards,
> Achim.

Re: OK to put out an -rc2 for version 5.4?

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
>> I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
>> problem isn't properly solved 
>
> Thank you for reminding me of that problem.
> I reviewed the original report and the trail of issues filed with the
> Cygwin and Qt upstreams.  It seems that nothing came of either after
> the first flurry of investigation.

It sort of got stalled, yes.  The consensus was that the patch proposed
would probably have unintended side-effects and that the bug was likely
within Cygwin itself.

> However one point was raised which you might know more of.
> As I understand it, the original diagnosis was that Cygwin was using
> named pipes to emulate unix sockets. But that was corrected by 
> Corinna Vinschen, who said that Cygwin was moving towards using
> named pipes but was [at that time] using  loopback IPv4 sockets to 
> implement AF_UNIX sockets.  That was more than a year ago.
> Has the situation changed?  If switching to named pipes would
> resolve this problem and the work is planned anyhow, perhaps it is worth
> prodding to see how close to completion it might be?

Since then there was a lot of work done on pipes which is still not
complete (and I think at least two bugfixes for the socket code), but
unfortuntaley it didn't remove the bug that's the problem for gnuplot so
far.

> No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
> driver.   About 10 years ago there was some work to create one because at the
> time the inboard driver did not work on OSX, but it never reached completion
> and also I think the OSX problem resolved itself.
>    https://sourceforge.net/p/gnuplot/patches/380/

OK, that's a bit disappointing even though semi-expected.  I have
resolved for now to building gnuplot five times with different
configuration options (which fortunately is fast enough on my new build
machine), package the various bits and pieces separately so that users
can mix and match and then using alternatives to select the correct
executables.

Instead of having outboard drivers running a s a separate process as you
use for X11 and Qt may driver modules could work?  The problem for
packagers really is that e.g. wx pulls in about half of the GNOME stack
as a dependency and it's linked to the executable.  Having that
dependency chain in a separate library that could be dynlinked if and
when the driver was actually used would alleviate that problem.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves