Re: "features" problems

[Philip Nienhuis]

Carnë Draug wrote:
> 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.

Sure. It's natural that core Octave has priority, yet maintaining and 
adapting OF packages also implies a big cost at times.
But let me be clear: I don't want to complain. I just want to bring up 
my motives.

<snip>
> 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.

As for that question about what configuration / host system / runtime 
information is required, I'd suggest the complete VAR list returned by 
the octave-config command (executable): ("octave-config --help"):

API_VERSION            LOCALARCHLIBDIR
ARCHLIBDIR             LOCALFCNFILEDIR
BINDIR                 LOCALOCTFILEDIR
CANONICAL_HOST_TYPE    LOCALSTARTUPFILEDIR
DATADIR                LOCALVERARCHLIBDIR
DATAROOTDIR            LOCALVERFCNFILEDIR
DEFAULT_PAGER          LOCALVEROCTFILEDIR
EXEC_PREFIX            MAN1DIR
EXEEXT                 MAN1EXT
FCNFILEDIR             MANDIR
IMAGEDIR               OCTDATADIR
INCLUDEDIR             OCTFILEDIR
INFODIR                OCTINCLUDEDIR
INFOFILE               OCTLIBDIR
LIBDIR                 PREFIX
LIBEXECDIR             SHLEXT
LOCALAPIARCHLIBDIR     STARTUPFILEDIR
LOCALAPIFCNFILEDIR     VERSION
LOCALAPIOCTFILEDIR

(matching the info in small caps that octave_config_info returns)

Reasoning:
Several pieces of Octave's installation subdirs can be put in 
non-default locations depending on credentials (local vs. global) and 
various configure prefixes. So those locations should be discoverable as 
easily as possible.

The rest that I care about can be obtained using __have_feature__.m

My wish is that something similar should also apply to OF packages, but 
pkg.m isn't that far yet. Maybe "pkg -verbose describe" could at some 
time echo it. That would obviate the rest of this post :-)

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

....*may change*....
- I haven't read about deprecating PKG_ADD/PKG_DEL yet.
- That m-file subdir will be there as long as there is an io package and 
pkg.m setup is similar.
When things change "adversely" we'll see what to do then.

As I answered you in that (somewhat private because package release 
tracker) discussion you referred to:  the io package could be several 
releases further when/if core Octave innards change along your fears. 
Indeed, since that discussion io evolved from some 2.2x to current 2.4.1 
and it still works fine with stable Octave - it's main "audience".

So there's ample time for preparation.

The current Octave development version is in a volatile phase, indeed; 
as soon as Octave-4.2 (5.0?) is out I'll see what is really needed to 
get io running with it and til then I plan to try to keep up with 
minimum effort. The more so as JWE may still have plans to move the 
spreadsheet I/O to core.

> 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).

Hmmm, a slight change of subject. I get to that further below but first 
back on track:

The problem that the io package has with PKG_ADD, or maybe better: with 
the way pkg.m initializes packages upon loading, is that "pkg install" 
puts it in the arch-dependent subdir that apparently gets loaded before 
the m-file subdir. As a consequence PKG_ADD in the arch-dependent subdir 
is already invoked and calling package functions (notably .m functions) 
while the complete package hasn't been loaded yet.
Now, post_install.m is used to move PKG_ADD to a better place. Some 
octave_config_info is required for that job.

I see that the stk package has PKG_ADD in the m-file subdir and not in 
the arch-dependent subdir. That begs the question: how/why did PKG_ADD 
get there? (or why does it for the io package end up in the 
arch-dependent subdir?)

> 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).

Yes, I know PKG_ADD runs in the current scope; io package's PKG_ADD is 
careful and cleans up after itself.

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

That is a good suggestion.
But it doesn't change the PKG_ADD location issue which was at the base 
of this part of the discussion - to wit, why certain octave_config_info 
output could be required.

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

OK sorry / thanks, but computer() does not return (all) the info that is 
required. E.g., api_version is missing.

Philip