Re: Policy of refering to packages? Policy of choosing package for ML-compatible functions?

[Olaf Till]

On Fri, Dec 23, 2016 at 03:46:25PM -0800, Mike Miller wrote:
> On Thu, Dec 22, 2016 at 13:42:14 -0500, Nicholas Jankowski wrote:
> > I'm wondering if this would also help the issue that arises periodically
> > when a user attempts to call a function from a non-loaded package, and
> > maybe provide a more reliable or automated way to provide a "you need to
> > load package XYZ to use that function" message.
>
> <snip>
> One idea was to query the lists of functions in installed-but-not-loaded
> packages.
> <snip>
> This is open bug #45855, which I started to poke at but could use some
> more contributions to fully integrate with the missing function hook.

In the context of possibly referring the user to an OF package, it
seems right to check if 'pkg load' can provide the function. Current
'__unimplemented__.m' does this for the builtin list of some ML
toolbox functions. But as you say, there could be a need to check this
for all functions, with 'pkg ("describe")'. (BTW, current pkg treats
argument "all" as a package name).

> Beyond looking at installed-but-not-loaded packages, another option
> could be to (possibly via an opt-in setting) query a web API that
> returns a not-yet-installed package for a given function.
> 
> Or if that's too automatic (I think it is), maybe a "pkg search"
> subcommand that could return a package or list of packages that contain
> functions matching a query.

Both suggestions would potentially solve the original issue that
current Octave sometimes refers the user to a wrong OF package, due to
the lack of a consensus to strictly adher to ML toolbox structure.

I'd think, as things and opinions currently stand, it would be right
to follow one of these suggestions, instead of only using the builtin
package/function relation in '__unimplemented__.m'. But I'm not sure.

A secondary question would be if 'pkg search' (or something similar)
should be performed/suggested only for a list of ML toolbox functions,
or for other functions also.

And of course, doing any such change would require that an overall
function database is available (and automatically maintained) at
OF. As noted before, such a database could be useful for other things,
too, e.g. to avoid name clashes within OF.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature