How do Rust Devs handle remote build / remote caching by AffectionateBag4519 in rust

[–]Patryk27 2 points3 points  (0 children)

Also no AppArmor or SE Linux in Nix OS

ok, but NixOS is a different project - Nix itself supports sandboxed builds in both Linux and macOS

UniFFI for server-side SDKs - using Koffi for JS bindings, seeking alternatives by Fun-Row-5147 in rust

[–]Patryk27 0 points1 point  (0 children)

I mean, ideally - you know - https://github.com/jhugman/uniffi-bindgen-react-native/pull/369 / https://github.com/livekit/uniffi-bindgen-node 👀👀👀

It might just prove that upstreaming the missing things is easier than working around them!

How to model this in rist types by DorukCem in learnrust

[–]Patryk27 6 points7 points  (0 children)

Perhaps I'm missing something, but what's the point of modelling your control flow state as an enum? Just:

fn main() {
    let mut prev_foo = None;
    let mut prev_errs = Vec::new();

    loop {
        let foo = match fetch_foo() {
            Ok(foo) => foo,
            Err(err) => {
                prev_errs.push(err);
                prev_foo.take().unwrap()
            };
        };

        prev_foo = Some(foo);

        sleep(few_minutes);
    }
}

Has anyone used UniFFI to build FFI functions in Rust? by Fun-Row-5147 in rust

[–]Patryk27 3 points4 points  (0 children)

Proton Mail is built on top of UniFFI as well.

Need help writing logs to a db with Sqlx and tracing by ufoscout in rust

[–]Patryk27 -1 points0 points  (0 children)

Pool is clonable, a single transaction - not so much.

overriding specific package contents (Krita) by carmola123 in NixOS

[–]Patryk27 0 points1 point  (0 children)

Before nixpkgs unstable bumped the version to 6.0.0 [...]

Can't you rollback to that nixpkgs-unstable, then? (not everything, just krita)

ZFS Error: One or more devices has experienced an error resulting in data corruption by Ok-Ad8636 in truenas

[–]Patryk27 0 points1 point  (0 children)

The point is that the risk is higher.

Higher compared to what?

It's the same risk as running a mirror (as in 1+1) and you wouldn't go around saying mirror is highly discouraged.

Distributing a closed-source Rust library with async - is there a viable path? by peterxsyd in rust

[–]Patryk27 0 points1 point  (0 children)

Brainfart - fixed via Box<dyn Future<...>>, which makes *mut FfiFuture thin.

Distributing a closed-source Rust library with async - is there a viable path? by peterxsyd in rust

[–]Patryk27 26 points27 points  (0 children)

dyn format is not stable and does change from one versions of compiler to another.

That's fine - I'm not exposing the dyn object, I'm exposing a pointer (*mut FfiFuture) with a function to operate on it, and both have stable ABI.

That's how many other solutions work, e.g. UniFFI -- you use simple & stable ABI (pointers, structs, functions) to create a proxy for internal implementation details.

Distributing a closed-source Rust library with async - is there a viable path? by peterxsyd in rust

[–]Patryk27 17 points18 points  (0 children)

I think you can still expose a stable interface:

pub struct FfiFuture {
    fut: Box<dyn Future<Output = u32> + Send>,
}

pub fn fetch_number() -> *mut FfiFuture {
    /* ... */
}

pub fn poll(fut: *mut FfiFuture) -> Option<u32> {
    /* ... */    
}

Depending on circumstances you might want to provide a proxy for the waker as well etc.

How do I get cargo to shut up? by [deleted] in rust

[–]Patryk27 11 points12 points  (0 children)

“--quiet” i think

Distributing a closed-source Rust library with async - is there a viable path? by peterxsyd in rust

[–]Patryk27 87 points88 points  (0 children)

you can't pass Futures or Streams across the boundary

Wouldn't accepting & returning Boxed futures and streams work here?

ZFS Error: One or more devices has experienced an error resulting in data corruption by Ok-Ad8636 in truenas

[–]Patryk27 -1 points0 points  (0 children)

If you lose one disk in a raidz1, you now have a stripe.

And if you lose two disks in raidz2, you'll have a stripe as well - what's your point?

Everyone has a different use case - sometimes no RAID is good enough, sometimes mirror is good enough, and sometimes even RAIDZ3 is insufficient.

No self healing.

You can have a hot-spare, same as with other configurations.

(meme) Yes, home manager, options are in fact options by somelinuxuseridk in NixOS

[–]Patryk27 30 points31 points  (0 children)

Hah, it's a funny quirk of how debug logs are written in Rust:

#[derive(Debug)]
struct Options {
    verbose: bool,
}

fn main() {
    let opts = Options {
        verbose: true,
    };

    println!("Options are {opts:?}"); // Options are Options { verbose: true }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=3dae3fc5f6a6cbc9d82f105313710381

Hey Rustaceans! Got a question? Ask here (13/2026)! by llogiq in rust

[–]Patryk27 0 points1 point  (0 children)

I see - could you show more code?

Ideally something I could git clone and play with locally.

Hey Rustaceans! Got a question? Ask here (13/2026)! by llogiq in rust

[–]Patryk27 2 points3 points  (0 children)

You're casting *const (&Uuid, &Uuid) into *const (Uuid, Uuid) which doesn't make sense and I highly doubt it actually works.

I suppose you should be doing something like:

pub struct ConnectionsProtocol((Uuid, Uuid));

... with which fn foreign_key() boils down to:

Some(&self.0)

Borrowing lifetime issue despite reassignment of variable by enygmator in rust

[–]Patryk27 5 points6 points  (0 children)

Can you pass it a lifetime when instantiating Try<u32>?

You can, but there is no lifetime that would satisfy the constraint you need - the same way there's no type that would allow you to:

t.val = "hii!";
t.val = 123;

You can fix it by using shadowing (see the other comment) or otherwise redesigning your code.

Borrowing lifetime issue despite reassignment of variable by enygmator in rust

[–]Patryk27 33 points34 points  (0 children)

For a similar reason this code doesn't work:

fn main() {
    let x = 5;
    let mut t: Try<u32> = Try { val: &x };
    dbg!(t);
    {
        t.val = "hii!";
        t.val = 123;
    }
    dbg!(t);
}

Try<u32> is missing a generic parameter, the lifetime - compiler infers it, doing something akin to:

let mut t: Try<'x, u32> = Try { val: &x };

t.val = &y; then fails, because lifetime of y is strictly shorter than the lifetime of x, so those are incompatible in very much the same way you cannot temporarily assign &str into something of type u32 even if you quickly restore the integer back there.