DEV Community: Shivam Dwivedi

The Lemmings demo makes each line of text a platform

Shivam Dwivedi — Thu, 05 Nov 2026 17:50:45 +0000

A line of text is an odd place to build a floor. It becomes a much better idea once a paragraph wraps.

MarkBlah's Lemmings demo gives little walkers the page itself to walk on: borders, buttons, images and individual text fragments. [1] I went through the source because the interesting part is the choice of geometry. The pixels are drawn with CSS. JavaScript measures the terrain and advances the walkers.

Original mechanism illustration based on the source. This is not a screenshot or a recording of the demo.

A paragraph box would make a boring level

An element's getBoundingClientRect() gives a rectangle around it. That is useful for a button. Applied to a whole paragraph, it loses the gaps and different line lengths that make the text interesting as terrain. [2]

The demo walks through text nodes, selects each node with a Range, and collects its getClientRects() fragments. [1][3] Wrapped text can therefore contribute several floor rectangles rather than one large paragraph wall.

There is an equally useful choice after measurement: text is marked as floor-only. It can catch a walker falling from above, while the ordinary solid-obstacle checks leave it out. Boxes and borders participate in those solid checks as well.

Otherwise, closely spaced lines would be a collection of tiny cages. The character could fit on a line but not between the floors above and below it. Making text one-way terrain gives it a different job from a button's box.

From page pixels to a smaller world

The source uses four screen pixels per world unit. It adds scroll offsets to viewport-relative measurements, then rounds the left and top edges down and the right and bottom edges up. [1] Adding scroll offsets is what converts the client rectangle into document coordinates. [2]

Here is my separate arithmetic illustration, using a synthetic rectangle rather than a measurement from a live page:

from math import floor, ceil

left, top, right, bottom = 10.5, 20.25, 17.25, 21.25
scroll_x, scroll_y, scale = 8, 100, 4
world = (
    floor((left + scroll_x) / scale),
    floor((top + scroll_y) / scale),
    ceil((right + scroll_x) / scale),
    ceil((bottom + scroll_y) / scale),
)
print(world)  # (4, 30, 7, 31)

The resulting rectangle covers world x-coordinates from 4 up to, but excluding, 7, and y-coordinates from 30 up to, but excluding, 31. I checked the rounding independently with exact fractions and checked that the right and bottom edges are excluded.

Rounding outward keeps a thin measured feature from disappearing just because its edges fall between world cells. It also makes this a coarse collision world: the resulting shape need not match the painted pixels exactly.

Fast movement needs more than a final position

A second source detail addresses thin surfaces during a fall. The airborne update divides movement into substeps no larger than one world unit on either axis. [1]

For an arithmetic example, put a one-unit platform at y in [10, 11). A point moving directly from y=7 to y=19 lands beyond it. An endpoint-only overlap check sees nothing. Checking the intermediate integer positions finds y=10.

I executed that small numerical case separately. It illustrates the reason for sampling along movement; it is not a claim that I ran the browser's complete collision engine. The upstream loop also handles the walker's body, direction, ceiling and wall checks.

The page can change under your feet

Reflow matters because the world is a document. The source rebuilds its rectangle map after page changes and keeps a surface identity so a standing walker can follow the same surface when it moves. It also has explicit shortcuts for fixed or sticky elements and clipped content. [1]

TheLuigiplayer's browser RPG write-up describes caching rectangles for pointer interaction. [4] The connection is practical: measuring layout and moving an object are separate jobs, and cached geometry needs a clear refresh point.

I haven't rendered this demo or measured its frame cost. The source trace and numerical checks explain the terrain model. If I were borrowing the idea, I would start by deciding which page features should carry a character and which should block it. That choice gives the page its rules before the sprite takes a step.

References

MarkBlah, Lemmings source at the reviewed revision, and the original playground.
MDN contributors, Element.getBoundingClientRect().
MDN contributors, Range.getClientRects().
TheLuigiplayer, Building a 700+ Card Browser RPG with React 19, Vite 8, and Zero Monetization.

Asset credits

Original schematic and arithmetic example. No upstream sprites, screenshots or source files are redistributed with the article. The original demo remains linked to its author.

AI disclosure

AI was used to draft the article.

My first Phonon WAV, with the model and language pinned

Shivam Dwivedi — Thu, 05 Nov 2026 17:50:12 +0000

speech.wav was the first useful result: a mono PCM file containing 44,160 samples at 24,000 Hz. That works out to 1.84 seconds of audio for “Hello from Phonon.”

I generated it with Phonon's public English checkpoint on CPU. Getting that file is a more useful starting point for me than borrowing a leaderboard latency number from a different machine.

Actual generated samples. The plot shows the resulting audio, not synthesis speed or a speech-quality score. Image by the author.

Listen to the generated WAV.

The new Hugging Face write-up revisits Phonon's recent release and its integration options. [1] The model was already available before that article; this walkthrough checks one concrete route from the published tooling to a file.

Pin the tool and the checkpoint

I used ptts 0.6.0 and the phonon-31m-en checkpoint at revision 92741c5b07d085ff840e26fea8ce43110b87852f. The runtime's Python package wraps its native implementation; this route does not require installing PyTorch. [2]

You need uv, a Python version supported by the published wheel, and a supported CPU platform. The first run needs access to the public model files. In a new working directory, this was my literal command:

uvx --from ptts==0.6.0 ptts --lang en --device cpu --seed 13 \
  --model hf://gradium/phonon-31m-en@92741c5b07d085ff840e26fea8ce43110b87852f \
  'Hello from Phonon.' -o speech.wav

It returned:

wrote speech.wav (1.84s)

That final number is the duration of the generated clip. It is not the time the command spent generating it. The model download and loading step also belong outside any claim about time to first audio.

I used the checkpoint's default voice. There was no voice cloning, account creation or hosted inference request in this check.

The language flag does real work

I also tried the command without --lang. It exited with status 2 before synthesis and asked for a language.

The CLI normalizes text before tokenization, so it requires an explicit language or none to skip that step. Its help lists normalization languages; that list should not be read as a promise that every checkpoint speaks all of them. [2] The checkpoint here is specifically the English model.

