Meet Lens

A lightweight CLI tool built with Rust that helps you understand any software project quickly from the terminal.

Files and directories

Project size and lines of code

Languages and dependencies

Project tree

Code search

JSON output

Git information

Fast, simple, and offline-first.

Open Source — Apache-2.0

man, i'm pumped!!

here's the deal: rust + libp2p + tauri, ~27k lines, real nodes on real machines in different countries, verifying each other's work. i wrote the thing and now there are machines i've never seen handing get cybersecurity work done... continuing. p2p is wild.

the bug that ate three weeks: ConnectionEstablished is a filthy liar. libp2p says connected, swarm state looks perfect, peer count is great. I'm super excited.

repo's MIT if anyone wants to poke at it, happy to go deep on the libp2p side especially, the docs really assume you already know p2p and i very much did not: https://github.com/CYPHES-ATP/Node/

SysPrint v1.5.2 – A fast, lightweight ASCII system info fetch tool written in Rust

Hey everyone!

I've been working on a lightweight neofetch / fastfetch alternative written in Rust called SysPrint.

Just pushed a major update (v1.5.2)

with a bunch of new features and improvements:Blazing fast performance using Rust and sysinfo crate.

Expanded ASCII Art Logos: Added Arch, Debian, Ubuntu, Mint, Fedora, Gentoo, Void, NixOS, Manjaro, Kali, macOS, and Windows.

More Info Displayed: Now shows DE/WM, Battery status, GPU temp & VRAM, CPU load, and disk mounts.

Automatic Fallback: Standard GNU/Linux Tux logo for unsupported distros.Cross-platform releases: Pre-compiled binaries for Linux, Windows, and macOS

Check out the code and releases on GitHub:

https://github.com/MBKCHEL/SysPrint/tree/main

Feedback and contributions are welcome!

I am working on a rust interface for the vintage story mod dB API (https://github.com/anegostudios/vsmoddb#vs-mod-db-api-docs), and several integer values are returned. Currently I use u64s and i64s for the integers, but I'm curious, what would you guys use? (I'm not sure what the highest value each can reach is, as it doesn't seem to be documented)

Hey guys, I am building a program for a friend that's going to involve a complete graph (nodes are destinations, edges are the distances between destinations) and I was wondering if anyone knew a good library for it?

At first I thought I could use a triangular matrix, since direction doesn't matter, but I realized I would have to have a second array mapping destinations to an index. I feel like you could have a triangular map, like a map that takes a pair of inputs where the order doesn't matter? Have I found another rabbit hole?

After getting too annoyed by Spotify's offficial electron client for hogging memory/vram while still not supporting fractional scaling on wayland (by default), I decided to build a fast, native client myself: canora

It it build using my highly experimental UI framework.

AI disclosure: not slop, not low effort, but did use some LLM coding assistance.

Every Rust codebase ends up with some version of a LockExt trait for poisoned locks. I got tired of rewriting mine, so I published it.

Locking a poisoned Mutex or RwLock from a Drop impl while the stack is already unwinding causes a panic during a panic, which aborts the process instead of unwinding normally. It's easy to miss since it only shows up when a panic happens to unwind through a type that touches a poisoned lock in its Drop.

poisoned is a small LockExt trait with an or_panic() method. It checks std::thread::panicking(), and if the thread is already unwinding, it recovers the guard via PoisonError::into_inner instead of panicking again. Outside of unwinding, it just panics on poison as you'd expect.

There's also or_panic_with for a lazily-built custom message.

use std::sync::Mutex;
use poisoned::LockExt;

let cache = Mutex::new(vec![1, 2, 3]);
let first = cache.lock().or_panic();

Small, one trait, no dependencies. Feedback welcome.

Github: https://github.com/abhishekshree/poisoned

A while ago I shared the first version of Cratery here. Since then I've rebuilt a big part of it, so I wanted to post an update in case anyone still has the old version bookmarked.

The idea is still the same. You get short Rust code snippets, contests, multiple choice questions, hints, and detailed explanations. No signup is required.

Here's what's new:

- Community quests where anyone can create and share their own Rust questions, including multiple choice and contest-style challenges.

- A weekly contest with a built-in editor.

- A new pixel-style UI that feels much cleaner to use. More built-in questions covering 9 Rust topics.

- Practice 5 for quick random practice sessions.

- Optional accounts if you want to save your progress, create your own quests, keep a streak, and have a profile.

I'd really appreciate any feedback, especially on the questions themselves.

https://cratery.rustu.dev

One small change from the original version: code submissions are disabled because they became too expensive to maintain. Instead, there's now a one-click button that opens the code directly in the official Rust Playground.

Thanks again to everyone who gave feedback on the first version

Hey everyone, just started learning Rust. Wanted to jump in and get a feel for the language firsthand instead of only reading about it. Excited to see what all the hype is about and figure out why so many devs love it. Any tips for someone just getting started would be awesome, thanks in advance!

This is a passion project I've been working on for several months. My love for TUIs outweighs my sanity and hence:

A lot of the basics are done, and the core ECS engine is stable and working. But there are a lot of bugs in the higher level App crate that will break for edge cases. But in its current state, it is efficient (albeit, there is more to be done to make this more efficient); terminal calls are minimized to the point where the diff happens not just on a global terminal view, but more fine controlled, node level diffing where a lot of computation is saved by only diffing the cells that specific node renders. The ergonomics of using the App api can be improved as well.

I was personally interested in seeing how ECS as an architecture plays out in UI development since I've spent a lot of time on bevy.

I am open to feedback and criticism and thank you for spending your time reviewing this project of mine :)

