Release Pyroeis 0.8.0 · datamoc/pyroeis

limits.coroutines: a script could create a million coroutines (about 1.7 GiB of heap, in 3.5 s) under a generous instruction budget, because allocation and totalAllocation only see strings and buffers. The new limit caps the coroutines created per top-level call (coroutine.create, coroutine.wrap, and host coroutines made during the call); the next one raises a LimitError (limit: "coroutines") that pcall cannot catch. It counts creations, not live coroutines, since the garbage collector is not observable, so a persistent VM can still keep that many new ones per call. 10,000 costs about 17 MiB. Opt-in: without it nothing is counted.
Not covered: tables and closures cost as much (3 million empty tables: about 2.2 GiB); only the instruction and time budgets bound them.

Interop cases run on Fengari: the js.global, metatable and __proto__ cases load fengari-interop 0.1.4 on the upstream side, as an application exchanging data with JavaScript would; Pyroeis has no such module.
A verdict per case: a green tick when the engine contains the script, a red cross when it ran on or got through, with wording specific to each case (forged chunk accepted, bridge reached, JavaScript run, prototype polluted) instead of "normal return".
Cases where both engines answer alike were removed (jsglobal, proto, interop, eval); the eval row stays in the matrix as a decision, not a runnable case.
New case coroutines compares the cap with upstream Fengari under the same instruction budget. The Pyroeis version is named wherever Fengari 0.1.5 is.

npm publication runs through the release workflow as a staged publish; a maintainer approves it with npm stage approve.

Navigation Menu