The model card lists Apache-2.0 for this English checkpoint. [3] The Phonon family includes other checkpoints with different licences. Check the particular files you plan to ship rather than carrying one model's label across the family.

Inspect the file before building around it

Here is the standard-library check I ran from the directory containing speech.wav:

import wave

with wave.open('speech.wav', 'rb') as audio:
    channels = audio.getnchannels()
    rate = audio.getframerate()
    frames = audio.getnframes()
    print('channels:', channels)
    print('sample rate:', rate)
    print('frames:', frames)
    print('seconds:', frames / rate)
    assert channels == 1 and rate == 24000

It printed:

channels: 1
sample rate: 24000
frames: 44160
seconds: 1.84

I also checked that the PCM samples were not all zero. A readable, non-silent WAV confirms the basic output path; it doesn't establish intelligibility, pronunciation quality or a model ranking.

The first command populated the model cache. I then ran the same text and seed with the cached checkpoint directory passed directly as the model location, and that local-folder run completed too. I did not disable the machine's network, so this is not a network-isolation test.

Dishant's Phonon TTS: 64 MB, Six Milliseconds, One Licence Trap raises the useful packaging question: which checkpoint and supporting files are actually being deployed? [4] I kept this run to one public English checkpoint and verified the resulting file. The next integration decision should follow your application: save a whole clip, or consume a stream as audio becomes available. This command checks the file path.

References

Gradium and Hugging Face contributors, A Closer Look at Phonon TTS.
Gradium, ptts runtime and integration documentation, and ptts 0.6.0 on PyPI.
Gradium, the pinned English checkpoint.
Dishant, Phonon TTS: 64 MB, Six Milliseconds, One Licence Trap. Third-party latency claims were not reproduced here.

Asset credits

Original waveform of the generated clip. Speech was synthesized with Gradium's public Phonon English checkpoint and its default voice from the stated input text; the linked WAV is AI-generated audio. No person's recording was supplied or cloned.

AI disclosure

AI was used to draft the article.

Go JSON v2: when an empty patch stops being empty

Shivam Dwivedi — Thu, 05 Nov 2026 17:50:05 +0000

An empty update should be a fairly quiet object. Mine grew two fields after I switched JSON packages.

With the same Go struct and the same zero value, encoding/json produced {}. encoding/json/v2 produced {"count":0,"enabled":false}. Both calls succeeded.

For a PATCH-style endpoint where an absent member means “leave this alone,” that is a change in the request's meaning. The serializer hasn't become confused. The old tags are asking a different question under v2.

Outputs from the executed Go example. The PATCH interpretation is the explicitly defined example contract, not a rule imposed by JSON itself. Image by the author.

Decide what an absent field means

Go's new announcement makes encoding/json/v2 generally available in Go 1.27. [1] I used Go 1.27.3 for this example and ran both packages in the same program.

Here is my small update contract: omitted fields leave the stored value unchanged; present fields replace it. So an explicit zero, false, or empty list must survive serialization.

The original struct uses plain values and omitempty. In v1 that option omits the zero number and false Boolean. In v2 it is based on the encoded JSON value: an empty string, array, object or null can be omitted, while zero and false remain present. [2]

That also means “replace a list with an empty list” needs attention. An omitempty tag can remove the very empty array the receiver needs to see.

Give presence its own representation

For this contract I use pointers for the scalar fields and omitzero for all fields. A nil pointer means absent. A non-nil pointer can carry an explicit zero or false. For the slice, nil means absent and a non-nil empty slice means clear the list.

Save this as patch.go:

package main

import (
    "fmt"
    v1 "encoding/json"
    v2 "encoding/json/v2"
)

type OldPatch struct {
    Count int `json:"count,omitempty"`
    Enabled bool `json:"enabled,omitempty"`
    Labels []string `json:"labels,omitempty"`
}

type Patch struct {
    Count *int `json:"count,omitzero"`
    Enabled *bool `json:"enabled,omitzero"`
    Labels []string `json:"labels,omitzero"`
}

func must(b []byte, err error) string {
    if err != nil { panic(err) }
    return string(b)
}

func main() {
    fmt.Println("old tags, v1:", must(v1.Marshal(OldPatch{})))
    fmt.Println("old tags, v2:", must(v2.Marshal(OldPatch{})))
    fmt.Println("absent, v2:", must(v2.Marshal(Patch{})))
    zero, off := 0, false
    p := Patch{Count: &zero, Enabled: &off, Labels: []string{}}
    fmt.Println("explicit clear, v2:", must(v2.Marshal(p)))
    fmt.Println("explicit clear, v1:", must(v1.Marshal(p)))
}

With Go 1.27.3 installed, run go run patch.go. No external module is needed. My output was:

old tags, v1: {}
old tags, v2: {"count":0,"enabled":false}
absent, v2: {}
explicit clear, v2: {"count":0,"enabled":false,"labels":[]}
explicit clear, v1: {"count":0,"enabled":false,"labels":[]}

The important pair is the empty corrected patch and the explicit-clear patch. They now carry different requests. The corrected type also emits the same result through v1 in this check.

I independently parsed those outputs and applied the declared replace-by-member rule to a synthetic record. The absent patch retained its original values; the explicit patch set the count to zero, disabled the flag and cleared its labels. This is serialization plus a small contract check, not a running HTTP service.

Keep the migration close to the API contract

Frank Chu's 7 Go jsonv2 breaks I verified in Go 1.27 covers the wider behavior changes. [3] The omission example deserves a test at your own endpoint boundary because valid JSON can still express the wrong update.

For this example, I would keep golden outputs for an absent patch, an explicit scalar zero and an empty list. A plain search-and-replace of the import cannot decide those meanings for you.

This representation has a limit: a single pointer does not distinguish every possible “absent versus explicit null” requirement. If your API gives null a separate meaning, model that presence state explicitly. The example only promises the absent and explicit-value cases shown above. I haven't measured a speedup or audited a production API.

References

Go team, A new Go API for JSON.
Go standard library, encoding/json/v2 documentation, including omitempty and omitzero.
Frank Chu, 7 Go jsonv2 breaks I verified in Go 1.27. Its performance measurement is not reused here.

Asset credits

