problems with "aoutoload" in 3.1.55

[Carlo de Falco]

On 22 May 2009, at 19:06, John W. Eaton wrote:

> On 20-May-2009, Carlo de Falco wrote:
>
> | On 20 May 2009, at 20:34, John W. Eaton wrote:
> |
> | > Can you provide a minimal and simple self-contained example that  
> does
> | > not depend on an external package?
> | >
> | > Thanks,
> | >
> | > jwe
> |
> | This looks like the simplest failing test case I can construct.
> | Thanks for looking into this!
> | c.
> |
> | ---------------------
> | $ /opt/octave/3.1/bin/mkoctfile low_level_functions.cc
> | $ /opt/octave/3.1/bin/octave -q
> |  >> suppress_verbose_help_message (1)
> |  >> help myfun
> | `myfun' is a function from the file /Users/carlo/Desktop/ 
> autoloadbug/
> | low_level_functions.oct
> |
> | MYFUN: this version of myfun is defined in an oct-file
> |
> |  >> help myfun
> | `myfun' is a function from the file /Users/carlo/Desktop/ 
> autoloadbug/
> | myfun.m
> |
> |   MYFUN: this version of myfun is defined in an m-file
> |
> |  >> version
> | ans = 3.1.55
> |  >>
>
> You can also demonstrate this behavior just by executing myfun twice:
>
>  octave:1> myfun
>  ans =  1
>  octave:2> myfun
>  ans = 0
>
> I think I can explain why this happens, but I'm not sure what the best
> fix is (if any).
>
> When Octave looks for the definition of a symbol, it uses the
> following precedence list:
>
>  variable
>  subfunction
>  private function
>  class constructor
>  class method
>  legacy dispatch
>  command-line function
>  autoload function
>  function on the path
>  built-in function
>
> So the first time myfun is executed, the autoload is found.  The next
> time it is executed, Octave tries to determine whether the definition
> of myfun is out of date.  In doing that, it looks for a function on
> the load path and finds myfun.m.  Since myfun.m is not the same file
> where the first definition of myfun came from, the new file is used
> (maybe a new file was added in a directory on the path that is ahead
> of where the first definition was found, for example).
>
> I suppose we could fix this by checking for autoload functions when
> doing the out-of-date check (i.e., only look at the timestamp for the
> autoloaded file), but then it would be impossible to replace an
> autoload function with a .m file (for example).

There is already a case where this happens (being unable to replace an  
autoload command) that I noticed and reported some time ago:
if, when loading a package, an autoload directive is found, even after  
un-loading the package,
the autoloaded funcions will still be defined.
It would be nice to have some command to undo autoload directives that  
could be put in the PKG_DEL file so that when a package is unloaded  
its functions disappear completely

> Or, maybe autoloaded functions should be looked up last, after
> built-in functions?  In that case, your myfun.m file would always be
> found, and the autoload would be ignored.  By doing this, users could
> override autoload functions.
>
> I think the latter alternative might be best.

I don't know what is the best choice in general, but in my case this  
would be contrary to the reason for which I have both oct- and m-file  
versions of some functions in my packages. The idea is that if for  
some reason (incomplete octave installation, missing compilers or  
libraries) the compilation of the oct file fails then the m-file  
version is still usable. This is also useful to keep compatibilty with  
matlab (which I need for the nurbs package). If autoloaded functions  
are searched for after .m files in the path then the oct  
implementation would never be fund.
If you decide to take this approach,  could you suggest a way to  
modify my package so that the autoladed version is used by default and  
the m-file is only kept as a backup resource?

> Comments?
> jwe

c.