On the left, we have lmsensors metrics, expanded with it86 because my MB uses one of those blasted SuperIO chips for fan control (“SmartFan 6”). Incidentally, the sensors report temps from the 4 NVMe slots on the MB, each housing an 8TB WD Black drive.

On the right, data is pulled from SMART for each drive, on any drive port.

Both are populated by their respective PMDAs, metric agents that are emitting data to PMCD, which in turn is fed through PMLogger to Redis and finally Grafana.

The SMART data seems to disappear randomly, even though it is forced to refresh every second:

log mandatory on 1 second {
        nvidia
        smart
        lmsensors
        filesys
}

This config forces PMCD to poll the PMDA data for those four agents every second. It’s a bit much, as there’s some static data in there (you’re not hot-plugging GPUs every second, right?), but I have enough storage and I would rather not dig through the entire metrics tree. That’s why the lmsensors graph on the left is so detailed. So WTF is going on with the SMART data? This dashboard was in place before I added the new storage and worked just fine?!

Let’s just restart and see what’s what:

$ smart sudo systemctl restart pmcd
$ smart pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4

Ah nice, it works! 4 metrics (for four drives) are flowing in. But wait, a second later:

$ smart pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature -12386 No PMCD agent for domain of request

The agent disappeared?! What was the last thing it did?

$ sudo tail -n 50 /var/log/pcp/pmcd/smart.log
Log for pmdasmart on aitop started Sun Nov 23 12:23:32 2025

[Sun Nov 23 12:23:40.487304] Warning: __pmSendResult(1,...) failed: Broken pipe

Log finished Sun Nov 23 12:23:40 2025

It failed to send data, the pipe to PMCD was shut down - it ran into a closed door and gave up. Why did PMCD close the door?

$ sudo tail -n 50 /var/log/pcp/pmcd/pmcd.log
Configuration file ‘/etc/pcp/pmcd/pmcd.conf’ unchanged
Restarting any deceased agents:
    “smart” agent
    “bpftrace” agent

pmcd: unexpected end-of-file at initial exchange with bpftrace PMDA

active agent dom   pid  in out ver protocol parameters
============ === ===== === === === ======== ==========
[...]
libvirt      140 3682865  31  32   2 bin pipe cmd=/usr/bin/python3 /var/lib/pcp/pmdas/libvirt/pmdalibvirt.python
docker       141 3682870  33  34   2 bin pipe cmd=/var/lib/pcp/pmdas/docker/pmdadocker -d 141
smart        150 3686839  38  39   2 bin pipe cmd=/var/lib/pcp/pmdas/smart/pmdasmart -d 150

[Sun Nov 23 12:23:38] pmcd(3682845) Warning: pduread: timeout (after 5.000000 sec) while attempting to read 12 bytes out of 12 in HDR on fd=39
[Sun Nov 23 12:23:38] pmcd(3682845) Info: CleanupAgent ...
Cleanup “smart” agent (dom 150): protocol failure for fd=39

OK, multiple things are wrong. First off, there are read errors in the bpftrace and smart agent, they’d been marked as “deceased”, which explains why the PMDA couldn’t send any data - PMCD killed it. The timeout could be it, but the PID seems to point to libvirt’s PMDA. Let’s disable both bpftrace and libvirt metrics to isolate the smart failure:

$ cd /var/lib/pcp/pmdas/smart
$ cd ../libvirt
$ sudo ./Remove
Culling the Performance Metrics Name Space ...
libvirt ... done
Updating the PMCD control file, and notifying PMCD ...
Check libvirt metrics have gone away ... OK
$ cd ../bpftrace
$ sudo ./Remove
Culling the Performance Metrics Name Space ...
bpftrace ... done
Updating the PMCD control file, and notifying PMCD ...
Check bpftrace metrics have gone away ... OK

OK, now checking the behavior again, it seems like the SMART probe takes longer and longer to respond, before being killed:

$ sudo systemctl restart pmcd
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 7% cpu 0,052 total
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 6% cpu 0,051 total
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 0% cpu 4,838 total
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature -12386 No PMCD agent for domain of request
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 0% cpu 3,467 total
$ sudo tail -n 50 /var/log/pcp/pmcd/pmcd.log
[Sun Nov 23 13:19:49] pmcd(3857845) Info:

pmcd RESTARTED at Sun Nov 23 13:19:49 2025

Restarting any deceased agents:
    “smart” agent

[...]

[Sun Nov 23 13:19:49] pmcd(3857845) Info: PMNS file “DEFAULT” is unchanged
[Sun Nov 23 13:19:55] pmcd(3857845) Warning: pduread: timeout (after 5.000000 sec) while attempting to read 12 bytes out of 12 in HDR on fd=34
[Sun Nov 23 13:19:55] pmcd(3857845) Info: CleanupAgent ...
Cleanup “smart” agent (dom 150): protocol failure for fd=34

OK that starts to make sense: the last successful probe took nearly 5 seconds, and the next one failed. PMCD is enforcing a 5-second timeout, and our polling forces a 1 second refresh. Let’s change the forced refresh to 10s for the SMART PMDA, and also adjust the PMCD timeout to match:

log mandatory on 1 second {
        lmsensors
}

log mandatory on 10 second {
        nvidia
        smart
        filesys
}

And adjust the timeout config in /etc/pcp/pmcd/pmcd.options:

# longer IPC timeout delay for slow agents (default 5)
-t 10

OK, seems to work:

$ sudo systemctl restart pmcd
$ pmprobe -v pmcd.control.timeout
pmcd.control.timeout 1 10
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 0% cpu 5,533 total
$ time pmprobe smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature 4
pmprobe smart.nvme_attributes.composite_temperature  0,00s user 0,00s system 4% cpu 0,088 total

Timing fluctuates a bit, but 10s gives us enough headroom. The reason for the delay is data availability. The default polling is advisory for most metrics, and once for one-offs:

