problems with "aoutoload" in 3.1.55

John W. Eaton jwe at octave.org
Fri May 22 12:06:28 CDT 2009


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

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.

Comments?

jwe




More information about the Bug-octave mailing list