bugGNU Octave - Bugs: bug #61842, New "too many inputs"...

 
 

bug #61842: New "too many inputs" error message wrong with anonymous functions

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Mon 17 Jan 2022 03:52:55 PM UTC
 
Category:  Interpreter Severity:  1 - Wish
Priority:  3 - Low Item Group:  Inaccurate Result
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sun 13 Feb 2022 10:04:49 AM UTC, comment #13: 

Imho, the remaining wish of including the location where an anonymous function was created in the error message shouldn't block Octave 7.

Setting release to "dev" and lowering priority.

Markus Mützel <mmuetzel>
Project Member
Tue 18 Jan 2022 04:50:25 PM UTC, comment #12: 

@jwe: It was just a minor wish to get the anonymous function name, but if it is too difficult then we can skip it.  Giving the location where the anonymous function is defined would be enough. 

I think we should try and keep the printed message to be nearly the same as for a regular function.  For the text I would propose something like

error: called from
  @<anonymous function> defined in FUNCTION_NAME at line L column C

FUNCTION_NAME would be the current reporting structure which is the name of the m-file without the ".m" extension or the notation using '>' for subfunctions.  I would use the line and column of the '@' character as you suggest.

Sample file in tst_err_reporting.m

function tst_err_reporting (do_anon = true)
  disp ("Entered function 'tst_err_reporting'");

  subfunction1 (do_anon);

endfunction

function subfunction1 (do_anon)
  disp ("Entered function 'tst_err_reporting>subfunction1'");

  fanon = @(x) x + 1;

  if (do_anon)
    fanon (1, 2);   # Will cause a parse error
  else
    error ("calling error() function from 'subfunction1'");
  endif

endfunction

This can be called with input parameter true or false to see the  different report mechanisms.

octave:1> tst_err_reporting (false)
error: calling error() function from 'subfunction1'
error: called from
    tst_err_reporting>subfunction1 at line 16 column 5
    tst_err_reporting at line 4 column 3
Entered function 'tst_err_reporting'
Entered function 'tst_err_reporting>subfunction1'
octave:2> tst_err_reporting (true)
error: @<anonymous>: function called with too many inputs
error: called from
    subfunction1>@<anonymous>
    tst_err_reporting>subfunction1 at line 14 column 5
    tst_err_reporting at line 4 column 3
Entered function 'tst_err_reporting'
Entered function 'tst_err_reporting>subfunction1'

Currently the callstack from error() correctly identifies the file and function "tst_err_reporting>subfunction1" but the report from an error in an anonymous function leaves off the main function name "subfunction1>@<anonymous>" making it slightly harder to find the source of the problem.

My proposal would be something like

    tst_err_reporting>subfunction1>@<anonymous> at line 11 column 11

In my ideal world we could swap out "anonymous" for the name of the variable so it would read "@<fanon>" in this example.  But, that's gravy.