$ grep ‘^log’ /var/lib/pcp/config/pmlogger/config.default | sort | uniq
log advisory on 5 minutes {
log advisory on default {
log advisory on once {
log mandatory on 10 second {
log mandatory on 1 second {

I’m pushing the system a bit with tight mandatory polling, and SMART doesn’t care how fast you want the data. But this works for now.

The naming in PMLogger is a bit odd, but one way to think about mandatory vs. advisory is: mandatory is like CSS’s important - it always wins and sets the specific logging period. PMDAs might provide advisory periods, i.e. if no one requests mandatory logging for this metric, maybe do it every so often (the timing is defined by the advisory). Mandatory also defends against any overrides by PMLC. TL;DR:

if mandatory == on:
    log it (at mandatory interval)
elif mandatory == off:
    do NOT log it
elif mandatory == maybe:
    if advisory == on:
        log it (at advisory interval)
    else:
        do NOT log it

One sensible thing to do here would be to specify the metrics I’m actually interested in. Currently, every 10s, the entire SMART PMDA is polled. But I plan to keep this while I’m building out the dashboard. After that, I can disable the metrics I’m not interested in. PMLC is a nice tool for interactive configs, but remember that our PMLogger config overrides this:

$ pmlc
Performance Co-Pilot Logger Control (pmlc), Version 7.0.3

pmlc> show loggers
The following pmloggers are running on local::
    primary (3898924)
pmlc> connect primary
pmlc> status
pmlogger [primary] on host local: is logging metrics from host aitop
PMCD host        aitop
log started      Sun Nov 23 13:30:22.133330434 2025 (times in local time)
last log entry   Sun Nov 23 13:41:47.612559601 2025
current time     Sun Nov 23 13:41:47.912865078 2025
log volume       0
log size         2121756
pmlc> query smart.nvme_attributes.composite_temperature
smart.nvme_attributes.composite_temperature
    adv  off nl              [0 or “sda”]
    adv  off nl              [1 or “sdb”]
    adv  off nl              [2 or “sdc”]
    adv  off nl              [3 or “sdd”]
    adv  off nl              [4 or “sde”]
    adv  off nl              [5 or “sdf”]
    adv  off nl              [6 or “sdg”]
    adv  off nl              [7 or “sdh”]
    adv  off nl              [8 or “sdi”]
    adv  off nl              [9 or “sdj”]
    adv  off nl              [10 or “sdk”]
    adv  off nl              [11 or “sdl”]
    adv  off nl              [12 or “sdm”]
    adv  off nl              [13 or “nvme3n1”]
    adv  off nl              [14 or “nvme2n1”]
    adv  off nl              [15 or “nvme1n1”]
    adv  off nl              [16 or “nvme0n1”]

A “query smart” prompt would also give you a good idea of how long a full tree probe takes.

To help with debugging issues that happen “overnight,” I also want to revisit the retention periods. We have three components in play:

1. PMCD serves metrics live (in RAM), no retention, what isn’t logged is lost

2. PMLogger writes metrics to disk (as the name implies)

3. PMProxy + Redis format the data for Grafana as timeseries

2 and 3 have retention periods.

PMLogger runs a log rotation job, and keeps k days of metrics on disk. This parameter can be changed in XXX:

$ grep PMLOGGER_INTERVAL /etc/default/pmlogger
# PMLOGGER_INTERVAL=60
$ sudo nano /etc/default/pmlogger_timers
# change/add: PMLOGGER_DAILY_PARAMS="-E -x 14 -k 180"
$ sudo systemctl restart pmlogger

This means:

• -E: don’t bail out on minor metadata issues (default)

• -x 14: compress archives older than 14 days

• -k 180: delete archives older than 180 days

And in /etc/pcp/pmproxy/pmproxy.conf, add, for example:

[pmseries]
stream.expire = 2592000   # TTL in seconds
stream.maxlen = 43200     # max samples per metric/host

The latest additions are all MaxQ RTX Pro 6000 cards, hardware-limited to 300W, with effective air evacuation through the rear of the card, keeping the insane heat generated out of the main area of the system.

But when I started, Blackwell had just gone to market, and the only option was an OEM PNY version of the Workstation edition. Using the oversized flow-through cooler design from the 5090, it also inherits its biggest liability: 600W of power draw, via a connector that had never been designed for this, and has since turned into a fire risk.

This card is unwieldy, dangerous, and has the worst airflow path for my application. I’m looking to swap it at some point for a MaxQ, but in the meantime I need the horsepower.

Fortunately, nvidia-smi does provide a power limit switch:

$ sudo nvidia-smi -i 1 -pl 300
Power limit for GPU 00000000:81:00.0 was set to 300.00 W from 600.00 W.
All done.

But I want to minimize the chance of this ever spiking above 300W. So let’s first create a tool to set a power limit across all GPUs:

#!/usr/bin/env bash
set -euo pipefail

TARGET_WATTS=300

NVIDIA_SMI=/usr/bin/nvidia-smi

# Wait for GPUs to appear (up to ~30 seconds)
for i in {1..30}; do
    if “$NVIDIA_SMI” -L >/dev/null 2>&1; then
        break
    fi
    sleep 1
done

# If still no GPUs, just exit quietly
if ! “$NVIDIA_SMI” -L >/dev/null 2>&1; then
    echo “set-nvidia-power-limit: no GPUs found, exiting”
    exit 0
fi

# Make sure persistence mode is enabled (helps keep settings)
# to enable, run once at any time: sudo nvidia-smi -pm ENABLED
“$NVIDIA_SMI” -pm 1 || true

# Loop over all GPU indices and set the power limit
for idx in $(”$NVIDIA_SMI” --query-gpu=index --format=csv,noheader); do
    echo “Setting power limit for GPU $idx to ${TARGET_WATTS}W”
    “$NVIDIA_SMI” -i “$idx” -pl “$TARGET_WATTS”
done

Saved as /usr/local/sbin/set-nvidia-power-limit.sh, then try it once after enabling settings persistence (don’t forget to set the execute flag):

$ sudo nvidia-smi -pm ENABLED
$ sudo /usr/local/sbin/set-nvidia-power-limit.sh
Persistence mode is already Enabled for GPU 00000000:41:00.0.
Persistence mode is already Enabled for GPU 00000000:81:00.0.
All done.
Setting power limit for GPU 0 to 300W
Power limit for GPU 00000000:41:00.0 was set to 300.00 W from 300.00 W.
All done.
Setting power limit for GPU 1 to 300W
Power limit for GPU 00000000:81:00.0 was set to 300.00 W from 300.00 W.
All done.

Nice. Now create a service to run this at boot in /etc/systemd/system/nvidia-power-limit.service

[Unit]
Description=Set NVIDIA GPU power limits at boot
After=multi-user.target
Wants=nvidia-persistenced.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/set-nvidia-power-limit.sh

[Install]
WantedBy=multi-user.target

And enable it:

$ sudo systemctl daemon-reload
$ sudo systemctl enable nvidia-power-limit.service
$ sudo systemctl start nvidia-power-limit.service
$ systemctl status nvidia-power-limit.service

○ nvidia-power-limit.service - Set NVIDIA GPU power limits at boot
     Loaded: loaded (/etc/systemd/system/nvidia-power-limit.service; enabled; preset: enabled)
     Active: inactive (dead) since Sun 2025-11-16 15:45:03 CET; 14min ago
    Process: 524590 ExecStart=/usr/local/sbin/set-nvidia-power-limit.sh (code=exited, status=0/SUCCESS)
   Main PID: 524590 (code=exited, status=0/SUCCESS)
        CPU: 204ms

Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524595]: Persistence mode is already Enabled for GPU 00000000:81:00.0.
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524595]: All done.
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524590]: Setting power limit for GPU 0 to 300W
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524599]: Power limit for GPU 00000000:41:00.0 was set to 300.00 W from>
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524599]: All done.
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524590]: Setting power limit for GPU 1 to 300W
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524601]: Power limit for GPU 00000000:81:00.0 was set to 300.00 W from>
Nov 16 15:45:03 aitop set-nvidia-power-limit.sh[524601]: All done.
Nov 16 15:45:03 aitop systemd[1]: nvidia-power-limit.service: Deactivated successfully.
Nov 16 15:45:03 aitop systemd[1]: Finished nvidia-power-limit.service - Set NVIDIA GPU power limits at boot.

Done! A little more peace of mind. A Grafana dashboard and alert monitor this as well via pmlogger, the NVIDIA PMDA and PCP/Redis, just to be sure.

On GitHub we detect a repo’s primary language using linguist (which can be customized or overwritten using git attributes). However, many more repos feature more than one language. In orange (57%) are the repos that have a different primary language but feature some Nim, and below that is a breakdown of the most common additional languages:

Putting this into perspective, we host1 significantly more than 100,000,000 repos that contain JavaScript (without even counting embedded in HTML, TypeScript or other variants). Still, at rank 212 of 711 recognized languages, Nim is slightly more popular than other niche languages, including LiveScript (27k), V (25k), Crystal (22k). OTOH, all of Zig, COBOL (yes, really), AppleScript, Coq, and Ada have a 2x or larger footprint than Nim. Maybe not surprising, given some of those have had a multi-decade headstart.

I should also mention that this is merely a snapshot. The growth rate for all languages is different, and so are distributions in active contributions. Once a year, we aggregate all of these factors into the Top 10 languages in the Octoverse report. Needless to say, Nim doesn’t make the cut.

Originally published on YouTube.

Today, let’s push synchronization further by coordinating a single outcome for the entire shader run: a hash of the contents of a texture.

Like TCB, content hashing is important in effect pipeline optimization. TCB allows us to shed useless data and save memory, while content hashing allows us to skip pipeline steps entirely based on whether the content has changed.

What we’ll implement today is exact hashing, and it is very sensitive even to small changes, including sub-pixel anti-aliasing, even for seemingly identical code. In a real application, you’d extend this with additional “fuzzy” hashing (color histograms, FFT analysis, etc.) to get even more savings.

This once again plays into two strengths of compute shaders:

• many-to-few calculations, essentially reducing the input (millions of pixels) to just a few bytes of output

• coordination: the ability to use memory barriers to coordinate between threads

Doing content hashing on the CPU, especially in Lua, would be prohibitively expensive, whereas our hashing shader can comfortably run in real-time.

Before we go to implement the hash, it helps to consider which algorithm we’ll base our shader on. We need absolutely minimal required math or bit operations, low memory overhead (no large LUTs), and as few sync barriers as possible.

One good choice is SplitMix, essentially a PRNG. Its core quality is a high degree of avalanche, meaning small changes in the input bits flip lots of output/intermediate bits. SplitMix relies on XORing values, which is one of the least expensive operations possible, and constant factor multiplication, which can also be optimized to more rudimentary operations. The constant factors in SplitMix are chosen to further maximize avalanche.

Without further ado, here’s our shader implementation. I’ll explain the thread synchronization later down below. You’ll also notice a “bounds” parameter. You can ignore this for now; it’s meant as an entry point for TCB to allow hashing of only the true content of a canvas. Not something we’ll implement today.

