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

early release of version 5.4.5 (please test)

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

I have uploaded a testing copy of a version 5.4.5 release to the "testing"
area on SourceForge:
  https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

The reason for an earlier than usual release is to correct a regression
that affected version 5.4.4 (only) and to provide a fix for mousing in
the Windows qt terminal.

The regression in 5.4.4 caused string->integer type promotion to
incorrectly interpret leading '0' characters as indicating an octal number.
For example in extracting sequence numbers from filenames "run_009.dat",
"run_010.dat", the first conversion would fail ('9' is not a legal octal
character) and the second would yield 8 rather than 10.

My thought is to leave a week for testing and then announce the actual
release at the end of this month.

Changes in 5.4.5
================
* NEW    "set key offset <dx>, <dy>" tweaks placement of the key
* NEW    data-driven histogram colors (variable color from extra using column)
* CHANGE re-order drawing 3D labels to come after pm3d depthorder surfaces
* CHANGE hpgl: add terminal option "fontscale <value>"
* CHANGE for nonuniform matrix data, column(0) returns linear position in matrix
* CHANGE set pointintervalbox 0 disables drawing the background box   Bug #2544
* FIX    svg: hypertext font handling
* FIX    track columnheaders of multiple data blocks in a single file Bug #2538
* FIX    Clean up positioning of polar border, raxis, and theta tics  Bug #2130
* FIX    Autoscaling of logscaled raxis
* FIX    memory corruption if a small plot structure is recycled      Bug #2550
* FIX    regression in 5.4.4 - promotion of string to integer should
         should not assume that a leading 0 means octal               Bug #2551
* FIX    Windows qt: "pause -1" should not block mousing              Bug #2549

        Ethan

Re: New gnuplot subsystem "watchpoints"

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

The output of demo of watchpoints (watchpoints.dem) was prepared in pdf file and the file was uploaded to 
http://tmacchant33.starfree.jp/Files/watchpoits.pdf

Tatsuro

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> Date: 2022/09/07 水 23:48
> Subject: Re: New gnuplot subsystem "watchpoints"
> 
> 
> I have made windows and cygwin binary packages with "watchpoints" and uploaded the below.
> http://tmacchant33.starfree.jp/gnuplot_bin.html
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" <me...@uw...>
> > To: "gnu...@li..." <gnu...@li...>
> > Date: 2022/09/06 火 16:03
> > Subject: New gnuplot subsystem "watchpoints"
> > 
> > 
> > This is a project I started a couple of years ago.
> > I think it is now ready for general testing and use, so I have
> > added it to the development branch with a configuration option
> > 
> >     configure --enable-watchpoints
> > 
> > The "help" text is below:
> > 
> >  Syntax:
> >        plot FOO watch {x|y|z|F(x,y)} = <value>
> >        plot FOO watch mouse
> > 
> >        set style watchpoints nolabels
> >        set style watchpoints label <label-properties>
> > 
> >        unset style watchpoints      # return to default style
> > 
> >        show watchpoints    # summarizes all watches from previous plot command
> > 
> >  A watchpoint is a target value for the x, y, or z coordinate or for a function
> >  f(x,y).  Each watchpoint is attached to a single plot within a `plot` command.
> >  Watchpoints are tracked only for styles `with lines` and `with linespoints`.
> >  Every component line segment of that plot is checked against all watchpoints
> >  attached the plot to see whether one or more of the watchpoint targets is
> >  satisfied at a point along that line segment. A list of points that satisfy the
> >  the target condition ("hits") is accumulated as the plot is drawn.
> > 
> >  For example, if there is a watchpoint with a target y=100, each line segment
> >  is checked to see if the y coordinates of the two endpoints bracket the target
> >  y value.  If so then some point [x,y] on the line segment satisfies the target
> >  condition y = 100 exactly.  This target point is then found by linear
> >  interpolation or by iterative bisection.
> > 
> >  Watchpoints within a single plot command are numbered successively.
> >  More than one watchpoint per plot component may be specified.
> >  Example:
> >       plot DATA using 1:2 smooth cnormal watch y=0.25 watch y=0.5 watch y=0.75
> > 
> >  Watchpoint hits for each targets in the previous plot command are stored in
> >  named arrays WATCH_n.  You can also display a summary of all watchpoint hits
> >  from the previous plot command;  see `show watchpoints`.
> > 
> >       gnuplot> show watchpoints
> >       Plot title:     "DATA using 1:2 smooth cnormal"
> >         Watch 1 target y = 0.25         (1 hits)
> >                 hit 1   x 49.7  y 0.25
> >         Watch 2 target y = 0.5          (1 hits)
> >                 hit 1   x 63.1  y 0.5
> >         Watch 3 target y = 0.75         (1 hits)
> >                 hit 1   x 67.8  y 0.75
> > 
> >  Smoothing: Line segments are checked as they are drawn.  For unsmoothed data
> >  plots this means a hit found by interpolation will lie exactly on a line
> >  segment connecting two data points.  If a data plot is smoothed, hits will
> >  lie on a line segment from the smoothed curve.  Depending on the quality
> >  of the smoothed fit, this may or may not be more accurate than the hit from
> >  the unsmoothed data.
> > 
> >  Accuracy: If the line segment was generated from a function plot, the exact
> >  value of x such that f(x) = y is found by iterative bisection.
> >  Otherwise the coordinates [x,y] are approximated by linear interpolation
> >  along the line segment.
> > 
> >  Using the current mouse x coordinate as a watch target generates a label
> >  that moves along the line of the plot tracking the horizontal position of
> >  the mouse.  This allows simultaneous readout of the y values of multiple
> >  plot lines in the same graph.  The appearance of the point indicating the
> >  current position and of the label can be modified by `set style watchpoint`
> >  and `set style textbox`
> > 
> >  Example:
> > 
> >       set style watchpoint labels point pt 6 ps 2 boxstyle 1
> >       set style textbox 1 lw 0.5 opaque
> >       plot for [i=1:N] "file.dat" using 1:(column(i)) watch mouse
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: New gnuplot subsystem "watchpoints"

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