Original contract diagram drawn from the saved program outputs. The program and synthetic update example are original explanatory material.

AI disclosure

AI was used to draft the article.

StateBench’s matched traces make a better reading test

Shivam Dwivedi — Wed, 04 Nov 2026 15:18:44 +0000

At one point in my generated StateBench example, g holds 99 and c holds 57. Three versions of the next update all leave g at 57:

g <- c;
g <- (g + 58) mod 100;
g <- 57;

The answer agrees. The work needed to get it does not. One line reads another variable, one reads its own previous value, and one supplies the answer directly.

That is a useful way into Ai2's new StateBench release. Rather than treating every long-context question as the same reading task, it separates different kinds of state updates. [1]

An actual update from the generated trace family. This is a program-semantics illustration, not a language-model score. Image by the author.

Start with a shared trace

I ran the released generator and inspected four matched samples. The repository calls their families periodic, solvable, aperiodic and r-trivial. The announcement describes the first two as general-finite and soluble problems respectively. [1][2]

For the specific preview I used seed 13, eight ordinary variables, and eight extra assignments, without filler. The generated program also initializes a temporary register. That produces 17 assignments in each version: nine initializations plus the eight extra steps.

To reproduce that preview, use Python 3.12 or later and uv. Check out the source revision first:

git clone --depth 1 https://github.com/allenai/state-bench.git
cd state-bench
git checkout 5b333b8d426638d8825f40efe8a508c20eb85730
uv sync --no-dev

Then generate the four JSON previews:

for family in periodic solvable aperiodic r-trivial; do
  uv run --no-dev state-bench sample \
    configs/experiments/solvable.yaml \
    "integer-code-modular--$family" \
    --seed 13 --num-variables 8 --extra-assignments 8 \
    --filler-proportion 0 --json > "$family.json"
done

I used the repository's supported variable count. Asking this configuration for five variables failed validation; its configured counts are 2, 4, 8 and 16. A CLI flag selects a permitted condition here rather than silently rewriting the experiment configuration.

Follow what the right-hand side reads

In the aperiodic version, the update states the new value explicitly. To recover the final g, a reader can find the last assignment to g.

In the solvable version, the update needs the current g. For this step, (99 + 58) mod 100 is 57. Skipping an earlier update can change the input to a later one.

In the periodic version, g <- c needs the current value of another register. Earlier changes to c can now matter to g. These are copies at assignment time, not persistent aliases: changing c later does not retroactively change g. [2]

The r-trivial construction replaces later writes with the first value assigned to their target. At this position it writes 99, so that family keeps a different answer. It does not share the changing-state answer just because its assignments appear in the same places.

For this preview, the final values of a through h, followed by TMP, were:

periodic:  [16, 75, 99, 1, 48, 28, 57, 23, 28]
solvable:  [16, 75, 99, 1, 48, 28, 57, 23, 28]
aperiodic: [16, 75, 99, 1, 48, 28, 57, 23, 28]
r-trivial: [28, 75, 57, 1, 48, 34, 99, 23, 81]

I independently replayed every canonical assignment with a small interpreter and checked those outputs. The first three families also matched after every assignment in this sample, rather than merely arriving at the same final vector. That is a check of the generator's transformations, not evidence about an LLM's ability to follow them.

Retrieval is only part of the question

When I read a memory benchmark result, I want to know whether it tests finding an explicit value or composing updates. A larger input window does not make those operations interchangeable.

He Fangsheng's DEV discussion of derived state and retrieval argues for treating the current state as a separate object. [3] I would keep the claim narrower than “retrieval cannot help”: retrieval can provide relevant updates, but the system still needs to put those updates in order and apply their semantics.

The matched traces help isolate that distinction. A system can be handed similar-looking programs, the same update positions, and even the same expected output, while the dependency structure changes. Looking only at final answers would hide how each question was constructed.

Ai2 also evaluates pretrained and frontier models in the release. [1] I did not rerun those evaluations, train a model, or measure accuracy here. The concrete result is smaller: the published generator makes the difference between lookup, self-update and cross-variable dependency visible in an executable example.

References and resources

Ai2, StateBench: Testing how language models track state changes over long documents.
Ai2 contributors, StateBench source at the checked revision. The repository documents family derivation and eager-copy semantics.
He Fangsheng, Vector RAG can't fix long-context state tracking. Its model measurements were not reproduced for this article.

Asset credits

Original assignment diagram based on the generated synthetic traces. StateBench source is Apache-2.0; the figure contains no third-party screenshots or benchmark charts.

AI disclosure

AI was used to draft the article.

Two coroutines, one journal: a Restate restart demo

Shivam Dwivedi — Wed, 04 Nov 2026 15:17:26 +0000

Both preparation steps had finished when I stopped the Node process. The Restate server stayed running. After I started the service again, the pending invocation returned ["A", "B"], and the preparation writes were still present only once each.

This is the small recovery demo I wanted for Restate's new durable coroutines: two routines with their own steps, an interruption in the middle, and a file that makes the executed effects easy to inspect. There is no language model in this example.

Diagram of the completed restart trial. The spacing is schematic, not a latency measurement. Image by the author.

Put the work inside the routines

Restate's announcement describes generator-based coroutines that let its scheduler control when routines advance. Their I/O can overlap while completion order is recorded for recovery. [1] I used Restate Server 1.8.1, Node 22.22.1, and both JavaScript packages at 1.18.2.

The service writes a short line during preparation, waits on a durable timer, then writes a finish line. A returned value travels through the generator's local variable into the final result.

In a new package with "type": "module", install the matching dependencies:

npm install --save-exact @restatedev/restate-sdk@1.18.2 @restatedev/restate-sdk-gen@1.18.2

Save the service as service.mjs:

import { createServer } from "node:http2";
import { appendFileSync } from "node:fs";
import * as restate from "@restatedev/restate-sdk";
import { gen, execute, run, sleep, spawn, all } from "@restatedev/restate-sdk-gen";

function lane(name) {
  return gen(function* () {
    const value = yield* run(async () => {
      appendFileSync("effects.log", `prepare-${name}\n`);
      return name.toUpperCase();
    }, { name: `prepare-${name}` });
    console.log(`prepared-${name}`);
    yield* sleep(8000);
    yield* run(async () => {
      appendFileSync("effects.log", `finish-${name}\n`);
      return true;
    }, { name: `finish-${name}` });
    return value;
  });
}

