Rust, RR, Neovim: A perfect debug combination(github.com)
github.com
Rust, RR, Neovim: A perfect debug combination
https://github.com/vlopes11/rrust.nvim
101 comments
Shameless plug, but my development environment [1] may be close to what you're looking for. (There's pictures!)
A couple of details have changed since that post. The only one that you might care about is that I now have two tmux panes with gdb-dashboard. This is meant to use space better. One pane has all of the variables and nothing else. The other has everything else.
If you care about that, I'll tell you how to do it.
[1]: https://gavinhoward.com/2020/12/my-development-environment-a...
A couple of details have changed since that post. The only one that you might care about is that I now have two tmux panes with gdb-dashboard. This is meant to use space better. One pane has all of the variables and nothing else. The other has everything else.
If you care about that, I'll tell you how to do it.
[1]: https://gavinhoward.com/2020/12/my-development-environment-a...
This is very cool! I created this small convenience script without the intent to customize `Termdebug` itself, leaving any preferences to the users. But I can see many nice things you added there that can combine very well with the two!
The overall quality of a debugger is far more important than the question of which text editor it's integrated with for me personally.
To that end I would say Intellij products have the best debugging experience I've found on Linux. VS Code after that.
To that end I would say Intellij products have the best debugging experience I've found on Linux. VS Code after that.
I use nvim-dap[1] in combination with jester[2] (by me) to run and debug Jest tests in my project, it works perfectly.
[1]: https://github.com/mfussenegger/nvim-dap
[2]: https://github.com/David-Kunz/jester
[1]: https://github.com/mfussenegger/nvim-dap
[2]: https://github.com/David-Kunz/jester
I'm surprised nvim-dap-ui wasn't mentioned yet. It still has less features than vimspector, but personally I prefer the nvim-dap ecosystem. No memory viewer is a bummer though.
https://github.com/rcarriga/nvim-dap-ui
https://github.com/rcarriga/nvim-dap-ui
So over the weekend I just went through a vim reworking for myself after discovering astronvim. I replaced my config with that one and installed nvim-dap-python through the user template, was able to attach and debug like I was using pycharm in a few hours of tweaking. I really like it
I did have a couple of plugins I cant really live without (ZoomWinTab and A.vim) so Im working on porting them to lua with the help of chatgpt. Really like the experience so far. Def worth checking out astronvim / nvchad
I did have a couple of plugins I cant really live without (ZoomWinTab and A.vim) so Im working on porting them to lua with the help of chatgpt. Really like the experience so far. Def worth checking out astronvim / nvchad
Finding astronvim through this comment and it looks like it may be time to move on from my regular vim to nvim. I like keeping things light so I'll probably just steal some plugins used there but the functionality looks like things I already have except with better UX. Thanks for sharing!
nvim-dap is what’s being used the most.
https://github.com/mfussenegger/nvim-dap
https://github.com/mfussenegger/nvim-dap
VS code plus its vim key binding plugin. The neovim plugin world is just way too unstable in my experience.
Came here to say pretty much the same thing, except I use the Neovim extension for VS Code. It uses Neovim as the backend and, from my experience, behaves a lot more like (Neo)Vim. It is much easier to setup, since debugging is handled by VS Code. The main drawback is VS Code does not work in a terminal, which is okay IMHO since you still have access to Neovim from the shell.
VSCode with the CodeLLDB or MS C/C++ extensions both usually work out of the box for debugging most compiled languages (so far I tried C/C++, Rust and Zig), but compared to proper Visual Studio it's very bare bones (especially the variable view panel).
> compared to proper Visual Studio
Debugging in proper Visual Studio is by far the most pleasant experience I have ever had. Flame graphs, call graphs, memory and CPU utilisation graphs, straightforward call stacks and variable views... FOSS debugging utilities don't even come close to the debugging productivity on VS 2022.
Debugging in proper Visual Studio is by far the most pleasant experience I have ever had. Flame graphs, call graphs, memory and CPU utilisation graphs, straightforward call stacks and variable views... FOSS debugging utilities don't even come close to the debugging productivity on VS 2022.
> I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.
Totalview https://totalview.io/ or Ex-Allinea (now Nvidia) - don't know if it's still usable as a 'general' debugger though. https://developer.nvidia.com/allinea-ddt
Both don't work with Rust.
Totalview https://totalview.io/ or Ex-Allinea (now Nvidia) - don't know if it's still usable as a 'general' debugger though. https://developer.nvidia.com/allinea-ddt
Both don't work with Rust.
You could try vimspector. It's main target is vim and not neovim.
https://github.com/puremourning/vimspector/
https://github.com/puremourning/vimspector/
I tried nvim-dap but it is somewhat clunky, unintuitive to use. Turn out that that using delve, gdb, pydb directly on the command line is fine, I don't really need editor integration.
termdebug (used by the tool linked in the topic) basically does this for anything you can debug in GDB. It's the tightest integration of debuggers and (neo)vim I have used.
There are also DAP-based integrations, which I have put the effort into using.
There are also DAP-based integrations, which I have put the effort into using.
Look into nvim-dap and the ecosystem around it.
Investing in a good debugging tool and knowing your way around using it well, makes all the difference.
After recently doing some JavaScript work and not knowing how to debug it, any suggestions for a JavaScript debugger? Part of the problem is it's already difficult to get a modern JavaScript stack setup: TypeScript transpiles to JavaScript trasnpiles to different bundles that all get minified and backfilled and next thing you know your debugging a variable named i̷̪̱͆͛w̵̤̹̠͊̇̈x̷̨̻̽̍̄͆ on line 582956, and you ask your coworkers for help and none of them have ever used anything but console.log and are like ¯\_(ツ)_/¯ -- it was traumatic.
VSCode works well, both for command line stuff via node.js or Deno, and for (remote) browser debugging:
https://code.visualstudio.com/docs/typescript/typescript-deb...
https://code.visualstudio.com/docs/nodejs/browser-debugging
The JS-to-TS mapping is handled through source map (so you're 'debugging' the TS code, even though it's JS under the hood).
(also, in case you're not aware, browsers have a builtin debugger in their devtool panel, these also have source map support, but this may require some tinkering)
https://code.visualstudio.com/docs/typescript/typescript-deb...
https://code.visualstudio.com/docs/nodejs/browser-debugging
The JS-to-TS mapping is handled through source map (so you're 'debugging' the TS code, even though it's JS under the hood).
(also, in case you're not aware, browsers have a builtin debugger in their devtool panel, these also have source map support, but this may require some tinkering)
It's one of those things where 'just a puts/printf/console.log/prtln' always seems easier.
But all those tiny times add up, over years, decades. And eclipse the time of that afternoon+ spent on learning & configging debuggers in months already.
Don't be me, that senior dev who'd been promising himself for decades to really get down to learning and setting up gdbg or equivalent. And then, once invested, keeps thinking: "I should've done this years ago".
But all those tiny times add up, over years, decades. And eclipse the time of that afternoon+ spent on learning & configging debuggers in months already.
Don't be me, that senior dev who'd been promising himself for decades to really get down to learning and setting up gdbg or equivalent. And then, once invested, keeps thinking: "I should've done this years ago".
I've been using Rust on Windows, LLDB is just pain. Not being able to see content of enums is a show stopper, luckily VSCode has C++ debugger by Microsoft that works flawlessly.
FWIW CLion is worth the $$. For Rust and for C++. The debugger interface is fantastic, in both Windows and Linux. And also for WSL2 (run IDE in Windows but edit and run the binary inside your WSL2 container.)
I have it (CLion I mean), but didn't get it to run in WSL2. VSCode debugging is better but editor can get wonky.
I'm personally not a big fan of CLion. Too heavy, not as near customizable as (Neo)Vim, this damned `.idea` folder, constant re-caching. I tried to use it a couple of times, but always ended up going back to Vim.
I personally have never used a debugger in Rust. Logging and printing has typically been enough.
For those use cases where it is tough to see the output (tests, windows services, etc.) I wrote the `rdbg` set of crates. It is essentially identical to `dbg!` and `println!` macros, but delivers messages via a TCP socket to a simple command-line viewer (which can be on the same machine or remote). The design is such that it can be enabled and used the first time within a minute or two for "quick and dirty debugging". It can just as quickly be removed or turned into a no-op with a Rust feature.
Dependency: https://crates.io/crates/rdbg
Viewer: https://crates.io/crates/rdbg-view
EDIT: Apparently I need to update the README as I added the 'msgf' and 'valsf' macros that include auto-flush which is handy for short running programs where explicit flush doesn't work due to failing program/etc.
For those use cases where it is tough to see the output (tests, windows services, etc.) I wrote the `rdbg` set of crates. It is essentially identical to `dbg!` and `println!` macros, but delivers messages via a TCP socket to a simple command-line viewer (which can be on the same machine or remote). The design is such that it can be enabled and used the first time within a minute or two for "quick and dirty debugging". It can just as quickly be removed or turned into a no-op with a Rust feature.
Dependency: https://crates.io/crates/rdbg
Viewer: https://crates.io/crates/rdbg-view
EDIT: Apparently I need to update the README as I added the 'msgf' and 'valsf' macros that include auto-flush which is handy for short running programs where explicit flush doesn't work due to failing program/etc.
Looks handy. When you're writing certain types of programs going the opposite way can be useful.
For ex I recently added a /debug/:map_id endpoint to a server I'm writing that just returns format! ("{:#?}", state.maps.get(id)).
Obviously that'd be completely inappropriate in many cases, but for this one polling the current state via curl was quite handy.
For ex I recently added a /debug/:map_id endpoint to a server I'm writing that just returns format! ("{:#?}", state.maps.get(id)).
Obviously that'd be completely inappropriate in many cases, but for this one polling the current state via curl was quite handy.
I have written an extension for VSCode that replicates the repeat last test feature and lets you run the test under the cursor.
https://marketplace.visualstudio.com/items?itemName=fcoury.r...
https://marketplace.visualstudio.com/items?itemName=fcoury.r...
Only if you're debugging tests.
Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.
Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.
Is that true? I genuinly have no experience with it.
In their example they debug Firefox which I would consider a big application. Of course there are many levels above, and maybe you are talkning about tens of GB of memory usage?
In their example they debug Firefox which I would consider a big application. Of course there are many levels above, and maybe you are talkning about tens of GB of memory usage?
I haven't tried with FF personally, but the issue I have is that the traces are huge and reverse execution through memory-intensive codepaths takes a very long time, making the experience really slow. Or you can run a release build (with optimizations), in which case everything gets inlined, your asserts get nuked, and you're unable to inspect state well enough to figure out what's going on. In most cases, an ordinary debugger provides a better UX for me, but for the odd memory bug untraceable by normal hardware breakpoints in a traditional forward debugger, it comes in handy.
Please file an rr issue and tell us more about your situation.
Memory size and traffic shouldn't really be a problem. Multicore parallelism is the main problem. I've used rr with some very memory-hungry apps with good results.
Memory size and traffic shouldn't really be a problem. Multicore parallelism is the main problem. I've used rr with some very memory-hungry apps with good results.
That does not mirror my experience.
Can someone explain what I am looking at here with this? Genuine question.
Rust - Systems programming language (although used for more than just that today)
Neovim - Text editor popular for people who like terminals (forked from vim)
RR - Debugging tool that allows you to record failures/errors and play them back, facilitating easier debugging and reproduction (simplified: basically gdb on steroids)
All together (this repository) - A editor plugin for neovim users who use Rust, to use RR directly in neovim.
Neovim - Text editor popular for people who like terminals (forked from vim)
RR - Debugging tool that allows you to record failures/errors and play them back, facilitating easier debugging and reproduction (simplified: basically gdb on steroids)
All together (this repository) - A editor plugin for neovim users who use Rust, to use RR directly in neovim.
rr is basically black magic
It's a real shame that it can't be made to work on arm systems
Readme and latest release note says it now supports Neoverse N1 (ampere altra, graviton2 and maybe some cortex ones) as well as Apple M1.
Wow! That's amazing, i thought there were architectural issues that prevented it (something about interrupt timings sometimes increasing the number of instructions non-deterministically iirc).
Will have to check that out!
Will have to check that out!
AFAIK it works on AWS graviton.
It does seem to work on Apple ARM
Does it? Or is it running in Rosetta?
AFAIK it only works on Linux on bare metal M1 (so not on virtualized Linux in macOS).
Does this setup have nice visualizations of data structures? Can it show a Vec as a list of values or a HashMap as a list of (key,value)?
Oh no, this is just a wrapper for `RR`. Any visualization customization must be done via `~/.rr_gdbinit` and `~/.gdbinit`
This kind of things exist as a set of python scripts for C++.
It should be possible to do the same for Rust.
It should be possible to do the same for Rust.
Is there a similar tool for python? I don't like the DAP solution but prefer a gdb like python debugger :(
I hadn't realized there were alternatives to rust-lldb for debugging rust. I have some reading to do.
Funny thing is that thanks to rust compiler I never had a need to debug my code :-)
It may be true that this holds for issues related with out-of-bounds accesses or temporal safety errors, but nothing eludes your application to contain logic bugs. In fact, whenever the application is big enough and you spot a logic error, the debugging burden is still there. Good part is that the debugging utilities for C/C++ are still helpful for Rust programs.
Usually, understanding the type system changes you code/thinking about business logic too. That stems from the habit of thinking about how to check your expected behaviour before implementing it.
Needing a debugger still happens once in a while, but languages/projects that are well adapted to this way of thinking really make it extremely uncommon.
Needing a debugger still happens once in a while, but languages/projects that are well adapted to this way of thinking really make it extremely uncommon.
So true. With proper type driven design you basically don't need a debugger anymore.
But I still find it helpful when you need to check what's wrong in other people's code, since they might not design with types like I do.
But I still find it helpful when you need to check what's wrong in other people's code, since they might not design with types like I do.
I find myself using the debugger to explore complex types created by procedural macros. You can use cargo to expand them andnpoke around, or dump the structure to debug if it derives it, but sometimes the debugger seems easier.
Also it can help find why something three crates deep into your dependency tree panicked.
Also it can help find why something three crates deep into your dependency tree panicked.
Debuggers aren’t only for debugging. They’re also for exploring an unfamiliar codebase, speeding up the process of familiarising oneself with it.
serial_dev(9)
EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.