I have made windows and cygwin binary packages with "watchpoints" and uploaded the below.
http://tmacchant33.starfree.jp/gnuplot_bin.html

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>
> Date: 2022/09/06 火 16:03
> Subject: New gnuplot subsystem "watchpoints"
> 
> 
> This is a project I started a couple of years ago.
> I think it is now ready for general testing and use, so I have
> added it to the development branch with a configuration option
> 
>     configure --enable-watchpoints
> 
> The "help" text is below:
> 
>  Syntax:
>        plot FOO watch {x|y|z|F(x,y)} = <value>
>        plot FOO watch mouse
> 
>        set style watchpoints nolabels
>        set style watchpoints label <label-properties>
> 
>        unset style watchpoints      # return to default style
> 
>        show watchpoints    # summarizes all watches from previous plot command
> 
>  A watchpoint is a target value for the x, y, or z coordinate or for a function
>  f(x,y).  Each watchpoint is attached to a single plot within a `plot` command.
>  Watchpoints are tracked only for styles `with lines` and `with linespoints`.
>  Every component line segment of that plot is checked against all watchpoints
>  attached the plot to see whether one or more of the watchpoint targets is
>  satisfied at a point along that line segment. A list of points that satisfy the
>  the target condition ("hits") is accumulated as the plot is drawn.
> 
>  For example, if there is a watchpoint with a target y=100, each line segment
>  is checked to see if the y coordinates of the two endpoints bracket the target
>  y value.  If so then some point [x,y] on the line segment satisfies the target
>  condition y = 100 exactly.  This target point is then found by linear
>  interpolation or by iterative bisection.
> 
>  Watchpoints within a single plot command are numbered successively.
>  More than one watchpoint per plot component may be specified.
>  Example:
>       plot DATA using 1:2 smooth cnormal watch y=0.25 watch y=0.5 watch y=0.75
> 
>  Watchpoint hits for each targets in the previous plot command are stored in
>  named arrays WATCH_n.  You can also display a summary of all watchpoint hits
>  from the previous plot command;  see `show watchpoints`.
> 
>       gnuplot> show watchpoints
>       Plot title:     "DATA using 1:2 smooth cnormal"
>         Watch 1 target y = 0.25         (1 hits)
>                 hit 1   x 49.7  y 0.25
>         Watch 2 target y = 0.5          (1 hits)
>                 hit 1   x 63.1  y 0.5
>         Watch 3 target y = 0.75         (1 hits)
>                 hit 1   x 67.8  y 0.75
> 
>  Smoothing: Line segments are checked as they are drawn.  For unsmoothed data
>  plots this means a hit found by interpolation will lie exactly on a line
>  segment connecting two data points.  If a data plot is smoothed, hits will
>  lie on a line segment from the smoothed curve.  Depending on the quality
>  of the smoothed fit, this may or may not be more accurate than the hit from
>  the unsmoothed data.
> 
>  Accuracy: If the line segment was generated from a function plot, the exact
>  value of x such that f(x) = y is found by iterative bisection.
>  Otherwise the coordinates [x,y] are approximated by linear interpolation
>  along the line segment.
> 
>  Using the current mouse x coordinate as a watch target generates a label
>  that moves along the line of the plot tracking the horizontal position of
>  the mouse.  This allows simultaneous readout of the y values of multiple
>  plot lines in the same graph.  The appearance of the point indicating the
>  current position and of the label can be modified by `set style watchpoint`
>  and `set style textbox`
> 
>  Example:
> 
>       set style watchpoint labels point pt 6 ps 2 boxstyle 1
>       set style textbox 1 lw 0.5 opaque
>       plot for [i=1:N] "file.dat" using 1:(column(i)) watch mouse
> 
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

New gnuplot subsystem "watchpoints"

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

This is a project I started a couple of years ago.
I think it is now ready for general testing and use, so I have
added it to the development branch with a configuration option

    configure --enable-watchpoints

The "help" text is below:

 Syntax:
       plot FOO watch {x|y|z|F(x,y)} = <value>
       plot FOO watch mouse

       set style watchpoints nolabels
       set style watchpoints label <label-properties>

       unset style watchpoints      # return to default style

       show watchpoints    # summarizes all watches from previous plot command

 A watchpoint is a target value for the x, y, or z coordinate or for a function
 f(x,y).  Each watchpoint is attached to a single plot within a `plot` command.
 Watchpoints are tracked only for styles `with lines` and `with linespoints`.
 Every component line segment of that plot is checked against all watchpoints
 attached the plot to see whether one or more of the watchpoint targets is
 satisfied at a point along that line segment. A list of points that satisfy the
 the target condition ("hits") is accumulated as the plot is drawn.

 For example, if there is a watchpoint with a target y=100, each line segment
 is checked to see if the y coordinates of the two endpoints bracket the target
 y value.  If so then some point [x,y] on the line segment satisfies the target
 condition y = 100 exactly.  This target point is then found by linear
 interpolation or by iterative bisection.

 Watchpoints within a single plot command are numbered successively.
 More than one watchpoint per plot component may be specified.
 Example:
      plot DATA using 1:2 smooth cnormal watch y=0.25 watch y=0.5 watch y=0.75

 Watchpoint hits for each targets in the previous plot command are stored in
 named arrays WATCH_n.  You can also display a summary of all watchpoint hits
 from the previous plot command;  see `show watchpoints`.

      gnuplot> show watchpoints
      Plot title:     "DATA using 1:2 smooth cnormal"
        Watch 1 target y = 0.25         (1 hits)
                hit 1   x 49.7  y 0.25
        Watch 2 target y = 0.5          (1 hits)
                hit 1   x 63.1  y 0.5
        Watch 3 target y = 0.75         (1 hits)
                hit 1   x 67.8  y 0.75

 Smoothing: Line segments are checked as they are drawn.  For unsmoothed data
 plots this means a hit found by interpolation will lie exactly on a line
 segment connecting two data points.  If a data plot is smoothed, hits will
 lie on a line segment from the smoothed curve.  Depending on the quality
 of the smoothed fit, this may or may not be more accurate than the hit from
 the unsmoothed data.

 Accuracy: If the line segment was generated from a function plot, the exact
 value of x such that f(x) = y is found by iterative bisection.
 Otherwise the coordinates [x,y] are approximated by linear interpolation
 along the line segment.

 Using the current mouse x coordinate as a watch target generates a label
 that moves along the line of the plot tracking the horizontal position of
 the mouse.  This allows simultaneous readout of the y values of multiple
 plot lines in the same graph.  The appearance of the point indicating the
 current position and of the label can be modified by `set style watchpoint`
 and `set style textbox`

 Example:

      set style watchpoint labels point pt 6 ps 2 boxstyle 1
      set style textbox 1 lw 0.5 opaque
      plot for [i=1:N] "file.dat" using 1:(column(i)) watch mouse

