diff options
| author | Gabriel Schneider <[email protected]> | 2026-08-26 09:24:17 -0300 |
|---|---|---|
| committer | Gabriel Schneider <[email protected]> | 2026-08-26 09:24:17 -0300 |
| commit | ed8c5632e0228b1b821c87b511beb474c6a41f0c (patch) | |
| tree | ea6c37d2f040cf65c474c1a6d719bdb2e0494614 /src/main.zig | |
| parent | ddee44e2a70e8b9be7b2778390059de6279dd454 (diff) | |
| download | esp32p4-ed8c5632e0228b1b821c87b511beb474c6a41f0c.tar.gz esp32p4-ed8c5632e0228b1b821c87b511beb474c6a41f0c.zip | |
Fix the console: std.time.milliTimestamp does not exist, and zig build test could not see it
`zig build interact` did not compile. The mouse coalescer dated its held report with
`std.time.milliTimestamp`, and this Zig's `std.time` has constants and `epoch` and no clock
at all: the repo's own idiom is `std.Io.Timestamp`, already wrapped as `serial.Port.nowMs`,
which is what the three call sites now use.
The reason it survived every check I ran is worth writing down, because the same hole will
swallow the next one. `zig build test` compiles `tools/console.zig` as a test module, and
Zig only analyses what is REACHABLE: no test calls `attach`, so the loop containing the bad
call was never looked at. Seven passing MouseFilter tests and a green `zig build test` said
nothing whatsoever about whether the file compiles as part of an executable. Nor does plain
`zig build` - p4-console is not in the default install step - so the only thing that would
have caught it is building or running the named step, which is also the documented way to
use this repo: `zig build interact -Dpardes`.
Verified the way it should have been the first time: `zig build interact -Dpardes
-Dcpu-mhz=360` with piped stdin flashes, attaches, takes the keystrokes and detaches at
EOF. Also compiled every step's artifacts - elf, console, bench - and re-ran the matrix
that matters for the editor side: default, Debug, ReleaseFast, ReleaseSafe, ReleaseSmall,
and -Dplatform=p4 at Debug and ReleaseSmall, plus -Dp4-cols/-Dp4-rows at 40x12 and 80x24.
Note for anyone reading a failing `zig build console` or `bench`: those RUN their tool, so
they fail with DeviceBusy when something else is attached to the port. That is not a build
error, and it is how this one hid in plain sight in the middle of the output.
Diffstat (limited to 'src/main.zig')
0 files changed, 0 insertions, 0 deletions