/* hash_bounds.comp – 128-bit  */

layout(local_size_x = 16, local_size_y = 16) in;

/* inputs */
/* the canvas */
layout(rgba32f) readonly uniform image2D Src;
/* (minX, minY, maxX, maxY); maxX < 0 -> disabled */
uniform ivec4 Bounds;

/* output */
layout(std430) buffer Hash { uint h[]; };

/* work-group shared totals */
shared uint l0, l1, l2, l3;

void computemain() {
  ivec2 id  = ivec2(gl_GlobalInvocationID.xy);
  ivec2 dim = imageSize(Src);

  /* guard against ceil-dispatch overflow */
  if (id.x >= dim.x || id.y >= dim.y) return;

  /* skip pixels outside user-supplied bounds (if any) */
  if (Bounds.z >= 0) {
      if (id.x < Bounds.x || id.x > Bounds.z ||
          id.y < Bounds.y || id.y > Bounds.w) return;
  }

  /* zero work-group shared memory exactly once */
  if (gl_LocalInvocationIndex == 0u)
      l0 = l1 = l2 = l3 = 0u;

  memoryBarrierShared(); 
  barrier();

  /* per-pixel mix */
  vec4  px = imageLoad(Src, id);
  uvec4 c  = uvec4(round(px * 255.0));

  /*
    These are the two magic multipliers from SplitMix32 — a compact, 
    well-studied integer hash by Sebastiano Vigna (derived from Guy Steele’s 
    SplitMix64 constants). They’re deliberately odd and have good avalanche: 
    flipping a single input bit flips ~16 output bits on average.
  */
  uint m0 = c.r ^ ((uint(id.x) << 16) | uint(id.y));
  uint m1 = c.g ^ ((uint(id.y) << 16) | uint(id.x));
  uint m2 = c.b ^ (uint(id.x) * 0x45d9f3bu);
  uint m3 = c.a ^ (uint(id.y) * 0x119de1f3u);

  atomicAdd(l0, m0);
  atomicAdd(l1, m1);
  atomicAdd(l2, m2);
  atomicAdd(l3, m3);

  barrier(); 
  memoryBarrierShared();

  if (gl_LocalInvocationIndex == 0u) {
    atomicAdd(h[0], l0);
    atomicAdd(h[1], l1);
    atomicAdd(h[2], l2);
    atomicAdd(h[3], l3);
  }
}

First, let’s talk about Local Data Share, or LDS. LDS is a, well, local data store. It’s local to the GPU itself (not in VRAM) and enables fast read and write access for smaller amounts of data. Think of it like a really fast, small scratchpad. The per-group memory we allocate (uints l0 through l3) is only visible to the active work group (16x16 threads).

Our invocation index is a unique location within the current invocation and allows us to pin certain operations to an exact instance. In this case, for invocation 0 - the first - we use it to zero the memory once. LDS writes aren’t guaranteed to be flushed to memory immediately, so we do two things:

• use memoryBarrierShared to flush the data

• use barrier to halt all threads until they reach this point

This syncs all 256 threads to the same state. Barrier’d code ranges should be near-instant; otherwise, synchronization will massively degrade performance. Zeroing memory doesn’t cost anything.

But why do we have 4 LDS counters allocated? To ensure any channel in the input image (RGBA) can affect the output hash, we mix each channel’s data independently and use that to arrive at a 128-bit output hash.

Atomic operations, we’ve seen those in the last TCB example, are used to accumulate hash values in the LDS counters.

BTW, did you notice the different uses of local and global indexes? A local index refers to the current tile, the 2D work group of threads currently running. The global index is unique across all invocations and can be used for more heavy-handed synchronization - or to recover coordinates as we did last time.

The final batch of atomic adds targets the h array, which is the final output. Here we again need exactly one thread to perform the write. Barriers just before this ensure that the read from LDS contains all threads’ latest data.

From a high-level perspective of a CPU-side developer, this might look like a lot of synchronization - surely this would lead to contention? But a GPU has such a massively parallel architecture, and LDS access is so fast (single cycle), this is completely inconsequential. In fact, only one thread per tile ever touches VRAM. And the copy-back of data to the CPU is just 128 bits in total.

Let’s set up the usual love app:

function love.conf(t)
  t.version      = “12.0”
  t.window.title = “GPU Canvas Hash Demo”
  t.highdpi = true
  t.window.width = 500
  t.window.height = 400
end

And draw a demo:

local dpi      = love.graphics.getDPIScale()
local WCANVAS  = 512
local HCANVAS  = 512
local WG_SIZE  = 16           -- local_size in hash.comp

-- GPU resources
local canvas = love.graphics.newCanvas(WCANVAS, HCANVAS, {
  format       = “rgba32f”,
  computewrite = true
})
local cs   = love.graphics.newComputeShader(”hash.comp”)
local buf  = love.graphics.newBuffer(”uint32”, 4, { shaderstorage = true })

-- Demo scene state
local time      = 0
local animate   = true
local prevHash  = “”
local effectRan = false

-- Draw something (white rotating square + red circle) onto the texture
local function drawScene()
  love.graphics.setCanvas(canvas)
  love.graphics.clear(0, 0, 0, 0)

  -- rotating square
  love.graphics.push()
  love.graphics.translate(WCANVAS / 2, HCANVAS / 2)
  love.graphics.rotate(time)
  love.graphics.setColor(1, 1, 1, 1)
  love.graphics.rectangle(”fill”, -64, -64, 128, 128)
  love.graphics.pop()

  -- orbiting circle
  love.graphics.setColor(1, 0, 0, 0.8)
  love.graphics.circle(
    “fill”,
    WCANVAS / 2 + math.cos(time * 2) * 150,
    HCANVAS / 2 + math.sin(time * 2) * 150,
    40
  )

  love.graphics.setCanvas()
end

-- calculate pixel-space bounds & hash within them
local function hashCanvas(canvas, rectPx)   
  -- rectPx = {x, y, w, h} in *logical* px
  local Wpix, Hpix = canvas:getPixelDimensions()
  local dpi        = love.graphics.getDPIScale()

  -- convert logical → physical; build (minX,minY,maxX,maxY)
  local bx, by, bx2, by2
  if rectPx then
    bx  = math.max(0,      math.floor(rectPx.x * dpi))
    by  = math.max(0,      math.floor(rectPx.y * dpi))
    bx2 = math.min(Wpix-1, math.floor((rectPx.x+rectPx.w-1) * dpi))
    by2 = math.min(Hpix-1, math.floor((rectPx.y+rectPx.h-1) * dpi))
  else
    bx, by, bx2, by2 = 0, 0, -1, -1        -- “disabled” sentinel
  end

  -- zero output & send uniforms
  buf:setArrayData({0,0,0,0})
  cs:send(”Src”,    canvas)
  cs:send(”Hash”,   buf)
  cs:send(”Bounds”, {bx, by, bx2, by2})
  
  love.graphics.dispatchThreadgroups(
    cs,
    math.ceil(Wpix / WG_SIZE),
    math.ceil(Hpix / WG_SIZE), 
    1
  )

  -- read back 128-bit result
  local raw   = love.graphics.readbackBuffer(buf)
  local bstr  = raw:getString()
  local h0,h1,h2,h3 = love.data.unpack(”I4I4I4I4”, bstr)
  return string.format(”%08x%08x%08x%08x”, h0,h1,h2,h3)
end


function love.update(dt)
  if animate then time = time + dt end
end

function love.keypressed(k)
  if k == “space” then animate = not animate end
end

-- Draw to screen & demonstrate the hash workflow
function love.draw()
  drawScene()

  local hash = hashCanvas(canvas)
  effectRan  = (hash ~= prevHash)
  prevHash   = hash

  -- Present result
  love.graphics.clear(0.15, 0.15, 0.15)

  love.graphics.setColor(1, 1, 1, 1)
  love.graphics.draw(canvas, 32, 32, 0, 1 / dpi, 1 / dpi)

  local yText = 32 + HCANVAS / dpi + 8
  love.graphics.setColor(1, 1, 0, 1)
  love.graphics.print(”128-bit hash:  “ .. hash, 32, yText)

  love.graphics.setColor(effectRan and {0, 1, 0, 1} or {1, 0, 0, 1})
  love.graphics.print(effectRan and “-> content changed – ran expensive effect”
                                  or “-> identical – skipped effect”,
                      32, yText + 16)

  love.graphics.setColor(1, 1, 1, 1)
  love.graphics.print(”Press <space> to toggle animation”, 32, yText + 32)
  local ffps = love.timer.getFPS()
  love.graphics.print(”Current FPS: “ .. ffps, 32, yText + 32 * 2)
