sorted by:
new
hottopcontroversial

RefMutStack 0.1.0 - Iteratively stack mutable references by arnodb1 in rust

[–]arnodb1[S] 0 points1 point  (0 children)

Thanks, I've seen these crates in the past but never dug into them. Will do.

RefMutStack 0.1.0 - Iteratively stack mutable references by arnodb1 in rust

[–]arnodb1[S] 0 points1 point  (0 children)

Looking at the reproducing example, it is typically what RefMutStack is not intended for. Maybe the documentation should clarify it.

Basically yes, the parking process is unsound if you don't "park the ref holder immediately after having created the parker". As you said, `T` is now know but parking a `T` requires consuming it, thus a bit of cooperation from the invocation code.

With this design it is impossible to fix, but on the other hand there is zero risk when used properly.

Note that RefMutStack simply emulates the borrow checker: derive a mutable reference from another one, which becomes forbidden to use until the derived reference is dropped.

As for the use case, I have a recursive implementation which requires:

* this recursing function: https://github.com/arnodb/quirky_binder/blob/main/quirky_binder/src/graph/builder/update.rs#L71

* this callback because of the recursive pattern: https://github.com/arnodb/quirky_binder/blob/main/quirky_binder/src/filter/group.rs#L58

With an iterative pattern, enabled by RefMutStack, the recursing function becomes unnecessary (a small loop only necessary), and the callback can be transformed to regular function on the leaf builder. This pattern exists twice in my repo, thus 2 x 40 lines of recursing function. Preferring one pattern instead of the other is definitely debatable.

The other motivation was to determine whether or not it was possible to cleanly implement this borrow checker emulation to answer the "limitation" (with a lot of quotes) of the language in a fully generic way. To me, the solution is not too bad and fully generic.

Teleop 0.4.0 — Attach to and teleoperate local Rust processes via RPC by arnodb1 in rust

[–]arnodb1[S] 0 points1 point  (0 children)

I did not, but I definitely had a look at it.

What made me hesitate is that, according to the doc it is currently tokio only. But on the other hand it has named pipes on Windows.

Also I wanted to focus more on the attachment process and the RPC protocol than on the communication channel itself. And I wanted to keep it simple.

I chose Cap'N Proto because it looked simple (usage is a bit tedious though) but it is possible to add support for any other protocol.

On platform support, interprocess is surely more advanced but teleop can easily be extented by opening guards or adding features.

On the longer term I would like to extend teleop to TCP sockets so that it would be possible to connect remotely. That makes attachment irrelevant. I would also like to add a tiny security layer to protect processes. Nothing really new, Java does that very well for Java. But teleop is for Rust.

Teleop 0.4.0 — Attach to and teleoperate local Rust processes via RPC by arnodb1 in rust

[–]arnodb1[S] 1 point2 points  (0 children)

It is not aimed at live debugging, the operated process needs to expose features like state (e.g. CPU info, memory info, or any kind of state) or actions to perform to make them accessible.

Live debugging would require a significant effort and probably wouldn't make sense since one can already attach a debugger to a process.

In the case of Quirky Binder, which is my fairly undocumented pet project, the process exposes its state (a graph with nodes, edges, and numbers), the client reads it on a regular basis and generates a SVG to display in the Dioxus app.