[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Breakpoint bug [was Re: Breakpoint woes]
From: |
John W. Eaton |
Subject: |
Re: Breakpoint bug [was Re: Breakpoint woes] |
Date: |
Mon, 20 Apr 2009 15:03:55 -0400 |
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
- Breakpoint woes, John Swensen, 2009/04/08
- Breakpoint woes, John W. Eaton, 2009/04/20
- Re: Breakpoint woes, John Swensen, 2009/04/20
- Re: Breakpoint woes, John W. Eaton, 2009/04/20
- Re: Breakpoint woes, John Swensen, 2009/04/27
- Re: Breakpoint woes, John W. Eaton, 2009/04/27
- Re: Breakpoint woes, John W. Eaton, 2009/04/28
- Re: Breakpoint woes, John Swensen, 2009/04/30