Re: Breakpoint bug [was Re: Breakpoint woes]

[John W. Eaton]

On 14-Apr-2009, John Swensen wrote:

| On Apr 13, 2009, at 11:33 PM, John W. Eaton wrote:
| 
| > On 13-Apr-2009, John Swensen wrote:
| >
| > | So, I think the problem I was describing above is actually a bug.   
| > The
| > | problem occurs because the bp_table class stores pointers to
| > | octave_user_code objects that can become invalid without these items
| > | being removed from the STL map in the bp_table class.  I have come  
| > up
| > | with a solution, but want input from others to know if they think it
| > | is an acceptable solution.  The included patch has my proposed  
| > solution.
| > |
| > | My next question is whether there is a way to force the symbol table
| > | to update. I have the problem that after calling octave_env::chdir  
| > the
| > | symbol table doesn't update until the next time I press enter and go
| > | to the next readline prompt.
| >
| > Do you mean the symbol table or the load path?
| >
| 
| I guess I'm not sure what I mean.  I just know that after calling  
| octave_env::chdir to move out of a directory containing a function  
| with a breakpoint, if I look through my STL map containing  
| octave_user_code pointers, the pointers are still valid and indicate  
| the breakpoint still exists until after I ht return at the Octave  
| prompt.  That is, somehow the changing of directory programmatically  
| doesn't get processed until the next time the Octave prompt is  
| advanced.  I am wondering if there is a way to do this programatically  
| as I process things in the readline idle event loop.

The octave_env::chdir function is just a simple wrapper around the
corresponding system call.  Octave's cd function updates the load
path.  See the definition of Fcd and octave_change_to_directory in the
file src/dirfns.cc.

If the cd function from the scripting language does what you want,
then why not call it with feval?  I don't think you need to complicate
things by callinng additional functions in the readline event hook
function.

| > I haven't looked at this in detail, but I think it might be better to
| > call the remove_all_breakpoints_in_file function from the
| > function/script object destructor.
| 
| Which file is this in, so I can go look at it?

The classes that represent scripts and functions are defined in
src/ov-usr-fcn.h and src/ov-usr-fcn.cc.

| > Should breakpoint information be stored directly in the list of tree
| > objects that make up the body of a function/script instead of storing
| > it in a separate table?
| 
| When I originally worked on the bp_table class, I had though about  
| doing this, but decided against it since it seemed at the time that I  
| would have to walk through every known function to get a complete list  
| of breakpoints.  I am not 100% sure exactly the relationship between  
| the symbol table and the tree walker.  I am willing to do a complete  
| re-write of the guts of bp_table to always look at the underlying  
| representation that Octave stores of functions and breakpoints, but  
| would like to know if there is a more efficient way of doing it.  I  
| agree it doesn't make a lot of sense to store breakpoint information  
| in two places.

OK, I'd say keep it as it is now, but clear/invalidate the breakpoints
as needed.

jwe