0016: dida validator and debugger, focus selector perf and async children, emotional management, speed matters, moving faster, have you tried rubbing a database on it, handmade highlights, airtable scripts, bank python, napa, pollen, against markdown, zig-snapshots, exhaustive test inputs, gf, nixos debug symbols, duckdb blog

Published 2021-11-15

New stuff:

I virtually went to Handmade Seattle. Some of the highlights:

Also from last months Wheel Reinvention Jam, this cute sql gui has a lot of nice little touches like being able to snap nodes together to keep the graph tidy.

Randy Gauls coroutine gui demo reminded me how nice the airtable scripting api is.

Here's a silly little script that renames records:

let table = base.getTable("Menu");
let record = await input.recordAsync('Select a menu item', table);
if (record) {
    let new_name = await input.textAsync('New name');
    await table.updateRecordAsync(record, {Name: new_name});
}

I pop open the script editor and type in that code.

I couldn't get a screenshot of the autocomplete because it disappears when the window loses focus, but when editing the {Name: ...} it knows that it should be a record from the Menu table so it autocompletes the columns and types for that table. I'm not even sure how they're doing that - did they extend the typescript inference to look at the database schema whenever it sees base.getTable with a constant argument?

I hit run and it looks like this:

It reaches the input.recordAsync and suspends the script there, waiting for the user to pick a record from this gorgeous autocomplete:

Once the record has been picked the script resumes and creates a text input:

The whole thing took me a couple of minutes from a standing start. I've never seen anything else that approached this level of ease for writing plugins.

An oral history of Bank Python

Note how the same themes crop up as in airtable: a builtin editor, a single source of data, automatic deployment of code etc.

Napa: Powering Scalable Data Warehousing with Robust Query Performance at Google

Napa decouples ingestion from view maintenance, and view maintenance from query processing. This decoupling provides clients knobs to meet their requirements, allowing tradeoffs among freshness, performance, and cost.

Similar internal data model to DD. Seems like Spanner takes the place of DDs point-stamp exchange.

Disappointing that they didn't go into more detail on how they manage consistency during view updates. Maybe they just propagate updates in arbitary order and only withhold the final output? If so, it would seem like they could see internal consistency violations when querying beyond the QT.

I'm continually annoyed by how static site generators rely on anaemic template languages, and by how markdown limits the kinds of structures I can use for writing. I really like the idea behind pollen - just define a way to embed some real language directly into arbitrary text files. This can serve as a replacement for markdown, as a template language for html and css and as a scripting language for assembling derived state like rss feeds.

Markdown:

◊title{We don't need no markdown!}

Here is some ◊link{python}{https://www.python.org/} code:

◊(require pollen/unstable/pygments)
◊highlight['python]{
for x in range(3):
    print x
}

And some math:

◊(define ($ . xs)
  `(mathjax ,(apply string-append `("$" ,@xs "$"))))
◊(define ($$ . xs)
  `(mathjax ,(apply string-append `("$$" ,@xs "$$"))))
 
◊h1{I wonder if ◊${2^{\aleph_\alpha} = \aleph_{\alpha+1}}?}

HTML:

◊(define (important text) (div #:class "red" #:style "font-size:150%" text))
<html>
<body>
  ◊(->html doc)</body>
<footer>
  ◊important{Do ◊em{NOT} press the red button}
</footer>
</html>

CSS:

◊(define inner 2)
◊(define edge (* inner 2))
◊(define color "gray")
◊(define multiplier 1.3)
 
body {
    margin: ◊|edge|em;
    border: ◊|inner|em double ◊|color|;
    padding: ◊|inner|em;
    font-size: ◊|multiplier|em;
    line-height: ◊|multiplier|;
}
 
h1 {
    font-size: ◊|multiplier|em;
}
 
#prev, #next {
    position: fixed;
    top: ◊|(/ edge 2)|em;
}
 
#prev {
    left: ◊|edge|em;
}
 
#next {
    right: ◊|edge|em;
}

I'm not about to run out and rewrite my blog in racket, but I bet I could embed js or imp in a similar way...

Related - how documentation could be better and how markdown prevents that.

zig-snapshots produces before-and-after interactive views of linked executables. Seemingly intended for debugging the zig incremental linker, but seems like it would also be great teaching tool.

Generate all the things.

A little gem. Seems like it should be possible to combine this with the way hypothesis generates and shrinks inputs. Then you could have a single set of tests that could run exhaustively for small inputs and use coverage-guided fuzzing for large inputs with shrinking to find minimal examples.

Someone at handmade recommended trying gf, yet another gdb frontend. This is one is actually pretty slick, but there are some UX issues that would drive me crazy:

By toggling environment.enableDebugInfo to 'true' in /etc/nixos/configuration.nix, all separate debug info derivations in your systemPackages will have their debug output linked in /run/current-system/sw/lib/debug/ and will be automatically available to gdb.

Handles are the better pointers.

A useful glimpse of how an experienced c programmer manages memory.

Duckdb has a blog!