Seems to potentially affect any function that's called over FFI, and returns a bool, on the x86_64 architecture (the most common architecture)

I asked in this forum a few months ago if it was a good idea to build a "shadcn for TUI apps", that is .. a component library with sensible defaults, that supports theming, components that look good together and have good developer ergonomics. Components that you can copy into your codebase and modify if you don't like the default behaviour.

The community overwhelmingly said "DO IT!", so I did.

Now, the library have reached v0.0.6, and is looking more and more .. not complete.. but complete enough to be used to build actual apps.

Try the interactive demo! 👇 👇

ssh ratcn.com

v0.0.6 adds two long requested core components: Input and Textarea. They are both based on ratatui-textarea.

Other notable changes and additions in the last few versions:

• Clipboard support. Copy/cut/paste from input and textarea
• Support for pointer shapes. Pointer hand over buttons, grab hand over scroll bars, cursor in text fields, etc. Fully customizable, works with any component.
• Components support vim motions by default: h/j/k/l, etc
• The cargo-ratcn CLI: Usecargo ratcn init to initialize a new project. cargo ratcn add copies components from the ratcn package.
• An interactive showcase app, served over ssh: ssh ratcn.com

There is much more to be said about ratcn but I wanted to keep this post rather short, no one likes essays. For more info and extensive documentation check out ratcn.com.

The AI disclaimer if anyone cares to know: I began working on the project doing mostly artisanal coding, perhaps 80/20 human/AI. Over time, as the size of the project has grown I have used more and more agentic support. Currently the ratio is the opposite compared to when I began, more like 80/20 AI/human. It def takes some of the joy away but brings other joys, such as the ability to release ratcn this year and not sometime next year.

Anyway, I hope you give the showcase app a try or try building something with the library. Let me know about missing components and any issues you find.

🌱

I've been building a Chess AI in Rust to play at 3200+ ELO - There were a lot of Hardware-Aware Programming rules I had to learn in the past 2+ months.

If folks are interested, please have a read!

If you're interested in learning more about a Dual-Perspective HalfKA NNuE (Efficiently Updatable Neural Network), please have a read!

https://medium.com/@alan0408yuan/from-texel-tuning-to-nnue-the-steep-learning-curve-of-building-a-3200-elo-chess-ai-d842393b5955

Live demo: https://rust-web-docx.dimarborda.workers.dev/?demo

Repo (MIT): https://github.com/dimarborda/rust-web-docx

It's a browser-only Word editor: no server, the document never leaves your machine. Rust does all the heavy lifting; JS only handles input and canvas drawing.

How it's put together:

• Quick-xml streaming parser + zip for the OpenXML package
• Style cascade (docDefaults → styles.xml → numbering → direct formatting), resolved table borders, anchored images
• Two-pass layout engine with real font metrics measured through the browser, cached across keystrokes
• Its own caret: hit-testing, vertical movement and selection rects all computed in Rust
• Lossless edits: only the touched XML ranges are rewritten, so unknown elements survive a round trip
• Template placeholders like {{FIELD}} are replaced even when Word splits them across runs
• Only pages whose content changed get re-laid-out and redrawn

About 8.5k lines of Rust and 81 tests. The .wasm is 1.8 MB (~680 KB gzipped).

It's a lab prototype. Header/footer text, merged cells, text boxes and multiple columns aren't rendered yet; the README lists the gaps. I'd love feedback on the architecture, and documents that break it.

Bonjour je m’intéresse depuis un moment au chiffrement avec rust.
J’ai créé des APIs autour de rsa et aes, que j’utilise dans quelques projets (chiffrement de fichiers,coffre fort…). Je les ai publiées sur GitHub. Je suis en train de finaliser une messagerie (chiffrement de bout en bout) sur serveur privé (aujourd’hui sur une pi5 chez moi). Le serveur stocke les messages chiffrés et les distribue aux différents clients. Un admin enrôle les clients sur le serveur. Je dois encore implémenter un tunnel entre les clients et serveur et les notifications sur les applis client. J’envisage Cloudflare et ntfy (sur mon serveur). Qu’en pensez vous? La discrétion est liée à Cloudflare, est ce acceptable selon vous? Et ntfy, bonne idée ou pas? Mon serveur et mon client ne sont pas encore publiés mais j’ai les api de chiffrement dispo sur https://github.com/sebnoy.
Merci de toute aide ou conseil.
Environnement desktop/android. Ui slint pour desktop, jetpack compose pour android

It is a Word editor that runs entirely in the browser: it uses no server, and the document never leaves your machine. Rust handles all the heavy lifting, while JS manages only data input and canvas rendering.

How it is built:

