It doesn't have browser support yet because it's WASI-based, so there are a few more steps compared to Emscripten (two different ways to build for WebAssembly). But networking is supposed to work, did you have trouble with it?

I didn't try it. Given jslinux exists, and works, i suspect WASM based linux will be faster and more streamlined.

With RISC‑V emulation we get the virtual hardware components we need to boot Linux like MMU, registers etc. So a GCC WASM backend could definitely help, but I'm not sure it could replace the whole emulation layer.

It's a bit of a cheat, but you can hit 0.00% every time. Just measure the bar length, then cross-multiply. :)

Example: bar is 1250px, max is 2100, number is 376 → (1250 × 376) / 2100 ≈ 223.8px from the start, that's the 0.00%.

Working on a RISC-V emulator targeting Wasm. Is RVV 1.0 stable enough to be worth implementing, or would Zve32f/Zve64d already cover most use cases ?

That's cool, i did exactly the same few years ago

Nice, what are you building exactly ?

We are building cloud-native agent harnesses.

I am in the EU timezone and had some minor issues recently with GitHub as well, but it never lasts very long.

The worst that could happen is having your credentials stolen. It’s an LLM architectural flaw, so it has to be at the tools level so the only way to prevent it is still sandboxing in my opinion. Or at least sandboxing the tools themselves

I think a shared array just avoids the copy, not the serialization which is the main problem as they showed with serde-wasm-bindgen test

You can avoid the serialization in WASM by pushing structured bytes to the SharedArrayBuffer, then do serialization in JS which should be relatively cheap compared to pushing JSON strings across the boundary.

Wait, you just invented a reverse CAPTCHA for AI agent

The ole' click this button 10,000 times to prove you're a bot, eh?