# The pipeline: how to run the library, its reader and the writers Fixed scripts rather than a test suite. They produce output that is meant to be **looked at**, and they double as the answer to "what do I type?". ``` config.sh where everything is, and where the output goes build.sh build the library and the writer, in both languages one.sh one tool, one document - the answer to "how do I run this?" read.sh the library and its reader, over every document write.sh every writer, in both languages, over every document pdf.sh compile the .typ files that write.sh produced run.sh all of the above, in order ``` ## What you need first An **abstraction** to read: a directory holding a `.ssp` for each document-language and a `.ocda.db` for each document, and, where there is one, a `.sisupod` beside it. That is what spine writes: ```sh spine --show-abstraction --ocda-db --pod2 --output= ... ``` Everything downstream reads those files and nothing else. **No tool here parses markup**: parsing is spine's work, and the point of the exercise is that the abstraction is enough without it. ## Running it ```sh ARTEFACTS= OUT= sh pipeline/run.sh ``` `ARTEFACTS` is the directory above. `OUT` is where the output goes and defaults to `./pipeline-out`. Both, and every path to a sibling repository, are variables with defaults in `config.sh`; override them in the environment rather than editing anything. `LIMIT=3` takes the first three documents, which is what to use while looking at something. ## Where the output goes ``` $OUT/read/dump-d/ dump-g/ the library's dump, from each serialisation $OUT/write/text/{d,g}/ .txt $OUT/write/md/{d,g}/ .md $OUT/write/html/{d,g}/ .html $OUT/write/epub/{d,g}/ .epub $OUT/write/typst/{d,g}// .typ, and image/ beside it $OUT/write/pdf/ .pdf ``` `d` is the D implementation and `g` the Gleam one, throughout. ## One tool, one document ```sh sh pipeline/one.sh text-d .ssp sh pipeline/one.sh md-g .ocda.db en sh pipeline/one.sh html-d .sisupod sh pipeline/one.sh dump-d .ocda.db en sh pipeline/one.sh agree-g .ssp .ocda.db sh pipeline/one.sh read-d .sisupod en --tree ``` The tool names are `-`: `text`, `md`, `html`, `epub`, `typst` for the writers, `read` for the library's reader (ocda-read, which reads every form and takes its modes after the file), and `dump`, `agree` for the library; `-d` for D and `-g` for Gleam. Output goes to stdout, so a comparison is a pipeline. The epub and the typst name a file instead, because an epub is a zip and a `.typ` names its images by path: ```sh "$WRITERS/dlang/result/bin/ocda-write" --epub .ocda.db en --out x.epub "$WRITERS/dlang/result/bin/ocda-write" --typst .ocda.db en --out d/x.typ typst compile --root d d/x.typ d/x.pdf ``` ## What the counts at the end mean Each stage prints a few numbers. They are not a pass, they are a way to see a regression without reading every document. | `all four dumps identical` | the library's whole claim: two serialisations, two languages, one model | |---|---| | `ocda-read, all four identical` | the reader's tree of a document, the same from its .ssp and its .ocda.db, in D and in Gleam | | `D == Gleam, ` | the writers agree, in unrelated languages, neither written from the other. This is what says the model is sufficient | | `.ssp and .ocda.db give the same .typ` | a writer is not told which serialisation it was handed | | `typst compiled silently` | a link to a label that does not exist is a typst compile error, so this says every internal link in every document resolves | ## What this is not It is not the project's checking. The sweeps that hold each writer against an oracle - `spine --text`, spine's scroll html, epubcheck, typst - are separate and stricter. This is the pipeline you run to *look* at all of it at once.