|
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
__________________________
|