Giving up on wlroots-rs

Post by Twisol » Mon, Apr 29, 2019, 5:13 PM UTC

klodolph wrote: post #38

mcguire wrote: post #20

Earlier quoted context omitted.

Quick answer, without understanding all the details: a weak-pointer-like structure that performed all the necessary locking and checking before giving out access to the underlying SHM. Rust's borrow checking is more or less a formalization of C++'s RAII style; in my experience, solutions for that translate relatively simply.

Rust's borrow checking does not correspond to RAII. A simplified explanation is that borrow checking gives you the guarantee that mutable references are unique and immutable references do not change. Rust's lifetime system is vaguely like RAII, but the C++ type system gives you no way to create an object with lifetimes that don't correspond to some scope. In Rust this is done by moving values, but in C++ this is not…

    let items = &[42, 101];

    // All products (a*a, a*b, b*a, b*b)
    for x in items {
      for y in items {
        println!("{}", x * y);
      }
    }

    println!("");

    // Pairwise products (a*a, b*b)
    let pairs = Iterator::zip(items.iter(), items.iter());
    let pointwise_products = pairs.map(|(x, y)| x * y);
    for product in pointwise_products {
      println!("{}", product);
    }

Post by pjmlp » Mon, Apr 29, 2019, 5:22 PM UTC

kccqzy wrote: post #61

This code fn some_wlroots_callback(output_handle: OutputHandle, surface_handle: SurfaceHandle) { output_handle.run(|output| { surface_handle.run(|surface| { // maybe some more nested layers... }).unwrap() }).unwrap() } is just screaming continuation monad. You see the same code pattern in early Node.js code (sometimes leading to callback hell). In the JavaScript world, the problem was solved using Promises, and then…

Post by pjmlp » Mon, Apr 29, 2019, 5:23 PM UTC

ddevault wrote: post #50

shmerl wrote: post #47

A pity wlroots itself isn't written in Rust.

C is the lingra franca of programming. By writing wlroots in C, we make it easy for a half dozen projects to make bindings to other programming languages. Rust is the only one that seems to have failed, and it's not surprising given the constraints of the language. wlroots brings together over a dozen different libraries and interfaces which are implemented in C. You'd have to repeat this process a dozen times over,…

Post by klodolph » Mon, Apr 29, 2019, 5:26 PM UTC

Twisol wrote: post #62

klodolph wrote: post #38

Earlier quoted context omitted.

Rust's borrow checking does not correspond to RAII. A simplified explanation is that borrow checking gives you the guarantee that mutable references are unique and immutable references do not change. Rust's lifetime system is vaguely like RAII, but the C++ type system gives you no way to create an object with lifetimes that don't correspond to some scope. In Rust this is done by moving values, but in C++ this is not…

> C++ lets you have as many iterators as you like into the same container While it's true that Rust doesn't let you have multiple mutable iterators, it's worth pointing out that you can certainly have multiple immutable iterators. let items = &[42, 101]; // All products (a*a, a*b, b*a, b*b) for x in items { for y in items { println!("{}", x * y); } } println!(""); // Pairwise products (a*a, b*b) let pairs = Iterator:…

Post by timidger » Mon, Apr 29, 2019, 5:46 PM UTC

Diggsey wrote: post #49

timidger wrote: post #21

Earlier quoted context omitted.

Author here. The problem with that design (which is a great design given what I presented in the article by the way!) is that it doesn't allow you to share handles across callbacks, which is mandatory to do anything interesting. I'm assuming here that you can't use the handles except for that callback context. If you can, then that presents a different problem. https://play.rust-lang.org/?version=stable&mode=debug&ed…

The intent is that handles can be used across contexts (as long as both contexts are from the same instance of wlroots) - the context checks that the handle is valid before unwrapping it. Could you clarify what you mean by it presenting a different problem? With regards to the leaking issue - that's not actually correct. `Box::leak` does not give you access to the context with the `'static` lifetime, assuming the lif…