New week, new Rust! What are you folks up to?
Playing with the idea of triple buffering, wondering about applications beyond computer graphics. Seems to me like a great alternative to lock-protected data structures, RCU and message queues when you are in the right usage scenario for it:
- Single-producer single-consumer (allows lock-free implementation with very low overhead)
- Producer continuously updates the data structure, consumer can safely miss an update
- Data structure is cheap to move, ideally to copy as well (not a hard requirement, but allows interfaces with much better usability)
In this situation, triple buffering is simpler / faster than a lock (guaranteed to be nonblocking for both the reader and writer, requires only atomic exchange rather than full compare-and-swap), or an RCU construct (no compare-and-swap, no memory reclamation and ABA issues), and it avoids the large space and time overhead of sending lots of “update messages” down a message queue, only a small fraction of which will actually be useful.
Continuing work on
nuget-rs which is a tool for packaging Rust libraries as .NET nuget packages. I’m working on CI right now, which is working in Windows, but not on Linux or OSX yet.
EDIT: Wrong link
Started out this week by noticing my strategy to provide nice rust-alike API in
eventstore-tcp is not too great and will always have a chance of panics. I’m currently trying to rewrite the
codec layer to work directly with raw protobuf messages and to offer an user visible API to nicer messages via fallible conversion (custom
TryFrom) on top of the raw messages. User can then choose to either unwrap and accept panicing, or then add a fallback handling of the raw message until the bug can be fixed.
In hindsight, first building the support for only raw messages would had been more sensible…
Improving my markdown-to-plaintext crate: It converts Markdown to pretty plaintext (e.g. Links are always on the bottom, configurable coherent text wrapping, maybe also justification text layout…). I want to use it for an E-Mail authoring program where you type your E-Mail as Markdown and it creates an E-Mail with a beautiful HTML and plain text MIME part.
On the way I fixed a bug in Cursive (the Rust terminal UI crate), which I also forked with fewer dependencies.
Trying to build a basic key value store using tokio for server handling. Still need to learn more about where to keep state in (or out???) of my tokio service. Most likely coming to grips with async programming!
Thanks I’ll take a look at that!
Working on a 6502 assembler, and eventually emulator.
Planning to continue my work on
dlt-rs in the comming days.
After that I’ll probably make a blog post showing how somebody can connect from PC with the
Dlt-Viewer(the application from the screenshot) to a Rust application that has logging, running on Raspberry Pi.
Working on the apply binary for my porting shell_cmds to learn rust project. Unfortunately, poor choices of the original programmers from ancient days (cryptic single-letter variable names, re-used variables) mean that the source code literally has to be reverse-engineered in many spots to try to divine the intent and actual behavior of the original. At least they left some signpost comments!