u/Ok_Path_4731

Hi, happy to present to the community the challenging work and solution for the objective we had: Build an OS like environment that feels like a UNIX environment on top of webasm, where apps can run multi-process, multi-threaded. For several reasons we did not want to use WASI, instead we decided to work against FreeBSD like libc. There is lot of story to be said, in case there is interest. The tool was written for the yetty terminal app (https://github.com/zokrezyl/yetty), so that simple programs can be written in WASM and run in any environment where yetty runs: https://github.com/zokrezyl/yos. The intention is also to embedd yos into yetty, so that the user can run plugins inside the terminal.

Are you using Artificial Intelligence in your daily coding activity?

Have been implementing the last two years in my spare time Yetty terminal. It is the result of decades of observations, frustrations, imagination and bunch of other 'tions'. Among others the thought was, why do I need to leave the terminal, thus focus, to just view a pdf file, a plot, a CAD drawing, an animation etc. Or search for alternatives on a different platform for a pdf viewer or svg viewer. Or find even more complicated workarrounds when I login to a remote that does not have graphical tools, but I could render stuff on my local terminal remotely. That is Yetty: Am very curious about your opinion. Features are endless:
* you can render UI, rich text with shapes using SDF vector graphics and MSDF fonts
* we implemented a remote dawn rendering, thus you can remotely render to a virtual Dawn Webgpu surface
* we implemented an efficient remote rendering also for IMGUI.

Github: https://github.com/zokrezyl/yetty
Demo: https://yetty.dev

Hope you enjoy it

Hi, while I have difficulties to find a good motto for the work I have been taking care the last 2 years, but with ideas I have been collecting for decades, Yetty itself in in early beta version.

Born from frustrations related to constant context switch and Ideas I gathered over the last few decades. Why should I switch to another app just to view a pdf file, see the plot of a complex math function or audio buffer or a sequence diagram of a complex workflow. All this even with a remote connection to your home server or a server in the cloude. All these are now in yetty. Please do both yourself and me a favour and have a look at it. Your opinion would be more than helpfull to drive the future of Yetty. You have a live demo at https://yetty.dev. The demo gives you an idea of what you can do with YETTY. The Ygreeter app is started automatically when the terminal is started. The source code lives at https://github.com/zokrezyl/yetty . Thank you

PS: it uses extensively Webgpu

Have been working the last good couple of months on a new terminal. Born from frustrations related to constant context switch and Ideas I gathered over the last few decades. Why should I switch to another app just to view a pdf file, see the plot of a complex math function or audio buffer or a sequence diagram of a complex workflow. All these are now in yetty. Please do both yourself and me a favour and have a look at it. Your opinion would be more than helpfull to drive the future of Yetty. You have a live demo at https://yetty.dev and source code at https://github.com/zokrezyl/yetty . Thank you

Hi r/cpp,

I've been working on ycetl, a small header-only library that takes on the "build a data structure at compile time, ship it as a runtime constant" problem.

The core trick is a multi-type memory backbone: instead of a std::byte* arena that requires void* → T* casts (forbidden in constant evaluation in C++20/23, only legal in C++26 via P2738), you enumerate the type set up front and the allocator becomes a tuple<Backend<T>...> indexed at compile time. Every allocation stays typed end-to-end. No erasure anywhere.

On top of that, the usual STL shapes — dynamic_array (vector-shaped), flat-sorted set/map, open-addressing unordered_set/unordered_map, the multi* variants, stack, priority_queue, span, bitset, unique_ptr, shared_ptr + weak_ptr. Every container is tested under static_assert(lambda()) and at runtime, with the same code.

Small taste — sieve at constexpr time, result baked into .rodata:

constexpr auto compute_primes() {

primes_result<32> out{};

ycetl::default_memory<bool, std::pair<int,int>> mem; // working memory

auto sieve = mem.allocate<bool>(101);

auto records = mem.allocate<std::pair<int,int>>(32);

// ... sieve + collect into records + copy into out ...

return out; // result memory

}

constexpr auto baked = compute_primes();

static_assert(baked.records[24].first == 97);

There's also a worked example that drives libclang against dawn/webgpu.h and emits both a Python ctypes binding and a constexpr C++ tree of the same API — same source, two consumers.

Where it sits next to C++26. The "less-transient constexpr allocations" work (P3032) + the void* cast (P2738) tackle the same problem from the opposite direction: make the compiler smart enough to

promote std::vector-shaped allocations to static storage. ycetl is the explicit-control side of that trade — you write the type set and the result-shape, in exchange you get a transparent layout, no

void* round-trips, no proof-obligation on the compiler, and it runs on shipping GCC 12+ / Clang 16+ today. There's a section in the README laying both sides out honestly; I'd genuinely like to hear which trade people here prefer.

Honest about gaps: a few headers from an earlier design (vector.hpp, list.hpp, basic_string.hpp) haven't been ported and their tests are gated off. No real deque/queue yet. Single-threaded by design the smart-pointers use non-atomic counts.

Repo: https://github.com/zokrezyl/ycetl

Critique welcome — especially from anyone who's tried this kind of design and hit walls I haven't yet.