punkshell

1171 Commits

1 Branch

1 Tag

217 MiB

Commit Graph

Author	SHA1	Message	Date
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	2 weeks ago

Author

SHA1

Message

Date

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

2 weeks ago

1 Commits (226b691471d8008f3bc566dc48f2bdafe6a0eff0)