From: Alan W. I. <ir...@be...> - 2017-10-02 04:43:02
|
On 2017-10-02 00:14+0100 Phil Rosenberg wrote: > On 1 October 2017 at 21:01, Alan W. Irwin <ir...@be...> wrote: >> On 2017-10-01 09:49+0100 Phil Rosenberg wrote: >> >> [Alan said] >>>> >>>> With regard to your remark concerning writing a plsfillrule() function >>>> and systematically using it throughout src/plargs.c, I wouldn't want >>>> to do that myself, but if you or Jim want to make such a change and it >>>> passes comprehensive testing, I certainly would not object. >>> >>> >> [Phil responded] >>> >>> I can add a new API function if you think it is useful, but I can only >>> propagate it as far as the C and C++ APIs, someone else would have to >>> propagate it to other languages as needed. >>> >> >> From what has been said, my impression is a plsfillrule() function is >> C-only functionality to make src/plargs.c easier to understand and use >> correctly. If that impression is correct there should be no need to >> propagate this functionality even to our C++ binding since all our bindings >> simply wrap the C plparseopts routine without knowing its >> internal implementation details. But please educate me if that >> impression is incorrect. >> > > Hi Alan > I actually meant, do we want to add plsfillrule as an API function? It > feels more like it should be an API function rather than a command > argument. It would be little trouble to allow users to swap back and > forward between the two rules. But I have a feeling this functionality > is not used that often so maybe it's not worth the effort. Hi Phil: Sorry, but I think I have misunderstood this subset of this thread from the beginning since I assumed you were talking about some general capability rather than something specific to -eofill (which is obvious from the name of the "plsfillrule" function, but I simply missed the significance of that name until now). So to start over, it would be worthwhile to be able to set pls->dev_eofill to true or false at any time. But I don't think we need to add API to do that. Instead, we need to modify src/plargs.c such that -eofill takes a true (non-zero) or false (0) argument. with pls->dev_eofill being set appropriately to true or false. Then users in any language can call plsetopt("eofill", "1"); plsetopt("eofill", "0"); as needed. Of course, demanding that -eofill requires an argument is backwards incompatible, but if we mention that in the release notes I think that would be sufficient since my judgement is -eofill is not a heavily used option. If you agree with the above idea to add an argument to -eofill, then I would be willing to take responsibility for implementing that and documenting that backwards-incompatible change in README.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); 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 __________________________ |