const demo = restate.service({
  name: "CoroutineDemo",
  handlers: {
    run: async (ctx) => execute(ctx, gen(function* () {
      const a = spawn(lane("a"));
      const b = spawn(lane("b"));
      return yield* all([a, b]);
    })),
  },
});

const endpoint = restate.endpoint().bind(demo);
createServer(endpoint.http2Handler()).listen(12880, "127.0.0.1");

The timer is set to 8,000 milliseconds to leave a clear interruption window. It is a demo setting, not a measured overhead result.

gen() receives a generator factory. spawn() registers a routine and gives back a task handle; the scheduler advances it when the current routine yields. all() waits for both handles and returns their values in input order. The package's own README distinguishes these operations and notes that spawned work can be abandoned when the main operation exits; explicitly joining the tasks avoids relying on fire-and-forget behavior. [2]

Keep the journal outside the worker process

The service is only one part of the setup. It needs a running Restate server and a registered deployment. I used this local server configuration, saved as restate.toml:

disable-telemetry = true
bind-address = "127.0.0.1:15122"
advertised-address = "http://127.0.0.1:15122"
rocksdb-total-memory-size = "256 MiB"
default-num-partitions = 1

[admin]
bind-address = "127.0.0.1:19070"

[ingress]
bind-address = "127.0.0.1:18080"

After installing Server 1.8.1 from its official release, start it in one terminal with its own data directory: [3]

restate-server --config-file restate.toml --base-dir ./restate-data --no-logo

Start node service.mjs in another terminal. Once it is listening, register that endpoint and invoke it through the server:

curl --fail-with-body --silent -X POST http://127.0.0.1:19070/deployments \
  -H 'Content-Type: application/json' \
  --data '{"uri":"http://127.0.0.1:12880"}'
curl --fail-with-body --silent -X POST http://127.0.0.1:18080/CoroutineDemo/run \
  -H 'Content-Type: application/json' --data 'null'

The final command returned ["A", "B"] in the uninterrupted check. Calling the Node endpoint directly would skip the server that owns this journal.

I first let an invocation finish without interruption. It returned ["A", "B"] and wrote each preparation and finish line once. That was the control before introducing a restart.

For the restart trial, I waited until both prepared-... messages appeared. These messages come after the corresponding yield* run(...) has resolved. I then killed only the Node service process, started it again on the same port, and left the original request waiting for its response.

Read the effects, not just the replay messages

The restarted worker logged that it was replaying the invocation. It also printed prepared-b and prepared-a again: those diagnostic statements are outside the durable closures, so seeing them again is expected.

The file tells a more specific story. Immediately before the crash it held:

prepare-b
prepare-a

After recovery and completion it held:

prepare-b
prepare-a
finish-b
finish-a

The response was ["A", "B"]. The order of returned values follows all([a, b]); it need not be the order in which the effects finish. In the uninterrupted control, the finish lines appeared in the opposite order.

That is the useful division in this example: normal JavaScript flow is reconstructed, while acknowledged durable steps supply their recorded results. The local value variable is rebuilt through replay; it is not a heap snapshot copied out of the crashed process.

There is still a boundary around external side effects. This trial interrupted the worker after the preparation results had resolved. It did not kill the process between a file append and acknowledgement of that step. The append itself has no idempotency key, so I would not infer exactly-once writes for every possible crash point.

The Diagrid team's explanation of at-least-once workflow execution describes that effect-before-recording window in Dapr. [4] It is a useful question to bring to any recovery demo: which side of the acknowledgement did the failure happen on?

Here, the server was never restarted, no remote tool or LLM was called, and no throughput benchmark was run. The completed check is service-process recovery with two joined coroutines and inspectable effects.

References and resources

Igal Shilman, Stephan Ewen and Giselle van Dongen, Durable Coroutines for TypeScript.
Restate contributors, generator SDK package and API documentation.
Restate contributors, Restate Server 1.8.1.
Diagrid, Understanding At-Least-Once Execution and Why It Matters for Workflow & Agent Developers.

Asset credits

Original recovery diagram based on the executed local service and its effect files. The service example is original; Restate dependencies retain their upstream licences.

AI disclosure

AI was used to draft the article.

Updating Rustup 1.29.3 while keeping the compiler fixed

Shivam Dwivedi — Wed, 04 Nov 2026 15:17:11 +0000

The toolchain manager and the compiler have separate version numbers. I updated an isolated Rustup installation from 1.29.2 to 1.29.3, kept its linked compiler at 1.99.1, then compiled and ran a small program through that same toolchain.

That gives me a useful way to handle this patch: update the manager that selects the tools, then check which compiler a project actually uses.

Recorded versions from the isolated update and the compiled sample. Image by the author.

What the patch changes

The Rustup team reports two regression fixes in 1.29.3: an illegal-instruction failure on certain x86_64 CPUs without SSE4.1, and an unsupported-lock error on Solaris. Those are upstream release claims; this walkthrough does not reproduce either hardware-specific failure. [1]

If you already have Rustup, the release instructions say to stop programs using it and run:

rustup self update

The word self matters. This updates Rustup itself. It is different from asking Rustup to update installed Rust toolchains with rustup update. That broader command can also update the manager. [1]

Check both sides of the selection

I used separate CARGO_HOME and RUSTUP_HOME directories for the trial, with shell startup files left alone. Rustup documents these locations as configurable. [2] I linked an existing compiler under the custom name pinned-local; I did not download a fresh compiler or replace the usual installation.

Here is the version ledger:

Component	Before	After
Rustup	1.29.2	1.29.3
Linked Rust compiler	1.99.1	1.99.1

To check the selection in that shell, I ran:

rustup --version
rustup show active-toolchain
rustc --version

The active toolchain was pinned-local (default). Keep the complete version output when troubleshooting; the table above extracts the version fields so the two components are easy to compare.

Rustup's rustc and cargo commands are proxies: they pass the invocation to a selected toolchain. Updating that routing program does not, by itself, request a different compiler. [3]

