Rust

Not to throw shade, just wishing that somebody here can understand. Whenever an input is reasonably long, an analyzing function will crash, and this PR aims to fix that with a mechanism that contradicts the maintainer's understanding while a similar C implementation does not need this fix. ~~Clearly, the maintainer has not heard a certain programming mantra...~~

I’m personally very excited about this because Rauthy provides a robust foundation of OIDC-based identity for the fedi-connected platform we’re building with Weird netizens.

The addition of “social logins” such as GitHub means indie platforms like Weird can let people easily sign in with the mainstream identity provider they’ve already got, but once they’ve signed up they’ll have the option of using our open source identity provider for other services going forward, thus reducing their dependency on the Big Corp.

Original submission text (Bruce Hopkins):

Iced is an amazing library. I chose it for building a simple Code Editor. But Iced severely lacks documentation. I wrote this article as a good entry point into using Iced that can be easy to understand as long as you know Rust. I explain the parts that confused me when I began using the library, so I hope that my mistakes can be useful for someone else.
I might write articles into the more advanced topics in Iced, so if this article is something that you like, let me know.

This new version provides an easy path to migrate from ESLint and Prettier. It also introduces machine-readable reports for the formatter and the linter, new linter rules, and many fixes.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

I just had a random thought: a common pattern in Rust is to things such as:

let vec_a: Vec<String> = /* ... */;
let vec_b: Vec<String> = vec_a.into_iter().filter(some_filter).collect();

Usually, we need to be aware of the fact that Iterator::collect() allocates for the container we are collecting into. But in the snippet above, we've consumed a container of the same type. And since Rust has full ownership of the vector, in theory the memory allocated by vec_a could be reused to store the collected results of vec_b, meaning everything could be done in-place and no additional allocation is necessary.

It's a highly specific optimization though, so I wonder if such a thing has been implemented in the Rust compiler. Anybody who has an idea about this?

Hello,

I am trying to wrap some Rust code that uses sea-orm compiled with "runtime-tokio-rustls" feature. I am using the new pyo3 "experimental-async" feature, which AFAIK is based on pyo3_async.

So I get that this is supposed to be runtime-agnostic, and not have two event loops, one for python async and one for rust async.

But, how do I tell pyo3 to use tokio runtime specifically? Or, how do I set up Python asyncio eventloop to use tokio somehow?

Indeed, it seems that it does not use tokio runtime, so I get this error when I invoke the rust async function from Python:

pyo3_runtime.PanicException: this functionality requires a Tokio context

This year's (belated, as is tradition) April Fool's XKCD is written in the Rapier.rs physics engine.

It's like The Incredible Machine, but each person can contribute a cell towards the larger machine.