bugGNU Octave - Bugs: bug #54801, Errors in command-line functions...

 
 

bug #54801: Errors in command-line functions defined in scripts do not create a valid link to the source code in the command window

Submitter:  Lars Kindermann <larskindermann>
Submitted:  Sun 07 Oct 2018 01:47:55 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 13 Jan 2022 08:31:49 AM UTC, comment #16: 

Regardless of formally referring to an inline function or command-line function:

The command windows prints the correct location of the error in the code and provides a hyperlink that is supposed to jump there in the editor - but it does not, but shows an error box instead.

As the location is obviously known and printed correctly, it should be possible and straightforward to also format the link to point to the editor position.

This would make debugging much easier.

Lars Kindermann <larskindermann>
Sun 03 Mar 2019 08:58:52 PM UTC, comment #15: 

I used this script (script_fcn.m) to ask Octave what it thinks the function is


1;  % make this a script

function whatami ()
end

which whatami


When I run it I get


script_fcn
'whatami' is a command-line function


I changed the summary to refer to command-line functions in scripts not creating a valid link to the source.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 07:39:01 PM UTC, comment #14: 

Octave does not yet implement the feature of local functions in scripts at all as Matlab describes them.

If you have a script foo.m that defines a function bar, it is not a script local function in the Matlab sense. I am pretty sure the following would work in Matlab, but does not work yet in Octave


disp('This is script foo.m')
disp('Now calling bar()')
bar()

function bar()
  disp('This is function bar()')
end


At the moment, functions defined in script files are exactly the same as inline functions. After running the script, all functions defined in the script file are available in the global workspace to be called as if they were normal inline functions pasted at the command line.

If you think Octave should also support script local functions as defined by Matlab, that is a separate discussion, and I think it may have been discussed somewhere before.

Mike Miller <mtmiller>
Group Member
Sun 03 Mar 2019 06:42:45 PM UTC, comment #13: 

A function defined within a script is called a local function according to Matlab naming conventions and is totally legal. It is explained as the equivalent to what is typically called a subfunction in other languages:

https://www.mathworks.com/help/matlab/matlab_prog/local-functions-in-scripts.html

An inline function is something very different:

http://octave.org/doc/interpreter/Inline-Functions.html

So the error message is still missleading.

Lars Kindermann <larskindermann>
Sun 03 Mar 2019 03:19:19 PM UTC, comment #12: 

I agree with Torsten that a function defined in a script is necessarily an inline function, rather than a subfunction which has the specific meaning of being the second, third, fourth, etc. function defined in a function file.

I have marked the bug as confirmed and changed the Summary to be more specific about the issue.  I also lowered the priority.  It would be nice to give a line number, even for a script, to help with debugging, but this feels like an uncommon occurrence.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 09:57:07 AM UTC, comment #11: 

But in this case, "foo" really is an inline function, isn't it?

Torsten Lilge <ttl>
Group Member
Sun 03 Mar 2019 09:41:23 AM UTC, comment #10: 

Bug is still present.
While the fix solved it for a function foobar.m:


function foobar
 disp "click the error messages below:"
 function foo
  xyz
 end
 foo
end


it still fails for a script foobar.m:


#function foobar
 disp "click the error messages below:"
 function foo
  xyz
 end
 foo
#end


with a message box stating


foo is a built-in, compiled or inline
function and can not be edited.


Lars Kindermann <larskindermann>
Sat 02 Mar 2019 09:14:21 PM UTC, comment #9: 

Is this still valid?  I tried the example bar.m from comment #6 from Lars.  The backtrace shows two errors, both of which are hyperlinks, and both of which--when clicked on--go to the correct line number in the file.

Rik <rik5>
Group administrator
Thu 11 Oct 2018 04:48:02 PM UTC, comment #8: 

The issue reported in comment #6 (bar>foo not found) should be fixed by changeset http://hg.savannah.gnu.org/hgweb/octave/rev/e9c24b5e8673

Torsten Lilge <ttl>
Group Member
Wed 10 Oct 2018 06:19:22 PM UTC, comment #7: 

