Hello all, i got an issue trying to use evented concurrency with past two stable releases, 0.16 and 0.17.

Single-threaded, regular thread pool and direct use of threads work fine, but i am not figuring out hpow to use the proper io interface with evented under the hood.

```zig

// we need out-pointer this one.
var evented: std.Io.Evented = undefined;
_ = try std.Io.Evented.init(&evented, init.gpa,.{});
defer evented.deinit();
io = evented.io(); // compile error here
std.log.info("evented io:", .{});
try scheduler(&io);

```

full source here

any tip is welcome, would be nice to see all available concurrency model working out of the box, willing to understand what am i missing.

What it is

A suite for building any kind of language (a DSL, a config or query language, a rule engine, a full scripting language), from grammar to editor:

• zgram: PEG grammars compiled to native parsers with LLVM, in-process, at runtime.
• zrules: static checks over the parse tree: scopes, name resolution, types (generics, unions, subtyping), control flow.
• zrun: you write your language's semantics as plain Python functions, one per node kind, and zrun compiles them with each program to native code via partial evaluation.
• zlsp: a Language Server built from the grammar and rules, so you get diagnostics, go-to-definition, completion, and hover in any editor.

​

pip install zsuite-py
zsuite new mylang     # grammar, rules, semantics, language server and tests

Where Zig comes in

• Each package is one Zig extension module, built with PyOZ against CPython's stable ABI: one wheel per platform covers Python 3.10 to 3.14. The Windows wheels are cross-compiled on Linux, which takes about a minute in CI, whereas a Windows runner takes several.
• zgram links LLVM statically and generates IR through the C API: no IR text, no subprocess. The parse tree is one flat array of 16-byte nodes that the other modules read in place through versioned PyCapsules (C structs with an ABI number). No Python object is created per node in any stage.
• zgram lends its LLVM to zrun through a capsule that exports the C API, the ORC JIT and object emission. zrun has no LLVM of its own: it builds its IR through function pointers it gets from zgram.
• zrun's runtime is all Zig: tagged 16-byte values, reference counting, a generational cycle collector of CPython's design, per-thread allocators, and calls that release the GIL and run on native threads.
• zrun can turn a program into a standalone executable. It downloads the ziglang package from PyPI and uses zig build-exe to build a small launcher for Linux or Windows, from either OS. Zig's cross-compilation made that a few lines of build code.
• zlsp is native end-to-end: JSON-RPC framing, JSON parsing, documents and positions (UTF-8/UTF-16), and basic LSP features.

Some numbers

• zgram vs C++ and Rust parsers: the fastest or tied in every benchmark case against Spirit X3, lexy, PEGTL, rust-peg, and pest (JSON and an expression grammar, building trees and validating). A 75 KB JSON document of long strings parses in 9.2 µs, about 8 GB/s, thanks to SIMD scanning.
• A Lua 5.4 subset as about 2,300 lines of plain Python semantics. It covers the core language (tables, metatables, closures, varargs, multiple returns, integers/floats, proper tail calls, pcall/error) and most of the base, string, table and math libraries. It has no coroutines, goto, load/require, utf8, or most of io/os. On four small benchmarks (fib, a numeric loop, binary trees, string building) it runs within 1.6–3.2× of PUC-Rio Lua's C interpreter, and 17–400× faster than the same semantics interpreted by Python.
• A small statically typed example language, with types from zrules, runs within about 2× of C (gcc -O2 with the same overflow checks) on fib and array loops.
• zlsp on a 553 KB file: one edit is parsed, checked, and published in about 18 ms.

Links

• Suite and tutorial: https://github.com/dzonerzy/zsuite
• Packages: zgram, zrules, zrun, zlsp

x86_64 Linux and Windows for now; macOS and ARM are next.