end

Get the entire code here: turbo/love12-hash-shader

TCB are vital in compositing: there might be expensive shader effects applied to the contents of a Canvas (Texture), but the canvas itself is larger than it needs to be. For example, if we want to apply effects to the drawing operations performed on the main window, we’d first target them towards a canvas, then apply the effect. But the canvas size is likely much larger than the content, with the rest being transparent nothingness. Dragging this emptiness through the next compositing passes wastes GPU cycles and, more importantly, memory.

Ideally, we’d trim the excess at the start of the pipeline, operate on the content only, and then return the composite, with its own bounds and origin offset. This also allows us to cache effect operations based on the content, and avoid recomputing it if the content merely moves or scales.

Here’s a visual demonstration of the love app we’re going to build:

We also need to make sure this works for love apps in 1:1 and HiDPI rendering modes. This is a pretty nasty pitfall, because we’re crossing the boundary between Love’s logical pixels and the shader’s physical pixels!

Let’s start by declaring what we need:

local dpi = love.graphics.getDPIScale()

local canvas  = love.graphics.newCanvas(512, 512, {
  format       = “rgba32f”,
  computewrite = true
})

local quad          = love.graphics.newQuad(0, 0, 1, 1, canvas)
local time          = 0
local workGroupSize = 16
local cs            = love.graphics.newComputeShader(”bounds.comp”)
local buf           = love.graphics.newBuffer(
  “uint32”,
  4,
  { shaderstorage = true }
)

(Note: in Love 12, Canvas and Image will both become just Texture)

Our demo rendering area will be 512x512 logical pixels big. For later rendering, we also declare a Quad (so we don’t have to copy into a “trimmed” Canvas), and load our shader. The shader output will be the physical pixel TCB, for which we just need 4 uints (other types would also work).

workGroupSize determines the 2D edge length of the work group cube in the compute shader. GPUs organize the shader invocations (runs of the main entry point) into work groups of threads. The thread group has 1, 2 or 3 dimensions (the missing ones default to 1). We’ll work with a 16x16 2D work group size, which means that 256 threads invoke the main entry point in parallel. The GPU hardware can then also split these threads across cores, often in smaller packages of 32/64, etc. Threads within the same work group can also utilize synchronization primitives to coordinate with each other.

The group size is set at compile time (you’ll see later in the shader code), and at runtime we have to make sure to schedule enough groups to cover our data. In our example, we’re working with image data, which is 2D. So we can choose a 2D work group so that each thread maps to one pixel. The dimensions don’t have to match, and you need to profile your shader + hardware + data together to find the right parameters.

Let’s write the function to invoke our shader:

function getContentBounds(canvas, dpi)
  local W, H = canvas:getPixelDimensions()

  -- [minX,minY,maxX,maxY] ← [W-1,H-1,0,0]
  buf:setArrayData({ W - 1, H - 1, 0, 0 })

  cs:send(”Src”,    canvas)
  cs:send(”Bounds”, buf)

  love.graphics.dispatchThreadgroups(
    cs,
    math.ceil(W / workGroupSize),
    math.ceil(H / workGroupSize),
    1
  )

  local raw  = love.graphics.readbackBuffer(buf) -- ByteData
  local data = raw:getString()                   -- 16-byte string

  local minX, minY, maxX, maxY = love.data.unpack(”I4I4I4I4”, data)

  if minX > maxX or minY > maxY then return nil end   -- fully transparent

  return minX / dpi, minY / dpi, (maxX - minX + 1) / dpi, (maxY - minY + 1) / dpi
end

This needs to be DPI-aware. This is done by:

• reading the physical pixel dimension of the Canvas, not the logical size

• scaling the output bounds back to logical pixels using the DPI parameter (e.g. 2.0 on a Retina display)

Other than that, we pass the parameters to the shader, schedule enough work groups, and parse the output.

The core idea of the shader is to continually refine the bounds stored in buf. Inside the shader, the buf SSBO is expanded by each execution:

/* bounds.comp – find min/max XY of pixels whose alpha > 0 */

layout(local_size_x = 16, local_size_y = 16) in;

/* Texture to scan */
layout(rgba32f) readonly uniform image2D Src;

/* SSBO with four uints: minX, minY, maxX, maxY */
layout(std430) buffer Bounds { uint b[]; };

void computemain()
{
    ivec2 id = ivec2(gl_GlobalInvocationID.xy);
    vec4  p  = imageLoad(Src, id);

    if (p.a > 0.0) {
        atomicMin(b[0], id.x);
        atomicMin(b[1], id.y);
        atomicMax(b[2], id.x);
        atomicMax(b[3], id.y);
    }
}

What’s going on here:

• declare the work group layout: 2D 16x16

• declare the readonly input canvas

• declare the mutable buf, now Bounds as an unsized array

• the entrypoint to a compute shader is always computemain

• gl_GlobalInvocationID is the global 3D-based index of this thread

  • since our work group dimensions align with the input data (2D image), we can grab the x and y components and treat them as pixel coordinates directly

• imageLoad then uses those coordinates to pull from the input

• 0.0 is the alpha threshold for content

  • content may be blurred, anti-aliased, etc and any active pixel should count as content

• atomicMin/atomicMax are atomic compare-and-replace operations

  • even though 256 threads run in parallel, they fast-sync on these operations

So we move across the image data one 16x16 tile at a time, atomically expanding the TCB box.

Finally, we can call it and render a demo:

local function drawToCanvas()
  love.graphics.setCanvas(canvas)
  love.graphics.clear(0, 0, 0, 0)

  -- rotating white square
  love.graphics.push()
    love.graphics.translate(256, 256)
    love.graphics.rotate(time)
    love.graphics.setColor(1, 1, 1, 1)
    love.graphics.rectangle(”fill”, -64, -64, 128, 128)
  love.graphics.pop()

  -- moving red circle
  love.graphics.setColor(1, 0, 0, 0.8)
  love.graphics.circle(”fill”,
      256 + math.cos(time * 2) * 150,
      256 + math.sin(time * 2) * 150,
      40)

  love.graphics.setCanvas()                -- back to the screen
end

function love.update(dt)
  time = time + dt * 0.25
end

function love.draw()
  love.graphics.clear(0.25, 0.25, 0.25)

  drawToCanvas()

  -- trimmed region
  local x, y, w, h = getContentBounds(canvas, dpi)
  if x then
    quad:setViewport(x, y, w, h)

    love.graphics.setColor(1, 1, 1, 1)
    love.graphics.draw(canvas, quad, 32 + x, 32 + y)

    love.graphics.setColor(1, 0, 1, 1)
    love.graphics.rectangle(”line”, 32 + x, 32 + y, w, h)

    love.graphics.setColor(1, 1, 1, 1)
    love.graphics.print(
          (”trimmed %dx%d @ (%d,%d)”):format(w, h, x, y),
          32, 16)
  else
    love.graphics.print(”Canvas fully transparent”, 32, 16)
  end

  -- full canvas
  love.graphics.setColor(1, 1, 1, 1)
  love.graphics.draw(canvas, 600, 32)
  love.graphics.rectangle(”line”, 600, 32,
      canvas:getWidth(), canvas:getHeight())
end

You can find the full project here: turbo/love12-true-content-bounds - be sure to play with the highdpi setting in conf.lua!

There are many ways to calculate TCB, this is but one of them. But it serves as a nice introduction to basic compute shader concepts.

Try it out; it even includes a few example fonts, featuring GitHub’s very own Mona Sans:

turbo/harfbuzz-variable

If the (audio) job calls for bigger guns, I move to other tools:

• Analysis: deCoda, RipX DAW, BeatNet, Acoustica, etc.

• linear recording: LUNA, Logic Pro

• Sequencing: Maschine 3

What bugs me about all of them is that the waste of pixels on screen for their waveform rendering. You just get a solid, symmetrical plot - in 2025 (exception: RipX, which is space-age tech)! Sure, you can switch some of them to show spectrograms, but that’s also not helpful.

Meanwhile, DJs have enjoyed the best visualization - spectral waveforms - and it hasn’t made the jump yet to mainstream software.

So for my own sanity and maybe to inspire someone else, here’s libdjwaveform, a minimal C reference implementation using FFTW that can render spectral waveforms with plenty of options.

