Projects

Open code, measurable proof

Nine public repositories on my own Gitea instance. Beside each description is the evidence by which its quality can be judged: an official test suite, a differential comparison or Linux kernel tests. I run the projects in the BDFL style: I set the direction myself and answer for it fully, and the same principles hold across all of them: minimum dependencies, no vendor binding, and code that stays readable without me. Part of my work stays private; this is the part anyone can open.

Libraries

Tensor

Numerical library for Go: n-dimensional arrays, dense and sparse linear algebra, differential equations, discrete transforms, statistics, optimisation and reverse-mode automatic differentiation. Pure Go without cgo and without third-party dependencies; computations share all CPU cores, and deterministic behaviour is defined by the documentation.

One go get, and machine learning and numerics in Go without a GPU and without dependency worries.

Verification: comparison against reference values and determinism across platforms: the same input yields the same number on two machines.

Repository on Gitea

Interpres

A TOML 1.1 parser and encoder for Go with no third-party dependencies. The API follows the conventions of encoding/json/v2: the document maps between Go types and text. The implementation holds to the specification, with no extensions of its own and no exceptions from it.

Passes 100 % of the official toml-test suite: it follows the specification, not its own idea of it.

Verification: the entire official toml-test suite, with no cases skipped.

Repository on Gitea

Scriptorium

Server-side rendering of scientific documents in Go: Markdown to HTML, TeX mathematics to MathML Core, Mermaid diagrams to SVG. The engines build on the standard library alone. The output is markup the browser draws without JavaScript, and the same input returns byte-identical results, safe to cache, diff and sign.

Mathematics without JavaScript: the browser draws the MathML Core itself, and no rendering bundle ships to the page.

Verification: 649 of the 652 CommonMark examples, the three exceptions being the deliberate trade for GFM autolinks that GitHub's own implementation makes, and all 23 GFM extension examples; all 391 symbols of the KaTeX coverage table verified by a diff against KaTeX's own source; tests assert byte-identical output across repeated renders.

Repository on Gitea

Development tools

GAsm SDK

A software development kit for the Go Plan 9 assembler: lexer, parser, formatter, linter, a standalone assembler with AVX-512 and RISC-V support, a disassembler, a debugger and a language server. One self-contained binary, pure Go, no external toolchains.

One binary, and the Plan 9 assembler finally has the tools its ecosystem never built.

Verification: differential tests of the assembler against the Go toolchain on amd64, arm64, riscv64 and loong64. Two independent implementations must agree on the same input bit for bit.

Repository on Gitea

JSbox

The whole web toolchain in one binary, with no build step: a dev server with live reload, a static checker, a formatter, an automatic fixer, a test runner and a static site generator. The checker, formatter and fixes work on real parse trees of JavaScript, CSS and HTML, never on text patterns; tests run in a browser or in the built-in V9 engine, whose language support reaches ES2027.

This website is its output: sitegen generated both language versions from a single layout, with nothing standing between source and deployment.

Verification: its own test suite, runnable in a browser and in the V9 engine; every finding the checker reports comes from a real analysis and carries a file, a line and a proof.

Repository on Gitea

Systems and operations

NFS

A full NFSv4.2 server and client in pure Go: sessions, locking, delegations, pNFS, Kerberos and RPC-with-TLS on a single TCP port. The standard library only, no third-party packages.

Interoperability verified against the client from the Linux kernel: measured, not merely promised.

Verification: tests against the Linux kernel client, the least partial judge available.

Repository on Gitea

Volumen

A publishing engine where posts are plain text files in Markdown with TOML frontmatter, with no database. It serves a JSON API, an admin with a visual editor, RSS, JSON Feed and full-text search. Drafts stay hidden, and the excerpt and the reading time are computed automatically.

The content is a directory of text files, not rows in a database: the publication stays readable even without the engine.

Verification: the frontmatter is read by Interpres, which passes 100 % of the official toml-test suite; the API contract is exercised live by this website, whose browser test suite covers the post list, slugs, pagination and languages.

Repository on Gitea

Nuntius

A contact-form backend in one static binary: it takes JSON as well as plain HTML posts, validates the fields on the server and delivers messages over SMTP with STARTTLS or implicit TLS. It serves contact, feedback and newsletter forms, with double opt-in for the newsletter; every form has its own rate limit, honeypot and CORS allowlist. The configuration is a TOML file read by Interpres.

The contact form on the Contact page runs on it: the message goes from the browser to the inbox with no third party in between.

Verification: a test suite with an 80 % coverage floor; the production proof is this site's own contact form, served by the binary live.

Repository on Gitea

Scripts

An operations toolbox in Perl: system and network diagnostics, a security audit, server and workstation setup, system optimisation and inference deployment. The scripts get by on the interpreter alone, with no modules the target machine may not carry.

One repository, the whole operation: from the first diagnostic to a running inference.

Verification: runs on a bare installation where nothing beyond the interpreter is available.

Repository on Gitea

How to take part

The projects run on my own Gitea instance. Bugs, ideas and questions are all welcome: I treat every repository as a research artefact, so reports that include a way to reproduce the problem take priority. To contribute code, write to opensource@petrbalvin.org and ask for an account.

Need something like this for your project?

I will design it, write it, and measure that it holds. Write to me about the problem you are facing.

Write to me