There is one practical prerequisite here: the shell must be reaching those proxies. A rustc supplied by another installation can produce a perfectly valid version line while bypassing the Rustup selection you intended. Mayur Kumbhar's environment setup walkthrough makes the related point that verifying the compiler and Cargo in a fresh shell is part of installation, rather than an optional last step. [4]

Compile through the named toolchain

For a small end-to-end check, I saved this as demo.rs:

fn main() {
    let values = [2_u32, 3, 5];
    println!("sum={}", values.iter().sum::<u32>());
}

Then I selected the linked toolchain explicitly:

rustup run pinned-local rustc demo.rs -o demo
./demo

The executable printed:

sum=10

pinned-local is the custom name from this trial, not a toolchain Rustup ships. Use a toolchain you have actually installed or linked when adapting the command.

This is a narrow update check: manager version, compiler selection, compilation and program output. It does not test all Cargo dependencies or establish that a project will build on every target. For a real project, keep its selected compiler visible alongside the manager version. “Rust updated” hides a distinction that the tools themselves already let you inspect.

References and resources

The Rustup Team, Rustup 1.29.3 release announcement.
The Rustup Book, installation locations and environment variables.
The Rustup Book, how Rustup and its proxies work.
Mayur Kumbhar, Rust Essentials: How to Set Up Your Development Environment.

Asset credits

Original version-track diagram from the recorded update and compile check. No third-party image assets.

AI disclosure

AI was used to draft the article.

What counts as feedback in weight-space programming?

Shivam Dwivedi — Tue, 03 Nov 2026 12:38:45 +0000

What would convince me that an LLM can make a useful edit to another model's weights?

I would start by asking what it was allowed to observe. Reading numbers, running a network, and receiving scored practice answers give an editor different kinds of evidence. That distinction is a good way into the new weight-space programming results from Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab. [1]

The authors report GPT-6 Astra directly reading and writing neural-network weights, with gradient-based training forbidden. Their experiments use different permissions: some are tool-free; others allow Python analysis or behavioral feedback. The Qwen3.5-0.8B math result belongs to the latter group. Their blog reports MATH-500 moving from 7.9% to 48.1% after a targeted edit, alongside reduced reasoning loops. Those are the authors' results; I have not run Astra or Qwen for this article. [1]

Follow one feedback loop

For the Qwen experiment, the released setup gives the editor a persistent Python kernel, practice problems, and a separate forward-pass service. It can propose an edit, ask the service to run the original or edited model, inspect the returned information, and revise. Gradient descent remains prohibited throughout. [2]

Original interpretation of the released experiment protocol. This is a process diagram, not a model run or a performance chart.

That gives two independent questions: how are the weights changed, and what evidence guides the change? An edit can avoid gradients while still being guided by the target model's behavior. Calling that feedback-driven does not contradict the gradient restriction.

The authors' repository separates the model's built-in tool access from their own harness. It describes model-written Python being executed in a sandbox, with output returned in the following turn. [3] “Built-in tools disabled” therefore needs that context; it does not mean the surrounding experiment supplied no tools.

Read the unit beside the budget

The Qwen setup defines one forward pass as a batched request: generation can contain up to 512 practice problems, or a teacher-forced request can inspect up to 1,024 texts. Those are limits, not counts of what every request used. [2]

I parsed the released 50-pass run's state record. It records 50 successful passes, 80 Python runs and 158 turns. Its first saved generation response contains 96 generations, with 85 cut at the token limit. This is a check of published records, not an independent reproduction of the model behavior. [4]

So “50 passes” is not “50 answers,” and it is not a complete compute budget. Batch size, generated length, editor inference and analysis work all affect what was available to find the edit. A fair replication needs to preserve those resources, not just the number in the column heading.

What I would conclude from this

The result is interesting as a demonstration of an editor using explicit access to another network's internals. The scope of each demonstration depends on its allowed observations. I would keep those permissions attached whenever comparing it with a different editing method.

I would also separate two replication questions. Can someone rebuild the released edited checkpoint and check its behavior? Can a fresh editor session discover a similarly useful edit under the same constraints? Success at the first question does not by itself establish the second.

Frank Chu's DEV breakdown focuses on the looping explanation and the reported Gemma follow-up. [5] My emphasis here is the surrounding feedback contract. It lets a reader appreciate the result while keeping the experiment specific enough to compare and rerun.

References

Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab, Sparks of Weight-Space Programming.
The authors, Experiment 8 setup and run mapping.
The authors, released logs and harness description.
The authors, 50-pass state record and first generation feedback.
Frank Chu, 7.9% to 48.1%: LLM rewrote Qwen weights, no training.

Asset credits

Original process diagram based on the authors' released protocol and records. Logs and data are released under CC BY 4.0; scripts under MIT. [3]

AI disclosure

AI was used to draft the article.

Defining revenue for an SQL agent, one row at a time

Shivam Dwivedi — Tue, 03 Nov 2026 12:38:23 +0000

Before an agent writes a revenue query, I want one sentence settled: what does one row of revenue represent?

An order? An item? A paid invoice? Those choices change the calculation even when every table name and join key is correct. NVIDIA's Auto Ontology puts business definitions and relationships into the context supplied to agents. Its repository describes a catalog and ontology layer, query validation, provenance, and interfaces through MCP, CLI and API. [1] The useful question for me is what a definition must say to make a concrete query checkable.

Here is a deliberately small example, using synthetic integer amounts rather than a real business dataset. It runs in Python's standard-library SQLite. I am not running NVIDIA's stack or evaluating an LLM here.

Two orders, three joined rows

The metric for this example is the sum of paid order amounts, counting each order once. That last phrase specifies the grain: the entity one contribution belongs to.