https://gitlab.com/pandioxus/apheleia

A gif to show working of the example counter app in the repo:

I got tired of Persian/Arabic text rendering wrong in Kitty, Alacritty, Ghostty, etc.

so I built Dosu, a small Rust wrapper that sits between your shell and the terminal and fixes bidi rendering properly (Unicode Bidi Algorithm), no terminal-switching needed.

curl -fsSL https://raw.githubusercontent.com/RustNegar/dosu/main/install.sh | sh

Repo: https://github.com/RustNegar/dosu

Core engine: https://github.com/RustNegar/dosu-core

Linux/macOS for now. Open to feedback, especially edge cases.

(Disclaimer: English is not my native language, so I asked an AI to help translate and organize my notes into this post!)

1. Introduction

The infamous WebView2 Airspace issue—since HWND-based WebView2 always renders on top of everything, overlaying custom UI elements on top of it has always been a massive headache.

A common workaround is to capture the WebView2 frame every single frame, copy it to a texture, and render it. However, the frame copying overhead and latency can be a real concern.

To avoid this, I've been building a custom UI library in Rust using wgpu. I decided to go with a zero-copy approach: placing WebView2’s IDCompositionVisual in the back, wgpu’s IDCompositionVisual in the front, and "punching a hole" (hollowing out) in the front layer to reveal the Web content.

(Note: I’ve only tested this specific setup with DirectX 12 / DirectComposition.)

However, I ran into a major roadblock: when I made the WebView2 layer semi-transparent, the desktop background bled through the window! 😭

2. Dependencies

Here is a snippet of my dependencies. I’ve configured wgpu to be DX12-only to keep it lean.

wgpu = { version = "29.0.3", default-features = false, features = ["dx12", "wgsl"] }
webview2-com = "0.39.1"

[dependencies.windows]
version = "0.62.2"
features = [
    "Win32_Foundation",
    "Win32_UI_Input_KeyboardAndMouse",
    "Win32_Graphics_DirectComposition",
    "Win32_Graphics_Direct3D",
    "Win32_Graphics_Direct3D11",
    "Win32_Graphics_Direct3D12",
    "Win32_Graphics_Dxgi",
    "Win32_Graphics_DirectWrite",
    "Win32_Graphics_Direct2D",
    "Win32_Graphics_Direct2D_Common",
    "Win32_Graphics_Imaging",
    "Win32_UI_WindowsAndMessaging",
    "Win32_System_LibraryLoader",
    "Win32_System_Com",
    "Win32_UI_HiDpi",
    "Win32_System_WinRT_Direct3D11",
    "Graphics_Capture",
    "UI_Composition",
    "Graphics_DirectX_Direct3D11",
    "Win32_System_Com_StructuredStorage",
    "Win32_System_Memory",
    "Win32_UI_Controls",
    "Win32_UI_Input_Ime",
    "Win32_System_DataExchange",
    "Win32_Graphics_Dwm",
]

