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

[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...>]

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?

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

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

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

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

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

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