Lachlan,

I only used the last patch as I got the impression that the others have been pushed by Rik - see comment #7.
Is that correct?

With that latest patch:

../dev_VE/libinterp/octave-value/ov-usr-fcn.cc: In function 'std::string walk_nested_fcns(const octave_user_function*, const octave_user_function*, std::string)':
../dev_VE/libinterp/octave-value/ov-usr-fcn.cc:317:40: error: 'nested_fcn_separator' was not declared in this scope
           std::string nm = left_path + nested_fcn_separator + q->first;
                                        ^
Makefile:19544: recipe for target 'libinterp/octave-value/libinterp_octave_value_liboctave_value_la-ov-usr-fcn.lo' failed
make[2]: *** [libinterp/octave-value/libinterp_octave_value_liboctave_value_la-ov-usr-fcn.lo] Error 1

(Mageia 5)

Cool.  At least Matlab didn't decide to switch the nested function hierarchy separator between Windows and Unix platforms.

Dang.  Matlab has buried that syntax so deep I've never seen it.  Not critical for the 4.2 release, but probably a good thing to do.

Thanks, Rik.

I just tried to check whether dbstatus returns a>c>d or a>d (which is ambiguous, as d may also be nested in a different subfunction), and found that the new breakpoint doesn't show up at all :(

I'll fix dbstatus first, then look into using a>c>d syntax.

The attached patch has the recursive code to handle functions nested within subfunctions.  It should be applied on top of the .v2 patch in file #37185.

This time I've explicitly tested it on scripts, functions within scripts and functions within functions.

There is one idiosyncracy.  For

function a

  function b
    x = 1;
  end
  y = 1;
end

function c
  z = 1;
end

trying to set a breakpoint in line 2 (the blank line before b) will set the breakpoint on the next line in function a (since line 2 is in a), whereas trying to set a breakpoint in the blank line before c will set the breakpoint to the first executable line of c.

I think this is reasonable, or at least not worth the effort of changing.

(file #37193)

The new issue is probably the result of this construct

          // The breakpoint is either in the subfunction found above,
          // or in the main function, which we check now.
          if (main_fcn->is_user_function ())
            {
              int e = dynamic_cast<octave_user_function*> (main_fcn)
                      ->ending_line ();
              if (e >= lineno && e < earliest_end)
                dbg_fcn = main_fcn;
            }

I'm pretty sure a different case needs to exist for is_user_script ().

I updated the patch slightly.  Instead of using 1 << 30 as the initial earliest_end, I used std::numeric_limits<int>::max ().  According to the C++ standard, an int is only guaranteed to be 16 bits wide.  One would probably never encounter such a machine these days, but it seemed cleaner not to have a hardcoded value.  I also removed the BIST test.  In order for octave to find the function nested, it would need to be called nested.m rather than using something from tmpname().  I don't think that's a problem.  Once we get this right it doesn't need to be continually tested.

I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/4bf980861fd6).  Marked as fixed and closing report.

To reproduce this bug, create the file nested.m containing

function nested
  a = 1;

  function inner
    b = 2;
  end

  d = 3;

end

function subfunction

  c = 3;
end

and issue the command

dbstop nested 1 4 7 11

The results should be 2 5 8 14, but instead is 2 8 8 0.

The reason is that add_breakpoint stops once it reaches a (sub)function containing a line number at least equal to the requested line.  That means it can only set breakpoints in a single (sub)function per invocation.

More importantly, because the "end" of an outer function is processed before a nested function is, breakpoints cannot be set in nested functions at all.

I'll post a patch once I have a bug number.  It first checks which (sub)function contains each requested line, and then walks only the selected function.