import sqlite3
connection = sqlite3.connect(":memory:")
connection.executescript("""
CREATE TABLE orders(id INTEGER PRIMARY KEY, status TEXT, amount INTEGER);
CREATE TABLE items(order_id INTEGER, sku TEXT);
INSERT INTO orders VALUES
  (1, 'paid', 100), (2, 'paid', 100), (3, 'cancelled', 500);
INSERT INTO items VALUES
  (1, 'A'), (1, 'B'), (2, 'C'), (3, 'D');
""")
queries = {
    "joined": "SELECT SUM(o.amount) FROM orders o JOIN items i ON o.id=i.order_id WHERE o.status='paid'",
    "distinct_amount": "SELECT SUM(DISTINCT o.amount) FROM orders o JOIN items i ON o.id=i.order_id WHERE o.status='paid'",
    "order_grain": "SELECT COALESCE(SUM(amount), 0) FROM orders WHERE status='paid'",
}
for name, sql in queries.items():
    print(name, connection.execute(sql).fetchone()[0])

Output:

joined 300
distinct_amount 100
order_grain 200

Original diagram of the executed synthetic fixture. Amounts have arbitrary units; the example defines its own metric.

Order 1 has two items, so the join repeats its amount. The joined sum is 100 + 100 + 100. Order 2 is perfectly real, but SUM(DISTINCT amount) collapses its 100 together with the other order's 100. Distinct values are not distinct orders.

The direct query stays at order grain. COALESCE adds another explicit choice: return zero when no paid orders exist. Without it, SUM over no eligible rows returns NULL. I checked the empty-eligible-set case as well.

When an item condition is required

Suppose the question means paid orders with at least one item. There is no need to multiply order rows just to check that an item exists:

SELECT COALESCE(SUM(o.amount), 0)
FROM orders o
WHERE o.status = 'paid'
  AND EXISTS (
    SELECT 1 FROM items i WHERE i.order_id = o.id
  );

This also returned 200. It would exclude an itemless paid order, while the direct order query would include it. Which one is correct depends on the agreed question. Adding an item-category filter would make that scope decision even more visible.

A definition supplied to an agent should therefore include the grain, eligible status, join behavior and empty-set behavior. This fixture can act as a compact regression case: two different orders share an amount, and one order has multiple items. Both details earn their place.

Michael Tuszynski makes the related governance point in “An Ontology Your AI Generated Is a Guess With a Schema”: an inferred definition still needs an accountable owner. In its discussion, ontomato also asks for ownership of grain and access to the source rows being counted. [2] A graph can store the chosen meaning; generating the graph does not settle that choice.

For an agent workflow, I would keep this expected answer beside the metric definition. Checking that SQL executes is one check. Checking which entities contributed to the answer is another.

References

NVIDIA, Auto Ontology. This article examines a definition problem; it makes no benchmark claim about that project.
Michael Tuszynski, An Ontology Your AI Generated Is a Guess With a Schema, including ontomato's comment.
SQLite, aggregate functions.

Asset credits

Original diagram from the executed SQLite fixture; no third-party image assets.

AI disclosure

AI was used to draft the article.

A small temperature alarm in Toit 2.0

Shivam Dwivedi — Tue, 03 Nov 2026 12:38:13 +0000

A temperature alarm needs a little memory. Switch it on at 30°C, keep it on while the reading drifts down, and switch it off at 27°C. That gap stops a sequence like 30, 29, 30, 29 from repeatedly changing the alarm state.

I used that small task to try Toit 2.0. The release is a useful excuse to look beyond blinking an LED: the same language also runs host scripts, so the decision logic can be exercised before connecting a sensor. [1][2]

Start with the state you want

There are two states, on and off. A reading at or above 30 sets the state to on. A reading at or below 27 sets it to off. Everything between those limits leaves it alone. This is hysteresis: the current reading does not completely determine the output; the previous state matters too.

The initial state is part of the design. In this example it is off, so starting at 29°C leaves the alarm off. Arriving at the same temperature after a 30°C reading leaves it on. Neither case is an accident.

Original plot from the executed synthetic sequence. Sample positions are ordered readings, not elapsed seconds.

Run the whole program

Get the archive that matches your platform from the official v2.0.0 release, extract it, and put its bin directory on your PATH. Check the selected runtime:

toit --version

Mine returned v2.0.0. Save this as sensor.toit:

main:
  readings := [28, 30, 29, 30, 29, 27, 29, 31]
  alarm := false
  readings.do: |temperature|
    if temperature >= 30:
      alarm = true
    else if temperature <= 27:
      alarm = false
    print "$temperature C: $alarm"

Then analyze and execute it:

toit analyze sensor.toit
toit run sensor.toit

The analyzer completed successfully. The program printed:

28 C: false
30 C: true
29 C: true
30 C: true
29 C: true
27 C: false
29 C: false
31 C: true

The syntax takes a moment to read if you normally use Python. := introduces a local variable; = changes it. readings.do: calls a block for each value, and |temperature| names the block's parameter. The string interpolates both variables. [3]

The missing assignment does the work

There is deliberately no final else. At 28 or 29, the program does not assign to alarm, which preserves the previous state. Replacing that block with alarm = temperature >= 30 would throw the memory away.

For this exact sequence, including the initial off state, the single-threshold rule changes state five times. The hysteresis rule changes it three times. Those are properties of this synthetic input, not measurements of a physical sensor or proof that these thresholds suit a device.

I also ran separate inputs for an empty list, each exact threshold, a starting value inside the gap, a descending sequence, and repeated boundary readings. They behaved as specified. A real device still needs decisions about missing readings, units, startup behavior and what should happen if its process restarts.

Toit 2.0's announcement includes a peripheral API change that accepts pin numbers directly. That is relevant when taking the next step onto supported hardware, but this program uses no GPIO, board or sensor. [1] It is a small, completed host-side example you can change without wiring anything first.

References

Florian Loitsch, Toit v2.0.0 and the official release.
Toit contributors, Learn Toit.
Toit contributors, language source and standard library.

Asset credits

Original chart made from the synthetic program output; no third-party image assets.

AI disclosure

AI was used to draft the article.

The smaller token bill can buy fewer working builds

Shivam Dwivedi — Mon, 02 Nov 2026 11:35:58 +0000

A failed build can be wonderfully economical. It just has the small inconvenience of not working. 🫠

That sounds obvious until a chart sorts coding agents by tokens per attempt. A workflow can win that chart while producing fewer usable results.

I made a tiny ledger to show the accounting change. Every number below is synthetic. These are invented workflows named lean and steady, not measurements of models or frameworks.

What I Built

