Re: Stepping into local functions no longer works

[Daniel J Sebald]

On 04/28/2013 01:52 PM, John W. Eaton wrote:
> Could we please keep discussions on the list?
>
> On 04/28/2013 02:27 PM, Daniel J Sebald wrote:
> > On 04/28/2013 01:17 PM, John W. Eaton wrote:
> > > On 04/28/2013 02:10 PM, Daniel J Sebald wrote:
> > > > Debugging no longer into local functions inside a script file. Was that
> > > > change intentional?
> > >
> > > Probably not.
> > >
> > > Can you give a precise example and explain what steps are needed to
> > > reproduce the problem? I don't have time to guess.
> >
> > Give the attached function a try. It was open in my editor and I placed
> > a breakpoint. A dialog came up instructing if it should be added to the
> > path or change directory (nice). I selected change directory.
> >
> > I noticed that wouldn't step into the local function. Since I wrote the
> > previous post I noticed that the function returns the same value no
> > matter the input.
>
> Stepping in works for me.
>
> But initializations of global variables only happen once.

OK, putting the "global" declaration on another line solves that.


> OTOH, there does seem to be a bug in that if I set a breakpoint in the
> subfunction and then call the primary function, the debugger does not
> stop in the subfunction, even on the first call. I'm not sure why that's
> happening, but it seems to be independent of the global initialization.

That's been like that for a while.  I noted it here (#5/#6):

https://savannah.gnu.org/patch/?8006

The breakpoint inside the local function can't be removed.  But, 
set/unset breakpoints elsewhere in the file, and sometimes the set/unset 
of breakpoints inside local functions starts working again sort of. 
Perhaps it has something to do with the difference between a function 
name and a file name.


> I am able to step in to the subfunction if I set a breakpoint in the
> primary function then, on the first call to the primary function, step
> to the global statement and use the "step in" button or use "dbstep in"
> at the command line.

Right.  This relates to the fact I put "global" in front of one of the 
variables.  (I was testing how variables organize inside the workspace 
window.)  It wasn't being called so the debugger won't step in, except 
the first time through when I must not have done a "dbstep in".

Dan