bugGNU Octave - Bugs: bug #57205, meaningless error reports for F9

 
 

bug #57205: meaningless error reports for F9

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Mon 11 Nov 2019 11:24:22 AM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  Torsten Lilge <ttl>
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 15 Nov 2019 11:32:39 PM UTC, comment #16: 

I think error reporting has improved very much by now and we can close this finally.

Do you plan to change the handling of pasted input to the commandline, too? As pasting code suffers from similar ugly error messages.

Lars Kindermann <larskindermann>
Fri 15 Nov 2019 07:48:17 PM UTC, comment #15: 

Cset http://hg.savannah.gnu.org/hgweb/octave/rev/cf231bc5876f fixes the issue with parse errors.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Fri 15 Nov 2019 05:37:23 PM UTC, comment #14: 

The old way od executing selected code was line by line which was very slow and ignored a keyboard command (i.e. lines following keyboard were still executed). The new methods uses tmp script files and allows the use of keyboard for interrupting the program flow. I think this is not possible when just copying  the lines into the command window.

Right now I am working on a cset for improving the error message for cases you have mentioned in comment #12.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Fri 15 Nov 2019 05:20:15 PM UTC, comment #13: 

same code pasted into command window gives more info:

>> 1
ans = 1
>> if 2
3
4x
error: parse error:

  syntax error

>>> 4x
     ^
>> 5
ans = 5
>> end
error: parse error:

  syntax error

>>> end
      ^
>> 7
ans = 7
>>

Actually, I was not aware till now, that copy/paste and F9 behave differently. For years I was using both alternately, depending on the system I'm on. On Linux with a 3-Button mouse, the most convenient way is to mark some code, move the mouse over the command window and press the middle button to paste the selection. On Windows, F9 needs less keystrokes. I wonder why there are two different methods to handle both cases?

Lars Kindermann <larskindermann>
Fri 15 Nov 2019 03:44:22 PM UTC, comment #12: 

just a minor change in the example, executed with F9

1
if 2
3
4x
5
end
7

and you get no hint at all, what and where the problem might be:

error: parse error near line 1, column 1
>>

Lars Kindermann <larskindermann>
Fri 15 Nov 2019 02:28:55 PM UTC, comment #11: 

Lars, I do not see an improvement when citing the line that caused the error since in contrast to copying the code, the error message directly follows the related line when using F9.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Fri 15 Nov 2019 08:37:31 AM UTC, comment #10: 

ups, the last line should read just "7"...

Lars Kindermann <larskindermann>
Fri 15 Nov 2019 08:31:50 AM UTC, comment #9: 

After playing around with errors I would strongly opt for dropping line numbers from all error mesages ocurring in direct command line input, eiher typed, pasted or executed by F9. In my opinion they are useless for interactive work. Mostly they show line '1 column 1' only and are even misleading in other cases.
See bug #57239 "errors in multiline constructs"   

For F9 it might be helpful to cite the line verbatim which caused the error, something like
error: 'xyz' undefined in command 'x = xyz + 1' 

To demonstrate current behaviour, copy this script to the editor

1
if 2
3
x4
5
end
7paste

and run it (F5)

>> aaa

ans = 1
ans = 3
error: 'x4' undefined near line 4, column 4
error: called from
    aaa at line 4 column 2
>>

mark it and execut it (F9)

>> 1
ans = 1
>> if 2
>>  3
ans = 3
>>  x4
error: 'x4' undefined near line 1, column 1
>>

and copy/paste it into the command window

>> 1
ans = 1
>> if 2

3

x4

5

end
ans = 3
error: 'x4' undefined near line 9, column 9
>> 7
ans = 7
>>

Lars Kindermann <larskindermann>
Thu 14 Nov 2019 11:19:40 PM UTC, comment #8: 

I think this should be discussed with a broader audience in the maintainers list because error reporting should be as clear as possible and also somehow consistent between

- typing into command window
- pasting text into command window via clipboard
- executing selected text with F9

How to handle single line commands vs. multi line constructs?
There is some discrepancy at the moment.

Just found a real bug with this, will open a new bug report about incorrect line numbers...  

Lars Kindermann <larskindermann>
Thu 14 Nov 2019 09:36:19 PM UTC, comment #7: 

@Torsten: I think it is fine to drop the inaccurate line and column reporting.

Rik <rik5>
Project Administrator
Thu 14 Nov 2019 08:30:57 PM UTC, comment #6: 

So, if we agree that "line 1, column 1" is an issue in Octave I will drop that (actually not add it) to error messages that show up during execution of selected text with F9.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Thu 14 Nov 2019 07:30:04 PM UTC, comment #5: 

I think it is an issue that Octave reports misleading information about the error being in "line 1 column 1" when it is not.

Many Octave users are not professional programmers (i.e., they are scientists and engineers) and will assume that Octave is correct when it reports the location of an error.  This may waste a lot of their time and give them an unfavorable impression of Octave.

Either Octave should accurately report where the problem is (best choice), or it should not report the location at all.

Could someone file a different bug report about that, or bring this issue up on the Octave Maintainer's list?

Rik <rik5>
Project Administrator
Thu 14 Nov 2019 08:25:47 AM UTC, comment #4: 

I agree, the bug is fixed, "line 1 column 1" is the typical Octave behaviour.

It's just a matter of style and should rather be discussed somewhere else.   

Lars Kindermann <larskindermann>
Thu 14 Nov 2019 06:06:13 AM UTC, comment #3: 

The location "near lin 1, column 1" is common for commands executed in the terminal. When copying a block of code into the terminal, an error in any line of this block is also reproted as "line 1, column 1". So I think the behavior when using F9 is in line with the expected behavior.

However, it is no problem to drop the location is this is desired.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Wed 13 Nov 2019 10:34:37 PM UTC, comment #2: 

Ok, error message is back to old behaviour.

However, if you mark and execute (F9) several lines of code
with an error located at any position, the message always reads

error: 'xyz' undefined near line 1, column 1

So, "near line 1, column 1" is pretty much useless, too. 
Maybe that should be cut off for a more "aesthetic" behaviour.

Just being curious, what does Matlab say in this case?   

Lars Kindermann <larskindermann>
Wed 13 Nov 2019 06:35:33 PM UTC, comment #1: 

I pushed changeset http://hg.savannah.gnu.org/hgweb/octave/rev/becd6267d6d1
preventing the tmp file name in error messages and breakpoint locations if keyboard is used within the selected code.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Mon 11 Nov 2019 11:24:22 AM UTC, original submission:  

executing some garbage with F9

asdfg

results in

>> asdfg
error: 'asdfg' undefined near line 4, column 4
error: called from
    octave_j23498 at line 4 column 1
>>

Both the temporary scipt name and the line numbers are irrelevant for the user, even misleading, and should better be omitted.

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 (Updated the item)
  • -email is unavailable- added by ttl (Updated the item)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by larskindermann (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-14 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-11-13 ttl StatusConfirmed => Ready For Test
    2019-11-12 ttl Assigned toNone => ttl
    2019-11-12 siko1056 StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5