Louis Maddox

Concept T shirt that says “Deus ex machina is all you need”

A special requiremen1was an automated indentured par1slis1that would associa1call of 1heparts necessaryto manufacture a comple11end i1em. There grew to be abou1 two million pans in 1hc Apollo spacecraft

One thing I care about that no one else cares about is that the hierarchical, network, and relational database models were *all* explicitly developed to handle manufacturing data.

GitHub PR with 886 files changed, +5k/-45k lines

-18% ! 🥳 new high score

(building something neat… watch this space)

Example metadata: miscellanea that you might want to bring to a repo but not check in

We don’t really have any ability to ‘deploy against’ a repo in a ‘personal’ capacity, be it repo tasks, or just notes/annotations like links to things we’re reading, chats we’re having while coding and other memos

It also suggests a secondary purpose for syncdoc, rather than operating as a mirroring channel between two forms (in- and out-of-source), they could be additive

The migration CLI fully switches between forms but it actually already can be used this way—the md docs append to the in-source docstrings

Interesting idea: if you use syncdoc to sync docstrings to markdown (like mkdocs etc in python) then you had a comment in the markdown that got stripped before putting back into the code at docs compile time… then that operates as a kind of stored metadata, could be used for internal dev annotations

Hooks overwriting data between ‘invisible’ comment markers (to make computations that are “useful to see” visible) make a repo ‘reactive’ like a spreadsheet

Besides that visible reactivity though, doing so *within* a comment, keeping computation results *in*visible, would effect reactive *meta*data

New crate for repo decor 🦀🖼️

🛡️ blazon crates.io/crates/blazon
📜 docs.rs/blazon/lates...
📂 github.com/lmmx/blazon

“blazon fast” badge generator for Rust project stats (tree size, build size on disk)

Repo itself demos how to automate updating them via textum/git hook (see github.com/lmmx/blazon/...)

A before and after side-by-side diff of the textum CLI in use in a Justfile recipe to replace text between two HTML comments. It reduced from 20+ lines to just 5 lines

CLI greatly simplified without JSON ! 😅

Gravitating towards “anything in a repo that you want to update to ‘read out’ the state in-place should be implemented as a hook”

I typically externalise readout of repos’ metadata through artifacts either statically built on CI [think docs] or as live external web services [think CI status badges]

Repo CI bots are inherently limited to superficial (merely visual) activity, if they commit [for anything besides intermittent releases] they’d corrupt the VCS history with noise, and you wouldn’t want them to rewrite the history…

…So to intensify automation in a repo in-place requires commit hooks

My five-project (along with slides, video lectures, etc.) compilers course has all projects now available online free: kmicinski.com/functional-p.... Five projects have you incrementally build a compiler for a substantial language, including functions, mutation, loops, vectors, etc.

Chicken soup sour?

A print out of `textum -h` (the help text for textum) — Usage: textum <COMMAND> [OPTIONS] A syntactic patching tool with char-level granularity. Commands: replace <TARGET> <REPLACEMENT> <FILES>... Replace text in files delete <TARGET> <FILES>... Delete text from files apply [PATCH_FILE] Apply JSON patches Replace/Delete Options: --pattern Use regex pattern matching --lines START:END Operate on line range --until END_MARKER Operate between TARGET and END_MARKER --include-markers Include boundary markers (default: exclude) -n, --dry-run Preview changes -d, --diff Show diff -v, --verbose Verbose output Examples: # Simple replacement textum replace 'old' 'new' file.txt # Between markers textum replace '<!-- start -->' 'content' --until '<!-- end -->' README.md # Delete lines textum delete --lines 5:10 file.txt # JSON mode textum apply patches.json

textum v0.4.0 now has multiple CLI subcommands ! 🤩

JSON patches can still be used for programmatic CLI usage but this should be more human-friendly

Single module of CLI integration tests factored out into groups in subdir test module files. Cargo nextest list shows the files within the subdir files

Had not thought of this one before 🤔

Since a test module acts as if a crate unto itself, rather than use main.rs to spread em horizontally you can drop down into a submodule by reusing the ‘crate’ (module) name as an inline mod and listing subdir filenames in it, whose path thus resolves underneath

