From: Andrew R. <and...@us...> - 2010-06-01 08:37:25
|
Discussion move to plplot-devel as this has moved beyond the initial help request. On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: > On 2010-05-30 12:04-0400 Hazen Babcock wrote: > > > Ok, fixed in v11036. It should now behave like the qtwidget driver, which > > does not actually call plexit(). The stream is not really closed, but nothing > > can be plotted anymore so it at least appears closed. In the case of the > > examples, what happens is that once you click the close box all the > > subsequent plotting commands become nop's. > > Hi Hazen: > > That's great you discovered qtwidget does not use plexit and implemented a > solution without plexit for the xcairo case as well. I like your solution > of using a flag to turn all operations into no-ops when the window has been > closed. I confirm that solution smoothly exits from examples/c/x02c when you > close the window regardless of page. Thanks! This is a relatively elegant solution which avoids most of the pitfalls with plplot code being executed after the window has closed. Without full error handling in plplot and rewriting lots of user code it is probably the best we can do. > Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo > from within octave and close the window are you now happy with the results? Well it works fine. This is not really the main problem with octave though. The big issue is doing something silly which results in plexit being called in plplot crashes octave as well. Not a good solution. > > Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) > templates for the proper way to do window closing without plexit clobbering > the calling environment, and we should propagate those solutions to -dev > xwin, -dev tk, and -dev wxwidgets. Agreed, although perhaps it would be more efficient to do this at the library level rather than the driver level. We would only have to do it once, and then any new interactive drivers would simple have to detect the close window button press and set a flag. Andrew |
From: Alan W. I. <ir...@be...> - 2010-06-01 14:40:16
|
On 2010-06-01 09:37+0100 Andrew Ross wrote: > On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: >> Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo >> from within octave and close the window are you now happy with the results? > > Well it works fine. This is not really the main problem with octave > though. The big issue is doing something silly which results in plexit being > called in plplot crashes octave as well. Not a good solution. > >> >> Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) >> templates for the proper way to do window closing without plexit clobbering >> the calling environment, and we should propagate those solutions to -dev >> xwin, -dev tk, and -dev wxwidgets. > > Agreed, although perhaps it would be more efficient to do this at the library > level rather than the driver level. We would only have to do it once, and > then any new interactive drivers would simple have to detect the close window > button press and set a flag. Good idea that is also likely to solve the -dev tk issue caused by the recent xwin noop fix (which I had to revert because of the -dev tk issue). Also, to answer your further comment above about plexit, we could also just have that set a noop flag for the device used for the stream rather than exiting. Then when something goes wrong with a device, it can call plexit with impunity and similarly when something goes wrong with the PLplot core library, and from then on all device calls for the stream are turned into noops. To me the core library noop solution with plexit modified to use that solution is such a nice idea that my first instinct is to encourage you and Hazen to implement it before the release. However, yesterday I had to deal with three different regressions that had been introduced by very recent changes, and this is a sobering reminder of the downside of making too many changes close to release. That said, it is probably okay if you can squeeze in the changes today (Tuesday) because it gives all of us a chance to test them on all platforms accessible to us for 3 days prior to the release. However, I would be uncomfortable about the quality of our release if we had much less than 3 days to test. Thus, in the likely event that you and Hazen cannot meet such a quick deadline, then I suggest you should put off further noop changes until after the release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2010-06-01 19:11:00
|
On Tue, Jun 01, 2010 at 07:40:06AM -0700, Alan Irwin wrote: > On 2010-06-01 09:37+0100 Andrew Ross wrote: > > > On Sun, May 30, 2010 at 06:09:01PM -0700, Alan Irwin wrote: > >> Now a question for Andrew. If you try either -dev qtwidget or -dev xcairo > >> from within octave and close the window are you now happy with the results? > > > > Well it works fine. This is not really the main problem with octave > > though. The big issue is doing something silly which results in plexit being > > called in plplot crashes octave as well. Not a good solution. > > > >> > >> Assuming the answer is yes, then we have both C (cairo.c) and C++ (qt.cpp) > >> templates for the proper way to do window closing without plexit clobbering > >> the calling environment, and we should propagate those solutions to -dev > >> xwin, -dev tk, and -dev wxwidgets. > > > > Agreed, although perhaps it would be more efficient to do this at the library > > level rather than the driver level. We would only have to do it once, and > > then any new interactive drivers would simple have to detect the close window > > button press and set a flag. > > Good idea that is also likely to solve the -dev tk issue caused by the > recent xwin noop fix (which I had to revert because of the -dev tk issue). > Also, to answer your further comment above about plexit, we could also just > have that set a noop flag for the device used for the stream rather than > exiting. Then when something goes wrong with a device, it can call plexit > with impunity and similarly when something goes wrong with the PLplot core > library, and from then on all device calls for the stream are turned into > noops. > > To me the core library noop solution with plexit modified to use that > solution is such a nice idea that my first instinct is to encourage you and > Hazen to implement it before the release. However, yesterday I had to deal > with three different regressions that had been introduced by very recent > changes, and this is a sobering reminder of the downside of making too many > changes close to release. That said, it is probably okay if you can squeeze > in the changes today (Tuesday) because it gives all of us a chance to test > them on all platforms accessible to us for 3 days prior to the release. > However, I would be uncomfortable about the quality of our release if we had > much less than 3 days to test. Thus, in the likely event that you and Hazen > cannot meet such a quick deadline, then I suggest you should put off further > noop changes until after the release. Alan, I think this is a very useful feature, but it does need some thought. Do we for example want a method for the user to reset the flag once they have tidied up, or do they need to close then reopen the stream? We should also have a way of the user querying the flag so they can check for errors and clean up accordingly. I don't have too much time right now, and this is also likely to be quite an intrusive change so I suggest holding off until after the release. Andrew |
From: Hazen B. <hba...@ma...> - 2011-08-16 13:30:12
|
On 06/01/2010 10:40 AM, Alan W. Irwin wrote: >> >> Agreed, although perhaps it would be more efficient to do this at the >> library >> level rather than the driver level. We would only have to do it once, and >> then any new interactive drivers would simple have to detect the close >> window >> button press and set a flag. > > Good idea that is also likely to solve the -dev tk issue caused by the > recent xwin noop fix (which I had to revert because of the -dev tk issue). > Also, to answer your further comment above about plexit, we could also just > have that set a noop flag for the device used for the stream rather than > exiting. Then when something goes wrong with a device, it can call plexit > with impunity and similarly when something goes wrong with the PLplot core > library, and from then on all device calls for the stream are turned into > noops. > > To me the core library noop solution with plexit modified to use that > solution is such a nice idea that my first instinct is to encourage you and > Hazen to implement it before the release. However, yesterday I had to deal > with three different regressions that had been introduced by very recent > changes, and this is a sobering reminder of the downside of making too many > changes close to release. That said, it is probably okay if you can squeeze > in the changes today (Tuesday) because it gives all of us a chance to test > them on all platforms accessible to us for 3 days prior to the release. > However, I would be uncomfortable about the quality of our release if we > had > much less than 3 days to test. Thus, in the likely event that you and Hazen > cannot meet such a quick deadline, then I suggest you should put off > further > noop changes until after the release. Reviving a very old thread since this problem continues to bite some of our users.. Is this a good idea that got lost? Or did we have some reason for not following through? -Hazen |
From: Alan W. I. <ir...@be...> - 2011-08-16 16:12:07
|
On 2011-08-16 09:29-0400 Hazen Babcock wrote: > On 06/01/2010 10:40 AM, Alan W. Irwin wrote: >>> >>> Agreed, although perhaps it would be more efficient to do this at the >>> library >>> level rather than the driver level. We would only have to do it once, and >>> then any new interactive drivers would simple have to detect the close >>> window >>> button press and set a flag. >> >> Good idea that is also likely to solve the -dev tk issue caused by the >> recent xwin noop fix (which I had to revert because of the -dev tk issue). >> Also, to answer your further comment above about plexit, we could also just >> have that set a noop flag for the device used for the stream rather than >> exiting. Then when something goes wrong with a device, it can call plexit >> with impunity and similarly when something goes wrong with the PLplot core >> library, and from then on all device calls for the stream are turned into >> noops. >> >> To me the core library noop solution with plexit modified to use that >> solution is such a nice idea that my first instinct is to encourage you and >> Hazen to implement it before the release. However, yesterday I had to deal >> with three different regressions that had been introduced by very recent >> changes, and this is a sobering reminder of the downside of making too many >> changes close to release. That said, it is probably okay if you can squeeze >> in the changes today (Tuesday) because it gives all of us a chance to test >> them on all platforms accessible to us for 3 days prior to the release. >> However, I would be uncomfortable about the quality of our release if we >> had >> much less than 3 days to test. Thus, in the likely event that you and Hazen >> cannot meet such a quick deadline, then I suggest you should put off >> further >> noop changes until after the release. > > Reviving a very old thread since this problem continues to bite some of > our users.. Is this a good idea that got lost? Hi Hazen: Thanks for bringing this up. I have just now reviewed this whole interesting thread, and I still think this is a good idea. Sometimes, though, Andrew quietly fixes things so I am not sure whether this good idea has been implemented yet or not. Andrew? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2011-08-16 19:33:34
|
On 08/16/2011 12:11 PM, Alan W. Irwin wrote: > > Hi Hazen: > > Thanks for bringing this up. I have just now reviewed this whole > interesting thread, and I still think this is a good idea. Sometimes, > though, Andrew quietly fixes things so I am not sure whether this good > idea has been implemented yet or not. Sigh, I guess my memory really is going.. It looks like I added this about a year ago, though I did not remove the previous stream closed logic from the xcairo driver. Now I guess the question is whether we want to change plexit() to set this flag rather than taking the hard exit approach? -Hazen |