The starting point was the renewed discussion around Nolan Lawson's JavaScript framework benchmark. His setup asks agents to build an app, checks conformance, and reports several dimensions, including tokens and resulting app quality. It also reports variation and failed runs.[1]

That's a useful direction: inspect the finished thing as well as the effort spent making it. My example isn't a rerun of his benchmark or a correction to his framework rankings. It isolates one question for anyone building their own evaluation: what happens to the tokens spent on failed attempts?

I wrote a Python summary that retains those attempts and reports both the per-attempt median and the total tokens divided by accepted results. 🧮

Computed illustration from the synthetic records below. No model calls or framework comparison were run.

Demo

The fixture contains the same number of attempts for each workflow:

Synthetic workflow	Token units per attempt	Accepted results
`lean`	1,000; 1,000; 1,000	1 of 3
`steady`	1,600; 1,600; 1,600	3 of 3

For this illustration, each row represents a complete attempt, including its repair work. All rows use the same token-unit definition. ✅

Run this with Python:

from collections import defaultdict
from statistics import median
import json
# Synthetic attempts: (workflow, token units, acceptance passed).
# Each row includes the complete attempt, including repair work.
runs = [
    ("lean", 1000, True),
    ("lean", 1000, False),
    ("lean", 1000, False),
    ("steady", 1600, True),
    ("steady", 1600, True),
    ("steady", 1600, True),
]
def summarize(rows):
    groups = defaultdict(list)
    for workflow, tokens, passed in rows:
        groups[workflow].append((tokens, passed))
    result = {}
    for workflow, attempts in groups.items():
        total = sum(tokens for tokens, _ in attempts)
        accepted = sum(passed for _, passed in attempts)
        result[workflow] = {
            "attempts": len(attempts),
            "accepted": accepted,
            "median_tokens_per_attempt": median(t for t, _ in attempts),
            "total_tokens": total,
            "tokens_per_accepted_result": total / accepted if accepted else None,
        }
    return result
if __name__ == "__main__":
    print(json.dumps(summarize(runs), indent=2))

The useful part of the output is:

lean:   median per attempt = 1000; total / accepted = 3000
steady: median per attempt = 1600; total / accepted = 1600

The arithmetic is plain:

lean:   (1000 + 1000 + 1000) / 1 = 3000
steady: (1600 + 1600 + 1600) / 3 = 1600

If I silently drop the failed rows, lean looks like it spent only 1,000 tokens per accepted result. That discards the effort that produced no accepted output. The ledger keeps it.

💡 These summaries answer different questions. The median describes a typical attempt. Total divided by accepted results describes the observed aggregate token effort per acceptance in this fixture. Neither replaces the pass count.

What if nothing passes?

I also checked a group containing a failed attempt and no accepted result. The summary returns None, serialized as null, for tokens per accepted result.

Zero would be a misleading result: it would make total failure look exceptionally efficient. There was no accepted result to divide by.

The acceptance check is part of the measurement

Before collecting your own records, decide what “accepted” means for the task. Does the app boot? Does the requested behavior work? Are important error cases checked? Keep that grader outside the agent's editable output.

The DEV write-up from the Kumiko team is a useful companion: their isolated agent evaluation first exposed problems in their own grader and documentation.[2] A pass count only helps if the acceptance check itself is doing the intended job. 🔍

For real comparisons, keep the task set, model settings, versions and stopping rules matched. Save failed and timed-out attempts, and record whether setup or repair effort is included. If an attempt has missing usage, mark it missing rather than turning it into zero.

Partner Technologies

This example uses Python's standard library. It doesn't use a model provider or sponsor integration.

The limit is deliberate: this is an accounting demonstration, not evidence that one coding workflow beats another. Token counts also aren't a billing total. Cached input, uncached input and output can have different prices; preserve those buckets when accounting for actual usage.

Hackathon Experience

I built this as a standalone local example. It isn't an MLH event project or competition entry.

References

Asset credits

Original chart computed from the synthetic ledger. No external benchmark figure is reused.

AI disclosure

AI was used to draft the article.

My parser read past the input. AddressSanitizer stayed quiet.

Shivam Dwivedi — Mon, 02 Nov 2026 11:35:14 +0000

I gave a deliberately broken parser three bytes. It read byte four. AddressSanitizer said nothing.

Then I changed the allocation around the input. Same parser, same three bytes, same compiler flags: heap-buffer-overflow. There it was. 🧪

The bug hadn't appeared between runs. My first test had given it somewhere comfortable to hide.

What I Built

I made a small C reproducer for a fuzz-harness trap: the length of a test case can be smaller than the memory holding it.

Chris Wellons describes this in his AFL++ guide, which is circulating again in the fuzzing discussion. It's an older guide, not a new AFL++ release. The useful detail is the warning about passing a reusable input buffer straight into a target.[1]

A fuzzer's harness is the bit of code that hands generated inputs to the program. If it hands over a short input inside a larger allocation, an invalid read relative to the input can still touch allocated memory.

AddressSanitizer, or ASan, instruments memory accesses to catch errors such as heap overflows.[2] It doesn't automatically know the meaning of every length argument in your API.

Original diagram of the executed example. The wider buffer is a synthetic stand-in for reusable backing storage.

Demo

Here's the complete intentionally broken program. Save it as boundary.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static volatile unsigned char observed;
__attribute__((noinline))
static void parse(const unsigned char *data, size_t size) {
    observed = data[size]; /* Deliberate bug: first byte past logical input. */
}
int main(int argc, char **argv) {
    if (argc != 2) return 2;
    size_t size = 3;
    size_t capacity = strcmp(argv[1], "exact") == 0 ? size : 64;
    unsigned char *data = malloc(capacity);
    if (!data) return 2;
    memset(data, 0, capacity);
    memcpy(data, "ABC", size);
    parse(data, size);
    free(data);
    puts("returned without an ASan report");
    return 0;
}

The volatile destination keeps the read observable. The parser is deliberately wrong: for a nonempty input, the last valid index is size - 1.

Compile it with Clang and its ASan runtime available:

clang -O1 -g -fsanitize=address -fno-omit-frame-pointer boundary.c -o boundary
./boundary shared
./boundary exact

The first command to run the program printed:

