Hi Andrew: On 2011-11-03 21:12-0000 Andrew Ross wrote:
> On Thu, Nov 03, 2011 at 10:38:27AM -0700, Alan Irwin wrote: >> Hi Andrew: >> >> I agree this is an important issue that we need to solve to make >> interactive use of PLplot a much nicer experience. However, I >> am not sure it needs to be solved with a massive API change. >> >> Here are the current rough plexit statistics: >> >> software@raven> grep plexit drivers/*.c src/*.c |wc -l >> 228 >> software@raven> grep plexit drivers/*.c src/*.c |grep -iv mem |wc -l >> 97 >> >> The second command attempts to eliminate the "out of memory" ones from >> the result since I assume you do not want to do anything other than >> exit for such a major overall system problem. > > Even then I don't think it is up to plplot to exit. This is the > programs responsibility. You wouldn't want malloc to exit your > programme if memory allocation failed. Why should plplot be > different? If we tackle the problem, we should do it properly. Good point. Agreed. >> There are two cases to consider here [for replacing plexit]. >> >> + Public API. Replace plexit with plwarn and continue with the >> plot when that is possible or do a quick return otherwise. If >> our interactive users get a plwarn message when they make a >> mistake, and in addition no plot when it is a really bad mistake >> that should be sufficient, and I think a return code in addition >> would be overkill. The large advantage of this approach is no >> API change would be necessary. >> >> + Private functions. Presumably some of our private functions >> that are called by our public API routines currently call plexit >> themselves. For this case we should also replace the call to >> plexit with plwarn, but we should also return an error code to >> our public API routines which should then do a quick return with >> no plotting action for non-zero return codes. >> > I agree about your 2 classes of error above. > > One other additional option is to have some sort of global error flag, or > a new function to check the plplot error status. For the public API a > warning could also set the error flag. That way new code could check > for errors, but existing function return values would not change so > existing code would still work with a recompile against the new version > rather than potentially requiring changes. I don't like global variables, > and having to poll the variable / error function after every API call > that could fail is tedious. Changing the return value from void to int > would actually probably be no more invasive. A recompile would be > required anyway for an API (and hence soname) change, but old code > would not need to be modified - it would just ignore the return value. Yeah. Let's stick with the return code idea (as also recently supported by Steve). > > Anyway, I will try to start looking through the plexit calls to see > if we can downgrade some of them / pass the error back in a graceful > manner. Hopefully this will promote some debate. Well, maybe not debate since so far we seem to have come to general consensus about what needs to be done, but ideally your survey will help you to come up with a specific plan of what has to be done illustrated by a conversion of at least one of our source files. Once we have such a specific plan, then it should be straightforward to crowd-source extending the work to all our source files. A lot of us (including myself) don't have a lot of concentrated time we could contribute to this. On the other hand, most of us could presumably afford an hour or so of editing work each week working towards a well-defined common development goal that would make PLplot much easier to use. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
