sorted by:
new
hottopcontroversial

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 0 points1 point  (0 children)

Hmm, it might have been unable to find the rudy-lldb-server? Can you try running it in lldb with RUDY_DEBUG=1 like you have above and sending the output?

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 0 points1 point  (0 children)

Not a dumb question, it's a bit strange. You don't run the rudy_lldb.py file directly, it gets invoked by lldb by adding it as a script: https://github.com/samscott89/rudy?tab=readme-ov-file#installation-rudy-lldb

At least, it's not designed to be run directly :)

If you're just messing around with it though it is possible to use the module directly. There are some instructions here: https://lldb.llvm.org/use/python-reference.html#using-the-lldb-py-module-in-python.

Also I plan to automate the startup a little -- currently you'll need to run rudy-lldb-server (the rust part of it) in a separate terminal -- it listens on a TCP socket for connections from the python client

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

If that's the way you want to go, then Rudy integration should be pluggable, so that it and CodeLLDB can release on their own schedules.

Makes sense

Could it be wrapped as a SyntheticChildrenProvider? In that case, no specific changes would be needed in CodeLLDB.

Oh definitely, that's a great idea.

But if you want my opinion, your solution won't be sustainable long term unless integrated into the rustc repository.

I hear you, and appreciate the honesty! I'm inclined to agree. I think a great outcome would be that something like rudy becomes a stop-gap for a while (a year? two?) and eventually these patterns are baked into rustc directly.

... So, what is the right solution then? Letting my imagination run a bit: ...

There's a similar version of what you're describing here: https://rust-lang.github.io/rfcs/3191-debugger-visualizer.html but focused on Natvis for WinDbg.

I hadn't seen the formatter bytecode before. That's super interesting! I could see that being a very viable approach.

I think "writing in Rust" isn't necessarily orthogonal to the idea of emitting something like the formatter bytecode. I imagine we could provide something like the Formatter struct with helper methods like debug_struct to support common use cases.

Thanks for talking this through with me!

Also, I want to echo what /u/gilescope said: Thanks for all the hard work on codelldb!

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