Is it production-ready? Well, do you feel lucky?

Demo output:

Through these discussions, they hope to showcase a vision for static analysis and bug detection, particularly how LLMs can address the challenges of traditional static analysis techniques, including customization, compilation-free analysis, multi-language support, and multi-modal analysis.

Starting with their previous work on agentic & agentless LLM-powered dataflow modeling and security testing (LLMDFA and LLMSAN), this session is focused on sharing recent advances that have been published in December 2024 as LLMSA: A Compositional Neuro-Symbolic Approach to Compilation-free and Customizable Static Analysis.

Originally published on YouTube.

Originally streamed/published on YouTube.

dmon is a tiny C library that monitors changes in a directory. It provides a unified solution to multiple system APIs that exist for each OS. It can also monitor directories recursively.

In my first attempt, Findsight, the frontend HTML was generated using server-side-rendered karax. Note that this was not utilizing the karax reactive framework, but its DOM-builder DSL. However, the Alpine component code, state management, various app startup code, and htmx event handlers were all written using inline JS, which proved to be unwieldy as my projects grew.

In this article, we’ll explore how to use Nim as a full-stack language for type safety and maintainability. We’ll build a complete example of frontend and backend code, which will demonstrate the important concepts to keep in mind when using Nim with Alpine.

Alpine Primer

Consider a single binding:

<span x-show="open">Content</span>

That’s fine, as we’re including the component property open by itself and there’s no active JS code in here. However, even a tiny component store violates this by including a JS object:

<div x-data="{ open: false }">

Or, staying with the same example, an event binding that contains code:

<button x-on:click="open = true">Expand</button>

Side note: x-on can be shortened to @.

These are smaller examples, but in a sufficiently complex app, the complexity of these little inline snippets grows with it.

Fortunately, Alpine provides a way to extract the component (x-data) into a standalone JS object. Here’s an example straight from the documentation:

<div x-data="dropdown">
    <button x-on:click="toggle">...</button>
 
    <div x-show="open">...</div>
</div>
 
<script>
    document.addEventListener('alpine:init', () => {
        Alpine.data('dropdown', () => ({
            open: false,
 
            toggle() {
                this.open = ! this.open
            }
        }))
    })
</script>

And x-bind enables the same for any template directive. Both approaches combined keep the HTML clean.

But now we’d have to write JavaScript, and I’d like to stay in Nim. Nim does have a JS backend, and there are just a few steps needed to create those components in pure Nim.

Frontend

First create a frontend directory. We’ll put all client-side code in here, which will be compiled to JS from Nim, and then later minified and optimized.

Project Structure

.
├── frontend
│   ├── alpine.nim
│   ├── app.nimble
│   ├── app.nim
│   ├── components.nim
│   └── nim.cfg

The Nim config nim.cfg sets our backend, which is picked up by nimsuggest in VS Code to provide backend-relevant error checks:

backend:js
-d:release

It also forces a release build. Nim-compiled JS, depending on the libraries used, is extremely verbose and the debugging info that is generated is less useful in JS code. By compiling in release mode, we end up with more readable JS.

The resulting JS is still too large to ship directly to users, so we need to optimize it. For this, I’m using Terser, which is the best standalone optimizing minifier (esbuild and the Google Closure Compiler both have similar functionality, but are a less effective). Install it system-wide via:

npm install -g terser

Or use npx to invoke it later without prior installation.

Now add it as a build task to app.nimble:

import strformat

bin           = @["app"]
backend       = "js"

requires "nim >= 2.0.0"

after build:
  exec &"terser --compress hoist_funs,keep_fargs=false,unsafe --mangle toplevel {bin[0]}.js -o {bin[0]}.dist.js"

Other than the default terser options, we enable:

• additional compression options

  • hoist_funs: hoists function declarations

  • keep_fargs=false: discards unused function arguments (breaks code that relies on Function.length)

  • unsafe: enables all unsafe optimizations (which aren’t actually that unsafe)

• global name mangling (toplevel) which enables terser to mangle some of the support functions that Nim emits for e.g. string formatting which would otherwise have quite long gensym names

These options are optimized for this use case and will be different if you’re working on a Nim-JS project that isn’t Alpine. For example, you wouldn’t use global name mangling for JS libraries. Since Alpine component code depends on object properties and methods, they’re unaffected by the mangling algorithm.

Component Contract

In components.nim, let’s define the type interface for both the component state (used with Alpine.data) and the behavior (used with x-bind):

import std / [
  dom
]

type
  DropDown* = ref object
    init*: proc()
    destroy*: proc()

    open*: bool
    toggle*: proc(msg: cstring)
    timer*: Interval
    counter*: cint
    
  DropButton* = ref object
    `type`* = "button"
    `@click`* {.exportc: "['$1']".}: proc()
    `disabled`* {.exportc: "[':$1']".}: proc(): bool

To break down what’s going on here:

std/dom provides us with access to plenty of FFI types for interacting with the browser’s object implementations.

The object types are declared as ref, which is the default for JavaScript. Without ref, Nim will use copy semantics, and emit large helper functions for deep-copying, which are not required in this case.

DropDown holds the component state:

• init and destroy are object methods (in the JS sense) that are invoked by Alpine when the component is created and destroyed

• open will hold the current open/collapsed state

• toggle is the method that will change the open state, and also demos parameter passing to object methods

• timer demos a component property that refers to a native browser type, in this case a time interval

• counter is another property that will be used later to explain object property access from within methods

DropButton holds the binding:

• type is an Alpine attribute that determines the DOM type of the bound element

• @click (or x-on:click) binds to the event (x-on) click

• :disabled is a direct attribute binding that maps the given DOM element attribute value to a component method/property

You may notice the exportc pragmas on the last two properties. This is a necessary workaround for Nim’s name mangling. While some identifiers in Nim can be escaped with name, it’s not nearly as flexible as JS’s [’name’], so we have to cheat a bit with exportc‘s built-in string formatting:

• For @click, the “[’$1’]” format produces [’@click’]

• For disabled, the [’:$1’] format produces [’:disabled’]

Alpine Abstraction

We’re almost ready to dive into the component implementation, but we need a few FFI helpers first. In alpine.nim:

proc registerComponent*(name: cstring, component: pointer) 
  {.importjs: "Alpine.data(#, #)".}

proc bindElement*(binding: cstring, actions: pointer)
  {.importjs: "Alpine.bind(#, #)".}

proc env*[T](fn: (proc()), bar: T): (proc())
  {. importjs: "(#).bind(#)" .}

template this*(T: typedesc) =
  var this {.importc, nodecl, inject.}: T

• registerComponent and bindElement map to the respective Alpine functions

• env is a mapping of JavaScript’s bind function, which allows a caller to set the inner this - this may be confusing at first but is required later as we get into closures over object instances from within methods

• this allows us to make Nim aware of the implicit this in a method, and give it a strong type to make nimsuggest and compiler messages more helpful. importc and inject ensure that the code emitted by Nim refers to this literally

Component Implementation: State

In app.nim, we’ll place the actual implementation, starting with the component state and methods:

import std / [
  dom,
  strformat
]

import alpine
import components

proc dropdown(initialOpenState = false): DropDown =
  DropDown(
    init: (proc() =
      this DropDown
      
      this.timer = setInterval(
        (proc() = 
          this DropDown
          inc this.counter
          echo &"Counter is now at {this.counter}"
        ).env(this), # explicit binding
        1_000
      )
      
      echo "Component initialized and timer started"
    ),

    destroy: (proc() =
      this DropDown
      clearInterval(this.timer)
    ),

    open: initialOpenState,
    
    toggle: (proc(msg: cstring) =
      this DropDown
      this.open = not this.open
      echo &"Parameter passed to toggle: {msg}"
    )
  )

There’s a lot more behavior in here than required for a normal dropdown, mostly because I want to show you how to implement other common patterns as well. If you understand what’s happening in this component, you’ll be able to create components of virtually any complexity.

Let’s start with the proc signature:

proc dropdown(initialOpenState = false): DropDown;

Alpine.data (see the example at the beginning of this article) expects a function, which returns a component: a JS object with methods. This is that function. But Alpine also allows parameter passing, usually used for initial state. Here we receive a boolean that indicates the initial state of the dropdown and later copy this into the open property.

All other properties of the Dropdown component are methods. They’re declared inline for brevity, but that is not required. All of them open with this Dropdown, which declares the Nim identifier this with the given type.