(file #52677)

Rik <rik5>
Project Administrator
Tue 18 Jan 2022 07:45:35 AM UTC, comment #11: 

Will that also be working if an anonymous function handle is loaded from a file? Would that be referencing the location where the file was loaded?

Markus Mützel <mmuetzel>
Project Member
Tue 18 Jan 2022 04:22:54 AM UTC, comment #10: 

Rik, I think it should not be too difficult to modify the stack trace to look something like

error: calling error () from anonymous function
error: called from
  @<anonymous function defined at line 2 column 9 of /foo/bar/tst_line_num.m> at line L column C
  tst_line_num at line 5 column 5

It might be difficult to get the name of the variable (in this case, fanon) that contains the anonymous function.

Should the line and column info for the anonymous function be the line and column of the file the anonymous function is defined in or relative to the beginning of the anonymous function itself (location of the @ character)?

John W. Eaton <jwe>
Project Administrator
Tue 18 Jan 2022 12:02:02 AM UTC, comment #9: 

@jwe: There is enough information to figure out where the error is.  I just thought it would be helpful to programmers to list the name of the anonymous function in the same way we list the name of the function (if it is in an m-file) that generated the error.

Below is a test script (also attached)

# Line 1
fanon = @() error ("calling error() from anonymous function");

# Line 5 next, error should be in column 5
#    fanon ();

# Line 8 next, error should be in column 3
  fanon (1);

When run with line 5 uncommented the output is

error: calling error() from anonymous function
error: called from
    @<anonymous> at line 2 column 13
    tst_line_num at line 5 column 5

Note that the call stack references both where the function was called (line 5, column 5) and also where the actual error was thrown (line 2, column 13).

When I comment out line 5 and let line 8 generate the error from the parser I get

error: : function called with too many inputs
error: called from
    @<anonymous>
    tst_line_num at line 8 column 3

I still have the function invocation information, but not where the anonymous function was defined.  The extra information would be helpful if it is available.

(file #52675)

Rik <rik5>
Project Administrator
Mon 17 Jan 2022 07:29:14 PM UTC, comment #8: 

It's not clear to me that the information about the name of the variable that stores the anonymous function is available at the point where the error message is generated.  Does the stack trace location not provide enough information?  Maybe what we need is for the error message to provide the stack trace info to provide the location where the anonymous function is called and to have the name of the anonymous function that is shown in the error message include the location where the anonymous function is defined?

John W. Eaton <jwe>
Project Administrator
Mon 17 Jan 2022 07:23:50 PM UTC, comment #7: 

It seems to me that it would be better to ensure that the function name is always correctly set instead of having to check that the name is not empty everywhere octave_function::name() is used.

John W. Eaton <jwe>
Project Administrator
Mon 17 Jan 2022 06:57:59 PM UTC, comment #6: 

Thanks Markus, the message is now correct.

@Rik: Would you like to open another feature request to show the variable name rather than a generic @<anonymous>?

Pantxo Diribarne <pantxo>
Project Member
Mon 17 Jan 2022 06:34:25 PM UTC, comment #5: 

I pushed the patch here:
http://hg.savannah.gnu.org/hgweb/octave/rev/a3a52d968f71

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 05:25:42 PM UTC, comment #4: 

@Markus: Yes, that would be consistent.

Pantxo Diribarne <pantxo>
Project Member
Mon 17 Jan 2022 05:23:41 PM UTC, comment #3: 

Just for reference, here is what Octave does when error() is used (rather than an error detected by parser)

myfunc = @() error ("abc")
myfunc =

@() error ("abc")

octave:2> myfunc()
error: abc
error: called from
    @<anonymous> at line 1 column 14

So at least in terms of debugging functions like `dbstack` Octave uses "@<anonymous>" to refer to an anonymous function.  Hence, I think the patch in comment #2 is probably good.

As an improvement in the future, it might be nice if Octave could return the name of the variable that holds the anonymous function because that will be more useful to the programmer if, for example, they have defined 10 different anonymous functions and need to determine which one is at fault.  But, this could be made a wishlist item.

Rik <rik5>
Project Administrator
Mon 17 Jan 2022 04:56:29 PM UTC, comment #2: 

If the assumption from comment #2 is good enough, we could use something like the attached patch.

With it, I get:

>> toto = @() 1+1;

>> toto (1)

error: @<anonymous>: function called with too many inputs
error: called from
    @<anonymous>
>>

(file #52674)

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 04:13:56 PM UTC, comment #1: 

IIUC, that error is emitted here:
http://hg.savannah.gnu.org/hgweb/octave/file/b20da6bed444/libinterp/parse-tree/pt-eval.cc#l3421

I guess `name` is an empty string for anonymous functions.

Is it only an empty string if `user_function` is an anonymous functions? I.e., would it be save to replace that by some other string (e.g., "anonymous function") if `name` is empty?

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 03:52:55 PM UTC, original submission:  

There are duplicate characters ": " in the error message if emitted for an anonymous functions, e.g.:

octave:1> toto = @() 1+1;
octave:2> toto (1)
error: : function called with too many inputs
error: called from
    @<anonymous>

Pantxo Diribarne <pantxo>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52677:  tst_err_reporting.m added by rik5 (404B - text/x-matlab)
file #52675:  tst_line_num.m added by rik5 (189B - text/x-matlab)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by pantxo (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 project members can vote.

     

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-13 mmuetzel Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Release7.0.90 dev
    2022-01-18 rik5 Attached File- Added tst_err_reporting.m, #52677
    2022-01-18 mmuetzel StatusFixed In Progress
    2022-01-18 rik5 Attached File- Added tst_line_num.m, #52675
    2022-01-17 pantxo StatusReady For Test Fixed
    2022-01-17 mmuetzel StatusConfirmed Ready For Test
    2022-01-17 mmuetzel Attached File- Added bug61842-too-many-args-anonymous.patch, #52674
    2022-01-17 mmuetzel StatusNone Confirmed

    Back to the top


    Powered by Savane 3.9