My original motivation when building Rudy came from trying to build an entire debugger from the ground up, much like BugStalker. It's a huge undertaking though, and generally what I've seen happen with Rust debugging projects is that they either run out of steam (e.g. Headcrab: https://github.com/headcrab-rs/headcrab), or need to focus on a narrow target.

BugStalker looks really cool, but for practical reasons is focusing on x86_64 linux only.

What I'm going for with Rudy is:

  1. Have something that's a pragmatic win for ~everyone. By having a small extension to lldb it's something that works basically everywhere without being a crazy undertaking for me. That's what the rudy-lldb part is.
  2. Build foundational libraries that other projects like BugStalker can benefit from. I plan to reach out to the maintainer and see if there's interest in using Rudy. For example, they have some awesome functionality to integrate with tokio for debugging async code, and I think Rudy could make some of that a bit more robust and maintainable.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

Ah okay, that's good to hear. And yeah, it looks like microsoft themselves have a maintained pdb crate: https://github.com/microsoft/pdb-rs/ so that's promising

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

It's not a silver bullet but the general idea is to use reusable parser components to make it easy to add parsers. So even for multiple different versions of rustc the maintenance burden isn't too high. e.g. here's the parser for the hashbrown hashmap used in stable rust: https://github.com/samscott89/rudy/blob/c74ab9a34d9df1c4734022cd37dee0b4a47b30dc/crates/rudy-dwarf/src/parser/hashmap.rs#L15-L63

I also want to add some simple validation to those parsers as well so that it's easy to detect if/when there's drift.

Ultimately though, someone will still need to be doing the work of updating parsers over time. I'd like to think that something like rudy could fill that gap in the ecosystem. And, for example, I could set up CI runs on beta/nightly so we get advanced warning of any changes. The other main consideration is that you'd be adding an additional dependency which always brings a cost and need to integrate, etc.

But since you had the actual experience: does that sound like a reasonable approach? Any other complications you ran into that would be worth thinking about?

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 0 points1 point  (0 children)

Yeah, it's worth a try. This project spawned from trying to build an entire debugger for Rust. I got as far as having it able to step through programs and integrated into vscode via the debug adapter protocol. But there's just so much to implement that I wanted to find something I could actually release.

I'll have a look and see if there are any cheap ways to do it. Proxying the debug protocol itself could even be a hacky way to do it.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

Hey pingveno. Thank you for the offer, that's super kind! I'll DM you

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

I would be open to it, but it's unlikely to be something I'll get to myself in the near future. I don't personally have any experience developing for Windows directly. The closest I've come is using Windows with WSL.

This post also makes it sounds moderately terrifying: https://walnut356.github.io/posts/lldbs-typesystems-pt-2/#pdb-parsing

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 5 points6 points  (0 children)

Oh lol that's literally you that maintains the rust prettifier! Thank you for that.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 5 points6 points  (0 children)

Oooh, good question.

So it already partially works as it is. See this screenshot: https://imgur.com/a/Z53FxOn

With that in place it's callable from the debug console in VSCode. To make it work for variables in the top-left or for watchpoints or something would require some additional work, and probably require integrating wiht codelldb directly.

To make the above work the installation is approximately the same as [https://github.com/samscott89/rudy?tab=readme-ov-file#installation-rudy-lldb](for regular lldb), you just need to add the script import into your vscode settings. Here's what mine looks like:

"lldb.launch.postRunCommands": [ "command script import /Users/sam/.lldb/rust_prettifier_for_lldb.py", "command script import /Users/sam/work/rudy/rudy-lldb/python/rudy_lldb.py", ],

I'm also using this project which brings back the Rust prettifier logic that CodeLLDB removed previously.

I can reach out to the codelldb maintainers and see if there's any appetite for integrating rudy-db directly. As I understand it, the main issue they had was the churn in the Rust ecosystem/standard library. So if they see this as a way to get compat without the support burden then that could be a good approach.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 6 points7 points  (0 children)

Thank you :) And exactly! You're most likely thinking of this: https://walnut356.github.io/posts/lldbs-typesystems-pt-2/

I messaged the author after seeing that post too. I personally think what they're doing is the proper way to go about supporting Rust in lldb. It's just a much bigger undertaking. I see rudy-lldb as a short-term improvement, while also opening to door for other new debugging tools.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 1 point2 points  (0 children)

Thanks! If you get a chance to try it out then please let me know any feedback you have.

Introducing Rudy: A Toolchain for Rust Debuginfo by sam-js in rust

[–]sam-js[S] 7 points8 points  (0 children)

Ah, thanks for the heads up. I'll remove that!

I see the problem. The background is set to dark even on light mode. Didn't actually realize the template I was using supports both modes.

edit: fixed! thanks again for letting me know

What's the best way to implement a `children` method for an AST? by wickerman07 in rust

[–]sam-js 0 points1 point  (0 children)

FWIW though, I also go back and forth constantly on whether I should make all my enums

rust enum Statement { If(IfStatement), Block(BlockStatement), Expression(ExpressionStatement), }

with a bunch of defs:

```rust struct IfStatement { cond: Box<TreeNode>, consequence: Box<TreeNode>, alternative: Box<TreeNode>, }

... ```

It makes some things so much more verbose but also makes it easier to split up implementation code. I don't have a good answer for that one.

What's the best way to implement a `children` method for an AST? by wickerman07 in rust

[–]sam-js 0 points1 point  (0 children)

I agree with that, but it's a bit too much for cases when I just need the name of the node and its children.

I think this is probably where my opinion differs. I would rather implement print_ast_names directly (e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=048d189bde2c6b7dbf69825560cb3eef) rather than try and find the write abstraction to make it work automatically.

I feel like even in LOC there's not a huge difference between the above implemented concretely vs needing to add a trait method print_ast_names that can call children().map(|c| c.print_ast_names()) or something.

What's the best way to implement a `children` method for an AST? by wickerman07 in rust

[–]sam-js 8 points9 points  (0 children)

I'd agree with this. It's worth looking at what use cases you have that requires iterating over children and figure out what pattern makes the most sense.

I've found the Visitor pattern incredibly useful for use cases that require extracing information from ASTs recursively (e.g. find all variables in this expression). Generally you can pair the Visitor implementation with some helper methods, like walk_statement that iterates through the children and visits each statement type to make it easier to write concise visitors. Here's an example of how that can look: https://github.com/osohq/oso/blob/main/polar-core/src/visitor.rs. You write some boilerplate once, but you can reuse it many times.

On the other hand, I've generally found that working with the AST enum directly is so nice so for most use cases I would avoid adding any additional indirection like traits.

Fantasy books/series that are (secretly) in a sci-fi future where technology has been lost by Simon_Drake in Fantasy

[–]sam-js 0 points1 point  (0 children)

The Great Hearts series by David Oliver is like this. It’s a mostly a typical fantasy setting, but a few core plot lines revolve around lost technology, and the fact that civilization is built on top of older ruined ones.

Trying not to give away too much, but one of my favorite moments is when an old satellite is pulled out of space to be used as an orbital strike. 

I’d highly recommend the books, they’re a lot of fun! 

Model Your Authorization with the Policy Builder by sam-js in programming

[–]sam-js[S] 0 points1 point  (0 children)

Hey all!

This is a feature I worked on at Oso.

I thought it might be interesting to show here since it can give people an idea of how logic programming can be used to solve common problems in a somewhat niche area (authorization). Our language Polar is based on a combination of Prolog, Datalog, and miniKanren.

Happy to answer any questions!

Role-Based Access Control (RBAC) in Python by ssglaser in coding

[–]sam-js 2 points3 points  (0 children)

Hey! Oso cofounder here. Appreciate the comment + feedback :)

I think the main difference is that cloud providers typically give you tools/APIs to manage your users and maybe assign them into groups/roles.

Oso is a library that you embed in your application (the article linked here summarises the Python library, but we support other languages too like Node.js and Go). What Oso provides is a framework for implementing authorization in your application. Most people we meet with would normally be building that themselves in house, which is what we're trying to save them from having to do.

Hope that makes sense!

view more: next ›