Hi Phil: On 2016-02-23 23:36-0000 Phil Rosenberg wrote:
> I obviously don't have any idea of the size of ephcom, but Plplot must have thousands of internal function calls that would need the return value checking. I believe there are some 300 functions in our public and private API, and not all of those will be affected by this (because there are no error conditions they generate or they need to propagate). So I would estimate "hundreds" of functions rather than "thousands" would be touched by this propagation effort. Also, I think the editing task for propagating return codes would be a similar effort to the editing task for replacing the call to plexit by the generation of the equivalent message to stderr and an immediate return with non-zero return code. Note, the number of plexit calls is 220, from the results of find . -name "*.c" |xargs grep plexit | wc -l That number is roughly equivalent to the estimate I made above of the number of functions that would be affected by the propagation effort. That is the basis of my claim that the two efforts would be comparable. > I'm not sure there is any way we can reliably catch them all I am glad you asked that really important question. You stumped me for a while, but I have now thought of one test method which I believe would be almost completely reliable. Here is how you would perform that test. For each replacement of a "plexit" call you simply check (by testing with a temporary fake error message and temporary fake non-zero return code) that the fake return code propagates correctly. That check would be done by running all our C examples with the appropriate device. Normally, that device would just be the svg or psc one, but you would need to be more specific about the device whenever you are testing propagation of return codes from a particular device to libplplot. The point is that if the return code propagation is working correctly, the fake error message (generated right in the routine where the error occurs) should always be accompanied by a non-zero return code from one of the C examples. So this method tests both the propagation of the non-zero return code throughout our devices and C library and also through the C examples (which is a good thing). Of course, there is one obvious caveat about the reliability of this test method which is that our C examples might never call (directly or indirectly) the function where the fake error message and fake non-zero return code is being used for testing propagation. So extra caution would have to be used for the case where no C example prints out the temporary fake error message. But I don't think that case will happen very often because our C examples test libplplot pretty thoroughly. Anyhow, I am convinced by my above estimate that the propagation part of the work will require similar effort to the rest of the project, I do like the simplicity of the return code method that has proved to be so useful in the ephcom case, and I think the above testing method will insure the whole effort will give reliable return code results. Also, I think we are talking a few weeks of one-man effort rather than months to get this done completely. Therefore, I stand willing (early in the next release cycle) to make this happen. Of course, many hands make light work so I would welcome some help with this project. 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
