Tree: 2dd63fa700

master

v0.1a

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '2dd63fa700'

${ noResults }

Commit Graph

3 Commits (2dd63fa700b12c02f682371c091605a6a0bef8c3)

Author	SHA1	Message	Date
Julian Noble	2dd63fa700	G-129 + G-101: downstream back-pointers to G-131 ... Both pairs read as one-directional in goals_xref (G-131 -> G-129 scoring 3.55, G-131 -> G-101 scoring 2.03) because the dependency convention has the consumer point at its predecessor. Adding the reverse edge so a reader who opens G-129 or G-101 - the two goals likely to be activated first - sees what is waiting downstream. Non-contract Notes only; neither goal's Goal or Acceptance changes, and both still stand alone. G-129: G-131 generalises its derivation from "where is the zipfs image mounted" to "which container is attached at all". That does not change what G-129 delivers, but it does say something about HOW - keep the derivation factored as a step that answers a question about the running kit rather than inlining a zipfs assumption into the surrounding path assembly, so the metakit arm can be added beside it rather than around it. G-101: this is the more consequential one. G-131 wants a runtime that boots from EITHER container, which bears on how G-101's decision should be FRAMED - if G-131 is wanted, the useful outcome is not "pick one container for 8.6 and close the question" but "establish that metakit is carryable AND that the zipfs backport is carryable, and record which is the default". The file already surveys both candidates and both look additive; the two sections were written independently as competing options, and G-131 is the reason to read them as a possible pair. Recorded explicitly that this does not block G-101's decision - it can still be decided without committing to G-131. goals_xref now reports both pairs as linked. Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com	5 days ago
Julian Noble	226b691471	G-130 + G-131 drafted (user-approved); G-129 records why it stands alone ... Two goals from the third-party 32-bit kit investigation, plus the finding that kept G-129 independent. G-129 Notes: the developer asked whether G-129 is needed to support baking with third-party kits. It is - it is the LAST blocker. The chain is: read the runtime's attached payload (G-124, achieved), do not let the boot-precondition gate falsely refuse it (G-125, achieved, plus the punkboot::utils 0.4.0 third-convention fix), then have the baked kit FIND that payload at boot (G-129). Measured by running punk_main.tcl's detection logic verbatim under bin/runtime/win32-ix86/tclsh8.6.10-luck-zip.exe: has_zipfs is 0, the //zipfs:/app branch is never computed, the kitpath branch is skipped, and NO internal module or lib paths are added - while tcl::zipfs::mount really does report the archive mounted at the exe path. So the failure is not "mounted somewhere unexpected and mis-resolved", it is "concluded there is no zipfs at all". This corrects an earlier recommendation to fold G-129 into G-131: folding would have parked third-party kit baking behind a much larger goal that needs a runtime carrying two container capabilities, which in turn needs G-101's port work. G-130 - 32-bit windows runtimes from the buildsuites, both Tcl generations. The motivation is supply, not architectural completeness: old, firewalled or sandboxed systems (industrial ones especially) are where 32-bit persists, they cannot fetch what they need, and a machine carrying binary Tcl modules built for only one major forces the runtime to match the modules. No single supplier keeps current 32-bit windows Tcl available for both majors. Acceptance keeps the binary-extension gate the developer asked for - each runtime must LOAD a real 32-bit extension, not merely start - because accepting drop-in modules is the whole point; twapi 4.7.2 inside the LUCK runtime is a 32-bit dll already in the tree for the 8.6 side. Both generations are required before the goal is met, since the motivating case is precisely that the machine's modules dictate the generation. KIT/CONTAINER TYPE IS DELIBERATELY OUT OF SCOPE - this goal produces runtimes, not kits; that question is G-101's. Sequencing per the developer: before or around the FreeBSD work, because a bitness change is likelier to surface recipe assumptions than another OS at the same bitness. Recorded as verified: punk::platform::local already reports win32-ix86 from a 32-bit interpreter and make.tcl derives the matching host/target/store, so no platform-canon work is needed. G-131 - one runtime, either payload: boot-time container autodetection (metakit or zipfs). Today a runtime's container is fixed when the runtime is ACQUIRED, so deliverables multiply by container: per platform, per generation, per container. If the boot detected what is attached, the container would become a bake-time choice and the count would collapse to platform x generation. Drafted to EXTEND G-129 rather than supersede it, and to depend on G-101 for the metakit arm to exist at all on a suite-built runtime. Its zipfs obligation is only that G-129's derivation still holds when reached through container detection. Carries two constraints found during the survey: the design must be preinit-shaped from the start, because G-101's Tcl 9 survey found the proc tclInit override the tclkit lineage relies on is dead in 9.1 and tcl_libPath is gone; and it explicitly rejects KitCreator's compile-time KIT_STORAGE_MK4/_ZIP/_CVFS switch - the closest prior art - because a compile-time answer still produces one binary per container. Scope names src/make.tcl's kit_type_mismatch check, whose premise (a runtime implies one container) this goal makes false. cookfs and other exotics are out of scope by the developer's decision. Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com	5 days ago
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	5 days ago