"p variable" command prints all the elements within the variable in lldb. In Swift, just regular print() statement does not do this. A hack would be to loop through the backtrace of the variable and print the elements. I'm curious if there is an easier way to simulate the in-depth printing mechanism like the "p" command I'm not aware of.
Related
MATLAB has a feature to allow users to introduce a command in the script/function called keyboard and have the code stop there with a console/command prompt that gives direct access to the interpreter and the variable space. MATLAB keyboard() command docs
Is there something similar in Powershell? I don't want to deal with Powershell ISE as I don't like it's syntax highlighting (doesn't highlight all occurrences of selected phrase like Notepad++ does) and the macros is a lot weaker than what the plain Powershell console itself (like lacking F8 for recalling).
Stepping with a debugger is not quite as useful when you need to explore complex object structures and try a few things out with the current variable states, instead of just reading what the variables and values are in a docked window. It's much easier to work with the state of mind of the interpreted language at any point by interacting with it instead of ploughing through stack and trace information.
In both Powershell ISE and VSCode, you can read or update the same variables in your session from the terminal window at the bottom, even during debugging.
Suppose I set a breakpoint, that sets another breakpoint that is supposed to trace code execution. It looks like:
bp module!function "as /x {/v:alName} expr;ba w1 ##c++(expr) \".if(${alName}) {actions}\""
How do I make ${alName} evaluate at "ba" breakpoint hit? BTW I tried to enclose "ba" into .block statement right inside "bp" breakpoint command list, but this doesn't work for me either. If I put "bp" command list into a separate file and set "bp" to "$$><scriptName" - works ok. But this sort of "bp" I have here is already specified in another script file.
I have been playing around with vim macros lately (in MacVim at the moment), and sometimes I like to explicitly assign a macro into a register using e.g. :let #a='(macro keystrokes)'. This is generally working fine, but I found a weird behavior in which anytime I assign a string value that ends in Carriage Return / ^M, vim automatically adds a Linefeed / ^J to the end before putting it in the register, which affects the execution of the macro!
Example: Let's say I record a simple macro that gets into insert mode, types "hey", escapes out of insert mode, and then hits Enter twice to go down 2 lines. I record this into register #a by typing qaihey<Escape><Enter><Enter>q, which stores the following in #a:
ihey^[^M^M
So far so good, and executing the macro by typing #a does just what it's supposed to. Another perfectly ok way I can get this same macro into register #a would be by typing the whole thing (ihey<Ctrl-V><Escape><Ctrl-V><Enter><Ctrl-V><Enter>) into a buffer and then yanking it with "ay -- the end result is just the same. But here's the weird thing -- suppose I just wanted to assign that string directly into #a using a let statement:
:let #a='ihey^[^M^M'
Now if I type :reg to look at the value it says there's an extra ^J on the end for some reason:
"8 ...
"9 ...
"a ihey^[^M^M^J
"b ...
Having the extra ^J causes it to go down an extra line when I execute the macro, so it's actually changing the behavior.
Anybody know why this extra character is being added? Anyone know how I can get a string value ending with ^M into a register (or any variable), without having an extra ^J get added?
Some quick checking the vim help files says this:
:let #{reg-name} = {expr1} *:let-register* *:let-#*
...
If the result of {expr1} ends in a <CR> or <NL>, the
register will be linewise, otherwise it will be set to
characterwise.
In other words, ending the string with a carriage return will make Vim interpret it as a line ending
Quick googling give this from the VimTips wiki:
Note however, that the above method using :let will not work as expected for any macros which you make ending in a < CR > or < NL > character (carriage return or newline). This is because, as documented in :help :let-#, Vim will treat the register as "linewise" under these conditions. The reason for this is to make registers set with :let act "the right way" when dealing with yanked/deleted text, but it can cause headaches when dealing with recorded macros. Possible workarounds include using the setreg() function or adding "no-op" commands to the end of the macro, such as a < ESC >. See the discussion on vim_dev about unexpected behavior of the :let command for details.
So you have a few options: use setreg() or add some kind of no-op sequence (< ESC >) to the string when you use let.
In order to insert special keys easily using let, just use double quotes:
:let #a="ihey\<Esc>\<Return>\<Return>"
If you use single quotes vim will insert:
\<Esc>\<Return>\<Return> instead of their functions
I find when I'm typing a line like this to a clisp program's standard input ...
((74 25 80))
... the cursor seems to dance, and it doesn't matter whether I'm doing
(read)
or
(read-from-string (read-line))
That is, when I type each right parenthesis, the cursor briefly hovers over the matching left parenthesis. If I type ahead, sometimes the whole line typed up to that point is re-echoed back to me.
This would be fine, I guess, but I'm doing this over a pty, and I want the input from that pty (what shows up on the clisp program's standard output and error output) to be "clean". No dancing cursor, no re-echoing of the line.
I suppose I could use named pipes for the input and output, but I want to handle this through the pty.
How do I make standard input be purely vanilla? No dancing cursor? No re-echoing of typeahead? Can I just modify a configuration file somewhere?
Sounds like GNU Readline is being used. There's a -disable-readline command line flag for clisp according to this page. Failing that, I think you're going to have to use a pipe to either convince readline that it isn't reading from a terminal or that it isn't outputting to a terminal.
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.