bugGNU Octave - Bugs: bug #57902, Confusing debug output from...

 
 

bug #57902: Confusing debug output from commands executed with "Run Selection"

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Wed 26 Feb 2020 03:16:28 PM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 06 Dec 2020 06:39:51 PM UTC, comment #16: 

These days I don't see this behavior anymore.
Maybe it is related to, or the same as, bug #57634 that got fixed a while ago.

Closing report.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 14 Apr 2020 04:58:28 PM UTC, comment #15: 

I find that his almost surely happens when there's a continuation line in the selected code (i.e., a line ending on "...")

Philip Nienhuis <philipnienhuis>
Group Member
Fri 10 Apr 2020 12:20:58 PM UTC, comment #14: 

Sometimes I also see this on my home PC; but it remains quite elusive.

What I see there is that when executing commands through F9, the, or some, output from previous commands also issued through F9 is appended to the output from code currently selected & run with F9. Sometimes Octave issues warnings or errors, sometimes not.
It appears that it happens more often when an EOL is included in the code (that is, I select code incl. newline at the end). OTOH larger blocks of e.g., a for loop execute w/o issue.

As it seems to be a line of investigation in bug #57635, I'll try downgrading to Qscintilla < 2.11.4.

BTW why is this a "Wish"/"Feature Request" rather than a bug report? makes little sense to me.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 29 Feb 2020 07:47:24 AM UTC, comment #13: 

As mentioned earlier, the current implementation for executing selected code results in a behavior as if the selection was copied into the console window. keyboard works, but stepping through the code is not really meaningful.

If instead (or optional) the selected code  should be executed like a script, i.e., no echoing of the commands and no entries in the history, this would also be possible.

Torsten Lilge <ttl>
Group Member
Fri 28 Feb 2020 09:47:21 PM UTC, comment #12: 

"Print debug location in Command Window in addition to the marker in the editor"  has no influence on "dbsteps" entered in the console. This preference is used when calling dbstep etc. via the gui.

Isn't the only way to prevent the location printed by entering _db_next_breakpoint_quiet_ before each dbstep?

Torsten Lilge <ttl>
Group Member
Fri 28 Feb 2020 11:26:14 AM UTC, comment #11: 

@Mike, comment #9:
Good guess! but I checked and it is the other option that is selected ("Set focus to Command window ..."); which I usually have checked.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 27 Feb 2020 07:49:23 PM UTC, comment #10: 

Good point, but the setting about the debug location should not matter since printing the debug location is disabled by the tmp file. I'll check that.

Torsten Lilge <ttl>
Group Member
Thu 27 Feb 2020 08:18:41 AM UTC, comment #9: 

There is a setting in Preferences / Command called "Print debug location in Command Window in addition to the marker in the editor", that is disabled by default. I guess that you have that enabled on the computer where you see the name of the scratch file and not on the other. If so, that's not a bug in itself, but check to see if changing that setting has any effect on other behavior you are seeing, such as the crashing.

Mike Miller <mtmiller>
Group Member
Wed 26 Feb 2020 09:50:48 PM UTC, comment #8: 

Just to be complete, on my work PC I hit this bug, but on my home PC it works as it's apparently supposed to work (until Octave crashes, that is).
The first times after starting Octave, when running the script from the command line dbstep seemed to work fine. The crashes came after later starts of Octave. Maybe they are related to old incompatible qtsettings files or something else that is special on my box. I sometimes suspect the Variable Editor (whose contents are renewed at every dbstep) might be unstable.

Well, living on the bleeding edge (Octave 7) does have some consequences, isn't it :-)

FWIW, I noted in bug #57634 that I saw the name of the scratch file when pressing F9 to execute selected code, but TTBOMK that also only happened on my PC at work.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Feb 2020 09:47:19 PM UTC, comment #7: 

Personally I expect an execution in top-level workspace and think that Matlab also behaves like this, but I am not sure about this. 

@Mike: sorry for messing up your changes to severity etc., our comments were overlapping.

Torsten Lilge <ttl>
Group Member
Wed 26 Feb 2020 08:11:24 PM UTC, comment #6: 

Maybe we need something like "run selection in top-level workspace" and also "run selection in temporary detached workspace"?

John W. Eaton <jwe>
Group administrator
Wed 26 Feb 2020 08:07:32 PM UTC, comment #5: 

When using the run selection feature of the GUI, in what context are the selected lines supposed to run?  To be predictable, I'm assuming they should be run in some kind of dummy context where no other variables are defined.  That doesn't seem to be what is happening now.  If I create a variable in the top-level workspace at the command line (say, x = 13) then in the editor run a selection that contains "x", I'll get the value of the variable from the top-level workspace.  Is that what Matlab users expect?

John W. Eaton <jwe>
Group administrator
Wed 26 Feb 2020 07:59:57 PM UTC, comment #4: 

