Tree:
b757d183e8
master
v0.1a
${ noResults }
1 Commits (b757d183e8feac8fe96d1ffd7b65eb802faf1879)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
176f2ad702 |
punk-runtime list/use stop offering support files as runtimes (punkshell 0.27.3)
'bin/punk-runtime.cmd list -platform win32-ix86' listed a LUCK.url shortcut and a tclsh8.6.10-luck-zip.cfg build request as if they were selectable runtimes. Both payloads already filtered support files - .txt/.toml/.tm/.tmp/.log - so the mechanism existed and only the recognised set was too narrow. It was also duplicated across NINE filter sites in three syntaxes (a powershell array, a bash case pattern, a bash grep -E regex), and two of them had already drifted: the "not a selectable runtime" guard omitted .log and matched *_BUILDCOPY without a trailing wildcard. The set is now defined ONCE per payload - $PunkRuntimeSupportExt / Test-PunkRuntimeSupportName in the ps1, punk_support_ext_re / is_punk_support_name in the bash - and every site consults it, so the two payloads cannot drift apart. Their listings are required to agree byte-for-byte and now do so by construction. Recognised support files, by category: docs/text (.txt .md .html .htm .pdf .url), config/metadata (.toml .json .xml .yml .yaml .ini .cfg), dev leftovers (.tm .tmp .log .bak .old), checksums/signatures (.sha1 .sha256 .asc .sig) and archives (.zip .tar .gz .bz2 .xz .7z), plus any *_BUILDCOPY* name. Anything else is still treated as a runtime candidate - deliberately, so a stray binary is visible rather than silently hidden. Verified: the win32-ix86 listing drops from 6 entries to the 4 real runtimes; the bash helpers produce the identical four (the polyglot routes msys bash to the ps1 payload on windows, so the bash side was exercised directly). Re-wrapped per bin/AGENTS.md with checkfile ERROR-free; runtimecmd_roundtrip (byte-identity), runtimecmd_checkfile, runtimecmd_freshness (10/10, both payloads against the fixture server) and runtimebash_wsl (8/8) all pass, as does the full suite at its documented baseline. bin/runtime/README.md now states what a platform folder is FOR (a store tier keyed by the platform a runtime is for, not by this machine) and what is tolerated in it, with the recognised-support-file table and the warning that anything else will be offered as a runtime. It is force-added to git: /bin/* is ignored and a ! negation cannot re-include a file inside an excluded directory, so git add -f is the only mechanism - recorded in the .fossil-settings/AGENTS.md force-tracked one-off list, whose fossil counterpart is an explicit 'fossil add' at the next catch-up checkin. Also records in G-101 a survey of TEMP_REFERENCE/androwish for the zipfs-on-8.6 question the developer raised (non-contract findings; pointer added to TEMP_REFERENCE/AGENTS.md per its contract so the survey is not repeated). The undroidwish zipfs backport is ADDITIVE - generic/zipfs.c (6586 lines) + zipfs.h + a library/zipfs1.0 dir + one object line in the win and unix Makefiles - so it is carryable as a suite patch rather than a fork; it is C rather than C++ like mk4tcl; Tcl_StaticPackage registration is gated on ZIPFS_IN_TCL / ZIPFS_IN_TK, i.e. designed to compile into tcl or tk; and it is Christian Werner's, under the tree's Tcl-style license.terms. Its capability delta against Tcl 9 zipfs is recorded (no 'root', no ::zipfs ensemble, and not registered in child or thread interps), as is the exe-path mount convention that motivates G-129. Provenance of our specimen is established: LUCK is a CGI repacker that selects packages out of a prebuilt vanillatclsh binary's ZIP, so bin/runtime/win32-ix86/tclsh8.6.10-luck-zip.exe is a repack of androwish's own build - a working existence proof of zipfs-on-8.6 rather than a claim. Three open questions are recorded rather than guessed: whether it applies to 8.6.18 (the tree is 8.6.10), whether it builds under the pinned zig, and where the boot-time self-mount hook lives - stock tclAppInit calls Tclzipfs_Init only under #ifdef TCL_TEST, so it is in the vanillatclsh/undroidwish application main, which is also the hook a dual-container autodetecting boot would need. Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com |
4 days ago |