Re: "features" problems

[Carnë Draug]

On 19 March 2016 at 21:06, Philip Nienhuis <address@hidden> wrote:
> Carnë Draug wrote:
>>
>> On 19 March 2016 at 00:04, PhilipNienhuis <address@hidden> wrote:
>>>
>>> Carnë Draug wrote
>>>>
>>>>
>>>> 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?
>>>
>>>
>>> [...]
>>>
>>> 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__()
>>
>>
>> Why do you need api_version and libdir in the first place?  Those
>> would be among the ones that I'd guess should not be made public.
>
>
> Why should it not be public?
>
> IMO it's entirely up to users and esp. developers to determine what to do
> with this sort of info. It is there so why not make use of it if there is a
> clear need. I was glad it was so easy to get and use it.
> Obviously it's at the main developers discretion to select what info may be
> public but I find it akin to pedantic to withhold very useful and reliable
> configuration & system info from other developers (e.g., OF package
> developers).

There is a big cost implied in making internals public; the cost of
maintaining them.  If octave_config_info was made private from the start
(and I just explained why that should have been) we wouldn't be having this
discussion now.

Anyway, the whole point of this discussion is to come up with a list of
which configuration options should be made public, how they should be
made public, and for what purpose.  So that this doesn't happen again.

A good measure to decide what should be made public, is how useful and
reliable they are.

>
> In the io package libdir is used in a.o., chk_spreadsheet_support.m to find
> subdirs where Java class libs can be found. Some Linuces put those in
> /usr/bin or its subdirs.
>
> api version + other info like canonical_host_type is currently needed to
> find out where the arch-dependent package modules are located;
> post_install.m uses it to move PKG_ADD around. The underlying issue
> (invoking functions before all of the package has been loaded) has been
> discussed here or in the bug tracker a while ago but no solution emerged.

And I didn't argue that you should not be using post_install to move
PKG_ADD files around as part of the installation?  I think that it is
not documented that packages will be installed there.  This means that
it may change in future versions of Octave.

In the case of the io package, you could drop all of PKG_ADD into a
__init_io_package__ function, and then use a PKG_ADD directive that
calls it.  This is what stk package did to solve the same problem (it
uses stk_init).

That solution has another advantage.  PKG_ADD is sourced.  This means that
if anything in PKG_ADD generates a result it will replace local variables
(clearing variables at the end of PKG_ADD does not restore their value).
The reason for why PKG_ADD behaves like this is that it is meant for simpler
things, such as registering options.  If you need a complex piece of code,
use a separate function for it and call it from PKG_ADD.


>> You can get arch (I'm assuming you meant arch of the host --- beware of
>> cross compiling) using computer ().
>
> Please, I know about ispc/isunix/ismac. See above fro some of the info I
> (and a.o., the io package) use.

I never mentioned ispc/isunix/ismac.  I mentioned computer() which is very
much different.  It actually checks octave_config_info behind the scenes
so it will continue to work despite the new changes.

Carnë