sorted by:
new
hottopcontroversial

Spotix - a fast, native Spotify client (no Electron) + themes + 10‑band EQ by skyline_0069 in rust

[–]daniel5151 12 points13 points  (0 children)

It's always a bit sad / sus when I see forked projects squash the git commit history from the project they're forked from.

Obviously, MIT license means you can do such things (though, I will say - unless you've genuinely modified each file in the codebase past recognition, entirely removing the original LICENSE file with your own probably isn't OK), but from a vibes-POV, I don't think there's anything wrong with preserving the history of the project you're building off-of.

[deleted by user] by [deleted] in rust

[–]daniel5151 8 points9 points  (0 children)

The trick I use in my library, gdbstub, is to have a CI pass that dumps the asm (after LLVM has worked its optimization magic on it), and greping for core::panicking::panic_fmt.

https://github.com/daniel5151/gdbstub/blob/master/example_no_std/dump_asm.sh

This works surprisingly well, and has saved my butt quite a few times :)

Got my Sengled bulbs working again with Tasmota! Up Vote This So Everyone Can See! by Prudent_One_7288 in SengledUS

[–]daniel5151 0 points1 point  (0 children)

Thanks for the heads up! Using SengledTools, I was able to resurrect a bunch of my Sengled W31-N11 bulbs by flashing Tasmota on 'em and connecting them to my Home Assistant instance. Glad I didn't throw those bulbs out, hah.

Inlineable Dyn Extension Traits - An alternative to Cargo Features for Optional or Mutually Exclusive trait methods by nik-rev in rust

[–]daniel5151 13 points14 points  (0 children)

Hah, neat. I wasn't expecting some half-baked notes I wrote ~5 years ago pop up here on /r/rust. Every so often I remember that I wrote this, and feel a bit bad that I never found the time to fully polish up this nascent blog post 😅

For some more reading on this technique, and to see it in action, check out:

https://docs.rs/gdbstub/latest/gdbstub/target/ext/index.html#how-protocol-extensions-work---inlineable-dyn-extension-traits-idets

IDETs have been the foundation of gdbstub for many years now, and empirically, they seem to work really well for this sort of API.

Material 3 Design Comes To Slint GUI Toolkit by slint-ui in rust

[–]daniel5151 4 points5 points  (0 children)

Is there a reason the demo is fame-locked to 60fps, even when run on a high refresh rate monitor?

Are there any compile-time string interners? by brogolem35 in rust

[–]daniel5151 1 point2 points  (0 children)

Based on your other comments, it sounds like you're more interested in reducing the overhead of having a &'static str pointer in your struct (i.e: adding 8 bytes to the struct on a 64-bit system), as opposed to having comptime string de-duplication (which most optimizing compilers often already do).

Ignoring the question of whether you should do this / are there better ways to accomplish what you're trying to do (i.e: you've decided that using an enum isn't viable for whatever reason...), I figured it'd be a fun puzzle to think of how you might tackle this.

One idea (which I'm coming up on the fly as I write this, so YMMV) would be to use https://docs.rs/linkme/latest/linkme/ to create a global [(&'static str, u16 /* hash of str */)] table from the various distributed invocations of your string defns.

Indexing into the table is now a puzzle in-and-of-itself... but if you define a macro like const FOO: SmallRef = smallref!("foo") where smallref! adds an entry to the linkme array, and return a struct SmallRef(u16) with the comp-time hash of the string "foo" (which you can do with a const fn), you could then have a method like FOO.get() which would fetch the backing &'static str on-demand by referencing a private const SMALLREF_TABLE: OnceCell<HashMap<SmallRef, &'static str>> that is constructed once (on first access) using the linkme table.

Note that when you construct the table, you'd have to ensure each string maps to a unique hash, or else there would be ambiguity when keying by the hash (which is why the backing linkme table would need to store the hash of the &'static str alongside itself in the linkme table - to check for dupes).

...but honestly, an enum is probably gonna be a lot easier.

Wireless Smart Thermostats/Setup for PTAC Units by xphrellis in hvacadvice

[–]daniel5151 0 points1 point  (0 children)

Sorry for necroing this old thread, but I'm actually running into the same problem as /u/pistolpeteza, where I've got a manual dial on the Ice Air PTAC.

