7 ms·
Rust, RR, Neovim: A perfect debug combination
- n8henrie 3y agoI hadn't realized there were alternatives to rust-lldb for debugging rust. I have some reading to do.
- Aiedail 3y agoIs there a similar tool for python? I don't like the DAP solution but prefer a gdb like python debugger :(
- thegeomaster 3y agoOnly if you're debugging tests. Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.
- planede 3y agoThat does not mirror my experience.
- ObscureScience 3y agoIs 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?
- thegeomaster 3y agoI 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.
- roca 3y agoPlease 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.
- baq 3y agorr is basically black magic
- mijoharas 3y agoIt's a real shame that it can't be made to work on arm systems
- icholy 3y agoAFAIK it works on AWS graviton.
- guipsp 3y agoIt does seem to work on Apple ARM
- 3836293648 3y agoDoes it? Or is it running in Rosetta?
- hobofan 3y agoAFAIK it only works on Linux on bare metal M1 (so not on virtualized Linux in macOS).
- natrys 3y agoReadme and latest release note says it now supports Neoverse N1 (ampere altra, graviton2 and maybe some cortex ones) as well as Apple M1.
- mijoharas 3y agoWow! 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!
- JestUM 3y agoInvesting in a good debugging tool and knowing your way around using it well, makes all the difference.
- berkes 3y agoIt'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".
- Buttons840 3y agoAfter 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.
- liveoneggs 3y agohttps://stackoverflow.com/questions/34087143/load-separate-sourcemap-file-in-chrome-dev-tools https://stackoverflow.com/questions/34087143/load-separate-s...
- flohofwoe 3y agoVSCode works well, both for command line stuff via node.js or Deno, and for (remote) browser debugging: https://code.visualstudio.com/docs/typescript/typescript-debugging https://code.visualstudio.com/docs/typescript/typescript-deb... https://code.visualstudio.com/docs/nodejs/browser-debugging 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)
- colesantiago 3y agoCan someone explain what I am looking at here with this? Genuine question.
- capableweb 3y agoRust - 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.
- RcouF1uZ4gsC 3y agoDoes 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)?
- renox 3y agoThis kind of things exist as a set of python scripts for C++. It should be possible to do the same for Rust.
- zteppenwolf 3y agoOh no, this is just a wrapper for `RR`. Any visualization customization must be done via `~/.rr_gdbinit` and `~/.gdbinit`
- sp0ck 3y agoFunny thing is that thanks to rust compiler I never had a need to debug my code :-)
- carlmr 3y agoSo 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.
- galangalalgol 3y agoI 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.
- andsanmar 3y agoIt 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.
- pyrale 3y agoUsually, 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.
- yakubin 3y agoDebuggers aren’t only for debugging. They’re also for exploring an unfamiliar codebase, speeding up the process of familiarising oneself with it.
- DixieDev 3y agoAnyone got other useful tools for debugging within (neo)vim? Just seamlessly putting down breakpoints, stepping through code execution, and getting a fully fledged debugging UI experience (a la Visual Studio or Remedy BG)? This is possibly the only thing I miss from developing on Windows, and it's a shame! EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.
- 9029 3y agoI'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
- huseyinkeles 3y agonvim-dap is what’s being used the most. https://github.com/mfussenegger/nvim-dap https://github.com/mfussenegger/nvim-dap
- salicideblock 3y agotermdebug (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.
- BaculumMeumEst 3y agoThe 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.
- davidkunz 3y agoI 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 https://github.com/mfussenegger/nvim-dap [2]: https://github.com/David-Kunz/jester https://github.com/David-Kunz/jester
- serial_dev 3y ago[flagged]
- NoraCodes 3y agoThis is unproductive. I have significant criticisms of the policy draft, but this is not helpful.
- serial_dev 3y agoIn the original tweet, they say: > we invite you to review (..) and share any feedback (...). Your responses will help us ensure the Rust Trademark Policy is useful for all! I'm bringing attention and visibility to the proposal and hopefully help the foundation receive valuable feedback from more people.
- hobofan 3y agoYes, and you are doing so on a post about a random project written in Rust, which doesn't have anything to do with the policy proposal that just happens to be under review during the same time. This just diverts attention away from the original project that was posted here. Are you going to post the same thing under every project written in Rust during the next weeks?
- NoraCodes 3y agoSure. They provide a form for that, and there are discussion threads in many places. Commenting vitriol on random projects that are, in fact, totally unrelated to the Rust Foundation is not productive.
- deleted 3y ago[deleted]
- serial_dev 3y agoI'm sorry if you took my comment as vitriol, it's not meant to be that, it was a light-hearted joke. The proposal was very disappointing to me, and it has been on top of my mind when I browsed HN this morning, so when I saw a cool project that -- if some of the sections of the proposal go through -- would violate Rust's Trademark Policy, I thought it'd be acceptable to bring that up (and still think that). I believe raising awareness to issues with the proposal is productive, and hopefully at least some people here on HN decided to leave feedback in the Rust Foundation's form, so that as little of the non-sensical paragraphs stay in the final document as possible.
- nu11ptr 3y agoI 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 https://crates.io/crates/rdbg Viewer: https://crates.io/crates/rdbg-view 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.
- iudqnolq 3y agoLooks 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.
- favadi 3y agorr is pure magic! I wish that it is available on macOS.
- wuming2 3y agoIsn’t Apple known for integrating DTrace in Leopard back in 2007?
- vrglvrglvrgl 3y ago[dead]
- timcavel 3y ago[dead]
- fcoury 3y agoI 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.runst https://marketplace.visualstudio.com/items?itemName=fcoury.r...