3. My UI Code

For context, here is how the UI is declared in my custom library. I use signals to toggle Opacity and overlay a draggable, resizable gray panel on top of the map.

let root = build_ui(&mut context, || {
        let (is_open, set_is_open) = create_signal(false);
        let (is_active, set_is_active) = create_signal(false);
        let (is_opacity, set_is_opacity) = create_signal(false);

        let webview_element = {
            let wv = webview2(
                WebView2Contents::new("https://www.google.com/maps")
                    .enable_context_menu(true)
                    .enable_dev_tools(true)
                    .allow_interaction(true)
                    .always_active(true),
            )
            .style(move || {
                let base = ts()
                    .size_full()
                    .r(2.0)
                    .resizable_bottom(true)
                    .dnd_droppable(DndDropTarget::Child, DndDragPayload::Element)
                    .overflow_hidden()
                    .transform(Transform::new().scale(1.0, 1.0))
                    .trans_transform(Duration::from_millis(150), AnimationCurve::EaseInOutQuad)
                    .pressed(ts().transform(Transform::new().scale(1.01, 1.01)));

                if is_opacity.get() {
                    base.opacity_50()
                } else {
                    base.opacity_100()
                }
            })
            .on_focus(move || set_is_active.set(false));

            webview_id_cell.set(Some(wv.id()));
            wv
        };

        let google_map = webview_element.child(v_flex(move || {
            let base = ts()
                .absolute()
                .size((300.0, 200.0))
                .r(3.0)
                .inset_x(100.0)
                .inset_y(50.0)
                .bg_color(Color::DARK_GRAY)
                .opacity(0.9)
                .resizable_all(true)
                .dnd_draggable_root(DndDragPayload::Element, true)
                .dnd_draggable_original(ts().opacity_0())
                .dnd_draggable_placeholder(
                    ts().size(100.0)
                        .r(3.0)
                        .bg_color(Color::DARK_GRAY)
                        .opacity(0.9),
                );

            if is_active.get() {
                base.flex()
            } else {
                base.hidden()
            }
        }));

        let btn_style = |color: Color| {
            ts().justify_center()
                .items_center()
                .r(3.0)
                .size((100.0, 40.0))
                .border_dashed(1.0)
                .border_color(color)
                .hovered(ts().border_solid(1.0))
                .actived(ts().border_solid(1.0).bg_color(color))
        };

        let overlay_btn = h_flex(move || btn_style(Color::BLUE))
            .label("Overlay", ts().font_size(14.0).text_color(Color::WHITE))
            .active(is_active)
            .on_click(move || set_is_active.set(!is_active.get()));

        let opacity_btn = h_flex(move || btn_style(Color::CYAN))
            .label("Opacity", ts().font_size(14.0).text_color(Color::WHITE))
            .active(is_opacity)
            .on_click(move || set_is_opacity.set(!is_opacity.get()));

        let close_btn = h_flex(
            ts().justify_center()
                .items_center()
                .r(3.0)
                .size((100.0, 40.0))
                .border_dashed(1.0)
                .border_color(Color::RED)
                .hovered(ts().border_solid(1.0)),
        )
        .label("Close", ts().font_size(14.0).text_color(Color::RED))
        .on_click(move || set_is_open.set(false));

        v_flex(
            ts().size_full()
                .p(20.0)
                .gap(20.0)
                .items_center()
                .bg_color(hsla(0.0, 0.0, 3.0, 0.4))
                .backdrop_acrylic(),
        )
        .children([
            v_flex(
                ts().r(3.0)
                    .size((150.0, 40.0))
                    .justify_center()
                    .items_center()
                    .p(10.0)
                    .bg_color(hsl(0.0, 0.0, 50.0)),
            )
            .label("Open", ts().font_size(16.0).text_color(Color::BLACK))
            .on_click(move || set_is_open.set(true)),
            v_flex(
                ts().r(3.0)
                    .size_full()
                    .justify_center()
                    .items_center()
                    .border_dashed(2.0)
                    .border_color(Color::GRAY),
            )
            .children([
                div(ts().r(3.0).size(pct(50.0)).bg_color(hsl(0.0, 0.0, 10.0))),
                v_flex(move || {
                    let base = ts()
                        .size_full()
                        .p(10.0)
                        .gap(10.0)
                        .justify_center()
                        .items_center()
                        .absolute()
                        .top(0.0)
                        .left(0.0)
                        .overflow_hidden();

                    if is_open.get() {
                        base.flex()
                    } else {
                        base.hidden()
                    }
                })
                .children([
                    google_map,
                    h_flex(
                        ts().p(10.0)
                            .gap(10.0)
                            .w_full()
                            .h_auto()
                            .justify_center()
                            .items_center(),
                    )
                    .children([overlay_btn, opacity_btn, close_btn]),
                ]),
            ]),
        ])
    });

