The main goal here was to see whether RTen can yet provide a competitive alternative in terms of accuracy and performance for CPU inference (GPUs and NPUs are left as an exercise for the future). Also porting existing projects is a good way to find usability issues with the library.

Your (or your employer's) financial support for the PSF would be very much appreciated this year! (And every other year too) bsky.app/profile/pyth...

A quick glance at the CSS on the Airbnb homepage reveals a lot of Tailwind-like classes on elements, though not actual Tailwind.

"Let's get one thing straight: over-engineering in Rust is incredibly fun. The language hands you these shiny tools and it's hard not to play with them. It's like LEGO for programmers."

Quite a good take actually.

Someone in the ONNX project had a similar idea it seems, but it seems that is on hold for the moment - github.com/onnx/onnx/pu....

To work around this, rten v0.23 uses a custom Protocol Buffers parser, with entirely safe code, which enables minimizing copies for these fields when loading via regular file IO. This minimizes the overhead of loading from ONNX compared to the `.rten` format.

ONNX models with embedded weights are very large Protocol Buffers messages (up to 2GB) with the weights stored in `bytes` fields. This makes it difficult to load efficiently because the weights don't have the appropriate alignment to mmap the file, or to load the file into a single buffer.

What did it call the repository?

I've found using fixed values for the default size often works well if most item sizes lie in a "typical" range. It has the upside of being easy to reason about and gets you a reasonable initial scroll size before any item sizes are known.

A written policy can set ground rules that allow rapidly closing issues/PRs if obviously not followed. I like Ghostty's - github.com/ghostty-org/...

Do you have an AI contribution policy for these repos?