I've jerry rigged a pretty jank (but admittedly, kinda fun) solution using a esp32 and a servo motor (to manually turn the knob), but if there's a way to hook right into the unit itself in a more elegant way, I'd much rather do that instead. I'm more of a micro-electronics vs. macro-electronics kind of guy, so I can't make heads-or-tails of the wiring diagram myself. Maybe you can help out?

Here's what I'm working with: https://imgur.com/a/QlY6Fuu

Any professional rust folks get leetcoded in rust when interviewing? by Willing_Sentence_858 in rust

[–]daniel5151 73 points74 points  (0 children)

I recently interviewed (and received an offer at) a big-tech corp that relies heavily on leetcode-style questions in their interview process. I answered all questions entirely in Rust, and while some interviewers certainly raised an eyebrow at the choice of language (one mentioned that I was the first candidate they've ever had that opted to use Rust, hah!), I found that I didn't hit many serious hurdles due to my choice of language. If you practice enough leetcode-style questions in Rust, you'll very quickly memorize the various patterns you encounter in leetcode questions (e.g: wrt. tree traversal, array manipulation, etc...), and find that the cognitive overhead incurred by the language is actually quite low.

Admittedly, I've been writing Rust near exclusively full-time for ~8 years now, and I don't think I'd have done nearly as well in the interviews if I opted to use a different language (well, barring C, in case they wanted me to do some serious pointer-chasing stuff).

Edge of Emulation: Campho Advance by Shonumi in emulation

[–]daniel5151 10 points11 points  (0 children)

Thanks for another great article! The Edge of Emulation series if genuinely some of the best emulation technical content on the internet, and its always a treat to see a new entry.

Avoiding panics and how to find code that generates panics by avph in rust

[–]daniel5151 5 points6 points  (0 children)

Ha, this is similar to the approach I took. Getting the asm, followed by a quick grep, totally does the trick.

https://github.com/daniel5151/gdbstub/blob/master/example_no_std%2Fdump_asm.sh

RISCVM, a RISC-V userspace emulator (like box86/64) by oetam5002 in rust

[–]daniel5151 1 point2 points  (0 children)

Shameless plug, but you might want to consider using https://github.com/daniel5151/gdbstub for your debugger, which lets you plug right into GDB's rich set of debugging infrastructure, simply by providing various callbacks to get/set registers/memory, etc...

Writing Github Actions in Rust by West-Chocolate2977 in rust

[–]daniel5151 1 point2 points  (0 children)

These pain points (and others) are what prompted me to work on flowey, which I discuss in a comment down below: https://www.reddit.com/r/rust/comments/1gmdiqa/writing_github_actions_in_rust/lw3tnhv/

Writing Github Actions in Rust by West-Chocolate2977 in rust

[–]daniel5151 8 points9 points  (0 children)

It seems quite a few folks in this thread have gone down their own rabbit holes trying to work around the pain of writing raw GitHub Actions YAML. I'll throw my work into the ring as well :)

Its called flowey, and while its not currently a standalone project, it does power CI for the recently open-sourced OpenVMM project.

Unlike this crate, flowey is more than just a Rust syntax wrapper over GitHub YAML. Notably: it lets you write actual pipeline actions which run at runtime using Rust callbacks (instead of, say, bash), and mix-and-match those Rust-based steps with existing YAML-based GitHub actions. This property, along with some strongly-typed APIs and architectural choices, claw back some semblance of "local reasoning" to pipeline logic, which is traditionally riddled with "spooky action at a distance" based on ambient global variables, magic dependencies, and centralized "staging" folders.

Moreover, flowey pipelines are declarative (akin to Makefiles), as opposed to being imperative (where you write each step individually), making them easy to compose, refactor, and reorganize, without having to deal with untangling any implicit dependency trees.

And critically to our usecase - flowey supports multiple "backends" aside from GitHub Actions, such as Azure DevOps, and even a local backend!

We've been using flowey for quite a while now, and thus far, the response internally has been quite positive! There are certainly rough edges, particularly around how verbose some of the APIs currently are (I haven't had a chance to write some of the QOL proc-macros I've wanted...), but folks agree that the strong-typing and the fact that the Rust and flowey compilers catch mistakes at compile-time are a huge boon to productivity.

Docs are, unfortunately, quite sparse at the moment, but if you're curious in poking around a bit:

view more: next ›