Re: gnuplot latex documentation error with (MiKTeX 22.7)

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

Thank you for your reply.

I have been using MiKTeX for documentation of the LaTeX in the development branch of gnuplot.
I changed the TeX program from the MiKTeX to the TeXLive (+ghostscript) on the Msys2.
Now everything works as expected.

Tatsuro
 

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/08/26 金 13:49
> Subject: Re: gnuplot latex documentation error with (MiKTeX 22.7)
> 
> 
> On Thursday, 25 August 2022 21:06:33 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7
> > 
> > ************************************************************************************************.
> >   :
> >   :
> > LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.
> > 
> > 
> > LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.
> > 
> > 
> > 
> > pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
> > PDF version <1.7>, but at most version <1.5> allowed
> > 
> > ! LaTeX Error: Unicode character ∙ (U+2219)
> >                not set up for use with LaTeX.
> 
> 
> U+2219 is \bullet in LaTeX.
> Perhaps the unicode support package included with MiKTeX 22.7 is incomplete?
> The file .../texmf-dist/tex/generic/unicode-data/UnicodeData.txt
> should contain a line
> 
> 2219;BULLET OPERATOR;Sm;0;ON;;;;;N;;;;;
> 
> 
> As a work-around, this thread 
>   https://tex.stackexchange.com/questions/598469/package-inputenc-error-unicode-character-%E2%88%99-u2219
> 
> suggests it may be possible to say
>     \usepackage{newunicodechar}
>     \newunicodechar{^^^^2219}{\cdot}
> 
> but I think it would be better to figure out what is wrong with the MiKTeX
> installation.
> 
> 
> 	Ethan
> 
> 
> 

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

>> But in addition to that, gnuplot complains on the terminal:
>> 
>>   qt_gnuplot exiting on read error
>
> I am pretty sure you can only get that error if there is a mismatch
> between the gnuplot version and the gnuplot_qt version. It means that
> one of the commands set via the pipe from gnuplot to gnuplot_x11 is
> not recognized.

Good tip. It was calling /usr/bin/gnuplot, and setting the PATH made it
work. It maybe should fail more gracefully, and anybody actually using
this as a Qt widget would need to make it more robust. It's a good
starting point, though.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 18:39:19 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Do you have the option of logging in with a different window manager?
> > I normally us Plasma, which is maximally compatible with Qt, but I just
> > checked with an IceWM setup and it works fine there too.
> 
> This would be a good test, yes. I just tried on another box. I tried
> with both my tiling WM (notion) and an old "normal" WM (twm). Both have
> the same broken behavior as before. But in addition to that, gnuplot
> complains on the terminal:
> 
>   qt_gnuplot exiting on read error

I am pretty sure you can only get that error if there is a mismatch
between the gnuplot version and the gnuplot_qt version.
It means that one of the commands set via the pipe from gnuplot
to gnuplot_x11 is not recognized.

	Ethan

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

> Do you have the option of logging in with a different window manager?
> I normally us Plasma, which is maximally compatible with Qt, but I just
> checked with an IceWM setup and it works fine there too.

This would be a good test, yes. I just tried on another box. I tried
with both my tiling WM (notion) and an old "normal" WM (twm). Both have
the same broken behavior as before. But in addition to that, gnuplot
complains on the terminal:

  qt_gnuplot exiting on read error

This sounds fatal, but isn't: after a few minutes a single qt plot
window does still pop up, as before.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 16:47:18 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> >> I just tried it, and it doesn't work right for me. The embed_example
> >> program builds. Running it pops up a window that disappears immediately.
> >> Then I get the shell prompt back implying that the embed_example
> >> application has exited. BUT it keeps running in the background
> >> apparently. And I do get a qt window with a plot maybe a minute later.
> >> Sometimes. Sometimes the background process just exits after a few
> >> minutes without showing me a plot.
> >
> > I cannot explain any of that.  It works normally for me here.
> > A qt window pops up immediately with four embedded gnuplot widgets
> > and a text pane.  Output from gnuplot appears in the text pane.
> > The demo replots to one of the widgets every second or so and
> > continues to do so until I close the window or hit Ctrl-C in the
> > controlling terminal.   No zombies either :-)
> 
> Must be nice :)
> 
> I just tried it again. Grabbed fresh sources from git. Rebuilt from
> scratch. Same broken behavior consistently. 

Do you have the option of logging in with a different window manager?
I normally us Plasma, which is maximally compatible with Qt, but I just
checked with an IceWM setup and it works fine there too.

	Ethan



> Some things that could be a
> problem that weren't:
> 
> - I have in my ~/.gnuplot: "set terminal x11 noenhanced". A
>   gnuplot-based Qt widget shouldn't care. It's not clear if it does or
>   doesn't, since taking that away doesn't fix it
> 
> - I'm using a tiling window manager. This constrains the window
>   geometry. So fresh windows are resized immediately after they come up.
>   This tickles bugs in some applications (like the wxt terminal, by the
>   way). It's not the problem here, though: turning off the tiling
>   behavior doesn't fix it.
> 
> - The outboard driver could be using the system gnuplot_qt instead of
>   the just-built one. Setting the GNUPLOT_DRIVER_DIR to point to the
>   local copy doesn't fix it.
> 
> I can help debug, if you're interested in looking into it. I'm doing
> other things at the moment, though, so not going to dig into this myself
> for now.
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

>> I just tried it, and it doesn't work right for me. The embed_example
>> program builds. Running it pops up a window that disappears immediately.
>> Then I get the shell prompt back implying that the embed_example
>> application has exited. BUT it keeps running in the background
>> apparently. And I do get a qt window with a plot maybe a minute later.
>> Sometimes. Sometimes the background process just exits after a few
>> minutes without showing me a plot.
>
> I cannot explain any of that.  It works normally for me here.
> A qt window pops up immediately with four embedded gnuplot widgets
> and a text pane.  Output from gnuplot appears in the text pane.
> The demo replots to one of the widgets every second or so and
> continues to do so until I close the window or hit Ctrl-C in the
> controlling terminal.   No zombies either :-)

