5 ms·
#[debug_visualizer] seems like it will be very useful. One of the current issues with Rust (and a place where C++ is still better) is debugging. Granted, I end
by armchairhacker 3y ago
#[debug_visualizer] seems like it will be very useful.
One of the current issues with Rust (and a place where C++ is still better) is debugging. Granted, I end up needing to debug Rust code much less often than C++ code, but it would still be nice to actually call rust functions in IntelliJ (and it seems there's limited support in gdb and lldb), and view data-structures like maps opaquely instead of just their complex internals.
- mark_undoio 3y agoI'm a debugger specialist, not a Rust specialist - but I'm surprised the experience of viewing data structures is not better for you. What platform / debugger are you on? I'd expect the GDB pretty-printers (which from the article it looks like Rust has been shipping by default for the standard library) to be taking care of this relatively well - e.g. looking at https://github.com/rust-lang/rust/pull/72357 https://github.com/rust-lang/rust/pull/72357 it appears that `HashMap` and `HashSet` have printers. (Raw C++ data structures without some form of pretty printing are also incomprehensible for normal development - and I'd be surprised if third party libraries were particularly good at shipping pretty printers, though I may be wrong!)
- JakobH 3y agoI love debugging, how do I go deeper in the art of debugging?
- jackbracken 3y agoRelease more bugs
- wiz21c 3y agoper-bugging or re-bugging is the way
- mark_undoio 3y agoIf you use GDB, I recommend checking out the official documentation: https://sourceware.org/gdb/current/onlinedocs/gdb.html/ https://sourceware.org/gdb/current/onlinedocs/gdb.html/ It's quite hard work sometimes - there's a lot in there - but the capabilities available are amazing and it's well worth nosing around. I also recommend just hitting TAB a lot and seeing what commands are suggested. Then use the "help"command to find out more. My employer also hosts some articles that digest some knowledge we've gained into a more palatable form: https://undo.io/resources/gdb-watchpoint/ https://undo.io/resources/gdb-watchpoint/
- pkolaczk 3y agoWhy is it such a problem? Can't debuggers use `Debug` trait if defined? Or do they already?
- mark_undoio 3y agoI'm not sure they'd do so automatically but, given the ability to call functions (which it sounds like, for Rust, GDB lacks) it should be possible to plumb together. But debuggers like GDB have built in infrastructure for expressing how to display structured, potentially nested data structures - it's built for the purpose and powerful, so it's nice to bring it to bear if you've not already got something equivalent in they program. The other important thing is that the debugger's pretty printers work on a core file, without needing a live process.
- iudqnolq 3y agoIf you hunt around for the debugging working group and related issues there's some interesting reading on exactly that. (I'm on my phone and it's been a while since I looked into this). The issue is that a debugger generally can't assume your code doesn't have bugs. This would make bugs around state in Debug impls much more complicated, for example. This can creep in under a few layers of indirection - ultimately calling a function that gets the value of an interned string would be one example.
- armchairhacker 3y agoI’m using the IntelliJ debugger. It’s gotten much better. Primitive structures which are defined by their fields and builtins like `Vec`, `HashMap`, `String`, are handled good. But structures in library or user code which use “raw” and other non-trivial representations, but provide an opaque safe API, I can only introspect the non-trivial fields. This annotation is exactly what those custom structures need.
- diarrhea 3y agoI had wondered about this but am too green to get it. Is this the reason that in VSCode, when debugging, most variables show as basically raw bytes instead of something useful? That was very surprising to me and made debugging difficult. In Python I’m used to it just working.
- tempodox 3y agoIt's not VSCode, it's the plugin for the language you're using. And let's face it, most of them are rather shitty.
- TillE 3y agoC++ debugging on VS Code is pretty good in my recent experience (macOS / lldb), though not as full-featured as Visual Studio.
- 0cf8612b2e1e 3y agoJust to give some acknowledgment, the VSCode Python debugger is really great. I was a longtime print debugger, but the the tooling makes the process so straightforward to use, that it is now the only way I can operate.
- jauntywundrkind 3y agoIn this thread it is revealed that all (almost all) Rust devs are printf() not breakpoint devs, and why. This debugger_visualizer attribute does seem like a really cool capability. It's about embedding debugging scripts for debug tools, in your rust source code; couldn't be more direct! https://doc.rust-lang.org/nightly/reference/attributes/debugger.html#the-debugger_visualizer-attribute https://doc.rust-lang.org/nightly/reference/attributes/debug...
- 3836293648 3y agoNext step rustc can generate python pretty printers itself? At the very least I hope some crate can do that with a build script eventually
- masklinn 3y agoIt’s been shipping printers for a few years: https://github.com/rust-lang/rust/pull/72357 https://github.com/rust-lang/rust/pull/72357 Though that “only” dates back to 2020 so people with experience older than that would have had a worse experience, and may have ended once bitten twice shy as a result never noticing the improvements.
- 3836293648 3y agoNo, I meant generate printers for custom types, not ship printers for stdlib types.
- gnulinux 3y ago> In this thread it is revealed that all (almost all) Rust devs are printf() not breakpoint devs, and why. I'm a non-proud printf() debugger. I understand that if I get use to debugger debugging it'd be in many ways better. The thing is, it's an entirely different paradigm of development, and paradigm shifts can come with significant productivity cost. Of course, learning, growing and getting comfortable with new/different tools is part of being a software engineer.
- 3y ago
- dcz_self 3y agoYou can use QtCreator that way already: https://dorotac.eu/posts/debugging_rust/ https://dorotac.eu/posts/debugging_rust/ You can view the data structures opaquely even though the functions are written not in Rust, but in Python. One of the difficulties is that the Rust compiler will emit different debugging info depending on the compiler version. Perhaps I should look into how gdb deals with that (if at all). Patches welcome.
- tempodox 3y agoWow, those long lines that don't break are a special kind of horror, in an article from 2023 no less. Am I glad there's Reader View. But the contents is interesting. Bookmarked.
- dcz_self 3y agoWhich lines do you mean? This source code part? > $1 = alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x5555555abaa0}, _marker: core::marker::PhantomData<u8>}, cap: 3, alloc: alloc::alloc::Global}, len: 3}} On my browser, everything breaks according to the browser's window size (I set white-space: pre-wrap).
- riquito 3y agoDon't know about the long lines, everything wraps well to me, but on mobile (firefox) the zero padding on the left side is brutal. The gigantic comment section at the end is a small hindrance, while the right sidebar kills 30-40% of the page width (on mobile), which is annoying on longer articles. And thanks for the content :-)
- lolrustwtf 3y ago[flagged]
- tempodox 3y agoI've checked and saw that the site renders OK in Firefox, but in Safari the layout is totally broken. I guess it's a bug in Safari.
- j-pb 3y agoI feel that Rust could really profit from an interactive REPL like notebook like Julias Pluto. It makes visualisations during development and their integration with documentation so seamless.
- jo1gi 3y agoCheck out https://github.com/evcxr/evcxr https://github.com/evcxr/evcxr
- kibwen 3y agoYou can do this using the evcxr kernel for Jupyter: https://github.com/evcxr/evcxr/blob/1a2d6c40c467267801c7382edfa28028f99bbd9a/evcxr_jupyter/samples/evcxr_jupyter_tour.ipynb https://github.com/evcxr/evcxr/blob/1a2d6c40c467267801c7382e...
- j-pb 3y agoSadly jupyter is a very different experience to Pluto. The latter is similar to ObservableHQ (it even reuses part of the runtime afaik). So you don't have to manually evaluate cells, but they are evaluated based on the computations dataflow graph. Additionally it allows for very interactive visualisations and data input.
- Sharlin 3y agoI wonder why there's no protocol that simply tells the debugger that to pretty-print type X, it should call function Y in the debugged executable itself (using normal C ABI and some agreed-on calling convention). Then, for example, rustc could just generate simple glue functions that delegate to `Debug::fmt` in order to get formatting that the programmer is already familiar with or indeed has implemented themselves. (Some precautionary measures would of course be required to avoid infinite recursion and similar. But the same issues already exist in debuggers that allow pretty-printers to eg. run arbitrary python code. To avoid a pathological or buggy formatter breaking either the debugged program or the debugger itself, it might be best to execute the formatter in a separate child process.)
- progbits 3y agoOf course those would have to be side-effect free, or somehow "sandboxed". It seems like debug printers should be pure functions but you never know what sort of weird stuff people do.
- eklitzke 3y agoEven just formatting something as a string will likely require memory allocation for all but the most trivial cases, and memory allocation is not side effect free.
- yencabulator 3y agoTake the already-frozen process, make a clone with CoW memory, switch the clone to a sandbox that forbids most syscalls, run the pretty-printer function(s) in the clone process, abort if pretty-printing takes too long (hung on lock, infinite loop due to corrupt data structure, etc)? Lots of devils in the details, but that sounds possible.
- mark_undoio 3y agoYou're quite right, it's very possible. The product I work on does pretty much exactly this - we need it because our debugger time travels and we can't allow history to be altered! I wrote some words here: https://medium.com/time-travel-debugging/calling-functions-in-the-past-4bb03bdc124d https://medium.com/time-travel-debugging/calling-functions-i... But it's basically exactly what you propose. We didn't sandbox the syscalls but you could do that too.
- dannymi 3y ago>but it would still be nice to actually call rust functions I agree. > data-structures like maps opaquely instead of just their complex internals. Works for me: use std::collections::HashMap; fn main() { let mut m = HashMap::<String, u32>::new(); m.insert("a".to_string(), 5); m.insert("b".to_string(), 3); println!("Hello, world!"); } $ rust-gdb target/debug/t1 (gdb) b 7 (gdb) r (gdb) print(m) $3 = HashMap(size=2) = {["a"] = 5, ["b"] = 3}
- mr_00ff00 3y agoSlightly off topic, but is IntelliJ the best IDE for rust? I would have assumed Clion
- eulgro 3y agoMore features are enabled in CLion so you're right.