In Matlab, when I want to run a function through the debugger, I can type dbstop func, which puts a breakpoint at the first code line in func.m. Then, when I call func(...), I can proceed through the function step by step.
Is there any equivalent for methods? If I want to debug into an interactive call of obj.meth(), none of these alternatives work:
dbstep in only works if the code to be stepped into is part of the function I'm debugging, not if I'm calling it interactively
dbstop obj.mymeth, dbstop MyClass/mymeth, or dbstop MyClass.mymeth fail with Cannot find function MyClass.mymeth.
So, perhaps it's treated like a subfunction. However, dbstop in MyClass at mymeth fails with Cannot find function "mymeth" within "MyClass". This one actually surprises me most. Note that even if it would work, I would still need to find out the defining class first.
dbstop mymeth actually does set a breakpoint, but it sets it at line 1 of MyClass, rather than at the beginning of MyClass.mymeth. I have not tested what happens if mymeth is overloaded.
Next, I tried it through the metaclass and metamethod: ms = ?MyClass; meth = ms.MethodList(strcmp({ms.MethodList.Name}, 'mymeth'))
, gives me an meta.method object to my method. However, dbstop wants a string, so I can't put a breakpoint. And although the meta.method does tell me the defining class, it does not tell me the line number where the method is defined, so I can't set a breakpoint like this either.
Then, all that is left is to determine the defining class from the meta.method, open the corresponding file in the graphical interactive editor, search for the line defining the method, and put a breakpoint by hand. This is time-consuming and only works when working graphicaly.
Is there any way to step into an interactively called method, or to programmatically set a breakpoint at the beginning of a method? I'm using 2013a.
The following syntax worked for a simple test on my computer:
dbstop in MyClass.m at MyClass.mymeth
Related
I am trying to change the UVM verbosity of the simulation after satisfying certain conditions. Verbosity options of different components are passing through the command line as +uvm_set_verbosity. Once the conditions are satisfied, then the simulations should run with the the command line +uvm_set_verbosity option. Till then simulation runs with low verbosity for all components.
Looking through the UVM library code, it appears that there is a function called m_set_cl_msg_args(). This function calls three other functions that appear to consume the command line arguments like: +uvm_set_verbosity, +uvm_set_action, +uvm_set_severity.
So what I did was get the uvm_root instance from the uvm_coreservice singleton, and then use the get_children() function from uvm_component class to recursively get a queue of all of the uvm_components in the simulation. Then call the m_set_cl_msg_args() function on all of the components.
My code looks like:
begin
uvm_root r;
uvm_coreservice_t cs_t;
uvm_component array_uvm[$];
cs_t = uvm_coreservice_t::get();
r = cs_t.get_root();
r.get_children(array_uvm);
foreach(array_uvm[i])
array_uvm[i].m_set_cl_msg_args();
end
Even though this code compiles properly, But this is not changing verbosity. Any idea ?
Moreover I am able to print all the components in array_uvm. So I am guessing
array_uvm[i].m_set_cl_msg_args();
this as a wrong call.
Anyone have any other suggestion to change verbosity during run time.
You should never use functions in the UVM that are not documented in the language reference manual. They can (and do) change in any revision. I'm guessing +uvm_set_verbosity only works at time 0 by default.
There is already a function to do what you want
umm_top.set_report_verbosity_level_hier()
I suggest using +UVM_VERBOSITY=UVM_LOW to start your test, and then define your own switch for activating the conditional setting.
If you want a specific component, use component_h.set_report_verbosity_level() (add the _hier to set all its children)
You can use the UVM's command line processor get_arg_values() method to specify the name of the component(s) you want to set, and then use umm_top.find() to get a handle to the component.
This is my code:
%Activity 3.4 An object is thrown vertically with a speed vo reaches at
%height h at a time t.
function t = time(h,vo,g)
t = roots([0.5*g,-vo,h])
%Testing the function
test = time(100,50,9.81)
I've looked through different solutions but still can't figure out why I keep getting this error.
The error is happening on the line t = roots([0.5*g,-vo,h]).
Three comments:
You are probably pushing the Play button in the MATLAB editor. Don't do that. Forget that it even exists. Define h, vo and g in your Command Prompt, then do t = time(h, vo, g); in the Command Prompt. Again, do not push the Play button.
Make sure your working directory is set to where you defined the function time. MATLAB can't find this function that you defined. If you don't know how to do that, check out this from MathWorks: http://www.mathworks.com/help/matlab/ref/cd.html
Your error says it's trying to use a file called A3_4, yet your function is called time. In other words, It looks like you called your file A3_4.m yet it needs to be called time.m. Make sure it's in a file called time.m, then try again. That's one of MATLAB's cardinal rules. When you define a function, the function name and file name need to match.
Do all of those three steps in order, and you will be laughing and singing like these guys below:
(source: kym-cdn.com)
Someone on /r/matlab asked me a really interesting question a few days ago related to a Flappy Bird clone submitted to the MATLAB FEX. The poster noticed that if you open the main .m file, stop it in the debugger on the first line, and run a whos(), you see a bunch of variables before they are explicitly defined by the function.
The first thing that I noticed in the editor was the syntax highlighting indicating the presence of nested functions. At a glance, it seems like the variables returned by the whos() are only those that will be defined at some point in the scope of the base function.
You can recreate this with a simpler example:
function testcode
asdf = 1;
function testing
ghfj = 2;
end
end
If you set a breakpoint on the first line and run a whos(), you get
Name Size Bytes Class Attributes
ans 0x0 0 (unassigned)
asdf 0x0 0 (unassigned)
I couldn't seem to find anything explaining this behavior in the documentation for nested functions or related topics. I am not a computer scientist and my programming knowledge is limited to MATLAB and a very small sprinkling of Python. Can anybody explain what is going on? Does it have something to do with how MATLAB compiles the code at run time?
The workspace of a function with nested function is protected. When the function is called, Matlab has to analyze the code to determine which variables are in scope at what part of the function. Remember, variables that are declared in the main function and that are used in a nested function are passed by reference, and can be modified within the nested function even if not explicitly declared as input or output.
To avoid messing up any of the nested functions, and possibly to help speed things up, Matlab does not allow assigning any additional variables to the workspace of that function. For example, if you stop the execution of the code at line 1, and then try assigning a value to a new variable klmn, Matlab will throw an error. This can be a bit frustrating for debugging, but you can always assign ans, fortunately.
In Eclipse, is there a way to disable a breakpoint until another breakpoint is hit first?
This is a big hack, but it is a functional workaround:
Call the 'trigger' location breakpoint 1 and the target location breakpoint 2. We want breakpoint 2 to fire if-and-only-if execution has passed breakpoint 1.
Set conditional breakpoints at each.
For breakpoint 1, set the condition as System.setProperty("breaknow", "breaknow") == "". This condition will never be true, but will set a system property which we can read at breakpoint 2.
For breakpoint 2, set the condition as System.clearProperty("breaknow") != null. This condition will trigger when the system property is set, and also clear it (so we can repeat if needed).
As I said, it's a hack, but it seems to work. I submitted an Eclipse enhancement request to implement linking or chaining breakpoints as a native feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=390590). Unfortunately, I don't have bandwidth to implement it myself, but perhaps we'll get support for a cleaner solution someday.
One caveat (which applies to all conditional breakpoints, not just to this trick): From my experience, it appears that a setting a conditional breakpoint prevents the JIT from compiling the method of interest, running it in interpreted mode instead. Or perhaps, it allows the first C1 JIT stage but prevents the second-stage C2 compiler from optimizing?
In either case, you should be aware that the method you’re debugging will run considerably slower with a conditional breakpoint in place. This isn’t usually a problem, but when debugging very tight inner loops, I’ve found it better to fall back to the (sloppy) if (x) { // Do somthing useless and set a breakpoint here} method.
No. But you can have conditional breakpoints. I guess that hitting the other breakpoint indicates some change of state.
So, Right click the breakpoint -> Breakpoint properties -> check "conditional"
If you know the condition at which the other break point will be hit, then you can add that condition to the new breakpoint.
Conditional breakpoints are one possibility, and you can also set a Hit Count so that the breakpoint is only triggered after being hit the specified number of times.
But no, there is no way to do what you are asking.
Another idea is to disable your breakpoint and enable it once the other breakpoint is hit.
I am experiencing some very odd timing behavior from a function I wrote. If I wrap my function inside another empty container function, it gets a 3x speedup.
>> tic; foo(args); toc
time elapsed: ~140 seconds
>>tic; bar(args); toc
time elapsed: ~35 seconds
Here's the kicker - the definition of bar():
define bar(args)
foo(args)
end
Is there some sort of optimization that gets triggered in MATLAB for nested function calls? Should I be adding a dummy function to every function that I write?
The JIT accelerator does not operate on command line expressions as far as I know. Thus, when you run "tic; foo(args); toc" foo's code runs entirely in the MATLAB interpreter. However, when you run "tic; bar(args); toc", bar is evaluated in the interpreter and the JIT accelerator takes a shot at compiling the call to foo() to native code.
I'm really waving my hands over the details, but that's the gist of it. Details for MATLAB's JIT capabilities are hard to come by; most of what I've found is on Loren's blog at The MathWorks. The closest authoritative statement I can find about the command line being interpreter-only is here:
http://blogs.mathworks.com/loren/2006/05/10/memory-management-for-functions-and-variables/#comment-207
This is surprising behavior. An intermediate function call should not speed things up like that.
Try profiling it and see where it's spending its time. This is the best first resort to almost any "Why is my Matlab code slow?" question.
clear all
profile on -timer real
foo(args);
profile report
%read the report and save a screencap
clear all
profile clear
bar(args);
profile report
There ends the advice. Here starts the speculation.
There are a couple things that are different in the two calls. There is workspace interaction. Calling foo() from the command line may leave the variable "ans" populated in your workspace. When called from bar(), ans will be set but then immediately cleared when bar() returns. Also, the foo() may be using evalin()/assignin() to look into workspaces up the call stack, and it may interact with variables assigned in your base workspace. The bar() function has a clean workspace.
Depending on where bar.m is, it may actually be invoking a different foo(), or maybe resolving it slightly differently. Check your path resolution with "which foo" in both contexts.
Depending on how "args" is defined, different inputname()s may be visible to foo.
Also, foo() may contain pathological code that checks whether it is being called from the base workspace, or even whether it's being called by a function of a particular name, and behaves differently based on that.
That said, these should mostly be minor interactions and shouldn't cause a slowdown of that order. I'd suspect something else was going on, maybe just exposed by slightly different calling contexts. Adding a level of indirection with bar() shouldn't be the answer. See what the profiler has to say and go from there. Exact code to reproduce will help a lot in getting assistance from the community.
I don't know if you have tried running your code multiple times, but one potential explanation I've noticed is that the very first run of a newly updated file is usually slower than subsequent runs (I assume due to compiling). I'm guessing you may see different timing for the third line of the following (called after modifying foo):
tic; foo(args); toc; % First call of foo
tic; bar(args); toc; % Second call of foo inside bar
tic; foo(args); toc; % Third call of foo
Have you tried foo a second time without clearing variables? I'm unable to reproduce this performance increase if I run it repeatedly. Else, it does seem faster but that's only because MATLAB does precompile these functions if you run them once.
function barfoo
for i = 1:Inf
end
end
And,
function foobar
barfoo();
end