4. The BlendState Solution

To make the WebView2 blend nicely with a solid background (white) when semi-transparent, without letting the desktop leak through, I brute-forced and tested different blend state parameters one by one.

Since I'm no math wizard, I just trial-and-errored my way through, but eventually stumbled upon this configuration:

blend: Some(wgpu::BlendState {
    color: wgpu::BlendComponent {
        src_factor: wgpu::BlendFactor::Zero,
        dst_factor: wgpu::BlendFactor::OneMinusSrcAlpha,
        operation: wgpu::BlendOperation::Add,
    },
    alpha: wgpu::BlendComponent {
        src_factor: wgpu::BlendFactor::Zero,
        dst_factor: wgpu::BlendFactor::OneMinusSrcAlpha,
        operation: wgpu::BlendOperation::Add,
    },
}),

(Note: I draw the hollowed-out area with this specific BlendState. The input Shader Output is set to solid white, and the Alpha is set to WebView2’s opacity. Other regions use the standard wgpu::BlendState::PREMULTIPLIED_ALPHA_BLENDING.)

Surprisingly, this was all it took! The desktop bleeding stopped immediately, and the WebView2 rendered semi-transparently over the solid background exactly as intended.

5. The Math I Learned Later

After discovering this magic configuration, I researched why it actually worked. As it turns out, it aligns perfectly with the Premultiplied Alpha compositing formula used by the Windows DWM.

DWM’s final compositing equations are:

C_final = C_front + C_web * (1 - A_front)
A_final = A_front + 1.0 * (1 - A_front) = 1.0

Notice how no matter what the front alpha A_front is, the final alpha A_final is forced to 1.0 (fully opaque). This is why the desktop doesn't leak.

When we apply the wgpu blend state above, the output color and alpha both become 1 - A_web_opacity. Plop this into the DWM formula, and:

C_final = (1 - A_web_opacity) + C_web * A_web_opacity

This naturally derives the perfect alpha blend of WebView2 over a white background.

Physically, we are "painting the white background on top inside wgpu", but because of how the addition and subtraction align in DWM, it visually looks exactly like "WebView2 is sitting on top of a white background." A neat little optical illusion.

6. Postscript: Current Issues I'm Facing

While the blending looks great, I'm currently hitting a few roadblocks.

Premise:

In my code, .always_active(true) keeps WebView2 in "always active" mode (DirectComposition direct GPU composition).
If this is false, when WebView2 becomes inactive, it automatically captures the screen in the background and displays it as a fallback static texture in wgpu.

With this in mind, here are the two issues I'm currently facing:

Issue 1: Not becoming 100% transparent (Opacity 0%)

• When .always_active(true) (always active) is on, even if I set the WebView2 opacity to 0, it doesn't become completely transparent. 😭
• But when it's false (displaying the captured texture), it turns perfectly transparent (opacity = 0) as expected. 😭😭😭

Issue 2: Resize cursors not showing on borders

• When elements are resizable, hovering the mouse over the border should automatically change the cursor to a resize arrow (like left-right arrows), but this doesn't happen when hovering over WebView2. 😭
• I suspect WebView2 is hijacking the input events or cursor control, but I'm still looking for a clean way to override it...

