Rust

I'd like to know if anyone has succesfully flashed a board using their own FTDI chip and not a commercial debug probe.

I want to get into using Rust and I have these STM-based boards where I put an FTDI chip on them so I get a convenient USB-port for power and debug and flashing. I'd really like to get some Rust-software running but I've just hit walls so far with flashing the boards. They work fine when using platformio/openocd and C++ but nothing has worked so far for using "cargo embed" even though it seems to find the FTDI chip correctly and start flashing but then times out.

I'd love to know if anyone has a similar setup working or can give tips on what I could try.

cross-posted from: https://programming.dev/post/18265389

Hello again everyone, Dihar here. It's been a while since the last release of treedome, but here you go! This release is all about UI update, emojis, and bug fixes. Please consult this git diff for a more detailed changelog https://codeberg.org/solver-orgz/treedome/compare/0.4.5...0.5.0. These are the highlight of the release.

• Add emoji picker for title, will show up in tree!
• Text Editor toolbar is back, now with option to toggle both toolbar and floating menu independently!
• Checkbox is here! Thanks Mantine UI!
• You can check the size of each notes by navigating to Escape Menu -> Configure -> Show Note Sizes!
• Add created/last modified date in notes. Note created before this will not have this field and will set as today's date!
• Create child note can now be done through dropdown instead of only from shortcuts!
• Fix bugs of saving empty tree
• General UI update and more stability for auto scrolling in tree view
• Documentation update

I wrote a quick blog post about a pattern I discovered while building TUI applications in Rust. It's a bit unrefined, and I'm working on package to help make the pattern easier. Let me know what you think!

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) {
    // We use `expect()` in debug mode as a layer of safety in order
    // to detect any possibility of undefined bahavior.
    enemies.expect("*message*");
    } else {
    // SAFETY: The `if` statement (if self.body.overlaps...) must
    // run only once, and it is the only thing that can make
    // `self.enemies == None`.
    unsafe { enemies.unwrap_unchecked() }
};

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

// The 'U' stands for 'unsafe'.
pub trait UnwrapUExt {
    type Target;

    fn unwrap_u(self) -> Self::Target;
}

impl<T> UnwrapUExt for Option<T> {
    type Target = T;

    fn unwrap_u(self) -> Self::Target {
        if cfg!(debug_assertions) {
            self.unwrap()
        } else {
            unsafe { self.unwrap_unchecked() }
        }
    }
}

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.

Excerpt:

This is a reconstruction -- extracted and very lightly edited -- of the "prehistory" of Rust development, when it was a personal project between 2006-2009 and, after late 2009, a Mozilla project conducted in private.

The purposes of publishing this now are:

• It might encourage someone with a hobby project to persevere
• It might be of interest to language or CS researchers someday
• It might settle some arguments / disputed historical claims

Rust started being developed 18 years ago. This is how it looked until 14 years ago, where I believe the rest of development is on rust-lang/rust. The first Rust program looks completely different than the Rust we know today.

Table of Arena Crates

For a technical discussion of using arenas for memory allocation with an example implementation, see gingerBill's Memory Allocation Strategies - Part 2: Linear/Arena Allocators

Planning to build a PC in couple of weeks.

What is the optimal number of cores to have without having diminishing returns?

Hey there, I'm currently learning Rust (coming from object-oriented and also to some degree functional languages like Kotlin) and have some trouble how to design my software in a Rust-like way. I'm hoping someone could help me out with an explanation here :-)

I just started reading the book in order to get an overview of the language as well.

In OOP languages, I frequently use design patterns such as the Strategy pattern to model interchangeable pieces of logic.

How do I model this in Rust?

My current approach would be to define a trait and write different implementations of it. I would then pass around a boxed trait object (Box<dyn MyTrait>). I often find myself trying to combine this with some poor man's manual dependency injection.

This approach feels very object oriented and not native to the language. Would this be the recommended way of doing things or is there a better approach to take in Rust?

Thanks in advance!

EventHelix writes:

This article will investigate how Rust handles dynamic dispatch using trait objects and vtables. We will also explore how the Rust compiler can sometimes optimize tail calls in the context of dynamic dispatch. Finally, we will examine how the vtable facilitates freeing memory when using trait objects wrapped in a Box.

Maybe a little weird question but do you maybe know a smart watch that can run rust? I got running Egui on my Galaxy Watch 4 with WearOS and I'm thinking if any other watch (other than Galaxy and Pixel) can do that?

archived link

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

This feels like it should already be a feature in a terminal. But I didn't find anything that let me do this efficiently.

I had a rust library for converting list like 1-4,8-10 into vectors, but thought I'd expand it into a command line command as well, as it is really useful when I want to run batch commands in parallel using templates.

I wanted to share it since it might be a useful simple command for many people.