octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59451] Function handles become invalid if pat


From: Rik
Subject: [Octave-bug-tracker] [bug #59451] Function handles become invalid if path to function is removed
Date: Thu, 12 Nov 2020 12:09:48 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36

Update of bug #59451 (project octave):

                Category:                    None => Interpreter            

    _______________________________________________________

Follow-up Comment #3:

There are certainly some subtle issues here.

Consider creating a directory my_functions.  In this directory you create a
function file ls.m which does something completely different from listing the
contents of the current directory.  You add the directory my_functions to the
PATH with addpath and then create a function handle to ls.m.  Now when you
remove my_functions from the PATH, what should happen?

Octave shouldn't silently switch the function handle to point to the default
ls.m in scripts/miscellaneous because the behavior is completely different.

If I was arguing for the principle of least surprise I think the function
handle should continue to point to the original function file which probably
means having an absolute path to the file.

For a quick test, I tried the test case above,


octave:4> functions (f)
ans =

  scalar structure containing the fields:

    function = ls
    type = simple
    file = /home/rik/wip/Projects_Mine/octave-dev/myfcn/ls.m

octave:5> rmpath myfcn
octave:6> f(1)
error: ls: all arguments must be character strings
error: called from
    ls at line 64 column 5
octave:7> functions (f)
ans =

  scalar structure containing the fields:

    function = ls
    type = simple
    file = /home/rik/wip/Projects_Mine/octave-dev/myfcn/ls.m

 

What you can see is that even though the FILE field of the function handle
points at the correct m-file, the interpreter is trying to execute the first
ls.m it finds on the path which is now in miscellaneous.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59451>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]