Re: [Plplot-devel] [Plplot-general] Could someone help with this crash?

[Andrew R. <and...@us...>]

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