octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Breakpoint woes


From: John W. Eaton
Subject: Re: Breakpoint woes
Date: Mon, 27 Apr 2009 20:59:49 -0400

On 27-Apr-2009, John Swensen wrote:

| So this was quite an easy fix, and I think it is a much better  
| solution, but I still have one problem.  I added a little printf to  
| the octave_user_code destructor to see when it is actually being  
| called.  I found that if I set a breakpoint in a function in the  
| current directory, then 'cd' out of the directory, the destructor  
| isn't called immediately.  Instead, it appears the object isn't  
| destroyed until certain functions are called.  I have verified the  
| following things cause this cleanup to occur, but there may be many  
| more:
| 1) call dbstatus
| 2) call dbstop with the same function name as was used to set the  
| breakpoint
| 3) trying to call the function with the same name as was used to set  
| the breakpoint
| 
| Plus, it seems that it is somehow tied to the octave readline prompt  
| also.  I tried writing a simple OCT file that launched a new thread  
| and continuously called bp_table::get_breakpoint_list, just as  
| dbstatus does. However, this didn't cause the octave_user_code  
| destructor to be called unless I also had the thread set rl_done=1.

I think what you are seeing is that functions are only discarded when
they are known to be out of date.  So for example, if you did the
following in a directory that contained the function f in the file f.m

  orig_dir = pwd ();
  f ();
  cd ..
  cd (orig_dir);
  f ();

Octave would not call the destructor for F because on the second call
it would check to see if F has changed and find that it has not, so
there is no need to delete the definition and parse the file again.
But if instead you did

  f ();
  cd ..
  f ();

then the destructor would be called for F when the second call to F is
made and Octave checks to see whether the definition of F has changed.

| Any suggestion on where to look next? I suppose this is "good enough"  
| and I can issue the rl_done from my IDE to force directory changes to  
| affect breakpoints immediately, but it would be nice if I could figure  
| out what is being called after each iteration of the readline loop  
| that causes these things to be updated.

Exactly what is it that you are trying to update/get the status of?
Whatever the problem is, I'd guess that setting rl_done is the best
thing to do.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]