Search

Coming back to say a month later I am using Rust at work for one small service. I still use indices. See also the thread on tokio mutex, I found new way to confuse myself.

Works. Each new error teaches me that the thing I was doing was bad. It is like having strict teacher again.

Depends on your compiler version, the check looked at scopes rather than at drop calls for a long time. The block always works. Only use tokio::sync::Mutex if you actually need to hold it across an await, which is rarer than you'd think.

Why the block? Why not drop(g) before await?

std's guard has to be released on the thread that took it, and across an await your task may move to another thread. So holding it across an await isn't allowed in a spawned task. Good thing too, that would also block every other task waiti…

Hello again. Small service, I have shared state in Arc<std::sync::Mutex<...>>. let mut g = state.lock().unwrap(); g.count += 1; do_something().await; tokio::spawn gives: future cannot be sent between threads safely, MutexGuard is not Send. …

Same two pass thing applies in numpy, compute everything from the old array then assign. Learned that from a very wrong heat diffusion plot.

Oh. That was a bug I had and didn't know. Thank you.

For pairs from two separate halves, yes. For all pairs like you have, it just makes it harder to read. If you need to update both at once then split_at_mut, or swap to computing a list of deltas in one pass and applying them in a second. Th…

It works. There is also split_at_mut in documentation, is that better?

vek is right in spirit, you do end up reinventing handles and arenas. Though that's how a lot of good C ended up as well.

"Rewrite it in Rust" -> rewrites it in array indices, like Fortran

Indices, usually. for i in 0..particles.len() { for j in 0..particles.len() { if i == j { continue; } let d = particles[j].pos - particles[i].pos; particles[i].vel += d * k; } } Each indexing is a short borrow so there's no conflict. d is c…

Next problem then. My real code is a list of particles, and each one should look at its neighbours and change itself. for p in particles.iter_mut() { for q in particles.iter() { ... } } Same error of course. What is the normal way to do thi…

Yes. Non-lexical lifetimes. The borrow lasts until the last use.

OK this makes sense. But if I swap the last two lines it compiles. So the borrow ends at the last use and not at end of the block?

Can confirm the C++ part, I have the scars.

push might reallocate. If the Vec is at capacity it allocates a bigger buffer, moves everything and frees the old one. Then first points at freed memory. The borrow checker doesn't know whether this particular push will reallocate, so it re…

I learn Rust since two weeks. This does not compile: let mut v = vec![1, 2, 3]; let first = &v[0]; v.push(4); println!("{}", first); error[E0502]: cannot borrow v as mutable because it is also borrowed as immutable I understand the message.…