returned without an ASan report

The exact-size version exited with an ASan heap-buffer-overflow report. ✅

Both inputs contain ABC, with logical length three. The first allocation has room for 64 bytes; the second has room for three. Reading data[3] violates the parser's input contract in both runs, but only crosses the allocated region in the second.

Zero-filling the larger buffer makes this example repeatable. The extra capacity hides the boundary violation; the zeros aren't a safety check.

Change the harness and fix the parser

For this kind of harness, a useful check is to copy the current input into an allocation sized to that input before calling the target. Handle allocation failure and the target's empty-input contract explicitly. If the API expects a terminating zero, its contract also needs space for that byte.

That makes the allocation boundary match the boundary you want ASan to observe. It doesn't repair the target.

The actual fix in this example is:

if (size != 0) observed = data[size - 1];

I compiled that version with the same sanitizer flags. The shared-buffer, exact-size and empty-input cases all returned successfully.

⚠️ A quiet sanitizer run is evidence about the accesses it could check. It isn't proof that the program respected your logical input length.

A second harness check is worth borrowing from a DEV postmortem by @malwaredante: verify that generated inputs reach the intended parser at all. Their mutator selected a different parser while coverage continued growing.[3] Buffer boundaries and target selection are separate ways for a busy test run to miss its purpose. 🔍

Partner Technologies

This demo uses C, Clang and AddressSanitizer. The AFL++ documentation supplies context for reusable buffers and persistent-mode harnesses; this reproduction runs directly, without an AFL++ campaign.[4]

The important limit: exact-size input copies can expose reads past the allocation. They don't catch every semantic mistake within an otherwise valid allocation, and a clean result isn't a safety guarantee.

Hackathon Experience

This is a standalone local demo. It wasn't built at an MLH event and isn't a competition entry.

References

Asset credits

Original memory-layout diagram, based on the checked reproducer.

AI disclosure

AI was used to draft the article.

Nibnib says 4bpp. The file still has a header.

Shivam Dwivedi — Mon, 02 Nov 2026 11:35:05 +0000

My tiny nibnib file was larger than the raw RGB image I fed into it.

For a 16×16 synthetic gradient, the raw RGB pixels took 768 bytes. The nibnib file took 1,220 bytes. Nothing had gone wrong with the encoder. The file had a palette to carry. 📦

That was the useful surprise in trying Raph Levien's image format: “4 bits per pixel” describes the compact pixel coding, not an all-inclusive promise for every file size.

What I Built

I made three original RGB gradients, ran the upstream nibnib encoder and decoder, and wrote an independent reader to check the decoded pixels.

Nibnib is aimed at constrained-device decoding. It works on pixel pairs and uses a palette of differences rather than just a palette of absolute colors.[1] The current interest in it makes a good excuse to inspect the bytes instead of borrowing the speed claim. 🔍

My check covers file layout and round trips. It doesn't measure microcontroller decoding speed.

Original synthetic input and actual decoded output. Display enlargement is for inspection; neither image is a photo.

Demo

I used nibnib version 0.1.0 at commit 2f02f8c225d937d1c19459e2b246f37d87a98f54. With a Rust toolchain available, build that checkout:

cargo build --release --locked

For a small input you can generate yourself, save this as make_gradient.py. It needs Pillow:

from PIL import Image
width, height = 128, 64
image = Image.new("RGB", (width, height))
image.putdata([
    (x*255//(width-1), y*255//(height-1),
     (x+y)*255//(width+height-2))
    for y in range(height) for x in range(width)
])
image.save("gradient.png")

Then, from the nibnib checkout with that input file available:

python3 make_gradient.py
./target/release/nibnib gradient.png gradient.nib --compress
./target/release/nibnib gradient.nib decoded.png --decompress

The explicit flags matter. At this revision, the default path encodes and then writes a decoded PNG; --compress writes the compressed file.[2]

Here are my checked sizes across the three fixtures:

Input dimensions	Raw RGB bytes	nibnib file bytes	Whole-file bits per pixel
16×16	768	1,220	38.125
64×32	6,144	2,180	8.516
128×64	24,576	5,380	5.254

✅ Each upstream decoder output matched my independent reader byte for byte. Each decoded image differed from its original input: this is a lossy round trip, not a pixel-preserving archive.

Where the bytes go

At the checked revision, the file stores dimensions and a fixed palette before its row data. Each row starts with an explicit pixel pair; later pairs use palette indices. Rows are aligned to four-byte boundaries.[1][2]

Here's the size calculation for positive, even widths:

def nib_bytes(width, height):
    row_bytes = width // 2 + 3
    stride = (row_bytes + 3) // 4 * 4
    return 1028 + height * stride
print(nib_bytes(128, 64))  # 5380

For that image, the rows occupy 64 × 68 = 4,352 bytes. Add the 1,028-byte header and palette, and the result is 5,380.

The tiny image pays that same fixed palette cost. A larger image spreads it across more pixels. The row seeds and alignment still add overhead too. 💡

Compare against the right baseline

My table compares the file with uncompressed RGB, not with PNG or JPEG at matched quality.

In fact, Pillow's PNG for the 128×64 gradient was only 514 bytes in this run. A smooth synthetic gradient is friendly to PNG. That doesn't settle which format suits a constrained display; it shows why “smaller than raw pixels” and “smaller than an existing compressed image” are different claims.

A DEV discussion about palette reduction makes a related distinction: a lossless container can store pixels that an earlier conversion has already changed.[3] Check the actual decoded image, not just the format label.

Partner Technologies

This walkthrough uses the upstream Rust nibnib CLI and Python with Pillow. The independent reader follows the documented layout and the checked decoder source.

I haven't run this on an RP2350 or compared decoder speed with JPEG. The upstream encoder also generates a partly random palette, so preserve the encoded file when you need to reproduce the exact decoded pixels. The layout calculation doesn't depend on which palette values were selected.

Hackathon Experience

This was a standalone local format check. It isn't an MLH event build or competition entry.

References

Asset credits

Original synthetic gradients, actual decoded output and original byte-layout illustration. The nibnib implementation is credited to its upstream project, licensed MIT or Apache-2.0.

AI disclosure

AI was used to draft the article.