[Octave-bug-tracker] [bug #47675] Breakpoint conditions get corrupted when edited in the GUI

[Dan Sebald]

Follow-up Comment #6, bug #47675 (project octave):

Rik, I'm assuming you mean that the breakpoints are lost internally even
though the GUI is showing markers in the editor.  

My guess would be that the issue stems from the fact that internally, if I
recall correctly, breakpoints are all cleared for a file whenever there is a
change in the file date, i.e., a save is done in the GUI.  It was years ago
that I looked at the breakpoint code, and I think I added a marker object that
can keep track of its original line number and edited line number so that
breakpoints could be reinstated after a save.  I believe this is the code this
patch targets with some new feature "condition" that I can't recall.

Anyway, I've not looked closely at the code, but what you are seeing could be
a timing issue.  The GUI currently sets/clears breakpoints using the special
callback routines, last I remember.  And I don't recall there being any type
of MUTEX or timing control across threads.  So maybe what you are seeing is a
situation in which the GUI saves the file and updates the breakpoints before
the core (in a different thread) notices the file change.  Maybe the GUI needs
to save the file, somehow force an update to dbstatus so that the core
realizes the file has been changed, and then update the breakpoints.  (How to
get the core to do something in proper sequence?  I proposed/programmed a
background queue some time ago.)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47675>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/