fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the CLI binary was STALE -- screen info's keyframe times were the old parser's

Browse Source 
The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the
keyframe-record-layout fix. The old parser shifted every time by one slot and
could not time a group's final pose, printing a trailing '-':

  stale  pteff00.prm  4 kf  rest t=70  [12:0,0 70:0,0 80:0,0 -:0,0]
  fresh  pteff00.prm  4 kf  rest t=12  [ 0:0,0 12:0,0 70:0,0 80:0,0]

Both outputs are well-formed and neither announces its age.

That refutes the premise of screen-transitions.md's 2026-08-29 section, which
argued from 'there is exactly one untimed keyframe, and every element has it'.
There is no untimed keyframe, so the question it answered -- is 0.4 s the missing
duration of that keyframe -- has lost its subject. The ratio test in the same
section is untouched.

And it decodes the number the port asked about: pteff00.prm's final ramp is
70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to
refute the port's 10 against the bytes and could not.

So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10
decoded. That the remaining ~14 units are exactly the black hold is arithmetic
that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a
measurement; the decomposition stays open.

CONTAINER-NOTES gains the trap. Renders are byte-identical across the two
binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element
identity, pivots, keyframe counts and screen render output are unaffected -- it
is the times that move.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 11:22:43 +00:00
parent 951b9a4c80
commit 83b7316065
2 changed files with 49 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/agents/CONTAINER-NOTES.md
View File

@@ -251,3 +251,23 @@ and produced no `xenia_re_ui_draws_NN.log` at all.** The keypress goes to the
window and is silently lost — nothing in the session log distinguishes a run that
armed from one that did not, so **check the log file exists before spending the
run**, and treat a repeat measurement as needing more attempts than samples.
* 🔴 **`sylpheed-cli` in `$CARGO_TARGET_DIR` can be STALE, and `screen info` lies
quietly when it is.** The copy here was built **2026-08-29 12:38**, before the
keyframe-record-layout fix. The old parser shifted every keyframe time by one slot
and could not time a group's final pose, printing a trailing `-`:
```
stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0]
fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0]
```
Both outputs are well-formed and neither announces its age. A whole page of this
corpus (`screen-transitions.md`) argued from *"there is exactly one untimed
keyframe"*, which was the stale parser's artefact.
⚠️ **`cargo build -p sylpheed-cli` before trusting `screen info`** — it takes 8 s
against a warm cache. ✅ Renders are **byte-identical** across the two binaries
(checked on `GP_TUTORIAL` build 0, max per-channel difference **0**), so
`screen render` output and anything derived from element identity, pivots or
keyframe *counts* is unaffected. It is the *times* that move.