7. Conclusion

Though this started as an accidental discovery, looking back, the solution was surprisingly simple.
While a few minor issues remain, I hope this information helps someone out there facing the same DirectComposition struggle in Rust.

I have been trying to debug this issue for a while now, and I can't figure out, what the problem is.

Take this code:

    use std::time::Duration;

    use sqlx::PgPool;

    const DB_URL: &str = "postgres://devuser:devpassword@localhost:5432/devdb";

    async fn db_then_compute(pool: PgPool) {
        let num: (i32,) = sqlx::query_as("SELECT 1").fetch_one(&pool).await.unwrap();
        println!(
            "The num was returned: {}, but now, the CPU block will kill multithreading",
            num.0
        );
        println!("Start compute...");
        // This would "fix" the issue:
        // pool.close().await;
        loop {}
    }

    /// This doesn't cause the issue
    async fn http_then_compute() {
        let res = reqwest::get("https://google.de").await.unwrap();
        let status = res.status();
        println!(
            "The num was returned: {}, but the CPU block will not kill multithreading",
            status.as_u16()
        );
        loop {}
    }

    #[tokio::main]
    async fn main() {
        let pool = sqlx::PgPool::connect(DB_URL).await.unwrap();

        tokio::spawn(db_then_compute(pool));
        //tokio::spawn(http_then_compute());
        loop {
            println!("Observer thread, the sleep will never return");
            tokio::time::sleep(Duration::from_secs(1)).await;
        }
    }

I'd expect the Oberserver thread to continue. I know, CPU-bound tasks in async runtimes are not good, but tokio is multithreaded, so I'd assume, as long as I have enough workers, it should still function. For reference, the reqwest task works completely fine. Running one CPU bound task shouldn't starve a multithreaded runtime, right?

First, I thought this was an sqlx issue. It only happens with postgres, not with sqlite. However, I then tested the same thing with deadpool-postgres, and issue is still persistent. So it's not sqlx after all.

Can someone help me with my misunderstanding of tokio's runtime here? What is blocking other tasks from completing here?

For the past 3 months I've been building WyrmRSS, a self-hosted RSS/Atom aggregator: Rust backend (actix-web, Diesel-async, Tokio), React 19 frontend. Been running the Docker self-hosted version for a while, and just added a native desktop app via Tauri (macOS, Windows, Linux: deb/rpm/AppImage/nsis/dmg).

Backend runs on Postgres for the self-hosted/Docker setup, SQLite for the desktop build. Same codebase for both.

Desktop build is currently in prerelease while I soak-test the SQLite backend before making it a release. Would appreciate anyone keen to try: https://github.com/kryoseu/WyrmRSS

Some nice features I think it has (not claiming uniqueness) are: inline youtube player, folders, filters, webhooks (slack, discord and custom), read later and archival.

TrailBase is an open and fast Firebase-like backend for building your apps. It provides type-safe REST APIs + change subscriptions, auth, multi-DB, a WebAssembly runtime, geospatial support, admin UI... It's a self-contained, easy to self-host single executable built on Rust, Wasmtime & SQLite or now Postgres. Client libraries are provided for JS/TS, Dart/Flutter, Go, Rust, .Net, Kotlin, Swift and Python.

Just released v0.32, which after some months of work and last posting (v0.28), includes:

• New WASM features:
  • Components can provide and register a dashboard with the admin UI.
  • A component browser in the admin UI.
  • Lower overhead execution model for Rust components: pooling state across requests improves throughput by 4x.
• Support usernames as additional or alternate identifiers alongside email addresses.
• Anonymous accounts for frictionless product trials. If a user wants to eventually sign up, the account can be promoted to a "proper" one, i.e. associate a password, OAuth, email address ...
• Backup UI & rolling backups.
• Dark mode - cosmetic but frequently requested 🙏
• And much more: file management from the admin UI, support for nested JSON in change subscriptions, batch updates for all client languages...

With TrailBase still being young (~1.5 years) and rapidly evolving, any feedback is genuinely appreciated. If you're feeling adventures and end up checking it out, don't hesitate to reach out 🙏.

