Menu
▾
▴
gnuplot-beta
|
From: Jérôme L. <lod...@us...> - 2012-01-07 13:59:12
Attachments:
qtgnuplot1.patch
|
Hi, here is an update patch. It implement the idea mentioned in previous mails of an auxiliary program started by exec after the fork. On my Linux system, with this patch, the Qt terminal works as well as before. Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit : > It has its flaws, but I can finally see it plot a graph. > > So, here's a list of problems: > > 1.) Your headers don't compile That should be fixed in the new patch > 2.) When I plot something, two windows pop up in "dashboard" (or > however the space is called). The first one doesn't respond to > anything and I can only force-quit it (resulting in "Qt terminal > communication error: select() error Killed: 9"), but the second one > works fine. If I quit the second one (it allows me to do that > gracefully), I get > > > Quit application 23586 > > Quit application 23605 > Qt terminal communication error: select() error > > and gnuplot is still alive, except that at the next "plot <something>" > it enters some infinit loop without doing anything. Only killing the > first window also kills gnuplot itself. > > Is there a way to help you debug the problem? In the constructor, QtGnuplotApplication sets setQuitOnLastWindowClosed(false); which forbids the program to quit when you close the terminal window. This way, the program is still listening to events from gnuplot, and can open new windows when a new plot is requested. The application only quits when gnuplot exits. Apparently, this process is broken on OS X since the destructor of the QtGnuplotApplication (which prints the "Quit application 23605" mesage) is called when you close the terminal window. I have added the value of quitOnLastWindowClosed to this message to check whether this property is broken or overridden. Could you try again ? As for the additional window, I have no clue... Is there a way in OS X to find out the pid of a window, to check whether it is open by gunplot or gnuplot_qt ? Could you send the output of "ps auxwww" (or rather the lines that contain "gnuplot") ? > 3.) Print! WOW! I was really happy about that. However: > > Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>: > > kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1 > Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>: > kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch > errors as they are logged. > Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>: > kCGErrorIllegalArgument: > CGSSetWindowShadowAndRimParametersWithStretch: Invalid window > 0xffffffff Is the "print" window displayed or not ? > (Export to PDF create A4 instead of what's on screen, but that's not > related to your patch.) Yes, I have scratched my head about this one, but did not find any solution. Jérôme |
|
From: Mojca M. <moj...@gm...> - 2012-01-07 16:09:53
|
2012/1/7 Jérôme Lodewyck :
> Hi,
>
> here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.
>
> Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit :
>> It has its flaws, but I can finally see it plot a graph.
>>
>> So, here's a list of problems:
>>
>> 1.) Your headers don't compile
>
> That should be fixed in the new patch
>
>> 2.) When I plot something, two windows pop up in "dashboard" (or
>> however the space is called). The first one doesn't respond to
>> anything and I can only force-quit it (resulting in "Qt terminal
>> communication error: select() error Killed: 9"), but the second one
>> works fine. If I quit the second one (it allows me to do that
>> gracefully), I get
>>
>> > Quit application 23586
>>
>> Quit application 23605
>> Qt terminal communication error: select() error
>>
>> and gnuplot is still alive, except that at the next "plot <something>"
>> it enters some infinit loop without doing anything. Only killing the
>> first window also kills gnuplot itself.
>>
>> Is there a way to help you debug the problem?
>
> In the constructor, QtGnuplotApplication sets
> setQuitOnLastWindowClosed(false);
> which forbids the program to quit when you close the terminal window.
Just to make it clear: if I just close the window, there is no error
at all, but the application keeps running. But if I explicitly ask it
to quit (which it allows me to do without a problem), I get the
following:
> Quit application 34327 false
Qt terminal communication error: select() error 9 Bad file descriptor
gnuplot>
and if I try to plot something again, it just takes forever and
doesn't do anything at all. If I exit AquaTerm or X11, there are no
such problems and next plot open AquaTerm or X11 again. Oh, wait, I
checked again. If I exit X11 I get:
> XIO: fatal IO error 35 (Resource temporarily unavailable) on X
server "/tmp/launch-QIgba0/org.x:0"
after 544 requests (532 known processed) with 0 events remaining.
but next plot command reopens it and continues as if nothing happened.
> This
> way, the program is still listening to events from gnuplot, and can open new
> windows when a new plot is requested. The application only quits when gnuplot
> exits. Apparently, this process is broken on OS X since the destructor of the
> QtGnuplotApplication (which prints the "Quit application 23605" mesage) is
> called when you close the terminal window.
When I exit the application actually, not just close the window.
> I have added the value of
> quitOnLastWindowClosed to this message to check whether this property is
> broken or overridden. Could you try again ?
See above. The ps now says:
mojca 34327 0,0 0,4 2540360 22876 s024 S+ 4:30pm
0:02.07 gnuplot_qt
mojca 34326 0,0 0,4 2531780 21640 s024 S+ 4:30pm
0:00.44 ./inst/bin/gnuplot
> As for the additional window, I have no clue... Is there a way in OS X to find
> out the pid of a window, to check whether it is open by gunplot or gnuplot_qt
> ? Could you send the output of "ps auxwww" (or rather the lines that contain
> "gnuplot") ?
One window bears the name gnuplot (the non responsive one) and the
other one gnuplot_qt (the responsive one with the plot and proper
icon).
After I exit the gnuplot_qt window the ps shows me:
mojca 34326 0,0 0,4 2531780 21728 s024 S+ 4:30pm
0:11.01 ./inst/bin/gnuplot
mojca 34327 0,0 0,0 0 0 s024 Z+ 4:30pm
0:00.00 (gnuplot_qt)
Thank you very much for fixing QTVER.
Oh, I just realized. I can comment out
QApplication* application = new QApplication(argc, (char**)( NULL));
in qt_term.cpp and then I don't get the second unresponsive window.
But then I get warnings
QFont: Must construct a QApplication before a QFont
for every plot command. Apart from that, most things seem to work just
fine (mouse clipping works, resizing works apart from zillions of
warning about QFont).
And for a change, now I can use Shift+scrolling, Alt+Scrolling, ...
for zoom in/out, slide left/right, ... (maybe I didn't get the order
right, but that's not important) which didn't work yesterday. All I
was able to get to work yesterday way scrolling up and down.
One semi-nasty problem is that when loading a demo and when I get a
request to hit enter, I need to manually switch back to window with
terminal (with mouse or apple-tab) to be able to enter something into
terminal. X11 works optimally. I always see the graphic on top (if
plotting window was hidden, it gets displayed on top), but keyboard
focus stays in terminal.
Another funny experience: I switched from qt to x11. I then tried to
manipulate focus on window with qt plot, but of course nothing worked.
Then I switched back to qt and terminal started rolling (trying to
obey all the previous scrolling commands that I tried to use while
they didn't work).
Apart from that ... it looks a lot better now after commenting out
that line (still many glitches, but a good start).
Mojca
|
|
From: Jérôme L. <lod...@us...> - 2012-01-08 13:04:13
Attachments:
qtgnuplot2.patch
|
Hi,
what about this new patch ? (I'm not even sure it compiles, because it
makes use of the cocoa API which I cannot test here)
> (I don't particularly like the fact that I now
> have to install gnuplot before running it, but if that is what it
> takes, so let it be.
You don't have to install it. You can define the environment variable
export GNUPLOT_DRIVER_DIR=./src/
to point to the directory where the gnuplot_qt executable is.
> (Where should the image
> from setWindowIcon(QIcon(":/images/gnuplot")); come from?)
the image is in the src/qtterminal/images/ directory, and is included in the
executable by qrc using the configuration file QtGnuplotResource.qrc
Jérôme
|
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-09 05:56:08
|
On Sunday, 08 January 2012, Jérôme Lodewyck wrote: > Hi, > > what about this new patch ? (I'm not even sure it compiles, because it > makes use of the cocoa API which I cannot test here) > > Jérôme I have been running with this one (version 2) under linux. It looks pretty good. Over the day or so of testing I've accumulated 3 zombie gnuplot_qt processes, however. So there's a termination condition that's being missed somewhere. Ethan |
|
From: Jérôme L. <lod...@us...> - 2012-01-09 20:47:41
|
Le Dimanche 8 Janvier 2012 21:55:35 vous avez écrit : > I have been running with this one (version 2) under linux. > It looks pretty good. Over the day or so of testing I've accumulated > 3 zombie gnuplot_qt processes, however. So there's a termination > condition that's being missed somewhere. I tried very hard to crash it but failed to reproduce your observation. Each time I get a gnuplot_qt zombie, there is a gnuplot one, and killing the later kills the former. An interesting question would be whether the zombies you observed are still reachable by starting a new gnuplot and entering set term qt widget "qtgnuplotXXX" where XXX is the pid of the zombie gnuplot_qt. Jérôme |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-01-10 04:56:11
|
On Monday, 09 January 2012, Jérôme Lodewyck wrote: > Le Dimanche 8 Janvier 2012 21:55:35 vous avez écrit : > > I have been running with this one (version 2) under linux. > > It looks pretty good. Over the day or so of testing I've accumulated > > 3 zombie gnuplot_qt processes, however. So there's a termination > > condition that's being missed somewhere. > > I tried very hard to crash it but failed to reproduce your observation. Each > time I get a gnuplot_qt zombie, there is a gnuplot one, and killing the later > kills the former. I wasn't really trying to crash anything. I was just trying to debug other, unrelated, problems. Sometimes the program would crash. Apparently some of those times it would leave behind a zombie. I didn't notice till later, so I can't tell you exactly what I was doing at the time. Nevertheless, I think I can now reproduce it consistently. This is today's CVS with your patch #2 applied. Here is a recipe: $ ./gnuplot # terminal defaults to qt gnuplot> plot x # so far, so good [in another terminal window] $ ps -efT | grep gnuplot # both ./gnuplot and gnuplot_qt visible $ kill -9 <pid of ./gnuplot> $ ps -efT | grep gnuplot # gnuplot_qt is visible, ./gnuplot is gone [close the qt plot window by clicking 'X' in the window title bar] $ ps -efT | grep gnuplot # gnuplot_qt is now a zombie I think the problem is that if the parent process dies hard, either from an unintentional segfault or from receiving a KILL signal, then any atexit() processing that would have sent a signal to the child doesn't happen. I thought at first that maybe this only happened if the child window was closed at the time the parent process was killed, but apparently that doesn't matter. So what I see doesn't seem to match what you see, since you say that if you kill the parent process then the child process dies also. That isn't happening here. > An interesting question would be whether the zombies you > observed are still reachable by starting a new gnuplot and entering > set term qt widget "qtgnuplotXXX" > where XXX is the pid of the zombie gnuplot_qt. Yes, that works. So strictly speaking they are not zombies. But they will sit forever in that state unless you do something clever. cheers, Ethan |
|
From: Tait <gnu...@t4...> - 2012-01-10 10:31:45
|
> $ ./gnuplot # terminal defaults to qt > gnuplot> plot x # so far, so good > > [in another terminal window] > $ ps -efT | grep gnuplot # both ./gnuplot and gnuplot_qt visible > $ kill -9 <pid of ./gnuplot> > $ ps -efT | grep gnuplot # gnuplot_qt is visible, ./gnuplot is gone > ... > I think the problem is that if the parent process dies hard, > either from an unintentional segfault or from receiving a KILL signal, > then any atexit() processing that would have sent a signal to the > child doesn't happen. > ... The definition of a -9 kill is that the killed process CANNOT catch/handle/ignore the signal, receives no warning, and has no opportunity to clean up. Maybe you were thinking of a kill -1 (the default), which sends a sighup? A process would normally catch this and do the usual clean up before dying. The Qt discussion is way beyond my understanding, but the mechanism I've seen before for children to die gracefully when a parent dies is to keep a pipe open to the parent process, and then react to the sigpipe the child would receive if the parent died. |
|
From: Ethan A M. <eam...@gm...> - 2012-01-10 17:22:37
|
On Tuesday, 10 January 2012, Tait wrote: > > $ ./gnuplot # terminal defaults to qt > > gnuplot> plot x # so far, so good > > > > [in another terminal window] > > $ ps -efT | grep gnuplot # both ./gnuplot and gnuplot_qt visible > > $ kill -9 <pid of ./gnuplot> > > $ ps -efT | grep gnuplot # gnuplot_qt is visible, ./gnuplot is gone > > ... > > I think the problem is that if the parent process dies hard, > > either from an unintentional segfault or from receiving a KILL signal, > > then any atexit() processing that would have sent a signal to the > > child doesn't happen. > > ... > > The definition of a -9 kill is that the killed process CANNOT > catch/handle/ignore the signal, receives no warning, and has no > opportunity to clean up. Exactly. That was the point of the test. I wanted to reproduce a condition where the parent process did not send a signal to the child. > Maybe you were thinking of a kill -1 (the > default), which sends a sighup? A process would normally catch this and > do the usual clean up before dying. For what it's worth, I see exactly the same behaviour if I send kill -HUP. > The Qt discussion is way beyond my understanding, but the mechanism > I've seen before for children to die gracefully when a parent dies is > to keep a pipe open to the parent process, and then react to the > sigpipe the child would receive if the parent died. The issue is complicated somewhat by gnuplot's "-persist" option. If "persist" is set, then the plot window is supposed to remain on display even though the parent process has exited. Of course you are also supposed to be able to close/kill the display itself when you are done with it. I squashed a bug in the earlier CVS version of the qt driver that left you unable to get rid of the child window if it had already been closed at the time "persist" mode was enabled. The equivalent problem may have recurred in the fork/exec variant. However, I was _not_ using the -persist option in my tests. But it is possible, I suppose, that the code is incorrectly executing that path anyhow. Jérôme: Is it possible that the setting from setQuitOnLastWindowClosed(false) is persistent across Qt sessions? That is, maybe that setting is handled by the QSettings mechanism that you already described for the background color? Ethan -- Tradition is not the worship of ashes, but the preservation of fire. - Gustav Mahler |
|
From: Mojca M. <moj...@gm...> - 2012-01-07 14:06:23
|
2012/1/7 Jérôme Lodewyck:
> Hi,
>
> here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.
>
> Le Vendredi 6 Janvier 2012 15:14:47 vous avez écrit :
>> It has its flaws, but I can finally see it plot a graph.
>>
>> So, here's a list of problems:
>>
>> 1.) Your headers don't compile
>
> That should be fixed in the new patch
Thank you for the patch. I will test it now. (Where should the image
from setWindowIcon(QIcon(":/images/gnuplot")); come from?)
> As for the additional window, I have no clue... Is there a way in OS X to find
> out the pid of a window, to check whether it is open by gunplot or gnuplot_qt
> ? Could you send the output of "ps auxwww" (or rather the lines that contain
> "gnuplot") ?
>From the old patch:
mojca 27697 0,0 0,4 2538428 20716 s024 S+ 2:51pm
0:00.43 gnuplot_qt
mojca 27696 0,0 0,4 2533056 21648 s024 S+ 2:51pm
0:00.36 ./inst/bin/gnuplot
If I close the window with the plot (and one "window" remains):
mojca 27697 0,0 0,0 0 0 s024 Z+ 2:51pm
0:00.00 (gnuplot_qt)
mojca 27696 0,0 0,4 2532008 21648 s024 S+ 2:51pm
0:00.37 ./inst/bin/gnuplot
It looks to me as if one non-functional "window" belongs to gnuplot
(when you fork and so on) and the working one belongs to gnuplot_qt.
Let me be clear: there are two windows/programs displayed in dock. The
real window cannot be seen if I try to "apple-tab" to it and it is not
responding to anything.
>> 3.) Print! WOW! I was really happy about that. However:
>> > Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> > kCGErrorIllegalArgument: _CGSFindSharedWindow: WID -1
>> Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch
>> errors as they are logged.
>> Jan 6 15:11:53 smurfette.local gnuplot_qt[23619] <Error>:
>> kCGErrorIllegalArgument:
>> CGSSetWindowShadowAndRimParametersWithStretch: Invalid window
>> 0xffffffff
>
> Is the "print" window displayed or not ?
Print dialog box listing printers etc.? No, it isn't.
>> (Export to PDF create A4 instead of what's on screen, but that's not
>> related to your patch.)
>
> Yes, I have scratched my head about this one, but did not find any solution.
I can also take a look, but that is a much lower priority.
Mojca
|
|
From: Daniel J S. <dan...@ie...> - 2012-01-07 20:53:07
|
On 01/07/2012 07:43 AM, Jérôme Lodewyck wrote:
> Hi,
>
> here is an update patch. It implement the idea mentioned in previous mails
> of an auxiliary program started by exec after the fork. On my Linux system,
> with this patch, the Qt terminal works as well as before.
Thanks Jérôme. From Mojca's comments, it sounds like this has addressed
the major OS X issue of CoreFoundation access. I've looked through the
code and all seems straightforward. I guess I like the fact that
gnuplot_qt is now similar to the X11 terminal. Did you have to do
anything special with the communication channel? Or did that just work
out on its own?
...
Ethan/Jérôme, I have one comment about the hunk of code conditionally
compiled into the program:
+#if QT_VERSION < 0x040700
+ /*
+ * FIXME: EAM Nov 2011
+ * It is better to use environmental variable
+ * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
+ * "raster" is ~5x faster than "native" (default).
+ * Unfortunately "opengl" isn't recognized on my test systems :-(
+ */
+ // This makes a huge difference to the speed of polygon rendering.
+ // Alternatives are "native", "raster", "opengl"
+ QApplication::setGraphicsSystem("raster");
+#endif
I'm wondering if instead of conditionally compiled code, whether maybe
this would be better done as simple conditional code statements. That
way the binary would be portable across some compatible systems in which
perhaps the only thing different is that one computer has a different Qt
version than another.
There is an aboutQt() public function in the Qt utility:
http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#aboutQt
One could search the returned string for the version number and use that
to conditionally call the setGraphicsSystem() function. More than that,
it might be nice if somehow one could get information from the Qt
utility about the optional graphics selections. (Anyone see how?) That
way one could select the most efficient graphics rendering and prioritize.
http://developer.qt.nokia.com/doc/qt-4.8/qapplication.html#setGraphicsSystem
I wonder if there might now be a fourth option, "openvg" which uses any
available GPU. Check this discussion:
http://juhaturunen.com/blog/2010/12/how-to-enable-hardware-accelerated-qml-rendering/
and
http://qtunderground.org/wiki/OpenVG
There is an interesting comment that "raster" is much slower than
"openvg". (And apparently Ethan found "raster" is faster than "native",
which must really means something.) So, with the EAM conditionally
compiled code as it stands, "raster" is the best and only that the user
will get. Also, forcing "raster" as it does, there is no way to
optionally control the choice with an environment variable.
So, I would think that the roll of this little hunk of code would be to
achieve the greatest rendering speed, but not override any global
environment settings for Qt. How about something as follows
get version from aboutQt
if version >= Qt 4.5
if QT_GRAPHICSSYSTEM does not exist
pick highest rendering in order of
"openvg", "opengl", "raster", "native"
endif
endif
How exactly to do the inner part, I'm not sure given no way of querying
the Qt core. Also, it'd be nice if setGraphicsSystem returned an error
status, in which case one could try "openvg", if it fails try "opengl",
if it fails try "raster".
Does this sound logical and easy to do? If coded, is there someone with
a GPU accelerated video card that could experiment with the
QT_GRAPHICSSYSTEM environment variable to see how well this works.
...
One last item, once this has stabilized, check whether this line is
necessary:
// Make sure the forked copy doesn't trash the history file
cancel_history();
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2012-01-07 21:00:29
|
On 01/07/2012 02:52 PM, Daniel J Sebald wrote:
+ * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
I assume you are saying that although Qt added the setGraphicsSystem()
routine in version 4.5, it wasn't until version 4.7 that an environment
variable was added. But I think that is an easy fix if gnuplot Qt term
were to program it:
get version from aboutQt
if version >= Qt 4.5
if QT_GRAPHICSSYSTEM does not exist
pick highest rendering in order of
"openvg", "opengl", "raster", "native"
else
setGraphicsSystem(QT_GRAPHICSSYSTEM);
endif
endif
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2012-01-07 22:06:59
|
On 01/07/2012 03:00 PM, Daniel J Sebald wrote:
> On 01/07/2012 02:52 PM, Daniel J Sebald wrote:
>
> + * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
>
> I assume you are saying that although Qt added the setGraphicsSystem()
> routine in version 4.5, it wasn't until version 4.7 that an environment
> variable was added. But I think that is an easy fix if gnuplot Qt term
> were to program it:
I guess this doesn't make enough sense because it is only 4.5 where
setGraphicsSystem exists:
get version from aboutQt
if version >= Qt 4.5
if QT_GRAPHICSSYSTEM does not exist
pick highest rendering in order of
"openvg", "opengl", "raster", "native"
else
setGraphicsSystem(QT_GRAPHICSSYSTEM);
endif
endif
The version test could be dropped.
If one doesn't want to force the upgrade of Qt then:
#if QT_VERSION >= 0x040500
if QT_GRAPHICSSYSTEM does not exist
pick highest rendering in order of
"openvg", "opengl", "raster", "native"
else
setGraphicsSystem(QT_GRAPHICSSYSTEM);
endif
#endif
|
