I've been recently been playing around with LLDB's gui feature. (A stackoverflow link about this feature is described here. My current lldb is lldb-320.4.156)
So far, it seems very convenient, especially the ability to view local variables in the current stack frame. But is there any documentation (or tutorial) on how to use the LLDB's GUI mode?
Aside: I specifically have a few questions:
How to show the source code upon going into GUI mode. (Unless I stop at a breakpoint and type gui within LLDB, I can never get source code to show up.)
How to rerun a program while in GUI mode. (There is nowhere to type while in GUI mode.)
Are there colors in GUI mode? I notice if you type lldb --help in the command line, lldb tells you you could invoke it with a --no-use-colors option. (That being said, I've never seen colors with normal lldb mode...)
Is there a way to set breakpoints, prior to running lldb?
The GUI mode in lldb is a feature that Greg Clayton did over a few weeks of nights & weekends -- it's a really cool hack. But it's not completed to product-quality level and there's no documentation short of the command key tips that you can see with its built in help system. The biggest omission is definitely the lack of a console window where you could type arbitrary lldb commands - but adding a console pane like that was where things started to get tricky. :)
Hopefully an interested developer will pick up the gui mode work and add these features. For people who can't use a full IDE, it can be really helpful to have a text mode windowed UI when using a debugger.
But is there any documentation (or tutorial) on how to use the LLDB's GUI mode?
I don't know any official documentation. But this random video was helpful for me. Also, pressing h in TUI gives you a minimal documentation.
1. How to show the source code upon going into GUI mode. (Unless I stop at a breakpoint and type gui within LLDB, I can never get source code to show up.)
As you observed, unless gui command is executed while the program is paused due to a breakpoint or something, nothing happens in TUI.
2. How to rerun a program while in GUI mode. (There is nowhere to type while in GUI mode.)
AFAIK, impossible. Press Esc and execute run again.
3. Are there colors in GUI mode? I notice if you type lldb --help in the command line, lldb tells you you could invoke it with a --no-use-colors option. (That being said, I've never seen colors with normal lldb mode...)
In my environment (M1 Macbook Air), color works with no option (i.e. by default) both in CUI and TUI.
4. Is there a way to set breakpoints, prior to running lldb?
See #Johan's answer. You can also use ~/.lldbinit file if the breakpoint condition is fixed.
Don't have an answer for all your questions, but regarding breakpoints, you can save all your debug session "setup" commands in a file and then just load that file:
lldb -S <filename>
Found this option from here:
https://stackoverflow.com/a/34275770/1345329
Related
I have ctrl+f2 mapped to toggle bookmark in my vscode keyboard shortcuts.
{ "key": "ctrl+f2", "command": "bookmarks.toggle", "when": "editorTextFocus" },
It work correctly on Linux and Windows, but not on macOs.
I have enabled the setting to switch function keys (f1, f2, etc) to behave as standard function keys.
I have then unmapped ctrl+f2 in macOs keyboard shortcut settings.
But still ctrl+f2 keyboard shortcut is not registering with vscode.
Troubleshooting VS-Code Keybinding Issues
The best way to troubleshoot an issue with Keybindings in V.S. Code is to use the tool that was created for solving keybinding issues
The tool is simply named: "Keyboard Shortcut Troubleshooting Tool"
The tool comes with V.S. Code "out of the box", as a result; no downloading, or installation is needed. To use the tool you just activate it from the Quick Input Menu that drops open by pressing the F1-Key. If you cannot find it your self I posted instructions below, and an image. If you can find it yourself, then skip the "Activating the Troubleshooting Tool" Section, and go ahead and read, "Effectively Troubleshooting Issues with the Troubleshoot Keyboard-Shortcut Tool"
Activate V.S. Code's Troubleshooting Tool
Hit the F1-Key
When the quick input drops open type the following into the text input:
"Toggle Keyboard Shortcuts Troubleshooting"
Select the option: Developer: Toggle Keyboard Shortcuts Troubleshooting
It should automatically open the OUTPUT panel, which is located in the same panel that your terminal is. Make sure that the OUTPUT is set to LOG(Window) in the drop down. (I took a picture and posted it below if you can't find the Keyboard Shortcut Troubleshooter).
The image might have funny declensions because I am on a dual monitor setup with 1 1080x1920 curved screen and one 1080x720 screen.... I cropped it to a STD HD 1920 width.
HELPFUL SIDE NOTE:
"This tool may be the most verbose program ever written, as far as I can tell, it logs data to the OUTPUT Console each & every time you activate a keyboard event. Truth be told, I find this tool to be extremely distracting, and very annoying. Because of this, it is important to note, that even if you switch out of your OUTPUT console to your terminal or something. The Troubleshooter is still actively logging to the OUTPUT Console. Make sure when you are finished to turn it off."
Turning off the Keyboard Troubleshooter, requires the same process as turning it on.
Using V.S. Code's Troubleshooter
STEP-1: Close VS Code
This is not to be confused with reload V.S. Code. The only mechanism that VS-Code has for reloading its-self, doesn't provide the same functionality as closing, and reopening V.S. Code. The two are similar, but they are not equal (discussion for another time).
actually stop its process from running by hitting the X in the upper right corner of the title-bar, or hit
**[Alt + F4].
Step-2: Reopen V.S. Code W/O Any Extensions
Don't worry, you won't have to uninstall anything. You will start V.S. Code from the command-line though. Open up your bash terminal, or Powershell, and enter the following command:
$ code --disable-extensions
V.S. Code should start almost immediately
If the V.S. Code CLI doesn't open your editor, or this doesn't disable your extensions, you should refer to this link
Step-3: Start the Keyboard Shortcut Troubleshooter
I already explained this step above, so their is no reason to go over it again. Do make sure you have your panel open, and the OUTPUT tab is selected. You should see a bunch of logging being output, in the VS-Code output (that is redundant sounding), logging when you use any keybinding. The drop-down should have Log(Window) showing, as the current log selected.
Step-4: Test Your Keybinding
At this point you can use your keybinding, and get results. They might not be the results that you were hoping for, but the troubleshooter should give you details as to what is happening when you use your keyboard shortcut (aka bound-key, aka key-binding).
Step-5:
Fix the issue by opening the Keyboards Shortcuts configuration file by opening the quick input, (like I described above for the troubleshooter), and type Keyboard Shortcuts. Their will be two options, one is the default Keybindings that cannot be written too, the other is a configuration file, where you are allowed to overwrite all of the default keybindings if you choose. Look in the default keybinding.json file and make sure the keybinding that you feel is assigned to a certain task, really is assigned to it. Look in the regular keybindings.json file, and make sure if anything is written in it, that those keybindings are not affecting the keybinding that is not working for you. Use the information from the troubleshooter to help guide you through the process.
These links below further elaborate on V.S. Code keybindings:
V.S. Code Community Docs (Community Contributed)
V.S. Code Official Docs (Keybindings)
When I use PyCharm I find myself frequently trying out pieces of code interactively. So far, my workflow has been to use pdbfor this and set a breakpoint as pdb.set_trace, which then drops me into the console.
However, for PyCharm the resulting console has no command history - the up arrow instead moves the cursor upwards into the previous output, which is a pain to use.
I realize there's also the built-in debugger that has a console with history, but getting there involves more clicks (run the debugger, switch to Console tab and clicking on "Show Python Prompt").
There is a built-in console that does have a command history (Tools > Python Console), however, unfortunately that's not the console that's being run for pdbbreak points. Is it possible to get PyCharm to use a different console for pdb?
No, it's not possible. PyCharm has no control over what happens when you invoke pdb.set_trace().
Does anyone know if there is any command line args that i could pass to the windows magnifier (magnify.exe) so it would open using the Lens view.
Or maybe some other way, I tried opening and sending a keyboard input using the shortcut to change the view, but often it blinks before changing the view! =/
I just had the need to do the same thing, and wound up here trying to find a solution. It's ridiculous to think that they wouldn't have a command line switch to set the views, so I started just trying some. And behold! I scored:
Magnify.exe /lens (defaults to lens view)
Magnify.exe /fullscreen (defaults to fullscreen view)
Magnify.exe /docked (defaults to docked view)
Good luck!
Magnify.exe /? on the command line does not expose any sort of help for the executable. And a search online does not seem to provide evidence of any command line arguments. Leads me to conclude that magnify.exe does not take command line arguments.
I recommend reading this article on sending keystrokes to another application. His demo app worked for me to send keyboard shortcuts to magnify.exe. His source code is available as well so you can integrate into your application.
you could try something with autoit, its a scripting language similar to basic that is really well suited for automating tasks
Along those lines this autoit script might be helpful - it lists some msdn doco and if you know
autoit a script.
Maginifier UDF
I am using a work-around.
I created a Windows-8-style batch file that has a command "magnify /on".
I'm not sure if the "/on" part is necessary.
The program that I am trying to magnify,
(which is an old DOS program that runs in a DOS-Box),
launches with the magnify window conveniently available for me to change the magnification setting.
I tried to include a command after closing, "magnify /off", but it does not work;
therefore the magnifier window box has to be clicked to change the magnification back to normal.
This is a great case for the UNIX "strings" utility, of which there is a Sysinternals version here
It takes some digging and testing, but I found these options:
wait (doesn't magnify until you hit a key)
noutilman
hardwarebuttonlaunch
fullscreen
lens
docked
hilight
globalhotkey
Often in MATLAB I turn on 'automatic' debugging with dbstop if error. When an error occurs, the function enters debug mode, and I am able to query the variables in the command window and see exactly what is going on. Very useful.
However, when this occurs, the focus switches to the editor. To me this seems counter-intuitive; we are in debug mode, so I want to find out what is going on, not look at the code (which I can already see in the adjacent window). I always immediately tab back to the command window.
So my first question is: Is there any point in accessing the editor at this point? What can I usefully do, when my script has crashed, in the editor?
And secondly: If I want to, can I change MATLAB's default behaviour to keep the focus in the command window?
To your second question:
If you use MATLAB's desktop environment, just deselect "Open Files when Debugging" in the "Debug" menu.
If you use MATLAB without the graphical desktop you can change this preference by modifying your matlab.prf file. This file stores preferences set from the GUI. The menu option described above makes the same changes as the manual process described below.
NOTE: Editing this file is entirely unsupported. Do so at your own risk.
Open the file from the MATLAB command prompt,
>> edit([prefdir '/matlab.prf'])
Or use the prefdir command in MATLAB to find the directory and then open the file in whatever editor you prefer.
Search for a line that says
EditorGraphicalDebugging=Btrue
Change it to read
EditorGraphicalDebugging=Bfalse
If the line doesn't exist, add it to the file.
Restart MATLAB.
You can use the invocation stack to see how you came about to the particular error position. Sure, you can use dbup and dbdown for this in the command window, but it's much easier in the editor.
Also, seeing the variables (and their values, using mouse hover) in the context of the code that caused the crash is far better for understanding the root cause of the error than just seeing the static values.
I can answer only your first question.
Things you can do in the editor:
Mouse hover a variable, which pops up a 'quick view' window.
Any action you can do when not in debug mode, treating the function as a script - running a line (highlight + F9), running a code block, etc.
I use emacs on my mac to program in Xcode. It works really well for the most part. I double click on a file in xcode, and it pulls it up in an existing emacs window. I compile, and get syntax errors, double click, and they come up in the active emacs window. great.
This is all XCode talking to emacs. Does anyone know of a way to get emacs to talk to XCode? For example, I want to be able to set a breakpoint in emacs and have the XCode version of gdb acknowledge it.
You can actually use AppleScript to set breakpoints in XCode from within Emacs by embedding the AppleScript inside of elisp.
This page contains the code you need. It's in Korean, but there's actually not much Korean to understand. The first code block is just a straight AppleScript example that was used to develop the breakpoint code. The second block is the one you want. It embeds the first example in an elisp snippet that you can add to your .emacs file.
Other communication can be done using the same trick. Just figure out how to do what you want in AppleScript and then embed that AppleScript in elisp within Emacs.
BTW, here is the documentation for do-applescript, the lisp function, available on the Mac, that lets you call AppleScript.
Sounds like a job for a new plugin!