Re: Connecting Octave to the GUI

[John W. Eaton]

On 04/04/2013 12:02 AM, Daniel J Sebald wrote:
> On 04/03/2013 10:35 PM, Daniel J Sebald wrote:
>
> > I've compiled and I'm coming up to speed on this. I can crash by setting
> > a breakpoint in a file in the current directory. When the debugger stops
> > at that point, I then do a "cd ../<someotherdirectory>" then try to
> > continue. That file has gone out of scope of course.
>
> I've noticed that any breakpoints that are set in a file that goes out
> of scope because of a "cd" are lost. That info will have to be sent over
> to the GUI somehow, either as clear all breakpoints for a particular
> file or individually clear breakpoints. I see that right now the GUI
> retains the red dots even though Octave currently won't break there
> again even if the function in the file is run after returning to scope.
>
> However, I wonder why the breakpoints can't be retained and reactivated
> if the function comes back into scope. Is it that if one changes
> directory there could be another function of the same name which will
> confuse the core? The thing is, it would be pretty easy for a GUI user
> to change directory without being cognizant and breakpoints will be
> lost. It would be nice if the red dots faded to a translucent color when
> the file goes out of scope, then come back to solid red if the file
> comes back into scope.

I'm not seeing that behavior.  Using the function

  function f ()
    persistent x = 1;
    x++
  end

That is in the current directory, if I set a breakpoint in f and then
run it, debugging seems to work.  Then if I cd .. and then back to the
location of f, the debugger still stops on my breakpoint and I see
that x is not reset, so the function was not parsed again.

If that's not working for you, can you give me a precise test case
that demonstrates the problem?

jwe