Automated testing of UI is a tricky subject I feel like. You are heavily relying on your framework and UI test are super flaky (I've worked with Playwright, and had tests break because the backend was down when the end-to-end test ran).

For video games, It's even worst, there are almost ways to have testing, even in the large engines. You have unit tests, but no integration or end-to-end tests.

In my game engine, Vectarine, I've tried to see what having a good way to test games look like.

I've built a CLI tool that can run a game deterministically, take screenshots and compare them to a reference, make keyboard presses, etc. I'm trying to see hypothetically, how would the best experience to write tests look like.

The docs on testing are here. Sadly, I've had issues with rendering differences between Mac and Linux, so I'm comparing screenshots with an accuracy threshold.

I'd like to have your opinion on UI testing (especially the visuals), are there a way to have something less flaky / more enjoyable to work with.

So I started learning Rust and went straight to embedded with an ESP32 after being almost done with the book. I had previous programming experience with C++ (mainly in Unreal Engine, which uses its own build system), but I hate CMake, which was the main reason I learned Rust. I used esp-hal, embassy was ok, and all was good until I needed wifi. Tried using esp-radio, and it is so bad. There are breaking API changes from 0.16 to 0.18, which also means they did not follow SemVer, the docs on docs.rs say they failed to build for 0.18 so I am left with having to look for alternatives or use idf with the standard library which uses C bindings and takes ages to build because it needs to compile the underlying stuff too.

Is it just me, or is embedded dev prett painful with Rust because of the young ecosystem?

I'm stubborn ik, people often jump from other languages like c or python, java to rust but I wasted a lot of time and decided to go the hardest way.. till now I didn't feel like that.. but still if I say why i choose it? idk I see the future with this language probably.. if i learn python or other languages now the market is already filled with all roles.. rust has less jobs in my country but I'd at least try outside right so.

I'm learning basics from scratch the system works and how to code.. and all from gpt.. I've made my mentor and given specific instructions not to break rhythm not to provide code unless i do stuff myself and all yeah it's silly but that's how I learn slow but properly.

ai will eat up everyday then why learn? cause I want to learn that's the answer.. could've gone with any but yeah choose rust. ai will give me code I'm sure if it but I want to know stuff right.

now my question to you all.. ofc about jobs.. as I've seen mostly prefer someone with experience atleast with other langs but here I am.. is there any hope for me? ya ik still choose to learn and the reasons are above.

what projects should I keep doing.. is leetcode neet code imp? cause when I tried learning java back then , I was really really bad at data structures and gave up cause I got a support role but now it isn't for me and I want to learn but yeah practicality matters.

I just finished the Rust book and I'm starting my second year of college. I want to practice it, so I'm currently doing Exercism exercises. I want to extend my scope. Which website should I go to?

r/rust - I built a digital logic circuit simulator in Rust (egui/eframe)

Hey! I wanted to share a project i made for logic simulation nearly 100% rust and complied to WASM for some blazing fast in browser run times.

here's the link if you want to check it out: https://theta-rnd.itch.io/logic-sim

if you do would LOVE to hear your feed back thanks!

I've been working on a utility crate to make returning Tera templates from actix-web routes more ergonomic and would welcome any feedback. Most of the documentation material I can find seems aimed at using actix-web for APIs and it is very ergonomic for that use case. In a current project, however, I am trying to make a traditional multi-page website, where all responses should be returned as full HTML pages.

I initially started by extracting a tera instance and building context directly in each route handler, but this became quite verbose, especially all the match statements I had to use for proper error handling. To alleviate this, I tried to create a custom struct that hid all of the boilerplate in its implementation of Responder. As it seemed useful, I thought I would extract it out into a crate of its own for other projects, and in the hope that it would be useful for others.

The implementation is still in an early stage (my own project is just 2 pages so far) and could do with some refinement; any feedback on the API design would be welcome! In particular, I feel that Error handling is still not ideal as error responses must currently be returned manually. This is partially due to actix-web not exposing the Request to types that implement ResponseError.

The Polars expression plugin system has been instrumental in building the rich functionality of fenic. That part of the system is not super well discussed although it provides amazing opportunities to extend Polars in a performant way without having to fork the project.

I wrote a post going through the things we built on top of Polars with examples from the actual code base.

I thought it will be useful for anyone interesting in extending Polars and/or PyO3 and maturin among other things.

Here's the link to it

Hope you find it useful!

As a somewhat prolific open-source author over the past 25 years, I maintain hundreds of Rust crates, Ruby gems, Python packages, and so on. One of the painful aspects of large projects consisting of dozens of packages has been the individual READMEs for each package, with lots of repetitive elements but also a great deal of necessary package-specific variation.

Now, I don't want to just have an LLM generate my READMEs. People are increasingly sensitive to AI slop, and that certainly starts with a project's README: slop is readily recognizable through LLMs' lack of good judgment on README contents. More isn't always better: "If I had more time, I would have written a shorter letter" and all that.

I believe that at this point given widespread complex formatting of READMEs, what with CI badges, headers, footers, tables, images, inline HTML, etc, etc, we've in any case realistically drifted quite far from the original human-readable vision of Markdown as such. Perhaps, then, we ought to consider whether README.md files should not best be treated just as built documentation outputs, not as sacred artisanal relics to be read on a 80×24 monochrome screen?

Along these lines, I present Readmer, a first attempt at a proper README compiler. Readmer composes README.md files from Liquid or Jinja2 templates stored in an unobtrusive .config/readmer/ project directory, with lots of nifties such as support for rendering CSV files as Markdown tables. I hope it comes useful to someone!

console $ cargo binstall -y readmer $ cargo new myproject && cd myproject $ mkdir -p .config/readmer/ $ echo '# {{ package.name | capitalize }}' > .config/readmer/README.md.liquid $ readmer render > README.md

Hello there!

I have just released the first version of polybox. Polybox provides wrappers around mpsc-channels of flume and tokio (can easily be extended for other channels), to make usage more ergonomic and ease usage of the actor-pattern.

The fundamental idea is that a Sender<T> should not have to care about the actor it is sending to. The only thing that it should care about is the messages that can be sent over the channel. A sender should not care whether it is talking to ProcessA or ProcessB, only that they both accept the same Message. This is exactly what PolyBox provides.

If this sounds interesting, and you have feedback or a use-case in mind let me know! I'm pretty happy with where it's at, but it's still in an early stage.

(No AI was used except for some basic auto-complete)

Dear all, I’m building DCC-esp32, a no_std Rust firmware for an ESP32-C6 based DCC command station for model railroading, joining my passion for train models and programming (Rust). It's a first version of a command station for bare metal in Rust. Some hw of course is needed. Lot of things remain to do (i.e, desing a circuit for Railcom, adding Can, but I'm not an hw engineer and my skills in hw are at a basic level.

It uses esp-hal, Embassy async tasks, esp-wifi, ISR-driven RMT for DCC waveform generation, Z21-compatible UDP control (a Roco spec(, runtime WiFi provisioning, and early RailCom/POM integration.

I've changed also the big BTS H-birdge with a TI DRV8874 so the circuit is very easy for DCC only at the moment.

Repo: https://github.com/cc90202/DCC-esp32

I've tested with Roco, Trix and RIvarossi models and it's a pleasure to see them running.

Rust is amazing on Esp32.

side project I've been working on. turns an Android tablet or phone into a second monitor for Linux over WebRTC — kernel-level virtual display via evdi, not a workaround.

the stack if you're curious:

• evdi crate for the virtual display (X11 + Wayland via DRM)
• x11rb + ashpd + PipeWire for capture
• GStreamer pipeline for encode (VAAPI / NVENC / x264)
• axum + webrtc-rs + mdns-sd for transport
• evdevil + ashpd RemoteDesktop for reverse input
• Android client in Kotlin WebView

workspace is split into focused crates: orbiscreen-core, orbiscreen-display, orbiscreen-capture, orbiscreen-encode, orbiscreen-input, orbiscreen-transport, orbiscreen-daemon.

v0.1.0, still scaffolding the WebRTC streaming and Wayland DMA-BUF path. open to feedback especially on the GStreamer pipeline structure.

GitHub

Sniffnet, the open-source network monitoring tool written in Rust, has reached version 1.5.1 that brings connections latency measurements, support for CIDR ranges in IP blacklists, new Sinhala and Hungarian translations of the app by native speakers, and other improvements to the app stability and packaging

Hi all,

Given that there's been a lot of discussion about AI projects for a change, I though this is a good point to finally write a post about my very much hand-written 3D renderer retrofire, which I also used as a case study in my recently-accepted M.Sc. thesis titled "Type-safe(r) Model of Geometry in 3D Graphics".

retrofire is (optionally) no_std and has zero non-optional external dependencies. It also contains zero unsafe and, as mentioned, zero lines of LLM-generated or designed code. Last but not least, there are zero emojis :P

Please see the README for screenshots, can't post pictures in r/rust.

Umbrella package: https://crates.io/crates/retrofire

Git repo: https://github.com/jdahlstrom/retrofire

My thesis: https://www.utupub.fi/items/645d25b4-de42-4959-bd50-f96fb98b202a

A tiny example:

```rust

let verts = [
    vertex(pt3(1.0, 1.0, 0.0), rgb(1.0, 0.2, 0.0)),
    vertex(pt3(-1.0, 1.0, 0.0), rgb(0.0, 0.8, 0.2)),
    vertex(pt3(0.0, -1.0, 0.0), rgb(0.4, 0.4, 1.0)),
];

let shader = shader::new(
    // Vertex shader
    // Transform vertex position from model to clip space
    |v: Vertex3<Color3f>, mvp: &ProjMat3<Model>| {
        vertex(mvp.apply(&v.pos), v.attrib)
    },
    // Fragment shader
    // Just turn the float color to u8 RGBA format
    |frag: Frag<Color3f<_>>, _| frag.var.to_color4(),
);

let dims = dims::VGA_640_480;

// Render into a 2D buffer
let mut framebuf = Buf2::<Color4>::new(dims);

// Move the camera away a bit
let modelview = translate((0.0, 0.0, 2.0)).to();
// Use perspective projection
let project = perspective(1.0, dims.aspect(), 0.1..1000.0);
// Use the whole buffer as the viewport
let viewport = viewport(dims.into());

render(
    // Render a triangle with the given vertex indices
    [tri(0, 1, 2)],
    verts,
    &shader,
    &modelview.then(&project),
    viewport,
    &mut framebuf,
    &Context::default(),
);

```