Blog
[one machine, one day per recording; 10 of 596 commands have one; tri cast is not in a tri release yet] A recorded command can be replayed and checked, a described one can only be believed. tri cast records real terminal output, scrubs and checks it, and publishes a page, a preview card and a player.
A command that is described in prose can be doubted; a command that was recorded can be replayed. tri cast records a real command in a terminal, checks the recording, and publishes it as a page with a preview card, a GIF for GitHub and a player for the blog. Ten of the 596 tri commands now have a tool card that ends with their own recording, and each one can be opened at t27.ai/term/.
tri selftest · the dependencies tri needs
Earlier posts in this blog said what a command printed and linked a log. A reader had to trust that the log came from that command, on that day. A screenshot is worse: it is a picture, and a picture can be edited or staged. We wanted a record that a reader can replay, and that carries its own checks.
tri cast record runs each command in a pseudo-terminal and saves an asciicast v2 file: the real output bytes, with the real time each one arrived.tri cast scrub replaces the home directory with ~ in every event and says so in the file header (redacted). It is the only edit a published recording may carry.tri cast check fails (exit 1) unless every command exited 0, the home path is gone and no key from the local key file occurs in the text.tri cast render draws the session as a GIF for GitHub; tri cast publish writes the page t27.ai/term/<id>/ with the recording, a 1200×630 preview card, a meta.json and og: and twitter: tags, rebuilds the gallery, and archives a copy outside the worktree.tri. A name shared by two of the three tri command-line tools is left without one rather than bound to the wrong tool.The page is plain static HTML on purpose. X cannot read per-post metadata behind the site's hash routes, so a recording needs an address of its own whose preview card is the thing a post shows.
| Part of the recording | Status |
|---|---|
| The prompt and the typing | Staged: typed at a steady pace so the command is readable |
| Every byte the command printed, and when it arrived | Real |
| A silence longer than 2 s | Shortened to 2 s, and the frame says so |
| The home directory in paths | Replaced with ~ by scrub, recorded in the header |
The page states the same table. If the output is wrong, a stale banner, a typo in a command, text in the wrong language, the answer is to record again. A recording is never edited.
The first recording of the board session carried a banner that did not match the project's name, and re-recording it changed the numbers: the same fasm2frames took 33.3 s in one take and 36.8 s in the next. Every caption and every sentence quoting the first take had to change. That is why a post quotes numbers from the recording it embeds, and why the numbers are not copied by hand into a second place.
Eight were recorded to start with, chosen because they run in seconds, need no board and print something a reader can judge: tri fpga-specs, fpga-keycheck, fpga-selftest, game-selftest, game-tick, game-vault, blog list and selftest. With the two earlier sessions (the board run and the FPGA flow) that makes ten. The other 586 commands have a card and no recording yet.
Not from a release. tri cast is a command in the maintainer's skills directory, backed by one Python script, and it is not part of a tri release. The player and the published pages are public: the recordings play in the gallery and in this post without installing anything.
tri cast is not installable from a release yet.Work with me
I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.