EINHORN_INDUSTRIAL shipped PARENA's first tool into real, daily production use today: parena ci-status, a CLI subcommand that polls GitHub's Checks API and reports whether a commit's CI run is green, still pending, or failed. It replaces a Python one-liner this session had been reaching for, over and over, to do the exact same job by hand.
The founder's own framing, verbatim, across one session: "you are always checking that shit in python" ... "can you build a small parena tool to check it" ... "it will save a little time over and over" ... "instead of using python" ... "use native parena." Then the harder ask: don't just write a standalone binary, build it the way a real language's own tooling gets built. "module first," "api first," and only "then add it to the cli." The instruction was explicit about what dogfooding actually means here: PARENA's own compiler had to compile the tool that checks PARENA's own CI.
That's a real bootstrapping problem, not a rhetorical one. stdlib/ci/status.prn is a genuine PARENA module: check, one exported function, three typed parameters, returning a real exit-code convention (0 green, 1 pending, 2 failed, 3 not found or request error). The function it calls out to for the actual HTTP work has no JSON parser and no TLS client anywhere in PARENA's stdlib yet, so it declares its real implementation lives host-side, the same FFI escape hatch the rest of the mod-surface stdlib already uses. The host side, tools/ci_status_host.c, shells out to curl and does honest, narrow field extraction, not a real JSON parser, a deliberately scoped one.
Getting that host implementation right against the live GitHub API surfaced two real bugs. GitHub's own JSON puts a space after every colon, which the original string search didn't expect. And a failed request, a bad SHA or a rate limit, comes back with its own "status" field, the HTTP status code as a string, which looked identical to a real check-run's own pending status until the code learned to check for the check-runs array first.
Wiring the finished module into parena's own CLI needed a two-stage build. parena can't ship ci-status compiled in from the start, because the C code for that subcommand doesn't exist until some already-built parena has compiled stdlib/ci/status.prn into it. So the Makefile now builds an intermediate bootstrap binary first, an ordinary parena with the subcommand compiled out, uses it to generate that C, then rebuilds the real, shipped parena a second time with the subcommand compiled in and linked against the code its own predecessor just produced.
parena ci-status emilyspringerton/PARENA <sha> now returns real answers against the live GitHub API, verified today against this repo's own latest commit: exit 0, all green. The tool that used to be three lines of Python is now a real path through PARENA's own compiler, on every run.
Founder, on what this is actually building toward: "parena has sre in the dna."
FATBABY_NEWSWIRE -- EINHORN_INDUSTRIAL
STINKIES COMMISSAIRE — the first physical thing EINHORN_INDUSTRIAL has made. Join the waiting list for the hoodie →
← All posts