Fri 10 Jan 2014 04:39:40 PM UTC, comment #10:
I filed a separate bug report about dbstatus clearing breakpoints set in @class files (bug #41190).
This bug has been fixed so I'm closing this report.
|
Fri 10 Jan 2014 04:23:46 AM UTC, comment #9:
This actually looks like a separate bug that is also present in 3.6.4 with breakpoints on class functions, even without the .m file extension:
|
Thu 09 Jan 2014 05:29:26 PM UTC, comment #8:
The class breakpoint seems to be deleted if the dbstatus command is used. The following code works.
But if I use dbstatus after setting the breakpoint to check on it then 1) the breakpoint is not shown) and 2) it seems to be deleted because the command runs to completion.
|
Tue 07 Jan 2014 09:11:03 PM UTC, comment #7:
I checked in the following changesets:
http://hg.savannah.gnu.org/hgweb/octave/rev/0806c9e75e08
http://hg.savannah.gnu.org/hgweb/octave/rev/f26d527c1a71
With these, I'm able to set breakpoints in methods using the gui editor or at the command line using either dbstop @foo/fcn.m or dbstop @foo/fcn.
|
Tue 07 Jan 2014 03:31:47 PM UTC, comment #6:
Mike, good questions.
Here's what I can see: if I have a function '@cvx/norm.m', all three of these commands successfully set a breakpoint to the first line:
Yes, that last one works, even if the '.p' file does not exist. These produce an error:
This extension behavior is identical for normal functions, scripts, and class functions.
The subdirectory approach does not work for non-class subdirectories in the path. To test this, I created a subdirectory 'test' and a script in my ~/Documents/MATLAB directory, which is in my path. The "edit" command below succeeds, but the "dbstop" command fails. If I try use the editor to set a breakpoint in test/command_test.m, I get the modal dialog.
|
Tue 07 Jan 2014 12:31:18 PM UTC, comment #5:
Yes, there is shadowing if you add the actual @ directory to the path.
|
Tue 07 Jan 2014 05:08:15 AM UTC, comment #4:
Although Octave:shadowed-function is currently raised for class methods, I don't think it should be so -- your thoughts? There's really no namespace conflict in this case. Please let me know if I'm overlooking something.
|
Tue 07 Jan 2014 02:54:40 AM UTC, comment #3:
Yes, there are a few missing features of dbstop, see e.g. bug #36874 for conditional breakpoints. I'm retitling this bug to reflect the compatibility bug you've stumbled on that the argument should be allowed to be a file with a .m extension.
It would be good to get some more information about what Matlab does with different argument types. Are "dbstop func" and "dbstop func.m" always the same? Do both "dbstop script" and "dbstop script.m" work also, where script.m is a Matlab script instead of a function file? Does it work with an m-file in a non-class subdirectory of a directory in the path?
|
Tue 07 Jan 2014 01:43:55 AM UTC, comment #2:
Ah, good. That works indeed:
With the GUI enabled, the editor pops up with the breakpoint in the proper place. And the interpreter does indeed stop when expected.
What's funny, however, is that clicking on a new breakpoint within the editor still brings up the modal dialog. But maybe this is a GUI issue primarily.
However, if MATLAB compatibility is desired here, "dbstop @cvx/norm.m" should work as well. Then again, so should "dbstop if error", "dbstop if warning", "dbstop if caught error", etc. So I understand that's a work in progress.
Thanks for showing me one option that works!
|
Tue 07 Jan 2014 01:18:06 AM UTC, comment #1:
Can you try the same command but without the .m file extension?
For example the following works for me:
Does dbstop with "@class/function.m" work both with and without the .m file extension?
|
Tue 07 Jan 2014 12:37:04 AM UTC, original submission:
In CVX I make heavy use of class functions, stored in directories beginning with '@'. These directories are not intended to be in the path, but are visible if their subdirectories are.
However, the debugging facility cannot seem to handle them. If I type
I get the error: "error: add_breakpoint: unable to find the requested function". If I then do
The file is loaded into the GUI editor (indicating that it is, indeed, seen on the path). If I then attempt to enable a breakpoint using the GUI, I get the following modal:
Of course, I cannot do either if I want the code to work properly, because many of these functions overload built-in Octave functions, and would now shadow them. So it would seem that it is impossible to set a breakpoint inside a class function.
|