I recently discovered that you can set breakpoints in Xcode that will print to the console and auto-continue -- meaning you can insert log statements without having to write NSLog() calls and recompile (on-the-fly logging, woot).
Only problem is that it seems to be a little limited in what you can display when doing a log.
It shows some tokens you can insert, like %B to print out some info about the current breakpoint or %H for the hit count.
I'd like to know if there's any way I can insert a time stamp in a particular format into the log line?
I tried playing with the "shell script" breakpoint action, but it told me that the date command didn't exist.... strange...
Any help would be awesome,
Thanks guys!
Read the GDB manual about Breakpoint Command Lists
You can give any breakpoint (or watchpoint or catchpoint) a series of commands to execute when your program stops due to that breakpoint. For example, you might want to print the values of certain expressions, or enable other breakpoints.
And in particular:
for example, here is how you could use breakpoint commands to print the value of x at entry to foo whenever x is positive.
break foo if x>0
commands
silent
printf "x is %d\n",x
cont
end
Does this answer your question?
Related
As you can see I did not quote Hill correctly thus making the SQL command incorrect. The first SQL line has the database name followed by =# the second line has -#. After the incorrect SQL command there is '#.
The issue is no matter what, I cannot exit the '#.
Only option is to quit psql with \q. Is there a way to go back from '# to =# instead of completely exiting psql?
The '# tells you there is a dangling quote.
To finish the statement enter '); on the '# prompt.
The ' closes the string. The ) ends the VALUES part of the INSERT and the ; ends the whole statement resulting in a syntax error (obviously)
In my hands, you can't even use \q to quit, as that can be a legitimate part of a single-quote quoted string. I just get a message (on Linux) saying Use control-D to quit., which does work.
But to get out of the line entry without closing psql, another thing that you can do is hitting ctrl-C. (But this doesn't work on MSWindows, it bombs all the way out of psql). The problem with that is that you lose your buffer.
If you want to preserve your query buffer so you can go back and edit it to fix the problem, then do as the horse suggests and just close the quote and whatever other open constructs you have, to get the syntax error. Then hit the up arrow to go edit it, adding the missing quote in the proper place and deleting the extra one you had to add at the end to get things to close out. To be really careful, you should make sure the thing you are about to submit really is going to be a syntax error, and not accidentally a valid statement which does something you don't want. When attached to production, I take the ctrl-C route and accept the loss of the query buffer, it is safer.
This question already has answers here:
Stop and continue execution from debugger possible?
(6 answers)
Closed 6 years ago.
In MATLAB, I'm running some code which takes a while to run. I'd like to pause the code to check on some variable values. Is there a way I can do this without having to re-run the code from the beginning? I don't want to terminate the program; just pause it.
You can halt execution and give a command prompt in two ways of which I am aware:
Putting keyboard in your code where you want to stop.
Setting a breakpoint.
You can resume and stop execution with dbcont and dbquit, respectively. To step forward, use dbstep. dbstack lets you see where you are. There are many more commands. The help page for any of these will give you other suggestions.
As Dennis Jaheruddin has pointed out, dbstop also has several useful features worth trying. In particular is the ability to set conditional and global (any line meeting a criterion) breakpoints via the dbstop if syntax. For example, dbstop if error will break to a debugging command prompt on any error. One suggestion he made, which I now do, is to put dbstop if error into startup.m so that this behavior will be default when you start MATLAB. You may need to create this file in a userpath folder; edit(fullfile(regexp(userpath,'^[^;]*','match','once'),'startup.m')).
One way to achieve what you're looking for would be to use code sections (also known as code cells), where you divide your code into sections divided by lines with two percent signs (%%).
Then, in the editor, you can press ctrl+enter to execute the current code section, and ctrl+up/down to navigate between sections.
Well there is the pause command, but then you cannot check for the variable contents in the workspace because the program is running.
What you probably want is to set a breakpoint (See the Debug menu / key F12).
At a breakpoint matlab pauses the program and enters debugging mode in which you can see and edit the variables. Once finished, you can resume the program where it was paused.
I'm not sure about Windows users but if you're running Linux you can start Matlab in a terminal using
matlab -nodesktop
then once Matlab has started, cd to your project directory and start your Matlab script. Now whenever you want to pause execution you can use ctrl-Z. Then to resume type fg. I hope this helps.
I wonder what the difference is between entering a few lines in the command window, or letting a script execute them.
In the question Escape from nested try - catch statement I have an example function. I have put the selected code in a script and called it, however then it does not work properly. On the other hand, when I
select the lines and hit f9, it works as expected.
The lines are:
dbclear all
dbquit
dbstop if caught error
I call the example function as such:
dbstop if caught error
mytestmain
And the example function is:
function mytestmain
try
mytestsub
catch
end
% Definition of subfunction, may or may not be in the same .m file
function mytestsub
try
a=b; %Intentionally generate an error as b is not defined
catch
end
I think it's related to MATLAB's just-in-time (JIT) compiler, which compiles functions before it runs them.
It seems that it compiles functions differently if dbstop is set or not (see here for reference). As it currently stands, MATLAB can not recompile a function while it is run (just try saving a changed function during a dbstop, and you will get a message informing you). As you can add and remove breakpoints during a dbstop I think you can also do so programmatically, but it should be impossible to "turn on" debugging if it wasn't turned on at "compile time"
So in your cases:
Using F9 it's just pasted and parsed as if you input it manually. So first dbstop is set, then mytestmain gets compiled and executed.
Running as a script will first compile the script and mytestmain and then execute it - so dbstop would be set after compilation and therefore not in effect.
Depending on what you mean by "doesn't work", it could just be because the debugger is a special context and certain debugger commands - dbup, dbdown, and dbquit - only work when you're at a debugger "K>>" prompt. Once you call a script, you're no longer at the debugger prompt but in normal code execution - inside a nested M-code call stack - and they just don't work there. When you F9, it does the lines individually, so each one is done from the prompt.
As a workaround, if you really want to execute a sequence of debugger commands like this, you could write a little Java Swing widget to enter the text in to the command window just as though you were typing it in.
I have used Eclipse and VS. When I insert a breakpoint and debug the program, it will stop before the breakpoint.
But what if I want to debug the effect of the last sentence of the program? Inserting a meaningless sentence(say print 'pause' in Python) is OK but seems awkward. Is there any alternatives?
In Visual Studio you can put break point on closing bracket in main (or any) method of Program (or any) class (default naming, may vary), then debugger stops just before closing application.
Is there any reason not to use a breakpoint on the last statement, like you said, then manually proceed one step? Depending on the debugger, this can also be automated. In GDB, one can use commands N, where N is the breakpoint number, to set a list of (debugger) commands to be executed immediately after a breakpoint is hit.
I have a breakpoint action and am using the Log option from the drop down. I'd like to print out the string (summary) value. I'm doing this:
the person name is: #p.name#
but that prints the memory address. I can switch to the Debugger Command option and do
po f.name
but then I lose my description, as used in the first option. Using the Log option, is there a way to print the string value and not the memory address?
You can use NSLog statements with breakpoints using "Debugger Command", but you need to add "expr"
expr (void)NSLog(#"The Person Name is %#", p.name)
-
There are a couple of things you can do. Add a Log function from the drop-down, then add another box and select Debugger Command and enter po f.name.
If you want your log to be more complicated, you could do something more like this:
the person name is: #(const char *)[(NSString*)[p.name description] UTF8String]#
You best bet is probably to just use the debugger's graphical interface to watch variables. If you want to log messages, use NSLog.
Here is a solution using only one action, and using fewer characters than the expr solution.
However, unless you add the void like this:
po (void)NSLog(#"the person name is: %#", p.name)
you will get an annoying "nil" printed out with your log. for example:
(lldb) po NSLog(#"foo")
nil
2013-06-19 14:42:59.025 TheMove[95864:c07] foo
(lldb) po (void)NSLog(#"foo")
2013-06-19 14:43:10.758 TheMove[95864:c07] foo
If you can live with the nil (I can) it's faster to type and easier to remember just the po
I ended up using 2 different actions for the same breakpoint. First a Log and then a debugger command with po varName. Only downside it will print in 2 different rows.
For Swift and Xcode 12.2 you can double click on the breakpoint and use Debugger Command as an action and as a command whatever you usually time on the debugger.
In the example I use po with a string as param (to avoid printing the memory address) which contains the values I am debugging. I also enable Automatically continue... to avoid stopping the execution.
You can also add other text or other variables.
A thing to keep in mind though, running these takes some time, so for operations where timing is important, these are not good.
You don't need TWO actions in the breakpoint, you can just have ONE command (log message), where you put the message including the content of variables (see image). By clicking "automatically continues" it is just acting like having a print-command in code, but the good thing is, then you dont have print statements in your code.