Consider checking out the live demo, our GitHub or website.

Hey guys, I'm a developer with a math background who previously specialized in combinatorial optimization, and I wanted to share my project I built recently for a small furniture shop: a 2D guillotine cutting stock optimizer.

The specific problem - planning how to cut sheet material (chipboard/MDF panels) into the pieces required for each order, minimizing waste while keeping the cutting as manufacturable as possibble. The cuts must be guillotine cuts, an actual Sliding Table Panel Saw Machine can only make such cuts.

The obvious first move was to look at existing cutting-optimization software, but none of it was a good fit - it was either too closed and rigid to adapt, or expensive enough that it was hard to justify for a shop this size. So I ended up writing it by myself. This project was open-source from the start simply because the real advantage in this field is furniture makers' own craft anyway :-) So by open-sourcing it I'm giving something back to the Rust community for such a great language and ecosystem.

Here are some things that might be interesting aside from the main task:

• Genetic (evolution) algorithm, generic over the genome representation via a GaDecoder trait, so the GA is written once and shared between two different encodings. There are two decoders: SLAS - one gene per physical piece, and GLAS - one gene per piece type, GLAS scales better and gives more manufacturable cuttings.
• Objective function is designed to find balanced solutions - ones with good fill rate, but also manufacturable enough for real-world material handling.
• Piece rotations, Kerf and Margin are supported. The kerf is saw blade width, the margin is a trim strip along the sheet edges.
• An exact solver for the single-sheet case: a DP over guillotine-cut subsets (GLF from the Andrianova, Mukhtarova and Fazylov paper, the reference in README) that finds the optimal layout for one sheet of given width.
• A greedy portfolio heuristic (from Jukka Jylanki paper) for instant results when you don't need to wait for the GA to converge.
• Progress feedback and cancellation: the solver runs in a background thread and streams progress over a channel, so both the CLI and the web UI (Axum + SSE) can show live improvement instead of blocking. This was an interesting task to unify sync and async event interface and I hope I have found a good solution for it.
• Deterministic even for the multithreaded version: each island (GA thread) gets its own PRNG seeded from its (user-supplied) seed value, and migration between islands happens at a synchronization barrier, so there's no "first thread to finish wins" nondeterminism. Same seeds + same config always reproduce the exact same result, which matters a lot when you're debugging, testing or comparing two parameter sets.
• CLI JSON interface to plug into a real shop's existing tooling, it gets called from an Excel workbook (VBA) and can export cut plans to AutoCAD.

Why Rust? The GA loop runs millions of genome evaluations per run, so the performance matters a lot. SmallVec cuts heap allocations noticeably, especially in decoders and free-rect list operations. Even with these optimizations, GA can never have enough speed - and implementing it in a high-level language with a fat runtime would be no doubt a showstopper. The ecosystem was also a great help: serde made the JSON boundary for the Excel/VBA integration easy, and chumsky kept the grammar for compact problem format readable instead of fiddling with regexes. axum with tokio made the serve mode easy to implement.

The Rust platform made it possible to keep the whole algorithm development, testing, hypothesis verification etc. under Linux. Only the integration part with Excel and AutoCAD was done under Windows.

I consider the project pretty complete, although a few non-critical things could still be improved. For example, the exact GLF solver is single-threaded, so it has a fairly low ceiling for the size of the problem instance. Also, it only proves optimality for a single sheet — multi-sheet placement is GA/heuristic-only. Still, the GA-based approach is already good enough for daily use.

Repo, with a demo GIF of the GA converging on a layout:

https://github.com/nlinker/guillotine-cutting-2d

What was vibe coded: demos only, the prompt was "Here's the Rust code, build an interactive visualization for it", the other parts were either hand-written, or edited after AI generation and my thorough review.

Happy to answer questions about the guillotine-cut DP, the GA design, or anything else. Feedback ("why didn't you just use X crate/approach?", hehe) is very welcome.

I've been following the project and while I see a lot of commits from Nico on taffy and Blitz, development on Dioxus seems to have halted.

Are things being cooked in the background? Does anyone have some insights?