In init, on component creation, the timer property is initialized with a new interval timer using the JS function setInterval. Here we have to be careful with scoping. We need to ensure that the inline proc passed to setInterval closes over the correct this. We can’t use this Dropdown on its own in the timer proc because it is not invoked from the Alpine environment, but from the browser timer callback. Instead, we need to explicitly close over the outer this. There are two ways to do this:

• use the env binding we declared before as shown here - this will create a new function that wraps the inner function in a closure environment with the supplied this value

• declare a new variable in the method that the callback can close over

For the second variant, we’d have to add a line like var that = this below the this Dropdown in the init proc body, and then refer to that instead of this from the timer callback proc. Personally, I consider env to be a cleaner way of achieving this.

Other than that, the init method is simple: create a timer that keeps incrementing the counter and print new values to the console (echo becomes console.log). destroy ensures the timer is deregistered.

toggle is the core functionality of flipping the dropdown’s internal state. It also demonstrates the passing of parameters to component methods.

Component Implementation: Binding

The last thing we have to implement on the frontend is the binding, to keep the HTML as clean as possible:

proc dropbutton(): DropButton =
  DropButton(
    "@click": (proc() =
      this DropDown
      this.toggle("boo!")
    ),

    `disabled`: (proc(): bool =
      this DropDown
      return this.counter > 10
    )
  )

On a mouse click event, the toggle method is invoked with a parameter. After the counter reaches 11 (so after 10s), the toggle button will be disabled.

Finally, we register the component:

document.addEventListener("alpine:init", proc(e: Event) =
  registerComponent("dropdown", dropdown)
  bindElement("dropbutton", dropbutton)
)

Building the Frontend

A simple nimble build in frontend/ now produces two files:

-rw-r--r--@ 1 turbo  staff    11K Dec 29 23:43 app.dist.js
-rw-r--r--@ 1 turbo  staff    34K Dec 21 18:32 app.js

You may be surprised at how big the compiled artifact is. 34k for a simple dropdown?! What’s actually happened here though is that Nim has emitted standard library functions we’ve used, e.g. for string formatting. That will only happen once. As you add more functionality, those functions are re-used, so the output size doesn’t grow at this rate!

You can also see Terser has done its job and the final artifact is only a third of the size and looks like this:

