From: Thomas O. <tho...@or...> - 2012-06-11 13:21:31
|
Note: Sending this a third time now ... as I gather that the other attempts failed to reach the list (am I being filtered out as spam?). Hi, I have a long-standing problem with gnuplot's newer graphical terminals, first the wxt one, now the qt one showing the same. I brought this up on IRC some time ago, but without much success ... and I admit that I tried to ignore the issue by defaulting to the x11 terminal. But, well, since this is spreading into the qt terminal, too, I really would like to see the pattern investigated and fixed. This is gnuplot 4.6 currently. The issue can be reduced to this (on GNU/Linux): shell$ echo 'set term x11; plot x' | gnuplot -persist | cat shell$ That opens a x11 plot window which stays there and exits, giving me my shell prompt back. But this, shell$ echo 'set term qt; plot x' | gnuplot -persist | cat just hangs there. Why is the terminal type making a difference here? Gnuplot's input is closed ... why does it not close the output side? And yes, I am aware that dropping the '| cat' would fix the behaviour, but that would be missing the point as this is a very reduced example for a wrapper script that wants to hook something on gnuplot's text output. Alrighty then, Thomas PS: The qt terminal has fuzzy icons ... looks bad compared to the wxt one (which looks more complete anyway). But well, I prefer the simple x11 windows anyhow. And please, if they are about to be dropped in favour of qt, please add an option to remove any widgets, having only the plotting area remain. |
From: walter h. <wh...@bf...> - 2012-06-11 17:58:15
|
Am 11.06.2012 15:21, schrieb Thomas Orgis: > Note: Sending this a third time now ... as I gather that the other attempts failed to reach the list (am I being filtered out as spam?). > > Hi, > > I have a long-standing problem with gnuplot's newer graphical > terminals, first the wxt one, now the qt one showing the same. > I brought this up on IRC some time ago, but without much success ... > and I admit that I tried to ignore the issue by defaulting to the x11 > terminal. But, well, since this is spreading into the qt terminal, too, > I really would like to see the pattern investigated and fixed. > > This is gnuplot 4.6 currently. > > The issue can be reduced to this (on GNU/Linux): > > shell$ echo 'set term x11; plot x' | gnuplot -persist | cat > shell$ > > That opens a x11 plot window which stays there and exits, giving me my > shell prompt back. But this, > > shell$ echo 'set term qt; plot x' | gnuplot -persist | cat > > just hangs there. Why is the terminal type making a difference here? > Gnuplot's input is closed ... why does it not close the output side? > And yes, I am aware that dropping the '| cat' would fix the behaviour, > but that would be missing the point as this is a very reduced example > for a wrapper script that wants to hook something on gnuplot's text > output. > > > Alrighty then, > > Thomas > > > PS: The qt terminal has fuzzy icons ... looks bad compared to the wxt > one (which looks more complete anyway). But well, I prefer the simple > x11 windows anyhow. And please, if they are about to be dropped in > favour of qt, please add an option to remove any widgets, having only > the plotting area remain. > I use X11 most times beside postscript :) did you try a strace ? re, wh |
From: Thomas O. <tho...@or...> - 2012-06-12 07:42:12
|
Am Mon, 11 Jun 2012 19:58:07 +0200 schrieb walter harms <wh...@bf...>: > I use X11 most times beside postscript :) > did you try a strace ? There is no discernible difference in strace between the cases with and without |cat; the end looks like this: write(5, "@"..., 1) = 1 close(5) = 0 close(4) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER|SA_NOCLDSTOP, 0x2b262ebb45a0}, {0x2b262e344aa0, [], SA_RESTORER|SA_NOCLDSTOP, 0x2b262ebb45a0}, 8) = 0 write(3, "\1\0\0\0\0\0\0\0"..., 8) = 8 close(7) = 0 exit_group(0) = ? (That's without following forks ... as I gather that I'm rather concerned with the main process.) I also see that a gnuplot_qt process keeps hanging around after Ctrl+C-ing the console. It hangs in poll() Loaded symbols for /usr/lib/libtiff.so.3 0x00002b162a6ced6f in *__GI___poll (fds=0x11152f0, nfds=3, timeout=24463) at ../sysdeps/unix/sysv/linux/poll.c:83 83 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. in ../sysdeps/unix/sysv/linux/poll.c (gdb) where #0 0x00002b162a6ced6f in *__GI___poll (fds=0x11152f0, nfds=3, timeout=24463) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00002b16299aec2b in g_main_context_iterate (context=0x10b4f00, block=<value optimized out>, dispatch=1) at gmain.c:3613 #2 0x00002b16299aed5f in g_main_context_iteration (context=0x10b4f00, may_block=1) at gmain.c:3613 #3 0x00002b1628afc872 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #4 0x00002b1627f8c422 in ?? () from /usr/lib/libQtGui.so.4 #5 0x00002b1628ad4bd8 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #6 0x00002b1628ad4d8d in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #7 0x00002b1628ad8599 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #8 0x000000000040cb48 in main (argc=1, argv=<value optimized out>) Well, the Wx terminal also sits in poll, simply because that's the main even loop, I suppose. No difference to Qt there (just that it also succeeds in updating the coordinates). Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2012-06-19 08:50:19
|
Am Tue, 12 Jun 2012 09:42:23 +0200 schrieb Thomas Orgis <tho...@or...>: > Am Mon, 11 Jun 2012 19:58:07 +0200 > schrieb walter harms <wh...@bf...>: > > > I use X11 most times beside postscript :) > > did you try a strace ? > > There is no discernible difference in strace between the cases with and without |cat; the end looks like this: > [...] > Well, the Wx terminal also sits in poll, simply because that's the main even loop, I suppose. No difference to Qt there (just that it also succeeds in updating the coordinates). Nobody got any idea? Is this a sole toolkit question for Qt or Wx? Seems like I have to hack my frontend to ban non-x11 graphical terminals. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2012-06-24 15:21:02
|
Am Tue, 19 Jun 2012 10:50:38 +0200 schrieb Thomas Orgis <tho...@or...>: > [talking to himself] I updated https://sourceforge.net/tracker/?func=detail&atid=102055&aid=3309277&group_id=2055 with my latest findings. Somewhere in the qt and wx drivers, there needs to be closing if stdout and stderr. Please, please, someone have a look and apply something to that effect (my patch misses checking for persist, for example, and also is not portable). Alrighty then, Thomas |