6.12.6 launched the Dragon SDK this morning. It has been that kind of day since: writing the day’s tutorials found two compiler bugs, and the SDK’s first hours found a gap in our own packaging. So here are 6.12.7 and 6.12.8 in one article — two releases would deserve two, but three in a day is where we draw the line at the blog, even when we don’t at the compiler.

Both are small, both are the launch working as intended: the material we publish is built against the shipping compiler, so the day a big release goes out is the day its gaps have nowhere to hide. We would rather align everything before the first week starts than let a known miss run. The misses were ours; the fixes are same-day.

6.12.7 — two fixes the debugger found

While writing the cross-language debugging tutorial, we built an example whose call chain is a sandwich — Mica calling C through a contract, and the C library calling back into the running program’s exported function. That last hop crashed: a program target’s exp function ran the static-link walk in its prologue, and that walk trusts Mica’s internal calling convention — a depth register, the caller’s chain cell — which no C caller provides. Library exports never had the problem (the C-calls-Mica road was always safe); program exports did, on every tier and both architectures.

The fix respects what the walk was for: a global function’s cell always holds one value — the root activation’s frame, a per-process singleton — so the program entry now publishes it once and every global’s prologue copies it, consuming no caller state at all. Correct from Mica, correct from C, and the sandwich is a regression case run at two optimization tiers on both backends by every merge.

The second fix came from the same tutorial’s stepping sessions: step into a Mica function stopped before the parameters were homed, showing garbage arguments for one stop. The entry row of every function’s line table now carries its declaration line — GCC’s own convention — so gdb’s prologue skip works and step-into lands with every argument readable.

6.12.8 — the SDK package learns to speak Mica

The Dragon SDK shipped this morning with a commented C header a consumer can sit down and read — and, for a consumer working in Mica, nothing to read at all. The surface a Mica frontend imports with imp ... : dragon lives embedded in the compiler, which is why everything worked; but the vendor of the Mica language shipping an SDK that is better documented for C than for Mica is not a look we want to keep. Our mistake, and a same-day one to fix.

mica-dragon-sdk 6.12.8 installs the curated dragon surface as a readable file, beside the licence text it ships under:

/usr/share/doc/mica-dragon-sdk/dragon-engine.json

It is documentary by design — the compiler still resolves only the embedded surface, so a file on disk can never change what your build believes — and the package check holds it byte-identical to what the compiler embeds, so what you read is exactly what the compiler knows.

One more thing the SDK’s first day asked us, fairly: why does the SDK require the compiler package at all, when a C frontend never runs mica? The answer was true but written nowhere: the programs your frontend produces are linked against the Mica standard-library archive, which the compiler package installs — it carries the runtime the emitted code starts in and calls. That reason now lives where you meet the requirement: in the package description and on the SDK’s install page.

Installing

Both packages move together — apt enforces the version pair:

sudo apt install ./mica_6.12.8_<arch>.deb ./mica-dragon-sdk_6.12.8_<arch>.deb

Downloads: the compiler · the Dragon SDK. Nothing else changed today — the 6.12.6 announcement remains the release to read, and the run counts per release are in apt changelog mica.