bugGNU Octave - Bugs: bug #42708, Breakpoints should be removed from...


bug #42708: Breakpoints should be removed from files when changes are saved

Submitter:  Richard <crobar>
Submitted:  Tue 08 Jul 2014 02:29:35 PM UTC
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Sat 30 Jan 2016 10:50:26 PM UTC, comment #3: 

Yes, closing the bug report

Torsten Lilge <ttl>
Project Member
Sat 30 Jan 2016 07:37:54 AM UTC, comment #2: 

I think this works since Dan's patch was applied in
(after a few rounds of tweaking).

Can this bug be closed now?

Lachlan Andrew <lachlan>
Thu 05 Feb 2015 10:34:40 PM UTC, comment #1: 

Breakpoint management needs a better arrangement before it can become robust:


There are a couple aspects of it.  One is a more versatile means of communicating between GUI and core.  A second is a means to make the breakpoint more object-like with reference to the core's breakpoint and that of the editor (a level of indirection, if you will) so that breakpoints can move appropriately in the editor when the user modifies the file.

Dan Sebald <sebald>
Tue 08 Jul 2014 02:29:35 PM UTC, original submission:  

Breakpoints should probably be cleares (or greyed out, or otherwise modified) in the GUI editor when a file with a break points present already is edited and saved to avoid the following behaviour:

Take a function like below:

function parse_breakpoint_test ()
    x = 1;
    x = x + 1;

1. run in terminal, to make sure function is loaded by octave

2. put breakpoint on line 2 (x = 1)

3. edit  parse_breakpoint_test () and create a parse error, e.g. modify  x = x + 1;  to be  x = x + ; and save the file

4. run the function again (debugger will stop at line 2, either continue, getting the parse error or quit)

You will now be unable to deselect the break point symbol you created in step 1 which remains showing in the editor. Even after you save the file with the parse error fixed. This persists even if you run the file again, and you can place working break points as normal on the other lines which work.

You cannot now place a break point on this original break point line via the editor. You can still place one using dbstop however, and clicking on the break point in the editor still removes the brek point (although the symbol stays there, and you still can't add it back in again via the editor).

The only way you can 'reset' the editor behaviour I have found so far is to close the file and reopen it.

Richard <crobar>


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

Attach Files:

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 lachlan (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by crobar (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-01-30 ttl StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.9