v0.3 docs for textum — String-Based API (No Rope Required) For convenience, patches can be applied directly to strings without needing to import or work with Rope types. Use Patch::in_memory() for patches that don’t need a file path: ``` use textum::{Patch, Snippet, Boundary, BoundaryMode, Target}; let content = "hello world"; let snippet = Snippet::At(Boundary::new( Target::Literal("world".to_string()), BoundaryMode::Include, )); let patch = Patch::in_memory(snippet, "rust"); let result = patch.apply_to_string(content).unwrap(); assert_eq!(result, "hello rust"); ``` Apply Single Patch to File Apply a patch to a file from disk, with options to inspect or write results: ``` use textum::{Patch, BoundaryMode}; let patch = Patch::from_literal_target( "tests/fixtures/sample.txt".to_string(), "world", BoundaryMode::Include, "rust", ); // Get the result without writing let result = patch.apply_to_file().unwrap(); println!("Would change to: {}", result); // Or write directly to disk patch.write_to_file().unwrap(); ``` Composing Multiple Patches For applying multiple patches to one or more files, use PatchSet. Use apply_to_files() to get results in memory for inspection, or write_to_files() to apply and write directly to disk: ``` use textum::{Patch, PatchSet, BoundaryMode}; let mut set = PatchSet::new(); set.add(Patch::from_literal_target( "tests/fixtures/sample.txt".to_string(), "hello", BoundaryMode::Include, "goodbye", )); set.add(Patch::from_literal_target( "tests/fixtures/sample.txt".to_string(), "world", BoundaryMode::Include, "rust", )); // Get results in memory for inspection let results = set.apply_to_files().unwrap(); assert_eq!(results.get("tests/fixtures/sample.txt").unwrap(), "goodbye rust\n"); // Or write directly to disk // set.write_to_files().unwrap(); ```

textum v0.3

🪢 re-exports Rope to avoid consumers having to depend on the ropey crate too
💭 Patch can now be in-memory
📝 adds new write_to_file(s) methods for Patch/PatchSet and uses this in the CLI
🧮 adds a -d/--diff flag to show what a patch would change (a more useful alternative to -n/--dry-run)

Been listening to the song Colliding Walls on repeat for maybe 3 days and just twigged that’s why I’m back on my text boundary snippet targetting API library hype

Etymology redit 1 The word blazon is derived from French blason, 'shield'. It is found in English by the end of the 14th century. [1] Formerly, heraldic authorities believed that the word was related to the German verb blasen 'to blow (a horn). [2][3] Present-day lexicographers reject this theory as conjectural and disproved.[1] Grammar Blazon is generally designed to eliminate ambiguity of interpretation, to be as concise as possible, and to avoid repetition and extraneous punctuation. English antiquarian Charles Boutell stated in 1864: Heraldic language is most concise, and it is always minutely exact, definite, and explicit; all unnecessary words are omitted, and all repetitions are carefully avoided; and, at the same time, every detail is specified with absolute precision. The nomenclature is equally significant, and its aim is to combine definitive exactness with a brevity that is indeed laconic. [4]

mot du jour 🛡️🗡️👀 en.wikipedia.org/wiki/Blazon#...

It’ll vary by hardware but I saw the parser crate build 6x faster and -75% the build size (45 MB down to 12 MB), just from removing unused transitive deps!

Before and after the `ra_ap_parser` and `ra_ap_syntax` crates were pruned of unnecessary syn transitive dependencies (via default tracing “attributes” feature)

The rust-analyzer syntax and parse crates are now free of syn ! 😇 github.com/rust-lang/ru...

Expect it’ll be released tomorrow

The reason was tracing crate’s default features are “std” and “attributes”, the latter is only needed if you are using the `#[instrument]` attribute macro, these were not!

Top down view of Kirby hovering

rust-analyzer first time contrib auto-merge in 3... 2...

meh, this doesn’t save you any chars and is actually less legible because it implies the reader must know what -X does (batch execute on results list)…

💡

`rg foo $(fd -e ext) -l`

is just

`fd -e ext -X rg foo -l`

Very important that children learn how to swim so that when they grow up they are well-trained to hold their breath for minutes at a time while refactoring complex crate workspace dependencies

It’d become a badge of honour to have single digit crate trees… or better still have the badge link to a fresh cargo tree list so they can see for themselves and not have to go TOML chasing thru transitive deps

Occurs to me I could set this up to generate an inline SVG badge with a commit hook that stores some metadata in there, e.g. hash of the Cargo.toml, so you only recompute [i.e. build release mode target/calculate cargo tree size] if that changed…

Would it not be helpful to show crate tree size and built target size for the default features for crates? Seems obviously missing

Some filmic entrepreneur has set up a ring light and camera on a turntable blasting Mariah in the central embankment on Oxford Circus and presumably charging tourists

Area man overly excited by 0.4% improvement on arcane north star metric