Live data from Hacker News

Rust, RR, Neovim: A perfect debug combination

github.com

81–90 of 102 posts

Re: Rust, RR, Neovim: A perfect debug combination

#81

Earlier quoted context omitted.

This is unproductive. I have significant criticisms of the policy draft, but this is not helpful.

In 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.

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.

Re: Rust, RR, Neovim: A perfect debug combination

#82

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…

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!

Re: Rust, RR, Neovim: A perfect debug combination

#83
post #37

Earlier quoted context omitted.

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.

Re: Rust, RR, Neovim: A perfect debug combination

#84

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.

Look into nvim-dap and the ecosystem around it.

Re: Rust, RR, Neovim: A perfect debug combination

#85
post #31

[flagged]

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.

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.

Re: Rust, RR, Neovim: A perfect debug combination

#86
post #37

Earlier quoted context omitted.

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.

Re: Rust, RR, Neovim: A perfect debug combination

#87
post #64

Earlier quoted context omitted.

I just hope Rust won't end up being forked tho. We had such an amazing community around it...

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…

Rust->Roost

Cargo->Corvo

And from there on we have a ton of bird-related puns for naming.

Re: Rust, RR, Neovim: A perfect debug combination

#89
post #66
post #64

Earlier quoted context omitted.

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…

Cr st contains the word R st, which is illegal so you can't do that.

does it really work that way though? Not sure if I can tRust this assertion.

Re: Rust, RR, Neovim: A perfect debug combination

#90
post #26

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…

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.

Post reply on HN