Tree: 8cbdf86fff

master

v0.1a

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '8cbdf86fff'

${ noResults }

Commit Graph

1 Commits (8cbdf86fff744f9d16837af68ab924e3bc4e1d1d)

Author	SHA1	Message	Date
Julian Noble	8cbdf86fff	G-129 drafted (user-approved): kit boot finds its payload wherever the archive mounted ... Arising from the third-party 32-bit kit investigation. src/vfs/_config/punk_main.tcl decides whether the running kit has an attached zipfs image with two assumptions that held for every runtime punkshell had until now: it probes with 'info commands tcl::zipfs::root' and then looks for the mount at a compiled-in //zipfs:/app. Christian Werner's androwish / undroidwish backport gives Tcl 8.6 a working zipfs but no 'root', and mounts the executable's attached archive at the EXECUTABLE'S OWN PATH, so [info library] reads <exe>/tcl8.6. Against such a runtime punkshell concludes "no zipfs", neither the zipfs nor the kitpath branch runs, and the kit silently gets no internal module or lib paths at all - the failure surfaces later as packages that cannot be found. project_main.tcl carries the identical code, so the same defect ships into every generated project; both files are in Scope. Two third-party 32-bit runtimes now in the win32-ix86 tier bracket the problem and are named as the verification pair: tclsh8.6.10-luck-zip.exe (Lean Undroidwish Construction Kit - no 'root', no ::zipfs ensemble, mounts at the exe path, library at tcl8.6/, and no zipfs at all in child or thread interps) and tclsh9.1b0-tclsfe.exe (apnadkarni/tcl-sfe - the modern //zipfs:/app convention on the same architecture). The Acceptance requires both: the tclsfe kit proves the 32-bit target itself needs nothing special and that the derivation did not regress the ordinary case, the LUCK kit is the actual work. Both are untracked per G-004, so tests naming them self-gate on presence as the G-124 piperepl pin does; the LUCK build is reproducible from its .cfg build request. Approach settled in the draft: derive the mount point from tcl::zipfs::mount itself, whose entries pair mountpoint with mounted file - the entry naming this executable is this kit's archive wherever it landed. Detect zipfs by a command the backport also provides rather than by 'root'. Leave the kitpath and cookfs branches alone. Report on stderr when an archive is attached but no mount entry matches this executable, because silence is today's failure shape and is what made this expensive to diagnose. Overlap survey named G-031 (restructures this same file into a thin main plus shared boot core - whichever lands second adopts the other's shape, and the derivation belongs in the core), G-101 (its candidate container list already includes zipvfs-over-tclvfs boot, and the LUCK runtime is a ready-made specimen carrying zipfs, vfs 1.4.2 and starkit together), G-123 (these are punkbin candidates; kit-wrappability decides whether a runtime publishes as a usable tier), G-125 (achieved - its gate learned the tcl<M>.<m>/ library convention so such a kit can now be BUILT; making it BOOT is this goal), plus G-114 and G-127 as deliberate non-overlaps - same file, different axes. Also records in G-024 a design direction from the developer (non-contract Notes): the toml move is where NAMED GROUPINGS of mapvfs entries should be considered, prompted by wanting verification kits active but obviously not shipped products. Grouping would also give bake and bakelist a name to select on beyond per-kit names, and the commented-out historical entries somewhere honest to live. Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com	1 week ago