Must be nice :)

I just tried it again. Grabbed fresh sources from git. Rebuilt from
scratch. Same broken behavior consistently. Some things that could be a
problem that weren't:

- I have in my ~/.gnuplot: "set terminal x11 noenhanced". A
  gnuplot-based Qt widget shouldn't care. It's not clear if it does or
  doesn't, since taking that away doesn't fix it

- I'm using a tiling window manager. This constrains the window
  geometry. So fresh windows are resized immediately after they come up.
  This tickles bugs in some applications (like the wxt terminal, by the
  way). It's not the problem here, though: turning off the tiling
  behavior doesn't fix it.

- The outboard driver could be using the system gnuplot_qt instead of
  the just-built one. Setting the GNUPLOT_DRIVER_DIR to point to the
  local copy doesn't fix it.

I can help debug, if you're interested in looking into it. I'm doing
other things at the moment, though, so not going to dig into this myself
for now.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 15:07:23 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:

> > In the file .../src/Makefile.am is a commented out section that builds
> > a simple Qt app with embedded gnuplot windows.  
> >
> > Edit that file to un-comment the section and re-run
> >     ./prepare; ./configure; make
> >     ./embed_example
> 
> Cool! If this works, should building this be enabled by default?
> 
> I just tried it, and it doesn't work right for me. The embed_example
> program builds. Running it pops up a window that disappears immediately.
> Then I get the shell prompt back implying that the embed_example
> application has exited. BUT it keeps running in the background
> apparently. And I do get a qt window with a plot maybe a minute later.
> Sometimes. Sometimes the background process just exits after a few
> minutes without showing me a plot.

???
I cannot explain any of that.  It works normally for me here.
A qt window pops up immediately with four embedded gnuplot widgets
and a text pane.  Output from gnuplot appears in the text pane.
The demo replots to one of the widgets every second or so and
continues to do so until I close the window or hit Ctrl-C in the
controlling terminal.   No zombies either :-)

	Ethan

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

> On Saturday, 3 September 2022 13:12:11 PDT Dima Kogan wrote:
>> >> Let's say the request was "I want a gnuplot-powered plotting widget in
>> >> my GTK application". What would you suggest in that case?
>> >
>> > Isn't that what wxt is? 
>> 
>> Is it? If I was building a GTK application (not wx; plain GTK), could I
>> use the gnuplot wxt terminal as a widget in that application? The docs
>> don't make that clear, and definitely don't tell you how to do that.
>
> You seem to be asking for a cross-platform UI with widgets based on gtk.
> What I meant was that wxWidgets claims to be exactly that, although it
> doesn't use (or at least doesn't default to using) gtk on all the 
> supported platforms.  So if you base your UI on wxWidgets, then gnuplot's
> wxt terminal is a natural fit.

I don't actually write GTK applications, so *I* don't want this. But
somebody could be writing a GTK application, and they could want a
plotting widget. As I understand it, this isn't something that gnuplot
can provide today, unless that person rewrites their application with
wxt.


>> Similarly, what if I was building a Qt application? "help qt" mentions a
>> "widget" option, which maybe provides this function, but that option
>> isn't documented, so I don't know what it does.
>
> In the file .../src/Makefile.am is a commented out section that builds
> a simple Qt app with embedded gnuplot windows.  
>
> Edit that file to un-comment the section and re-run
>     ./prepare; ./configure; make
>     ./embed_example

Cool! If this works, should building this be enabled by default?

I just tried it, and it doesn't work right for me. The embed_example
program builds. Running it pops up a window that disappears immediately.
Then I get the shell prompt back implying that the embed_example
application has exited. BUT it keeps running in the background
apparently. And I do get a qt window with a plot maybe a minute later.
Sometimes. Sometimes the background process just exits after a few
minutes without showing me a plot.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 13:12:11 PDT Dima Kogan wrote:
> >> Let's say the request was "I want a gnuplot-powered plotting widget in
> >> my GTK application". What would you suggest in that case?
> >
> > Isn't that what wxt is? 
> 
> Is it? If I was building a GTK application (not wx; plain GTK), could I
> use the gnuplot wxt terminal as a widget in that application? The docs
> don't make that clear, and definitely don't tell you how to do that.

You seem to be asking for a cross-platform UI with widgets based on gtk.
What I meant was that wxWidgets claims to be exactly that, although it
doesn't use (or at least doesn't default to using) gtk on all the 
supported platforms.  So if you base your UI on wxWidgets, then gnuplot's
wxt terminal is a natural fit.

> Similarly, what if I was building a Qt application? "help qt" mentions a
> "widget" option, which maybe provides this function, but that option
> isn't documented, so I don't know what it does.

In the file .../src/Makefile.am is a commented out section that builds
a simple Qt app with embedded gnuplot windows.  

Edit that file to un-comment the section and re-run
    ./prepare; ./configure; make
    ./embed_example

	Ethan

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 13:04:11 PDT Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:
> 
> > Am 02.09.2022 um 02:22 schrieb Dima Kogan:
> >
> >> It feels like an odd thing to do to specifically mask out SIGTSTP,
> >> but I guess that's fine. Masking out SIGINT creates zombies, though,
> >
> > Well, the documented intent is to keep gnuplot_x11 from being killed
> > by Ctrl-C or Ctrl-Z typed into the console --- presumably the one its
> > parent gnuplot process was started from.
> 
> But you DO want it to die when the user hits C-c on the console!

Your expectations are unusual in this regard.
Ctrl-C is a normal way to return control to an interactive session.
For example it is documented as the recommended way to break out of a
long-running "fit" command.  It is safe to hit Ctrl-C in any gnuplot session.
The program will not exit and the graphics window will not close.

> Otherwise you get zombies. 

I suspect these are not zombies. Can you kill then with SIGTERM?
  killall gnuplot_x11 -SIGTERM

More likely they are hung waiting for piped input from a gnuplot
session that segfaulted.  That is not something that should be an
issue unless you have a more fundamental problem with the
gnuplot end of the pipe, and you can clean them up with 'killall'
if it bothers you to see them listed in a process table.

	Ethan


