The pin moves e4aa6a5 -> 149bee0, which is libakgl 0.8.0. Nothing in this
repository changed to accommodate it: both suites pass unmodified, 110 without
akgl and 111 with, and both breakout games run forty seconds headless with no
error line.
**0.8.0 is a whole collision subsystem** -- shapes, pooled proxies, a pluggable
broad phase over a uniform grid, a narrowphase answering with a contact carrying
a normal and a depth, world box queries, and static proxies for geometry that is
not an actor. None of it is called from here yet. This commit is the pull and
nothing else, so that if it has to come out it is one revert of one commit.
**It adds two submodules of its own**, `deps/libccd` and `deps/tg`, so a tree
that updates without `--recursive` configures and then fails compiling libccd.
libakgl's own suite was built and run standalone at RelWithDebInfo before
akbasic was pointed at it: 33/33.
`libakstdlib` and `libakerror` did not move. MAINTENANCE.md requires checking,
and the answer this time is that libakgl 0.8.0 pins exactly what this repository
already pins -- 669b2b3 and 5eaa956 -- so the pairing rule is satisfied without a
bump. Recorded because "we checked and it was already aligned" and "we forgot to
check" look identical in a diff.
**The version floor moves to 0.8.0** with its paragraph, following the
convention in that header of saying what each minor release did and why the
floor moved anyway. Worth knowing for whoever reads it next: `akgl_Actor` grew
fields, so a translation unit compiled against a 0.7 `actor.h` and linked
against 0.8 writes `renderfunc` and `actorData` at the wrong offsets -- and
`src/sprite_akgl.c` writes exactly those two. That is the case the soname cannot
catch and the guard exists for.
**libakgl's reserved status band grew from five codes to six**, gaining
`AKGL_ERR_COLLISION` at `AKGL_ERR_BASE + 5`, so it now owns 256-261 and the
headroom below akbasic's band starts at 262. Four documents said otherwise: the
coordinated range map in MAINTENANCE.md, the comment above the enum in
`include/akbasic/error.h`, the file header of `include/akbasic/akgl.h`, and
chapter 15. That map is the only coordination there is -- nothing enforces a
band boundary at compile time, and the first anybody would know of an overlap is
a status printing under the wrong owner's name in a stack trace.
Also cleaned on the way past: `deps/libakgl/deps/libakstdlib` was showing dirty
in `git status`. It had no local edits -- the checkout was simply one commit
behind the gitlink libakgl records -- so `git submodule update` restored it and
nothing was lost.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL
512 gains its new cause: a branch by number to a line the program did not
number. PARSE ERROR is what the prescans report as, since they run before
any statement does, so the class table says so.
514 claimed a branch to a line that does not exist raises it. Nothing does
-- AKBASIC_ERR_UNDEFINED comes from label, variable, field and host-struct
lookups only, and GOTO 500 with no line 500 walks to the end and stops.
That was already wrong before this work; it is more visible now that a
branch to a line that does exist can be refused.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ER# held numbers nothing explained. The appendix lists the four error classes
the interpreter prints, the eight codes it owns and what raises each, and the
codes that reach ER# from errno, libakerror and libakgl underneath it.
The table is not asserted. A program in the chapter trips seven of the eight and
prints what it got, and docs_examples byte-compares the result -- so the numbers
are checked rather than claimed. The eighth, 516, is not usefully trappable and
the chapter says why: entering a handler takes a scope, and the pool being empty
is what raised it.
Two things worth a reader's attention came out of writing it. Two codes register
the same ERR() text, so a program must compare the number and print the text.
And VAL reports libakerror's Value Error rather than the interpreter's 517,
which makes that number the platform's rather than ours -- filed as section 6
item 21, not fixed here, because deciding which libakstdlib failures to
translate is a boundary question and ENOENT out of DOPEN is the counter-case.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
