kyle
2f9d3d97e6
Dixie is capped (max_inflight 2, queue_depth 8, queue_wait 20s) and never queued on llama-server. Streaming chat, thinking off, 45s fallback to clean. Digest and chunk-embedding caches are content-addressed SQLite (Honcho context is not cached). Recover uses the guarded Fetcher. guardian-star is refused in code.
libc
Package libc is a partial reimplementation of C libc in pure Go.
⚠ READ THIS BEFORE UPGRADING ⚠
This package is to ccgo what the runtime package is to Go. It is not a
library you happen to link against, it is the other half of the compiler. Code
that ccgo produced and the libc it was produced for are one artifact split
across two modules, and they are only ever tested as a pair.
The version numbers here do not mean what semver says they mean. A release that bumps only the patch or the minor number can still change the contract between generated code and this package, which by semver's own rules it must not. Read every libc version as though it were a major one.
None of this is new — it has been documented for as long as this package has carried ccgo's runtime, and it holds for every release. What is new is how it fails.
Upgrading libc alone used to change behaviour quietly. It can now stop the
build. The setjmp/longjmp support changed shape: LongjmpRetval went from an
integer to a struct naming the jump buffer a longjmp targeted, because a region
recovering that panic has no other way to tell whether the longjmp was meant for
it or for a setjmp further out, and recovering one meant for another region
resumes the program at the wrong place. Code generated by an older ccgo does not
compile against it, failing on the conversion between LongjmpRetval and
int32.
That is the intended outcome rather than an oversight: a refusal to build, in
place of a program that would have built and then jumped to the wrong setjmp.
It is a correctness fix, and there is no backward compatible way to make it. Deciding which region a longjmp belongs to needs information the old panic value did not carry, so any fix has to change what that value is. Keeping the old shape working alongside the new one would leave every consumer silently on the broken path, which is the bug.
The remedy is what it has always been, and it is not to pin an old libc and
hope: recompile your C to Go with a ccgo new enough to depend on the libc you
want, then use that pair together. If you consume translated code produced by
someone else, modernc.org/sqlite for instance, take the libc version from that
package's go.mod and do not bump it on your own just because a newer libc is
tagged.