> There's some logic in there to die via a more
> "controlled" path or something, so most of the time the child
> gnuplot_x11 process does go away in response to a C-c, but sometimes it
> doesn't. I do see straggler gnuplot_x11 processes sometimes. And when
> debugging some updates to gnuplot_x11 I see them all the time.
> 
> 
> > It would be _very_ surprising to find out that this particular snippet
> > would have been as badly wrong as you claim it to be, after all this
> > time. X11 may be considered unimportant by some today, but that
> > definitely would have been no excuse of the majority of that time
> > frame.
> 
> I claim there's a bug, not that gnuplot_x11 is horribly, unusably
> broken. There are other gnuplot_x11 bugs that definitely exist that I
> can report too, but nobody has the cycles to work on them (including
> me), so that's not obviously useful.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

> Again only guessing, but I wonder if some window managers send SIGINT
> to the controlling process (or did back in the day) when a window is
> forcibly closed. 
>
>> I can try to keep SIGINT only, and dogfood that change in my everyday
>> usage (I make a LOT of plots). If I don't find anything obviously broken
>> as a result after a few weeks, can we merge it?
>
> You make a lot of plots but presumably they are all made from the
> same environment.  My concern would be that it breaks some other 
> window manager or desktop or OS or X-server etc...

I have the same concern too, but I can't effectively test other people's
setups. If nobody has the cycles to think about fixing bugs in the x11
terminal, maybe we should just leave this alone.


> ... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
> SIGINT handling as it is (masked) or do you mean keep (as in "not block")
> SIGINT?

I meant a small patch that only changes the handing of SIGINT: SIGINT
would have the default behavior (killing gnuplot_x11), but SIGTSTP would
be ignored. To keep the patch as small as possible, since the SIGTSTP
behavior isn't all that important.


>> In my mind, one big argument for gnuplot in general, as compared to
>> other plotting libraries, is its speed. Using a non-x11 terminal dulls
>> that argument.
>
> I think we had this discussion about 10 years ago :-)
>    https://sourceforge.net/p/gnuplot/mailman/message/30718556/

We did! I completely forgot about that!


