Rust

Hey all, just sharing a small, single-page site I built using Leptos + TailwindCSS, mainly intended as a demo for an API I built using Axum. Hope someone also finds it interesting!

I'm sharing this site and not the API itself cause I figure it's easier to look at and understand, but if you want to roast some code I would appreciate any feedback you have on the API itself (repo here). Trying to leave the front end developer scene so this is the first API I've tried building, fairly basic but it was fun (I am a big Civ V fan - I hear it's inspired by some niche thing called human history?).

Edit: whoops, looks like the link didn't get set cause I put an image - the site is available here, and the repo for it is here. The live API is available here

In case you haven't seen it, here's a talk regarding Rust's integration into the Linux filesystem that gets completely derailed at The Linux Storage, Filesystem, Memory Management and BPF Summit.

After reading Drew's pitch to the rust community to write our own kernel, I've searched for "linux abi compatible rust kernel" and found "Asterinas". Surprised that it is not mentioned here

So I'm trying to parse school's website for some info. I'm trying to get some values using xpath. So I found a html 5 parser and it can't properly parse the first line. Then I figure you it's actually XHTML and not HTML. After quick Google search I found out XHTML can be properly parsed using any XML parser and so I found one and... It can't parse the first line. So I ask LLama3.1 (like a real programmer) why I can't parse the first line with any parser. It explained so nicely that I did not destroy my keyboard when I was told that this document is "XHTML 1.0 Transitional" and it's a mix of HTML 4 and XHTML and can't be parsed with HTML nor XML parser. I hate the guy that invented that so much...

So I can't find a crate to parse XHTML 1.0 transitional? Or a crate to convert xhtml to something else? Any advice?

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

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