The use of temp. files for code that is invoked by F9 was introduced in order to make keyboard () usable in such code. Using dbstep steps through the tmp file, which contains some other stuff around the code to be executed in order to display and save the code lines in the history. That is what you are seeing.

IMHO, executing code by F9 is something comparable to entering this code into the console window by hand and not comparable to really executing a script (with possible breakpoints etc.). Is it a required feature to step through code lines executed by F9? If yes, then we definitely need another approach, that I currently to not see.

Torsten Lilge <ttl>
Group Member
Wed 26 Feb 2020 07:58:18 PM UTC, comment #3: 

To fix bug #42705, the Run Selection feature was changed to write the selection to temporary files and run those files. So yeah, if a breakpoint is hit, the user is going to see those temporary files and be stepping through artificially injected command lines.

If that's not desirable, if a goal is to be able to break and cleanly step through commands in the selection and not make it look like it does now, then maybe we need a new feature in the interpreter to support executing a sequence of commands with the ability to break and without adding them to the command history or making them look like they were pasted at the command prompt.

Mike Miller <mtmiller>
Group Member
Wed 26 Feb 2020 07:00:17 PM UTC, comment #2: 

Sorry for not mentioning right away:

Selecting the code and pressing F9.
That is how I hit this on my work desktop (Windows 7 Enterprise).

On my home desktop (Windows 7 Professional) the very same crossbuild works differently.
Running the script/code (from the command line or selecting the code and then pressing F9) catches the "keyboard" statement. From then on, the first dbstep seems to do nothing; the second dbstep makes Octave crash.
I can quite reliably reproduce this. But sometimes it goes through and after using several "dbstep"s execution proceeds.

Note:
This is with your cset 262cdfc6faf9 (comment #7 in bug #57439) backed out because with it I found Octave much too slow to be useful.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Feb 2020 05:14:07 PM UTC, comment #1: 

How are you running the script such that there is a temporary file created?

What happens if you just save the script and execute it normally from the command line using the name of the script file?  Does it work properly then?

John W. Eaton <jwe>
Group administrator
Wed 26 Feb 2020 03:16:28 PM UTC, original submission:  

When using a "keyboard" statement in scripts the output that follows on screen is hard to grasp and at times confusing.

I have script calling a function called "cleanup_ints" (both are in the path) and there's a "keyboard" statement at L. 14 of the script.
When that keyboard statement is hit I get the following output:

>> keyboard> dbstep
stopped in octave_uEiJOH at line 37 [C:\Users\Nienhu01\AppData\Local\Temp\octave\octave_uEiJOH.m]

37: __db_next_breakpoint_quiet__(false);
debug> dbstep
stopped in octave_uEiJOH at line 39 [C:\Users\Nienhu01\AppData\Local\Temp\octave\octave_uEiJOH.m]

39: octave_onhdtq (12, 'endif', 'endif');
debug> dbstep
stopped in octave_uEiJOH at line 42 [C:\Users\Nienhu01\AppData\Local\Temp\octave\octave_uEiJOH.m]

42: octave_onhdtq (13, '  [ints, vals] = cleanup_ints (ints, vals);', '  [ints, vals] = cleanup_in
ts (ints, vals);');
debug> dbstep
stopped in octave_uEiJOH at line 43 [C:\Users\Nienhu01\AppData\Local\Temp\octave\octave_uEiJOH.m]

43:   [ints, vals] = cleanup_ints (ints, vals);
debug> dbstep
stopped in cleanup_ints at line 46 [<some network drive>\...\cleanup_ints.m]


The confusion starts when the debug output mentions L.37 while the actual "keyboard" statement that triggers it is in L.14 of the script.
Also confusing is that Octave echoes the name of the temp scratch script (made by the interpreter I suppose) which is of little help for users.
Subsequent "dbstep" statements give additional confusing output, until execution finally lands in the called function "cleanup_ints.m".

The point I want to make here is that a lot of info is echoed to the screen that is of no immediate use to users, if not confusing because line numbers don't match what the user sees in the editor.

Philip Nienhuis <philipnienhuis>
Group Member

 

(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 ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-06 philipnienhuis StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2020-02-26 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupOther Feature Request
        StatusNone Confirmed
        SummaryConfusing debug output from scripts Confusing debug output from commands executed with "Run Selection"
    2020-02-26 ttl Severity1 - Wish 3 - Normal
        Priority3 - Low 5 - Normal
        Item GroupFeature Request Other
        StatusConfirmed None
        SummaryConfusing debug output from commands executed with &quot;Run Selection&quot; Confusing debug output from scripts
    2020-02-26 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupOther Feature Request
        StatusNone Confirmed
        SummaryConfusing debug output from scripts Confusing debug output from commands executed with "Run Selection"

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code