> At the time there was at least one plot type (3D images)
> for which x11 was faster, but I do not think that is true today.
>
> It's been a while since I did extensive benchmarking, but here's a
> quick timing run on my home desktop:
>
> [~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
> 14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
> [~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
> [~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w
>
> Both wxt and qt are faster than x11 (clock time).
> qt is impressively faster - the test run completes in less
> than half the time used by x11.
>
> Note that the 'u' and 's' times for wxt are for a single process
> while those for x11 and qt are for the inboard (gnuplot) process only.
> But qt is faster than x11 by that measure also.

I guess I wasn't convinced by the thread 10 years ago, but I'll look
again. Thanks for the measurements. In your view, which is the one to
use for interactive plotting on GNU/Linux boxes? qt or wxt? I just
quickly tried both of them, and there are a few bugs/quirks in both of
them I'd want to fix before moving all my usage to one of those. That's
for a later email.


>> Let's say the request was "I want a gnuplot-powered plotting widget in
>> my GTK application". What would you suggest in that case?
>
> Isn't that what wxt is? 

Is it? If I was building a GTK application (not wx; plain GTK), could I
use the gnuplot wxt terminal as a widget in that application? The docs
don't make that clear, and definitely don't tell you how to do that.

Similarly, what if I was building a Qt application? "help qt" mentions a
"widget" option, which maybe provides this function, but that option
isn't documented, so I don't know what it does.

And I want to use FLTK for my applications, so these don't help me. I
guess a new "fltk" terminal would be the "right" way to do that, but
that's not a good use of anybody's time. x11 is a good base to build on,
since all the widget toolkits depend on it (for now at least), and I bet
you could build UI widgets for most toolkits based on "set terminal x11
window whatever".

So yeah. I think there's value in maintaining it, and fixing bugs in it.
I don't have a ton of cycles to put towards that, but I will send some
patches when they're ready.

dima

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hans-Bernhard Bröker <HBB...@t-...> writes:

> Am 02.09.2022 um 02:22 schrieb Dima Kogan:
>
>> It feels like an odd thing to do to specifically mask out SIGTSTP,
>> but I guess that's fine. Masking out SIGINT creates zombies, though,
>
> Well, the documented intent is to keep gnuplot_x11 from being killed
> by Ctrl-C or Ctrl-Z typed into the console --- presumably the one its
> parent gnuplot process was started from.

But you DO want it to die when the user hits C-c on the console!
Otherwise you get zombies. There's some logic in there to die via a more
"controlled" path or something, so most of the time the child
gnuplot_x11 process does go away in response to a C-c, but sometimes it
doesn't. I do see straggler gnuplot_x11 processes sometimes. And when
debugging some updates to gnuplot_x11 I see them all the time.


> It would be _very_ surprising to find out that this particular snippet
> would have been as badly wrong as you claim it to be, after all this
> time. X11 may be considered unimportant by some today, but that
> definitely would have been no excuse of the majority of that time
> frame.

I claim there's a bug, not that gnuplot_x11 is horribly, unusably
broken. There are other gnuplot_x11 bugs that definitely exist that I
can report too, but nobody has the cycles to work on them (including
me), so that's not obviously useful.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

[Hans-Bernhard B. <HBB...@t-...>]

Am 02.09.2022 um 02:22 schrieb Dima Kogan:

> I suspected this predates you. 

Oh, there's no question at all about that ;-).  Those lines have 
remained essentially unchanged since version 3.2, from 1992.  Yes, 
that's 30 years ago.

> It feels like an odd thing to do to
> specifically mask out SIGTSTP, but I guess that's fine. Masking out
> SIGINT creates zombies, though, 

Well, the documented intent is to keep gnuplot_x11 from being killed by 
Ctrl-C or Ctrl-Z typed into the console --- presumably the one its 
parent gnuplot process was started from.

It would be _very_ surprising to find out that this particular snippet 
would have been as badly wrong as you claim it to be, after all this 
time.  X11 may be considered unimportant by some today, but that 
definitely would have been no excuse of the majority of that time frame.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Thursday, 1 September 2022 17:22:37 PDT Dima Kogan wrote:
> Hi Ethan.
> 
> 
> Ethan A Merritt <me...@uw...> writes:
> 
> > On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
> >>
> >> I'm looking at patching gplt_x11.c to work better with existing X window
> >> IDs. This is coming along. In the process I'm discovering other things.
> >> One is that for some reason the gnuplot x11 backend is explicitly
> >> ignoring the SIGINT and SIGTSTP signals:
> >
> > I do not recall, or never knew, those details. But I would imagine
> > that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> > bad idea - it would stop responding to new commands from the main
> > gnuplot process.
> 
> I suspected this predates you. It feels like an odd thing to do to
> specifically mask out SIGTSTP, but I guess that's fine. Masking out
> SIGINT creates zombies, though, so there's a clear downside. 

Again only guessing, but I wonder if some window managers send SIGINT
to the controlling process (or did back in the day) when a window is
forcibly closed. 

> I can try to keep SIGINT only, and dogfood that change in my everyday
> usage (I make a LOT of plots). If I don't find anything obviously broken
> as a result after a few weeks, can we merge it?

You make a lot of plots but presumably they are all made from the
same environment.  My concern would be that it breaks some other 
window manager or desktop or OS or X-server etc...

... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
SIGINT handling as it is (masked) or do you mean keep (as in "not block")
SIGINT?
 
> > It's been too many years since I was seriously using or looking at the 
> > x11 terminal driver.  I think the world has moved on from direct use
> > of Xlib to drive graphics output, in favor of higher level libraries.
> 
> One could say that the world has moved on from gnuplot too, yet here we
> are. For my own interactive use I use the x11 terminal exclusively. I
> find it to be dramatically faster than both qt and wxt. Doubly so if
> x-forwarding (the world is in the process of moving on from X, but it's
> not clear if it will ever get there). Yes, the x11 terminal doesn't do
> anti-aliasing or transparency or fancy text like qt and wxt do, but I've
> never felt like I missed those features in my usage.

If by "fancy text" you mean the text mark-up, it does support that.
The bigger issue is that it doesn't handle UTF8 [*].
X11 and PostScript were state of the art back when gnuplot was new,
but they both suffer from the same myopic view characteristic of
that era: "256 characters are enough".

 > In my mind, one big argument for gnuplot in general, as compared to
> other plotting libraries, is its speed. Using a non-x11 terminal dulls
> that argument.

I think we had this discussion about 10 years ago :-)
   https://sourceforge.net/p/gnuplot/mailman/message/30718556/

At the time there was at least one plot type (3D images)
for which x11 was faster, but I do not think that is true today.

It's been a while since I did extensive benchmarking, but here's a
quick timing run on my home desktop:

[~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
[~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
[~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w

Both wxt and qt are faster than x11 (clock time).
qt is impressively faster - the test run completes in less
than half the time used by x11.

Note that the 'u' and 's' times for wxt are for a single process
while those for x11 and qt are for the inboard (gnuplot) process only.
But qt is faster than x11 by that measure also.

Also note that there are some compute-heavy demos in that test set.
If I were to limit it to the ones that are more purely graphics
then the speed difference would be even more noticeable in favor of qt.
 
>
> [Large snip that I may get back to later]
>

> Let's say the request was "I want a gnuplot-powered plotting widget in
> my GTK application". What would you suggest in that case?

Isn't that what wxt is? 
On linux anyway.
The OSX version of wxt uses a different, non-GTK, back end by default;
I do not know if you can persuade it to use GTK there instead.

	Ethan

[*] Long ago I managed to get x11 to more or less handle UTF8 by
using multi-font support and encoding ISO10646 for the x11 fonts.
The scripts I used then no longer work, and I can't be bothered
to figure out how or if it can be made to work again now.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hi Ethan.


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

> On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
>>
>> I'm looking at patching gplt_x11.c to work better with existing X window
>> IDs. This is coming along. In the process I'm discovering other things.
>> One is that for some reason the gnuplot x11 backend is explicitly
>> ignoring the SIGINT and SIGTSTP signals:
>
> I do not recall, or never knew, those details. But I would imagine
> that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> bad idea - it would stop responding to new commands from the main
> gnuplot process.

I suspected this predates you. It feels like an odd thing to do to
specifically mask out SIGTSTP, but I guess that's fine. Masking out
SIGINT creates zombies, though, so there's a clear downside. I can try
to keep SIGINT only, and dogfood that change in my everyday usage (I
make a LOT of plots). If I don't find anything obviously broken as a
result after a few weeks, can we merge it?


> It's been too many years since I was seriously using or looking at the 
> x11 terminal driver.  I think the world has moved on from direct use
> of Xlib to drive graphics output, in favor of higher level libraries.

One could say that the world has moved on from gnuplot too, yet here we
are. For my own interactive use I use the x11 terminal exclusively. I
find it to be dramatically faster than both qt and wxt. Doubly so if
x-forwarding (the world is in the process of moving on from X, but it's
not clear if it will ever get there). Yes, the x11 terminal doesn't do
anti-aliasing or transparency or fancy text like qt and wxt do, but I've
never felt like I missed those features in my usage.

In my mind, one big argument for gnuplot in general, as compared to
other plotting libraries, is its speed. Using a non-x11 terminal dulls
that argument.


> You said you were looking at this in order to create a gnuplot widget
> for FLTK? I've not previously heard of FLTK, and the fltk.org web site
> is not particularly informative. It looks like it's left over from
> twenty years ago. Can you describe the functionality you need?

FLTK is a widget set. Like Qt or wxt or GTK. It's simple and fast, but
for the purposes of this conversation this is a detail. We can be
talking about GTK instead.


> For example, do you need mousing support inside this widget? If not,
> can you use one of the png terminals rather than x11? The graphics
> would be better, particularly the text handling.
>
> Or maybe you could use svg + domterm? http://domterm.org/Features.html

OK, so on a very high-level a want a plotting library that is

- Fast

- Stable over time

- Available in all contexts in which I plot stuff. Currently this is
  from the terminal, from python, and (hopefully) from an FLTK widget.
  Other people could want to plot from Qt or GTK or R or whatever, and
  it'd be awesome if the same plotting backend was available in all of
  those.

Today, gnuplot is the closest to tick all those boxes for me. There's no
reason why the preferred Python plotting library (matplotlib) is
different from the R plotting library (ggplot2) is different from
whatever you're supposed to do in GTK (gtkdatabox?). And so on. I
generally use FLTK for GUI tools, so I'd like good plotting there, but
the FLTK part is a detail. It would be awesome if Gnuplot were available
as a widget for every GUI toolkit, which is obviously a lot of work. Or
we can use the x11 terminal talking to an external X window, and with a
small number of limitations, we'd be done.

Let's say the request was "I want a gnuplot-powered plotting widget in
my GTK application". What would you suggest in that case?

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
> Hi.
> 
> I'm looking at patching gplt_x11.c to work better with existing X window
> IDs. This is coming along. In the process I'm discovering other things.
> One is that for some reason the gnuplot x11 backend is explicitly
> ignoring the SIGINT and SIGTSTP signals:

You ask "why"?

I do not recall, or never knew, those details.
But I would imagine that it ignores SIGTSTP because backgrounding
gnuplot_x11 would be a bad idea - it would stop responding to new
commands from the main gnuplot process.

It's been too many years since I was seriously using or looking at the 
x11 terminal driver.  I think the world has moved on from direct use
of Xlib to drive graphics output, in favor of higher level libraries.

You said you were looking at this in order to create a gnuplot widget
for FLTK?  I've not previously heard of FLTK, and the fltk.org web site
is not particularly informative.  It looks like it's left over from
twenty years ago.  Can you describe the functionality you need?

For example, do you need mousing support inside this widget?
If not, can you use one of the png terminals rather than x11?
The graphics would be better, particularly the text handling.

Or maybe you could use svg + domterm?
http://domterm.org/Features.html


	Ethan

> 
>   https://urldefense.com/v3/__https://github.com/gnuplot/gnuplot/blob/e9779f00507187653b8fb317f492833af5eaaa9a/src/gplt_x11.c*L5270__;Iw!!K-Hz7m0Vt54!nm8TuNQnOSs9oWJELaBt7rhGmG84fkSGIXqAfuInBOuZk6jnG84SldATh5Xd6jUvN2MWtynemioL8wudnMTwBw$  
> 
> This results in zombie gplt_x11 processes. During normal operation
> usually this doesn't happen, but I do periodically see gplt_x11 zombies.
> While testing my new patches, I see these all the time, however. Does
> anybody know why we're ignoring these signals? Version control says that
> we were doing this from day 0 more or less.
> 
> Removing those two signal() calls doesn't obviously break anything, and
> results in the zombie processes going away. Can/should we get rid of
> those?
> 
> Thanks
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!nm8TuNQnOSs9oWJELaBt7rhGmG84fkSGIXqAfuInBOuZk6jnG84SldATh5Xd6jUvN2MWtynemioL8wuvoGg3ZA$  
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> Date: 2022/09/01 木 16:12
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> I reverted the commit 1955b4151ceef88de644bc89c39477a3d537ad13 and ps_symbols.ps was generated correctly.
> 
> The commit 1955b4151ceef88de644bc89c39477a3d537ad13 may be inadequate and should be improved.
> I will file a bug report.
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" <me...@uw...>
> > To: "gnu...@li..." <gnu...@li...>; "Tatsuro MATSUOKA" <tma...@ya...>
> > Date: 2022/09/01 木 15:44
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> > > I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> > > For both: ps_symbols.ps (5.5 )  1631 lines.
> > > 
> > > The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
> > 
> > I see only one Windows-specific change to post.trm in the past year or so:
> > 
> > commit 1955b4151ceef88de644bc89c39477a3d537ad13
> > Author: Bastian Maerkisch <bma...@we...>
> > Date:   Sat Feb 12 19:00:42 2022 +0100
> > 
> >     pslatex, pstex: make sure we don't mix style of line endings
> >     
> >     (La)TeX chokes on mixing different line endings of Postscript data. This
> >     would be the case for a git checkout on Windows. We now make sure that we
> >     consistently use CR only line endings on Windows/DOS/OS/2.
> > 
> > > Is it better to file as a bug report?
> > 
> > That would be fine.
> > But before the bug report you could try reverting the above commit
> > to see if that fixes it.
> > 
> > 	Ethan
> > 
> > 
> > 
> > 
> > > 
> > > Tatsuro
> > >  
> > > 
> > > > ----- Original Message -----
> > > > 
> > > > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > > > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > > > Date: 2022/09/01 木 14:49
> > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > 
> > > > 
> > > > Thank you for your reply.
> > > > 
> > > > For me,two files are different
> > > > ps_symbols.ps (5.4.4 )  1631 lines 
> > > > ps_symbols.ps (5.5 )  1248 lines 
> > > > 
> > > > I have tested only on windows.
> > > > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > > > 
> > > > Tatsuro
> > > > 
> > > > > ----- Original Message -----
> > > > > 
> > > > > From: "Ethan A Merritt" <me...@uw...>
> > > > > To: "gnu...@li..." <gnu...@li...>
> > > > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > > > Date: 2022/09/01 木 14:34
> > > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > > 
> > > > > 
> > > > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > > > I cannot judge whether this is a bug or not.
> > > > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > > > 
> > > > > I cannot reproduce this.
> > > > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > > > differing only in the Creator and CreationDate header lines.
> > > > > 
> > > > > 	Ethan
> > > > > 
> > > > > 
> > > > > > 
> > > > > > $ gs ps_symbols.ps
> > > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > > see the file COPYING for details.
> > > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > > > Error: /undefined in UL
> > > > > > Operand stack:
> > > > > >    1.0
> > > > > > Execution stack:
> > > > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > > > Dictionary stack:
> > > > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > > > Current allocation mode is local
> > > > > > Current file position is 19030
> > > > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > > > 
> > > > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > > > 
> > > > > > $ gs ps_symbols.ps
> > > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > > see the file COPYING for details.
> > > > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > > > >>showpage, press <return> to continue<<
> > > > > > 
> > > > > > Tatsuro
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > gnuplot-beta mailing list
> > > > > > gnu...@li...
> > > > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center,  K-428 Health Sciences Bldg
> > MS 357742,   University of Washington, Seattle 98195-7742
> > 
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hi.

I'm looking at patching gplt_x11.c to work better with existing X window
IDs. This is coming along. In the process I'm discovering other things.
One is that for some reason the gnuplot x11 backend is explicitly
ignoring the SIGINT and SIGTSTP signals:

  https://github.com/gnuplot/gnuplot/blob/e9779f00507187653b8fb317f492833af5eaaa9a/src/gplt_x11.c#L5270

This results in zombie gplt_x11 processes. During normal operation
usually this doesn't happen, but I do periodically see gplt_x11 zombies.
While testing my new patches, I see these all the time, however. Does
anybody know why we're ignoring these signals? Version control says that
we were doing this from day 0 more or less.

Removing those two signal() calls doesn't obviously break anything, and
results in the zombie processes going away. Can/should we get rid of
those?

Thanks

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

I reverted the commit 1955b4151ceef88de644bc89c39477a3d537ad13 and ps_symbols.ps was generated correctly.

The commit 1955b4151ceef88de644bc89c39477a3d537ad13 may be inadequate and should be improved.
I will file a bug report.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>; "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/09/01 木 15:44
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> > I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> > For both: ps_symbols.ps (5.5 )  1631 lines.
> > 
> > The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
> 
> I see only one Windows-specific change to post.trm in the past year or so:
> 
> commit 1955b4151ceef88de644bc89c39477a3d537ad13
> Author: Bastian Maerkisch <bma...@we...>
> Date:   Sat Feb 12 19:00:42 2022 +0100
> 
>     pslatex, pstex: make sure we don't mix style of line endings
>     
>     (La)TeX chokes on mixing different line endings of Postscript data. This
>     would be the case for a git checkout on Windows. We now make sure that we
>     consistently use CR only line endings on Windows/DOS/OS/2.
> 
> > Is it better to file as a bug report?
> 
> That would be fine.
> But before the bug report you could try reverting the above commit
> to see if that fixes it.
> 
> 	Ethan
> 
> 
> 
> 
> > 
> > Tatsuro
> >  
> > 
> > > ----- Original Message -----
> > > 
> > > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > > Date: 2022/09/01 木 14:49
> > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > 
> > > 
> > > Thank you for your reply.
> > > 
> > > For me,two files are different
> > > ps_symbols.ps (5.4.4 )  1631 lines 
> > > ps_symbols.ps (5.5 )  1248 lines 
> > > 
> > > I have tested only on windows.
> > > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > > 
> > > Tatsuro
> > > 
> > > > ----- Original Message -----
> > > > 
> > > > From: "Ethan A Merritt" <me...@uw...>
> > > > To: "gnu...@li..." <gnu...@li...>
> > > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > > Date: 2022/09/01 木 14:34
> > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > 
> > > > 
> > > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > > I cannot judge whether this is a bug or not.
> > > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > > 
> > > > I cannot reproduce this.
> > > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > > differing only in the Creator and CreationDate header lines.
> > > > 
> > > > 	Ethan
> > > > 
> > > > 
> > > > > 
> > > > > $ gs ps_symbols.ps
> > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > see the file COPYING for details.
> > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > > Error: /undefined in UL
> > > > > Operand stack:
> > > > >    1.0
> > > > > Execution stack:
> > > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > > Dictionary stack:
> > > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > > Current allocation mode is local
> > > > > Current file position is 19030
> > > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > > 
> > > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > > 
> > > > > $ gs ps_symbols.ps
> > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > see the file COPYING for details.
> > > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > > >>showpage, press <return> to continue<<
> > > > > 
> > > > > Tatsuro
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > gnuplot-beta mailing list
> > > > > gnu...@li...
> > > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > > 
> > 
> > 
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> MS 357742,   University of Washington, Seattle 98195-7742
> 
> 

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> For both: ps_symbols.ps (5.5 )  1631 lines.
> 
> The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.

I see only one Windows-specific change to post.trm in the past year or so:

commit 1955b4151ceef88de644bc89c39477a3d537ad13
Author: Bastian Maerkisch <bma...@we...>
Date:   Sat Feb 12 19:00:42 2022 +0100

    pslatex, pstex: make sure we don't mix style of line endings
    
    (La)TeX chokes on mixing different line endings of Postscript data. This
    would be the case for a git checkout on Windows. We now make sure that we
    consistently use CR only line endings on Windows/DOS/OS/2.

> Is it better to file as a bug report?

That would be fine.
But before the bug report you could try reverting the above commit
to see if that fixes it.

	Ethan




> 
> Tatsuro
>  
> 
> > ----- Original Message -----
> > 
> > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > Date: 2022/09/01 木 14:49
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > Thank you for your reply.
> > 
> > For me,two files are different
> > ps_symbols.ps (5.4.4 )  1631 lines 
> > ps_symbols.ps (5.5 )  1248 lines 
> > 
> > I have tested only on windows.
> > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > 
> > Tatsuro
> > 
> > > ----- Original Message -----
> > > 
> > > From: "Ethan A Merritt" <me...@uw...>
> > > To: "gnu...@li..." <gnu...@li...>
> > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > Date: 2022/09/01 木 14:34
> > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > 
> > > 
> > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > I cannot judge whether this is a bug or not.
> > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > 
> > > I cannot reproduce this.
> > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > differing only in the Creator and CreationDate header lines.
> > > 
> > > 	Ethan
> > > 
> > > 
> > > > 
> > > > $ gs ps_symbols.ps
> > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > see the file COPYING for details.
> > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > Error: /undefined in UL
> > > > Operand stack:
> > > >    1.0
> > > > Execution stack:
> > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > Dictionary stack:
> > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > Current allocation mode is local
> > > > Current file position is 19030
> > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > 
> > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > 
> > > > $ gs ps_symbols.ps
> > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > see the file COPYING for details.
> > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > >>showpage, press <return> to continue<<
> > > > 
> > > > Tatsuro
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I cannot judge whether this is a bug or not.
> The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.

I cannot reproduce this.
I get identical postscript output files using either gnuplot 5.4 or 5.5,
differing only in the Creator and CreationDate header lines.

	Ethan


> 
> $ gs ps_symbols.ps
> GPL Ghostscript 9.55.0 (2021-09-27)
> Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> Error: /undefined in UL
> Operand stack:
>    1.0
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> Dictionary stack:
>    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> Current allocation mode is local
> Current file position is 19030
> GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> 
> ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> 
> $ gs ps_symbols.ps
> GPL Ghostscript 9.55.0 (2021-09-27)
> Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> >>showpage, press <return> to continue<<
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
>