Re: "features" problems

[PhilipNienhuis]

Carnë Draug wrote
> On 10 March 2016 at 22:42, John W. Eaton <

> jwe@

> > wrote:
>> On 03/10/2016 05:30 PM, Carnë Draug wrote:
>>>
>>> On 10 March 2016 at 22:21, John W. Eaton <

> jwe@

> > wrote:
>>>>
>>>> [...]
>>>> I recently changed the layout of the structure returned by
>>>> octave_config_info.
>>>>
>>>> Instead of writing
>>>>
>>>>    octave_config_info ("features").JAVA
>>>>
>>>> I recommend writing
>>>>
>>>>    __have_feature__ ("JAVA")
>>>>
>>>> as that will work with the new and old structure layouts.
>>>>
>>>
>>> Should we make use of this private and internal functions outside core?
>>>
>>> And since octave_config_info() was not a private function, if we want to
>>> change this, should we not deprecate "features" first?
>>>
>>> The whole point of not using a private function is that their behaviour
>>> will
>>> not change suddenly.
>>
>> Yeah.  Unfortunately, the layout of the structure returned by
>> octave_config_info wasn't very good.
>>
>> Probably octave_config_info should have been tagged as a
>> "system"/"private"
>> function as well.
>>
>> jwe
> 
> I discussed this with jwe and Mike Miller last week.  I think it's
> important
> that this is mentioned here since otherwise I don't think there's public
> explanation of the reasoning behind the change.
> 
> The reasoning behind this is that we can't ensure Octave will maintain the
> configure variables and names over versions.  Most of those names only
> make
> sense in light of the Octave internals that should not be made public. 
> The
> example that makes this the most obvious is the use of:
> 
>     octave_config_info ("features").MAGICK
> 
> This will tell us whether Octave has support for image reading and writing
> (we are currently using graphicsmagick or imagemagick for this).  But we
> may change in the future for another library such as cimg and MAGICK will
> stop having meaning.
> 
> There may be a very limited set of things, currently in
> octave_config_info,
> that we can make public.  We should decide which ones.  Some can be tested
> easily at runtime and already functions to do it (java and image io for
> example).  I have started a list of those at the wiki [1].
> 
> Which ones are tricky to test at runtime and should be exposed outside
> core?

No doubt there are very valid reasons for this change.

__have_feature__ (<feature>) works all right, be it that there's no warning
if e.g. a feature has been misspelled, e.g. __have_feature__ ("JAVE") , or
is simply non-existent - one just gets 0 for any not-recognized feature
names. octave_config_info at least warned (very handy in development stages)

A little issue with the __have_feature__ method is that it isn't possible
(or I have missed something) to find out e.g. , api version, or arch, or
libdir. The io package makes use of that info as well. 
Of course workarounds can be thought up but they seem less robust to me than
directly querying octave_config_info() or __octave_config_info__()

Philip





--
View this message in context: 
http://octave.1599824.n4.nabble.com/features-problems-tp4675361p4675648.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.