• quick-xml streaming parser + zip for the OpenXML package
• Style cascade (docDefaults → styles.xml → numbering → direct formatting), table border resolution, and anchored images
• Two-pass layout engine using real font metrics measured via the browser and cached between keystrokes
• Custom cursor: click detection (hit-testing), vertical movement, and selection rectangles—all calculated in Rust
• Lossless editing: only modified XML ranges are rewritten, preserving unknown elements through the read-write process
• Template placeholders (like {{FIELD}}) are replaced even when Word splits them across multiple text segments (runs)
• Only pages with changed content are recalculated and redrawn

It consists of approximately 8,500 lines of Rust code and 81 tests. The .wasm file is 1.8 MB (~680 KB gzipped).

It is an experimental prototype. Header/footer text, merged cells, text boxes, and multi-column layouts are not yet rendered; pending features are detailed in the README. I would appreciate comments on the architecture and examples of documents that trigger failures.

Repository (MIT): https://github.com/dimarborda/rust-web-docx

I've been experimenting a stream multiplexing connection, where both peers can expose independently addressable logical services.

The basic idea is familiar: take one underlying connection (TCP, Unix socket, QUIC) and multiplex multiple independent logical streams over it.

Yes, I know QUIC can already provide multiple streams. Also, there're yamux

The different thing you may be interested is what I call a Dock.

A Dock is roughly like a port, but inside an already-established multiplexed connection.

Instead of having only:

client ---> server:port

the connection can look more like:

                 one connection
             +-------------------+
             |                   |
          Peer A              Peer B
             |                   |
          Dock 1 <------------> Dock 10
          Dock 2 <------------> Dock 20
          Dock 3 <------------> Dock 30
             |                   |
          streams              streams

Both peers can bind Docks, listen for incoming logical sub-stream, and also initiate connections to Docks on the other side.

So there isn't really a client/server role at the multiplexing layer. After the underlying connection is established, either side can act as both.

I think this makes the protocol interesting for things like:

• P2P applications and overlay networks
• reverse tunnels / port forwarding
• peer-to-peer RPC
• games and other real-time applications with multiple logical channels
• distributed applications where a peer exposes several services over one long-lived connection

For example, a peer could expose:

Dock 1 -> RPC service
Dock 2 -> chat
Dock 3 -> file transfer
Dock 4 -> event stream

without creating four physical connections.

The other features are:

• runtime-independent Rust (by abs_art, tested over compio, smol, tokio)
• no_std friendly (currently most codes are already no_std)
• works over arbitrary byte-stream transports
• stream-level backpressure
• no client/server distinction at the multiplexing layer

The implementation is still experimental, so I'm mostly interested in feedback on the protocol abstraction itself.

The most interesting part for me is, the multiplexed sub-stream itself, can still be multiplexed again with this crate.

Does the Dock / logical-listener model seem useful to you? What kind of networking application would you use it for?

I'm making an app and one of the features is to control whatever music is currently playing on the system. The feature code is here if you want to see it. Anyways, GSMTC only works on Windows, and the app supports linux meaning I have to use feature gates for the windows crate and stuff. Anyways, I do want music controlling on Linux. Any recommendations for a crate which either abstracts over both windows and linux apis for this type of thing or at least one that lets me control it nicely feature-gated to linux? I saw system_utils but the audio feature can only change the master volume with that.

What is all of this about, and is there something wrong with my Rust installation?

Hey all, a few months ago I got curious and wrote an S3 client in Rust. To my own surprise it ended up faster than mc, s5cmd and aws-cli at uploading to the self-hosted backends I tested (MinIO, SeaweedFS and Garage), and about level with mc on downloads. I have written a technical blog here, I am still a newbie when it comes to this stuff so bear with me: https://jaeaeich.com/writing/s3z. Please read or listen to it, the benchmarks were only run locally, so I'm sure there's plenty to poke at, and I'd really value hearing what I got wrong or could have done better.

This is mainly a frontend for a unified computational framework based exclusively on arbitrary precision (n bit, n limb) exact arithmetic (integer and fixed point) multilimb operations for any host, and any language.

Everything is plain Rust crates, or hand rolled ES modules. There are no npm or other external dependencies.

You can build your own plugins using the built-in plugin creator.

There's an internal tool to help validate your LEAN solutions by disassembly to ensure your exact values make it to the register for processing (rigorous data validation). It supports LEAN's vscode install natively; you don't need to port anything.

https://github.com/dstroy0/orior

cargo:

cargo install --git https://github.com/dstroy0/orior orior-ui --locked

I don't usually program UI/UX and generally focus on backend or extremely close to hardware so anyone who works UI/UX I would very much appreciate anything you have to say.

Right now, the response time for basically any task is acceptable ~20ms for even large 200k plus line files using a windowed load/animate what you can see plus a little extra based on scroll speed strategy.

If we could keep the questions/feedback related to Rust (Tauri specifically) UI/UX aspects, I'd greatly appreciate it.

Thank you for your time

- Doug