Okay, this new error message


Can not find function bar>foo


is due to the fact that the gui does not check for this syntax (>) yet.

Torsten Lilge <ttl>
Group Member
Wed 10 Oct 2018 06:14:59 PM UTC, comment #6: 

right, my example was a script file called "bar.m" 
Maybe more intuitive, this bar.m shows a similar effect:


function bar
 function foo
  xyz
 end
 foo
end


except that the message is a bit different now:


>> bar

error: 'xyz' undefined near line 3 column 3
error: called from
    bar>foo at line 3 column 3
    bar at line 5 column 2


Now foo is recognized to sit within bar, but clicking the line


    bar>foo at line 3 column 3


will open an "Ocatve Error" message box, now stating


Can not find function bar>foo


Obviously scripts and functions are handled differently but neither correctly.

Lars Kindermann <larskindermann>
Wed 10 Oct 2018 05:48:10 PM UTC, comment #5: 

As far as I understand, foo was declared in a script file. As a result, octave says (using exist or which) that "foo" is an inline function.

It would be helpful if the error messages contains the related file, where a function was defined. Is this information stored somewhere? I recognized that the "file" field in the return values from dbstatus is empty if there is a breakpoint set in "foo".

Torsten Lilge <ttl>
Group Member
Wed 10 Oct 2018 11:57:54 AM UTC, comment #4: 

OK, so we need to fix the error messages to be better.  What should they say?

Lars, did you post a complete example file?  So in your case, foo is defined in a script file?


error: some problem LINE COLUMN in FILE
error: called from
    foo at LINE COLUMN in FILE
    bar at LINE COLUMN in FILE


?

What do Matlab users expect to see?

John W. Eaton <jwe>
Group administrator
Wed 10 Oct 2018 05:11:16 AM UTC, comment #3: 

Yes, the unix version of the terminal has a filter functionality for detecting links in the terminal output, the windows version scans any selected text when the context menu is activated.

Torsten Lilge <ttl>
Group Member
Tue 09 Oct 2018 08:41:48 PM UTC, comment #2: 

How does the GUI get info about the failure?  Is it parsing the error message?

John W. Eaton <jwe>
Group administrator
Tue 09 Oct 2018 08:29:31 PM UTC, comment #1: 

Is there a way to get the information on the file related to the subfunction from octave? Both, "exist" and "which" (or "__which__") say it is a command-line function.

Torsten Lilge <ttl>
Group Member
Sun 07 Oct 2018 01:47:55 PM UTC, original submission:  

When the interpreter encounters an error within a subfunction foo in file bar.m


disp 'this will fail:'
 function foo
  xyz
 end
foo


the result in the command window is


>> bar

this will fail:
error: 'xyz' undefined near line 3 column 4
error: called from
    foo at line 3 column 4
    bar at line 5 column 1


While clicking the line


   bar at line 5 column 1


jumps to the correct location in the editor, clicking


   foo at line 3 column 4


pops up an error message window, titeled "Octace Editor", incorrectly stating that


foo is a built in, compiled or inline
function and cannot be edited.


In addition to create the correct link, I suggest to always include the filename to the error messages, e.g.


error: called from
    foo at line 3 column 4 in file bar.m
    bar at line 5 column 1 in file bar.m

 
This would make debuging much easier.

Lars Kindermann <larskindermann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by larskindermann (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 rik5 SummaryErrors in inline functions defined in scripts do not create a valid link to the source code in the command window Errors in command-line functions defined in scripts do not create a valid link to the source code in the command window
    2019-03-03 rik5 Priority5 - Normal 3 - Low
        StatusWorks For Me Confirmed
        SummaryErrors in subfunctions do not create a valid link to the source code in the command window Errors in inline functions defined in scripts do not create a valid link to the source code in the command window
    2019-03-02 rik5 StatusNone Works For Me
    2018-10-09 rik5 Carbon-CopyRemoved 72865 -
    2018-10-09 rik5 SummaryErros in subfunctions do not create a valid link to the source code in the command window Errors in subfunctions do not create a valid link to the source code in the command window

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code