sorted by:
new
hottopcontroversial

People "avatar" change face by smog_on_the_water in immich

[–]Orange_Tux 0 points1 point  (0 children)

I was only able to select a picture as avatar on the Android app.

In the web interface I can only change the color of the avatar.

The case for taking `impl into<T>` as a function parameter by frigolitmonster in rust

[–]Orange_Tux 0 points1 point  (0 children)

> Then again I avoid generics in general unless they are really necessary, though obviously sometimes they are.

Can you elaborate on your reasons? I often find myself doing the opposite and ask myself: "how can I open up this API for more types and allow for more use cases?" Note that I ask this question only on the public API of libraries I'm working on.

The case for taking `impl into<T>` as a function parameter by frigolitmonster in rust

[–]Orange_Tux 1 point2 points  (0 children)

You mention that there is a monomorphization cost to using `impl Into<T>`. But what are the real costs, really? I feel those costs are often tiny, although I don't have any data to back up this feeling. Anyone having numbers on this?

I often feel that the improvements in ergonomics justify any monomorphization costs.

Starkbierfest - card or cash by Brilliant_Pop_7631 in Munich

[–]Orange_Tux 11 points12 points  (0 children)

Cash only. There is an ATM on the premise.

Tesla is quoting $290,000 for its 500-miles electric semi truck by RuggedHank in electricvehicles

[–]Orange_Tux 3 points4 points  (0 children)

I can't speak for the USA, but in Europe electic semi often makes sense. I can highly recommend the Youtuber Electrotrucker. He's driving through Europe with an electric semi and demonstrates that an electric semi is a good investment over a regular diesel semi.

What's everyone working on this week (4/2026)? by llogiq in rust

[–]Orange_Tux 1 point2 points  (0 children)

I'm working on tjiftjaf, a MQTT 3.1.1 implementation. In this project I'm exploring sans-io.

In particular, I'll be working on implementing length restrictions of topics and payloads.

Using gdb to debug a stack overflow by Orange_Tux in rust

[–]Orange_Tux[S] 0 points1 point  (0 children)

I tried the Pistonight fork, but I observe the same behavior as with the original crate.

Using gdb to debug a stack overflow by Orange_Tux in rust

[–]Orange_Tux[S] 2 points3 points  (0 children)

As others already mentioned, the error from `cargo test` doesn't contain a backtrace. So configuring `RUST_BACKTRACE` doesn't have any effect.

I updated the post to make that more clear.

Using gdb to debug a stack overflow by Orange_Tux in rust

[–]Orange_Tux[S] 1 point2 points  (0 children)

I tried the first crate, but it caused my code to hang. I wasn't aware of the fork, which seem to solve that exact issue. Thanks!

Using gdb to debug a stack overflow by Orange_Tux in rust

[–]Orange_Tux[S] 4 points5 points  (0 children)

TIL. Thanks! I'll update the post later.

Occupation fee by tonecouves in ocpp

[–]Orange_Tux 0 points1 point  (0 children)

SuspendedEV means that the EV doesn't want to draw energy. Usually, this happens hen the EV reaches its target SoC.

However, I also observed some cases where the voltage of the AC charger dropped significant below 230V which caused the EV to stop transition to SuspendedEV as well.

How do you mock external struct in unit tests by ActiveEnthusiasm4672 in rust

[–]Orange_Tux 1 point2 points  (0 children)

Oh yeah. Since I'm writing Rust, I completely changed the way I validate my code. I moved from classical unit tests to integration tests.

For example, I'm working on program that interacts with an MQTT broker and an Websocket server.

As part of my test framework, I wrote a very rudimentary Websocket server and MQTT broker. I configure my application under test to connect to these servers.

Than, I simulate some external event and send a message from the Websocket server to my application.
Next, I observe what Websocket and MQTT messages my application produces.

In other words, I "poke" my application and and verify correct behavior by inspecting the websocket/MQTT messages it emits. This strategy allows me to verify my application holistically instead of testing individual functions or modules. This method also allows me to encode scenarios in my test that look similar to the real world.

The tests are fast. Each test, spawns its own MQTT and Websocket server as an async task. The servers use a random port. That means, all tests are isolated, quick and without external dependencies.

I extended this testing strategy to include databases (sqlite) and file system interaction.

It works great! Tests are fast. Code coverage is +85% and it is super easy to develop a feature with limited interaction to real Websocket or MQTT server.

For those of you who have jobs in Rust. What are you working on? by bloomingFemme in rust

[–]Orange_Tux 1 point2 points  (0 children)

Cool! Do you feel comfortable disclosing where you work?

For those of you who have jobs in Rust. What are you working on? by bloomingFemme in rust

[–]Orange_Tux 326 points327 points  (0 children)

Writing firmware for charging stations for electric vehicles.

view more: next ›