On 8-Apr-2009, John Swensen wrote:
| A while back I submitted a patch to Octave for the bp_table class.
| This class provided a class with static message to easily add,
remove,
| and retrieve breakpoints. However, as I have recently been working
| with including breakpoint capabilities into the OctaveDE editor, I
| realize the bp_table interface to Octave breakpoint is seriously
| flawed. I will give a few examples, then describe what I think the
| problem is and ask for suggestions on how to fix it. I can work on
| patches, but am not sure exactly where all the problems are.
|
| Example 1:
| 1) Set a breakpoint
| 2) Call 'clear all'
| 3) Call 'dbstatus'
|
| Example 2:
| 1) Set a breakpoint in a file in the current directory
| 2) Change directories (e.g. 'cd ..')
| 3) Call 'dbstatus'
|
| There may be many more things that cause this problem. In
particular,
| I think the problem occurs when breakpoints are changed in the
actual
| symbol table, but aren't updated in the bp_table representation of
| breakpoints. One solution for this is to have the bp_table class
run
| through the entire symbol table looking for breakpoints when
dbstatus
| is called, rather than storing pointers to and out-of-date symbol
| table. Another option would be to have events like saving a file,
| clearing all, changing directories, etc call back to the bp_table
with
| updates. Or, is it as simple as looking at the results of the
| out_of_date_check in do_get_breakpoint_list and removing items from
| the bp_map based on these results. Maybe someone else has a
| suggestion on what the problem really is and the best way to solve
it.
When functions are cleared, they should also remove information about
themselves from the breakpoint map. Since we can have overloaded
function names, we probably need to fix the map so that it uses a full
file name for the function instead of a simple function name.
Maybe the solution for handling directory changes and files found in
the current directory is to update the list of functions with
breakpoints so that it only contains those that are currently
visible. Or, when listing breakpoints, make sure that each function
in the breakpoint table is currently visible in the path before
reporting information about it. Storing the full name of the file in
the table instead of just the function name might help with either of
these approaches. Either way, I think that calling out_of_date_check
in in bp_table::do_get_breakpoint_list is probably not the right thing
to do.
jwe