Mon 18 Jul 2016 06:40:04 PM UTC, comment #17:
@Lachlan: Is file #37906 the final cset, or just for testing by Philip? I notice that there is a block of code in bp_table::do_get_breakpoint_list that is commented out with
That's fine for testing, but probably should be removed for production code.
|
Sat 16 Jul 2016 09:46:48 AM UTC, comment #16:
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?
|
Sat 16 Jul 2016 02:27:56 AM UTC, comment #15:
Thanks for testing, philip.
There were three changeset (one for dbstatus, one to find nested functions, and one to show them). Only one needed updating, so I only posted the new version of one. I like to keep mq changesets small, since mq doesn't keep histories.
Here is a combined patch that contains all three changesets.
(file #37906)
|
Fri 15 Jul 2016 06:59:08 PM UTC, comment #14:
With that latest patch:
(Mageia 5)
|
Fri 15 Jul 2016 11:57:14 AM UTC, comment #13:
Here is a refreshed patch to show nested function names.
(file #37888)
|
Thu 07 Jul 2016 04:47:43 PM UTC, comment #12:
Cool. At least Matlab didn't decide to switch the nested function hierarchy separator between Windows and Unix platforms.
|
Thu 07 Jul 2016 04:19:32 PM UTC, comment #11:
Setting breakpoint in GUI ("Enable breakpoint on current line"
Then using command line syntax:
ML 2016b prerelease
I might have time to try the patches this weekend, maybe tomorrow
|
Thu 07 Jul 2016 02:00:51 PM UTC, comment #10:
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.
|
Thu 07 Jul 2016 12:56:23 PM UTC, comment #9:
It turns out that Matlab's syntax is a>c/d. I'm not sure if that becomes a>c\d on Windows.
(Philip [added to Cc list], if you have access to Matlab on Windows, can you check what is reported if you set a breakpoint in function d() in Rik's file a.m and run dbstatus? Thanks!)
The reason dbstop didn't find a>c/d or a>c>d is that the symbol table didn't support support that at all. Three patches are attached. One allows the syntax to be used. One generates it for error messages. One causes dbstatus to display breakpoints in nested functions correctly.
(file #37752, file #37753, file #37754)
|
Sat 21 May 2016 12:04:07 AM UTC, comment #8:
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.
|
Fri 20 May 2016 06:11:30 PM UTC, comment #7:
@Lachlan: I applied both of your patches. On the second patch, I changed "FIXME --" to "FIXME:" since that is what we use. I also changed the comments which referred to the old variable line so that they refer to the new variable lineno.
This may be reaching, but is there a way to set a debug point within a nested function of a subfunction using a string syntax?
For ordinary subfunctions, you can use the expression
to have the interpreter stop at the first line of the subfunction. Consider the m-file a.m which is attached.
Within Octave the following all work:
However, I can't set a breakpoint on function d, a nested function of a subfunction.
The first thing to test is whether Matlab allows this. If it doesn't then at least we are compatible and can set the breakpoint using a line number.
(file #37214)
|
Wed 18 May 2016 03:26:57 AM UTC, comment #6:
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
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)
|
Tue 17 May 2016 12:50:48 PM UTC, comment #5:
Thanks, Rik. You're absolutely right. The attached changeset should fix that.
However, in testing it, I noticed that functions nested within subfunctions are still not covered, since they are not subfunctions of the main function.
If you apply the .v2 patch, please keep this bug report open while I write that larger patch.
Thanks also for applying all the other patches, and giving tips along the way -- I've been meaning to find out the C++ version of MAXINT for ages!
(file #37185)
|
Mon 16 May 2016 04:58:29 AM UTC, comment #4:
The new issue is probably the result of this construct
I'm pretty sure a different case needs to exist for is_user_script ().
|
Mon 16 May 2016 04:44:49 AM UTC, comment #3:
Oops. I have to reopen this. Apparently you can no longer set breakpoints in scripts which don't have a function context.
For example, create the following file tst_dbstop.m
and then try
This returns an empty matrix and the breakpoint is not set.
|
Mon 16 May 2016 03:51:59 AM UTC, comment #2:
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.
|
Sat 14 May 2016 12:04:48 AM UTC, comment #1:
Confirmed. I didn't check that your root cause analysis is correct, but you're right that the output should be 2 5 8 14.
|
Fri 13 May 2016 11:39:39 PM UTC, original submission:
To reproduce this bug, create the file nested.m containing
and issue the command
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.
|