function n(n){var l=m(n.length),e=0,t=0;n:for(;e<n.length;){var a=n[e];if(a<128)l[t]=String.fromCharCode(a),e+=1;else{var u=m(0);l:e:for(;;){0;var i=a.toString(16);if(1==(null==i?0:i.length)?u.push(”%0”):u.push(”%”),u.push(i),e+=1,n.length<=e||n[e]<128) // and so on

If you’re size sensitive, you should reduce the reliance on std libraries and bundle JS libraries instead, that you then access via FFI. For example, if I remove the strformat import and the echo statements from the app.nim module, we end up with a much smaller file:

-rw-r--r--@ 1 turbo  staff   3.0K Dec 29 23:49 app.dist.js
-rw-r--r--@ 1 turbo  staff   7.6K Dec 29 23:49 app.js

Backend

Our frontend project is now complete, and we have to serve it. I’m not going to show you how to build a full MASH app, just the basics of SSR HTML that uses the component we built above.

Here’s the project structure:

.
├── backend
│   └── server.nim
├── frontend
│   ...
└── server.nimble

The nimble file will need to build the frontend first:

srcDir        = "backend"
bin           = @["server"]
backend       = "c"

requires "nim >= 2.0.0"

requires "karax#head"
requires "mummy >= 0.3.5"

before build:
  withDir "frontend":
    exec "nimble build"

We’ll also pull in mummy and karax. The backend for this is c (or any other native backend you want).

Statically including the Frontend Code

I prefer to do this, you may also choose to read it from disk or serve it from a CDN:

import std / [
  strutils,
  strformat
]

import mummy, mummy/routers
import karax / [karaxdsl, vdom, vstyles]

const appJs = "./frontend/app.dist.js".readFile

Rendering the HTML

First, let’s build the <head> section:

proc rHead(): VNode =
  buildHtml head:
    meta(charset = "UTF-8")
    meta(
      name = "viewport", 
      content = @[
        "width=device-width", 
        "initial-scale=1", 
        "maximum-scale=1", 
        "user-scalable=0",
      ].join(", ")
    )
    meta("http-equiv" = "X-UA-Compatible", content = "ie=edge")
    script(
      src = "https://cdn.jsdelivr.net/npm/alpinejs@3.x.x/dist/cdn.min.js",
      "defer" = ""
    )

The various meta directives are the minimum required to make sure our page renders fine on all device sizes with sensible defaults.

We also import the Alpine release. The defer attribute causes the browser to fetch the remote script immediately after parsing the <script> tag, but delay execution until after the entire HTML has been parsed. This is important for our init directives to fire deterministically. Usually boolean attributes are activated like attrib = true in karax, but since it conflicts with the built-in Nim keyword, we need to use the string version.

Now let’s build the <body>:

proc rBody(): VNode =
  buildHtml body:
    tdiv("x-data" = "dropdown(true)"):
      button("x-bind" = "dropbutton"):
        text "Toggle Me"
      tdiv("x-show" = "open"):
        p: text "I’m inside!"

    verbatim &"""
      <script>
        {appJs}
      </script>
    """

A few notes:

• tdiv is karax’ way of avoiding conflicts with the Nim operator div

• x-data is the component initializer, also passing the initial open state to our new dropdown

• x-bind means the <button> will inherit all behavior from the binding we created in Nim

• x-show ensures the inner paragraph is only shown when the open property is true (or truthy)

verbatim includes the bundled frontend code inline. Again, this is a personal preference (avoid another request), you don’t have to do this.

Now emit the entire HTML file as a string:

proc home*(): string =
  let vnode = buildHtml html(lang = "en"):
    rHead()
    rBody()

  result = "<!DOCTYPE html>\n" & $vnode

Serve it

The very last thing to do is to serve this via mummy:

proc indexHandler(request: Request) =
  var headers: HttpHeaders
  headers["Content-Type"] = "text/html; charset=utf-8"
  request.respond(200, headers, home())

var router: Router
router.get("/", indexHandler)

let server = newServer(router)
echo "Serving on http://localhost:8080"
server.serve(Port(8080))

Conclusion

After nimble run, we can view the result at http://localhost:8080

Let’s take a look at the Caddyfile for Findsight:

:9999 {
	respond "We’ll be right back (usually within 3 minutes)!"
}

www.findsight.ai {
	redir https://findsight.ai{uri}
}

findsight.ai {
	handle {
		reverse_proxy localhost:8080 :9999 {
			lb_policy first
			lb_try_duration 1s
			fail_duration 30s
			transport http {
				dial_timeout 500ms
			}
		}
	}
}

Here’s what’s happening:

In normal operation, Caddy reverse proxies requests to localhost:8080 where the main Findsight app listens. The entry point is a domain (findsight.ai), and Caddy will automatically handle certificate provisioning and TLS termination. Additionally, there’s a request rewrite for the www subdomain.

If localhost:8080 were the only upstream defined and the server goes down (e.g. for database migration) Cloudflare, which is the CDN for Findsight, would display a generic “upstream dead” error and that’s not a good look. It leaves the user guessing: why is it down? When will it be back?

We need to define a fallback. If Caddy considers an entry for reverse_proxy to be dead, it moves on to the next one. That behavior is defined by the lb (load balancing) policy first. Dead upstreams remain dead for 30s. This duration can be tuned to taste, I chose it mainly to avoid requests hitting the server during start-up after a crash, when the port is reserved, but requests won’t be processed yet.

Now requests hit the internal :9999 upstream, which serves a static response directly from Caddy. Here, one could alternatively display a full HTML page.

This approach should not be employed for defending against application layer or network layer (D)DoS attacks; rather, such defense should be pushed towards the edge, utilizing Web Application Firewalls or analogous policy agents that can drop suspicious traffic with minimal overhead.

In contrast, this approach is more suitable for enforcing fair use limits or limits that are part of a license, which restricts the number of operations an actor can perform.

SQLite is used to:

• store the limits configuration, each with a maximum count per configurable time period

• store instances of active counters for actors (we’ll use “visitors” for this example)

• manage expiration

Interface

The goal is that with a single query executed for every operation, rate limiting calculations are performed automatically:

INSERT INTO visitor_limits(visitor_id, limit_id)
VALUES (1, 1)
ON CONFLICT DO UPDATE SET count = count + 1
RETURNING denied, resets_at;

• We inform the database that visitor 1 is attempting to perform an operation limited by limit 1.

• If the limit is not yet reached, the current counter is incremented

• If the limit is reached, denied will be 1 (SQLite has no booleans), and resets_at is defined as the next UTC unix epoch timestamp after which the limit resets. resets_at is not defined when the request isn’t denied.

This allows the counter to be incremented by other positive integer values, for example, if the “cost” between operations varies, which is useful for consumption-based enforcement.

Database Setup

Limits

The schema for this is quite simple. First, we define a static configuration table for the limits:

CREATE TABLE IF NOT EXISTS limits (
  id INTEGER PRIMARY KEY ASC
  ,name TEXT UNIQUE NOT NULL
  ,maximum INTEGER NOT NULL CHECK ( maximum > 0 )
  ,period_minutes INTEGER NOT NULL CHECK ( period_minutes >= 1 )

  ,UNIQUE (name, maximum)
) STRICT;

• name uniquely identifies the limit; this should be the limited operation, e.g. send_message

• maximum is the maximum number of allowed operations within the period. This is inclusive, so a maximum of 5 allows 5 requests in a period and denies the 6th

• period_minutes defines the time between counter resets.

The period can alternatively be expressed in seconds, which is the highest usable time resolution in SQLite.

To add a new limit:

-- allow 5 messages per 2 minutes
INSERT INTO limits(name, maximum, period_minutes)
VALUES (’send_message’, 5, 2);

Counters

Next, create a table for the counter instances. These will be lazily populated - if a visitor never executes a given operation, there’s no need to create a row for it:

CREATE TABLE IF NOT EXISTS visitor_limits (
  id INTEGER PRIMARY KEY ASC
  ,visitor_id INTEGER NOT NULL REFERENCES visitors(id)
  ,limit_id INTEGER NOT NULL REFERENCES limits(id)

  ,denied INTEGER NOT NULL DEFAULT 0 CHECK ( denied IN (0, 1) )

  -- set by trigger
  ,count INTEGER CHECK ( count >= 0 )
  ,resets_at INTEGER CHECK ( resets_at > 1680373723 )

  ,UNIQUE (visitor_id, limit_id)
) STRICT;

Note: this references another table visitors, this may not be the case in your application. Use whichever actor identifier fits your model best.

A sanity check is added to resets_at to protect against logic bugs, using a reasonably recent timestamp and making it clear in the DDL that this column will be a unix epoch in seconds.

Triggers

To implement the add and reset logic, two triggers are required:

CREATE TRIGGER IF NOT EXISTS init_visitor_limit_counter
AFTER INSERT
ON visitor_limits
WHEN (NEW.count IS NULL OR NEW.resets_at IS NULL)
BEGIN
  UPDATE visitor_limits
    SET
      count = 1
      ,resets_at = (unixepoch() + (60 * (SELECT period_minutes FROM limits l WHERE l.id = NEW.limit_id)))
      ,denied = 0
  WHERE id = NEW.id;
END;

This runs after the INSERT statement in our final interface query. If there wasn’t a counter for this operation and visitor, we initialize the counter, flag, and first reset timestamp.

For any INSERTs after this, we need to maintain the flag and reset the counter if necessary using a second trigger:

CREATE TRIGGER IF NOT EXISTS update_visitor_limit_counter_breaker
BEFORE INSERT
ON visitor_limits
BEGIN
  -- trip breaker for non-expired
  UPDATE visitor_limits
    SET denied = visitor_limits.count >= (SELECT maximum FROM limits l WHERE l.id = NEW.limit_id)
  WHERE visitor_limits.visitor_id = NEW.visitor_id
    AND visitor_limits.limit_id = NEW.limit_id;

  -- or reset if expired
  UPDATE visitor_limits
    SET
      count = 0
      ,resets_at = unixepoch() + (60 * (SELECT period_minutes FROM limits l WHERE l.id = NEW.limit_id))
      ,denied = 0
  WHERE visitor_limits.visitor_id = NEW.visitor_id
    AND visitor_limits.limit_id = NEW.limit_id
    AND unixepoch() > visitor_limits.resets_at;
END;

This runs before the INSERT to make sure the denied flag that is returned is up to date. In our example, the 6th message should be denied, not the 7th.

Testing

That’s it. We can test this now by running the same interface query repeatedly:

INSERT INTO visitor_limits(visitor_id, limit_id)
VALUES (1, 1)
ON CONFLICT DO UPDATE SET count = count + 1
RETURNING denied, resets_at;

-- send 6 messages in < 2 minutes:

-- Run 1 returns: 0, NULL
-- Run 2, 3, 4, 5 return: 0, 1680441289
-- Run 6 returns: 1, 1680441289

-- ... wait for 2 minutes ...

-- Run 7 returns: 0, 1680441422

As the limit is reached, the counter will continue to increment; which can be leveraged to gain insights into the behavior of limited users. A minor overage is to be expected, but a drastic surge in requests beyond the set limit could signify a bug or the presence of a malicious bot.

In LLM-only systems, such as search engines powered by RLHF-tuned models, there’s a risk of the core model confidently stating wrong facts or making assertions that go beyond or even contradict the available ground truths (e.g. a search index). This problem is more commonly known as hallucination.

There are several ways to engineer prompts to minimize this effect, and combined with instruction fine-tuning are generally successful in limiting hallucinations. In systems where fact retrieval is the primary use case, though, this issue can be almost eliminated.

HyDE-powered search relies on embeddings, dense vector representations of (in this case) textual data. OpenAI embeddings for example, can effectively encode abstract qualities of short and long-form text (up to ~8,000 tokens per embedding) in ~1600-dimensional vectors. These vectors can then be stored in vector-similarity (VSS) indexes (e.g. HNSW/RediSearch) that facilitate efficient VSS or hybrid VSS and full-text queries.

However, these systems are then limited to retrieving similar facts. A user interface could prompt the user for a fact, which is then embedded and used as a query vector to retrieve the nearest (most similar) facts from the index. This requires the user to already have a possible answer in mind, which is much less intuitive than asking a question.

Instead of embedding the user input directly, a sufficiently trained LLM can be used to generate hypothetical answers, which are in turn embedded and used for retrieval. The LLM will likely hallucinate details for its answers, but since these answers are not relayed to the user as fact, these errors are inconsequential. The embedding is much more sensitive to the structure and language used in the answers, rather than their correctness.

An example prompt (here using LLaMa-65B) may look like this:

Three possible answers to the question ‘what are the negative effects of the war on drugs?’ are:
1.

with an example output:

1. Incarcerated people in the U.S. have exceeded two million and the great majority of the people in jail are there for drug related crimes. In many cases, these people don’t get to go to school and learn the skills they need to lead healthy, productive lives.
2. People all over the world die daily, in violent confrontations, related to the trade of illegal drugs.
3. Millions of people, including children, are sick with diseases caused by using contaminated, illegal drugs. These people are spreading disease to others.

Depending on the performance of the embedding and the difference between the answers, one embedding per answer (then averaged) or one embedding for the entire answer list can be used. For non-fiction fact retrieval (excerpts from books), I found it helpful to include the question itself in the embedding for each HyDE, since this type of content often poses a question only to immediately answer it.

The Nim 2.0 release candidate is out, and includes a whole host of amazing changes and additions. I had been holding off on exploring Nim because I was waiting for ORC and multi-threading to become the default. They have been available for a long time, but defaults matter - it’s what first-time and first-time-in-a-while users experience. It forms their opinion of what the language is about.

Installing Nim on Apple Silicon Macs is pretty straightforward. The official installer sets up choosenim and a default stable release:

curl https://nim-lang.org/choosenim/init.sh -sSf | sh

However, both Nim itself and the compiler output will be amd64 (Intel) binaries. To go native, and to benefit from Nim 2 right now, more configuration is required.

Set up Nim 2 natively

We need a source build, and thankfully that’s easy:

git clone https://github.com/nim-lang/Nim
cd Nim
git checkout version-2-0
sh build_all.sh

Yep, that’s it. We don’t have to mess with our PATH either. Instead, we can now point choosenim at the new build:

choosenim <location>/Nim

And confirm the architecture with:

$ nim -v
Nim Compiler Version 1.9.1 [MacOSX: arm64]
Compiled at 2023-01-14
Copyright (c) 2006-2022 by Andreas Rumpf

(2.0 RC self-reports as 1.9.1 as of Jan 15 2023)

To switch back, use choosenim stable.

Native & universal binaries

Building a project with this toolchain will produce an Intel binary. To get a full build on macOS, we have to follow Apple’s guidelines and set the correct compiler and linker targets. In your project’s nimble (nimble init if you don’t have one yet), add a new target:

task release_clang, "Build a production release (macOS)":
  --verbose
  --forceBuild:on
  --cc:clang
  --define:release
  --deepcopy:on
  --cpu:arm64
  --passC:"-flto -target arm64-apple-macos11"
  --passL:"-flto -target arm64-apple-macos11"
  --hints:off
  --outdir:"."
  setCommand "c", "hello.nim"

• -flto is required because clang doesn’t like Nim’s default passing of LTO parameters

• note the cpu and -target parameters

• the rest are standard release flags

ORC and threads are default now, so no need to enable them here anymore. It’s a good idea to pin the Nim version in the nimble file, in this case to >= 1.9.1.

Running nimble release_clang now gives us a nice native binary:

$ file hello
hello: Mach-O 64-bit executable arm64

If you want to build an Intel binary, add another task and change the target to x86_64-apple-macos10.12. If you need a universal binary, build both the Intel and ARM targets first, then merge them using lipo:

lipo -create -output universal_app x86_app arm_app

A final note: you should always also use -d:malloc. It will be slower, but default Nim (as of October 2025) leaks memory.

In that post, I mentioned that baking soft-body dynamics is a lot harder. There are several reasons for that:

• Soft body deformations rely on per-vertex transformations

• Apart from Alembic, there are no standard ways of transporting point-based animations between 3D software

• Even then, some simulations (e.g. fluids) may change the vertex and thus poly count, something barely any software can deal with

This problem isn’t new, and the industry has come up with two methods to address this:

1. Portable dynamics bake caches (take a look at the previous post for an explanation of dynamics baking). This is a way of transporting the internal bake cache between applications without “rendering” the transformations to a mesh. Notable software includes e.g. ChronoSculpt, which can work with three major cache formats (incl. Alembic)

2. The brute force method: Bake a new mesh for every single frame. This is supported by many apps as “OBJ sequences” or “mesh sequences”, notably AE Element3D. As the name implies, the export format is a folder full of single OBJ files, one for each tick (a frame). The benefit of this method is the wide compatibility: everything supports OBJs (though not necessarily sequences), and changing poly counts are a non-issue since we exchange the entire mesh every tick.

So mesh sequences address a similar problem to Alembic, but how can we convert between them? I needed to do this recently, to transport soft-body physics baked in Cheetah to Marmoset Toolbag 4 for rendering. Cheetah supports nothing - it stores its bake cache in the main scene file but the format is undocumented, and there isn’t any support for exporting Alembics. Toolbag on the other hand only supports Alembic, but not mesh sequences.

The first issue was easy enough to address, and I won’t go into much detail because you’re likely not using Cheetah and are here to learn how to do the conversion from sequences to Alembic. In short, there’s both an import and an export script for OBJ sequences for Cheetah, created by forum users.

Baking and exporting leaves us with a folder full of OBJs:

Now we need to convert those into one Alembic file. I’ve searched a while for a simple way to do this, but I’m afraid there isn’t one. We have to involve another piece of software, but thankfully it’s free: good old Blender.

Users of Blender have tried to solve this problem in the past, and a few have had success with slightly abusing the Stop Motion OBJ plugin, though that workaround seems to no longer work in Blender 3.

Enter Barnaba Mikułowski, who graciously provided a plugin-free conversion setup based on a geometry node network in Blender. I’ve adapted his original file to be a more generic template, and you can download it here (3 MB).

Open the Blender scene (I used Blender 3, I recommend you do the same). Click to highlight the “Import Sequence Here” collection and enable visibility if required.

Go to File -> Import -> Wavefront (.obj) – don’t use the legacy option

Navigate to your mesh sequence folder and click-shift-select all files that are part of the sequence (make sure the naming produces proper ordering!)

Click import, you should now see all OBJs imported as children of the import collection, in proper order, and rendered in the viewport.

To clean up the viewport, untick the box on the collection object to re-exclude it from the viewport. In the bake network, confirm the input is set to the import collection. Adjust the Blender animation timeline to fit your imported sequence (start and end frames can be set at the top right of the keyframe panel, and FPS can be set in the output properties which can be found behind the printer icon in the vertical icon bar on the right between the viewports and the inspector). Click the play button to preview your animation and check everything’s in order.

Now select (!) only the bake network in the object tree and go to File -> Export -> Alembic (.abc). Change the scene options if required, but make sure “Only: Selected Objects” is ticked!

Now, the file can be imported into any package that supports Alembic:

This is a pretty straightforward solution, and how much hassle is involved depends on the 3D modeler you’re using. I re-used a model of a microSD card I recently created in my modeler of choice (Cheetah) and used Cheetah’s Bullet integration. Bullet is a dynamics engine that supports a range of features, including rigid body and soft body dynamics, and effectors (or forces). These are all standard features of any modern modeling package and you should be able to follow along in Blender, C4D or whatever else you’re using.

For this technique to work, each “particle” has to be a separate mesh within the scene. This will then show up as a separate mesh object in the FBX hierarchy and mo2. The main problem with this approach is performance. Separate objects perform much worse during the simulation than particle-systems that instantiate the same reference object.

Before we worry about that though, we need to set up a scene. For this demo I went with:

• a floor: a plane

• a hit target: extruded text

• an effector: a cylindrical turbulent force effector helps to “throw” the SD cards down with a satisfying twist

If dynamic objects are allowed to interact with a complex but static shape, the added disturbance and physical complexity make the result much more enjoyable and communicate to a viewer that this isn’t hand-key-framed animation. Here’s my scene setup in Cheetah 8.

The plane and text get a rigid body tag. A tag in Cheetah is an extended object property page, in this case it connects the object it tags to the dynamics engine and sets up the basic physical properties of the object.

The rigid body tag for the floor plane is “static”, i.e. it doesn’t move. The “concave” collision model means the faces of the mesh itself are used to calculate the collisions, rather than a bounding box or shaped hull. As the name implies, this is required for concave objects, since other objects may need to penetrate its bounding box, but also increases simulation precision at the cost of performance. Since we’re not trying to get good realtime performance in Cheetah, this isn’t relevant - crank everything up. Cheetah has several other precision levels that I needed to turn up to the max, and you’ll likely have to do the same. Look for parameters like “margin”, “precision”, “dynamics sampling”.

I later tuned the frequency of the cylindrical turbulence effector until I got a pleasing visual result from the “throw”.

The next step is to manually instantiate multiple copies of the object. I’d keep it below 100 for use in mo2. This can be scripted if your modeler supports that. Make sure the initial object has the required rigid body properties and material assignments.

A fringe benefit of this is the ability to further specify separate materials. All instances have the same material reference, and mo2 will import it once, and then create links. However, you could later assign different materials to different particles to make it visually more interesting.

Now it’s time to bake. How you do this will again depend on your software, but the process I’m referring to here works like this: In realtime (no bake cache) mode, every time you play the animation time-lime or your current take, the dynamics engine will recalculate everything in real time. Because of random seeds, you’ll get different results. This simulation only exists in this software though and won’t be exported automatically with an FBX file. Baking runs the simulation once, and caches the physics state (once per frame). Successive plays will now look identical, as the the dynamics are no longer simulated but rather replayed from the cache.

If you need to, set up your frame-rate before doing this!

One more thing to do: transfer the internal cached states to keyframes.

mo2 supports basic f-curve animation. Each mesh within an FBX hierarchy can be animated independently, but only the basic transformations are available: scale, rotate, translate. Other software may support vert-based movement, allowing you to bake soft-body physics, but mo2 doesn’t.

Again, this depends on your choice of software, but in Cheetah my general approach is:

1. Group particles into folders (no more than 50 each)

2. Switch to animation view and select a folder group

3. Activate “key hierarchy” - this will ensure keyframe record commands propagate to all child objects

4. Key record each frame

5. ungroup all batches

6. (optionally remove physics tags)

The keyframe timeline should then look like this:

And we’re done! Now export your FBX scene, paying attention again to set the correct frame-rate in the export tools.

And then import into mo2, by choosing Add -> Model -> Import. You can bake multiple different simulations as separate takes, and mo2 will pick those up (along with the take name!).

Here’s a quick render of the final result:

And another earlier test, using cube meshes: