problems with "aoutoload" in 3.1.55

[Carlo de Falco-2]

I experienced the following strange behaviour with 3.1.5 for functions  
that are autoloaded from a .oct file,
but I am not sure whether it is a bug or I just don't understand how  
autoload is supposed to work

------------------------
 >> version
ans = 3.1.55
 >> pkg load nurbs
 >> which findspan
`findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
i386-apple-darwin9.6.0-api-v37/low_level_functions.oct
 >> which findspan
`findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
findspan.m
 >> autoload("findspan","/Users/carlo/octave/nurbs-1.0.0/i386-apple-
darwin9.6.0-api-v37/low_level_functions.oct")
 >> which findspan
`findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
findspan.m
 >>
------------------------

anyway this worked differently in 3.0.5

------------------------------
 >> version
ans = 3.0.5
 >> which findspan
findspan is the dynamically-linked function from the file
/Users/carlo/octave/nurbs-1.0.0/i386-apple-darwin8.9.1-api-v32/
low_level_functions.oct
 >> which findspan
findspan is the dynamically-linked function from the file
/Users/carlo/octave/nurbs-1.0.0/i386-apple-darwin8.9.1-api-v32/
low_level_functions.oct
 >>
------------------------

any comments would be appreciated.
c.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On  9-May-2009, Carlo de Falco wrote:

| I experienced the following strange behaviour with 3.1.5 for functions  
| that are autoloaded from a .oct file,
| but I am not sure whether it is a bug or I just don't understand how  
| autoload is supposed to work
|
| ------------------------
|  >> version
| ans = 3.1.55
|  >> pkg load nurbs
|  >> which findspan
| `findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
| i386-apple-darwin9.6.0-api-v37/low_level_functions.oct
|  >> which findspan
| `findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
| findspan.m
|  >> autoload("findspan","/Users/carlo/octave/nurbs-1.0.0/i386-apple-
| darwin9.6.0-api-v37/low_level_functions.oct")
|  >> which findspan
| `findspan' is a function from the file /Users/carlo/octave/nurbs-1.0.0/
| findspan.m
|  >>
| ------------------------
|
| anyway this worked differently in 3.0.5
|
| ------------------------------
|  >> version
| ans = 3.0.5
|  >> which findspan
| findspan is the dynamically-linked function from the file
| /Users/carlo/octave/nurbs-1.0.0/i386-apple-darwin8.9.1-api-v32/
| low_level_functions.oct
|  >> which findspan
| findspan is the dynamically-linked function from the file
| /Users/carlo/octave/nurbs-1.0.0/i386-apple-darwin8.9.1-api-v32/
| low_level_functions.oct
|  >>
| ------------------------
|
| any comments would be appreciated.

Can you provide a minimal and simple self-contained example that does
not depend on an external package?

Thanks,

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

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








_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

On 20 May 2009, at 20:54, 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
> >>
> ---------------------
>
> <myfun.m><low_level_functions.cc><PKG_ADD>
>

BTW the same example seems to show also a bug in get_help_text:

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

 >>  [text, format] = get_help_text (myfun)
warning: implicit conversion from scalar to string
text =
format = Not found
 >>
------------------------------------------------------

c.


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

On 20 May 2009, at 21:16, Carlo de Falco wrote:

> BTW the same example seems to show also a bug in get_help_text:
>
> ------------------------------------------------------
> >> 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
>
> >>  [text, format] = get_help_text (myfun)
> warning: implicit conversion from scalar to string
> text =
> format = Not found
> >>
> ------------------------------------------------------
>
> c.

Sorry this was just my mistake (I forgot the quotes):

----------------------
 >>  [text, format] = get_help_text ("myfun")
text = MYFUN: this version of myfun is defined in an oct-file

format = plain text
 >>  [text, format] = get_help_text ("myfun")
text =  MYFUN: this version of myfun is defined in an m-file

format = plain text
 >>
----------------------

so get_help_text seems to work as expected
on the other hand:

-----------------------
 >> ls
PKG_ADD low_level_functions.cc low_level_functions.o
low_level_functions.oct myfun.m
 >> gen_doc_cache ("DOC_CACHE", canonicalize_file_name("./"))
warning: gen_doc_cache: unusable help text in  
'low_level_functions.oct'. Ignoring function.
warning: function name `myfun' does not agree with function file name `'
warning: function name `myfun' does not agree with function file name `'
 >>
-----------------------

the reason I am looking at this is that I get plenty of similar errors  
if I try to install
the nurbs package on 3.1.55

also this might be some mistake on my side somwhere rather than a bug,  
but I can't see where...


c.


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

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


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 20-May-2009, Carlo de Falco wrote:

| BTW the same example seems to show also a bug in get_help_text:
|
| ------------------------------------------------------
|  >> 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
|
|  >>  [text, format] = get_help_text (myfun)
| warning: implicit conversion from scalar to string
| text =
| format = Not found
|  >>

I don't think this is a bug.  You haven't passed a function name to
get_help_text.  Instead, you are passing the result of calling myfun
to get_help_text.  So it is as if you did

  get_help_text (0)

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

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.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

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

>
> I don't think this is a bug.  You haven't passed a function name to
> get_help_text.  Instead, you are passing the result of calling myfun
> to get_help_text.  So it is as if you did
>
>  get_help_text (0)
>
> jwe

Yes, I noticed this myself, sorry for the noise.
Anyway there still is something going on that I don't understand which  
I described here:

http://www.nabble.com/Re%3A-problems-with-%22aoutoload%22-in-3.1.55-p23642184.html

Any clue about what could be going wrong?
Thanks,
Carlo
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 22-May-2009, Carlo de Falco wrote:

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

Create a single .oct file for each function you wish to define instead
of autoloading them from a single .oct file?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

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

> On 22-May-2009, Carlo de Falco wrote:
>
> | 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?
>
> Create a single .oct file for each function you wish to define instead
> of autoloading them from a single .oct file?

Yes, that's what I am usually doing. But in this case the functions in  
the .oct file depend on each other,
so I had to put them in the same file to avoid using to many calls to  
feval...

> jwe
c.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Carlo de Falco-2]

On 25 May 2009, at 07:49, Jaroslav Hajek wrote:

> On Fri, May 22, 2009 at 10:11 PM, Carlo de Falco
> <carlo.defalco@...> wrote:
>>
>> On 22 May 2009, at 22:08, John W. Eaton wrote:
>>
>>> On 22-May-2009, Carlo de Falco wrote:
>>>
>>> | 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?
>>>
>>> Create a single .oct file for each function you wish to define  
>>> instead
>>> of autoloading them from a single .oct file?
>>
>> Yes, that's what I am usually doing. But in this case the functions  
>> in
>> the .oct file depend on each other,
>> so I had to put them in the same file to avoid using to many calls to
>> feval...
>>
>>> jwe
>> c.
>
> In that case, you can create a separate source with the core
> functions, and then just wrap them in DLDs, one per .oct file (linked
> with the "common" file).
> mkoctfile -c common.cc
> mkoctfile func1.cc common.o
> mkoctfile func2.cc common.o
> etc.
>
> That's called "software engineering" (nah, I'm kidding, it's called "a
> trick to make stuff work").
>
> regards
>

Jaroslav,
Thanks that's a cool idea!
I was actually thinking of creating a shared library with the core  
functions and link to it
but I didn't know how to do it in a portable way. Static linking is  
much simpler.
Thanks,
Carlo


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 25-May-2009, Jaroslav Hajek wrote:

| In that case, you can create a separate source with the core
| functions, and then just wrap them in DLDs, one per .oct file (linked
| with the "common" file).
| mkoctfile -c common.cc
| mkoctfile func1.cc common.o
| mkoctfile func2.cc common.o
| etc.

I think this will work OK if the functions don't share any global
data.  If they do, then you will probably need to use a shared library
for the common parts, or use some other method to ensure that there is
only one instance of the shared global data.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On 20-May-2009, Carlo de Falco wrote:

| On 20 May 2009, at 21:16, Carlo de Falco wrote:
|
| > BTW the same example seems to show also a bug in get_help_text:
| >
| > ------------------------------------------------------
| > >> 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
| >
| > >>  [text, format] = get_help_text (myfun)
| > warning: implicit conversion from scalar to string
| > text =
| > format = Not found
| > >>
| > ------------------------------------------------------
| >
| > c.
|
| Sorry this was just my mistake (I forgot the quotes):
|
| ----------------------
|  >>  [text, format] = get_help_text ("myfun")
| text = MYFUN: this version of myfun is defined in an oct-file
|
| format = plain text
|  >>  [text, format] = get_help_text ("myfun")
| text =  MYFUN: this version of myfun is defined in an m-file
|
| format = plain text
|  >>
| ----------------------
|
| so get_help_text seems to work as expected
| on the other hand:
|
| -----------------------
|  >> ls
| PKG_ADD low_level_functions.cc low_level_functions.o
| low_level_functions.oct myfun.m
|  >> gen_doc_cache ("DOC_CACHE", canonicalize_file_name("./"))
| warning: gen_doc_cache: unusable help text in  
| 'low_level_functions.oct'. Ignoring function.
| warning: function name `myfun' does not agree with function file name `'
| warning: function name `myfun' does not agree with function file name `'
|  >>
| -----------------------
|
| the reason I am looking at this is that I get plenty of similar errors  
| if I try to install
| the nurbs package on 3.1.55
|
| also this might be some mistake on my side somwhere rather than a bug,  
| but I can't see where...

What does

  help low_level_functions

display?  Where is myfun defined?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Søren Hauberg]

tir, 26 05 2009 kl. 13:56 -0400, skrev John W. Eaton:

> | the reason I am looking at this is that I get plenty of similar errors  
> | if I try to install
> | the nurbs package on 3.1.55
> |
> | also this might be some mistake on my side somwhere rather than a bug,  
> | but I can't see where...
>
> What does
>
>   help low_level_functions
>
> display?  Where is myfun defined?

These warnings are due to the problem in '__list_functions__' we talked
about earlier today. If '__list_functions__' get fixed, this should just
go away.

Søren

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave