In case the wording tripped anyone, generators (blocks and functions) have been available for a while as an unstable feature.

This works (playground):

#![feature(gen_blocks)]

gen fn gfn() -> i32 {
    for i in 1..=10 {
        yield i;
    }
}

fn gblock() -> impl Iterator<Item = i32> {
    gen {
        for i in 1..=10 {
            yield i;
        }
    }
}

fn main() {
    for i in gfn() {
        println!("{i} from gfn()");
    }
    for i in gblock() {
        println!("{i} from gblock()");
    }
}

Note that the block-in-fn version works better at this moment (from a developer’s PoV) because rust-analyzer currently treats gfn() as an i32 value. But the block-in-fn pattern works perfectly already.

Traditional server-based self-hosting will have lower average uptime, will be easier to attack, and will have a much higher chance of disappearing out of nowhere (bus factor event, or for any other reason).

A decentralized or distributed solution would make more sense as a suggestion here. Radicale (this one) is such an effort I’m aware of, although I never tried it myself or take a look at its architecture.

Is there a tiling Wayland compositor out there that supports applying custom shaders to windows (similar to picom)? This has been a known limitation for many years. And I brought it up myself with a couple of compositors’ developers, and they told me that it would break direct scan-out, and I told them that I would be fine with that, and then discussions fizzled out.

I also tried an x11vnc alternative I don’t remember the name of, and besides the generally buggy experience, it completely broke when power management kicked on the sever side (turning off the monitor IIRC). So that’s another show stopper, although maybe not as relevant as custom shader support which I need for applying my custom color inversion shaders to specific windows, otherwise, my vision would go bad quickly.

So yeah, I will be sticking with my Awesome WM (+picom +x11vnc) setup for a while too.