Anyone 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.
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.
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!
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.
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
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!
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).
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 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.
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.
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".
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'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.
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.
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?
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.
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.
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).
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.
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.
I started watching [3]. I have no stakes in this, but a lot of stuff I should be enraged about... I'm just not? Doesn't look fundamentally different to Debian or Firefox trademark policies.
I guess it is an abrupt change in trademark enforcement for Rust.
Just ignoring that it is fundamentally gross and pointless, which some people don't understand somehow, consider the practical implications. I can't casually make a youtube video or blog article teaching about Rust without worrying about trademarks if I use the word. Hundreds of rust libraries have Rust in the name and would be in violation of this policy the second it changed, etc.
IANAL but it's important to understand what is and isn't enforceable regarding a trademark. I can write about Debian, Firefox and Rust without an explicit disclaimer that I'm not endorsed by their corresponding foundations if it's obvious in context. I can also write about Coca-Cola, Nintendo and Oracle in a similar manner. It doesn't matter what any of the trademark policies say.
I wouldn't worry about writing on rust, the language. It certainly sucks that the language, the compiler and the foundation share the same name. But it probably sucks for the foundation as well regarding enforcement.
I don't get why people like to put the name "rust" in crate names, unless they write tools that work with the language (linters, auto-formatters), it just feels redundant.
> I don't get why people like to put the name "rust" in crate names, unless they write tools that work with the language (linters, auto-formatters), it just feels redundant.
In crate names it is redundant. As a project or domain name it isn't.
It feels redundant when you search for it on crates.io/lib.rs, it's not redundant when you search for it or talk about it anywhere else (Google, Twitter, GitHub, real life, events, conferences).
The difference is that the R-word foundation goes above and beyond their (reasonable) interests of protecting their brand/identity. This is not about trying to fend off people impersonating as "Official Rust..." or "Rust Foundation ..." but tries to stop you from even having the _word_ "rust" or "cargo" in your domain name.
Also there is some ideology-driven nonsense which is impossible to enforce but that does not stop them from the attempt to treat their community condescendingly like that.
From Mozilla's trademark policy:
If you want to include all or part of a Mozilla trademark in a domain name, you have to receive written permission from Mozilla. People naturally associate domain names with organizations whose names sound similar. Almost any use of a Mozilla trademark in a domain name is likely to confuse consumers, thus running afoul of the overarching requirement that any use of a Mozilla trademark be non-confusing. If you would like to build a Mozilla, Firefox Internet browser or Thunderbird e-mail client promotional site for your region, we encourage you to join an existing official localization project.
From Node Foundation's trademark policy:
You need permission to register or use a domain name that contains a Node.js mark in it. Please don’t
register a domain that looks or sounds similar to a Node.js or includes a misspelled Node.js mark as that
can confuse community users
From Debian's trademark policy:
You cannot use Debian trademarks in a domain name, with or without commercial intent.
Don't look fundamentally different? May I'm missing something but I have not seen a single tutorial or article about something Debian or Firefox that starts that with the disclaimer "This is not affiliated with the official Debian etc" Like the R** Foundation is asking to.
Let's not even mention the unreasonables of not being able to name package writen in R** as package-rust.=, somethng that no other programing language forbids as far as I'm aware of.
Go ahead and write a tutorial about Rust without a disclaimer. This is totally non-enforceable, trademarks can't limit talking about the thing. As long as it's clear that you are not representing them, it's fine, even without a disclaimer as described in their policy.
IANAL and this is not legal advise, but I wouldn't sweat about it. This same thing applies to any other trademark too, be it Debian, Firefox, Nintendo or Coca-Cola.
Yeah, it's such a weird outrage. I went and compared it to the node foundation one and its very similar. Some of the other issues he has are kind of deranged. I'm glad the Foundation want Rust meetups to be firearm free. Good Lord. Is that really worth getting so upset about?
I've got a couple small things I don't like, but once again, it seems to be right in line with other open source trademark policies. I just had never looked closely at them before
> I'm glad the Foundation want Rust meetups to be firearm free. Good Lord. Is that really worth getting so upset about?
I strongly, STRONGLY, agree with their political stance. However, I find their forcing their politics down people's throats extremely concerning. Keep in mind that you also have to seek approval to use the word Rust (I am not affiliated with the Rust Foundation), which means that they could disallow it merely because they don't like you or what you stand for (which the prior rule shows a tendency to do). Call me crazy, but I fail to see how that's in any way progressive (yes, given even the tolerance paradox) - especially given that the other people and beliefs will be running the Rust Foundation at some point in the future.
This isn't a matter of "keep your politics out of tech," it's a matter of bringing in politics being actually harmful to the community.
Ending gun violence in America is the responsibility of voters and lawmakers, not the Rust Foundation.
So a "Ferris and Firearms" meetup is simply not allowed to occur. That sounds extremely inclusive.
This also implies that organizers would have to go through the effort AND cost (because you are only allowed to collect fees for food and drinks) of doing entry control or a meetup.
Yes, but for a different reason. From the document's section on User Groups
>The main focus of the group is discussion of and education about Rust software;
It's a programming language, not a lifestyle brand. Not everything needs to be dragged down into US-centric culture wars. It's good that they don't want to dilute the brand and are keeping it focused on the software. If you want to go to the range with a group there are tons of meetups for that. I don't know why you would want to make one based around a programming language.
Amazing, you get lawyers involved and they proceed to immediately alienate a large number of people in the very community the foundation is meant to nurture. It's a pretty good example of an own-goal by the rust foundation. Fire the idiot lawyers and draft a much toned down, much restricted version of this.
For the sake of the argument, let's imagine that you fork rust. You'd have to come up with another name for it right?
But since the name it's the only thing that is getting in the way with this new (draft) policy, you wouldn't really have to fork the language and the tooling etc. All you have to do is to just use this new made up name in place of rust (and similarly for cargo) and you've achieved independence with a fraction of the cost.
E.g.
Rust -> Crust
Cargo -> Embargo
"Hey, here's a quick Crust tutorial: check out this git repo and run: embargo build"
In the last few hours, I've been thinking about how much effort would it really be to fork it, Iceweasel style, and IMO even just forking, renaming would be a pretty significant effort (if done right).
Fork the web page, you cannot just replace Rust with ALTERNATIVE, because ALTERNATIVE is not used at npm, you don't have a Discord community, and you don't have books and videos, and no foundation. All those changes would need to be kept up-to-date.
You could also have a new file type, .altrs, while you still want to be able to use Rust's files. Same goes for tooling, supporting websites such as crates.io: you might want your own, but you also want all the tools to work with the Rust crates. With the new file type, you need people to know how to change their config to treat .altrs files as regular .rs files.
.. though I don't know how much of it would be really necessary if all you want is to not violate their new policy, so it's more of a thought experiment at this point.
Even that point is ridiculous. Ferris was released from the original author as "public domain" property. It is not a "gift" or "compromise" of the foundation, they would not be able to restrict Ferris' usage, even if they wanted to (and after reviewing their document, I am 100% they would love to)
Yes, 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?
Sure. 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.
I'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.
I expect them to change things, too: they will remove 1 or 2 of the most egregious stuff and will leave in the rest, and then celebrating that they listen to the community. I hope I'm wrong, but moves like this really irk me and they shutter the built-up trust immediately.
Sanctioned by the foundation. According to the February 2023 Rust Foundation Board meeting notes (https://foundation.rust-lang.org/static/minutes/2023-02-14-m..., Paragraph 7.), the board reviewed and believes this is fine, this has been in discussions for months.
It is based on the results of a previous survey: https://old.reddit.com/r/rust/comments/wkv8gv/rust_foundatio.... Looking at where we are now it's safe to assume that not all community feedback was given the same level of care, the (vocal) community is against this, as am I.
EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.