port: expand VC6 C89 core frontier
This commit is contained in:
RayPals
+213
-1
@@ -1,4 +1,196 @@
|
||||
## Latest revision (frameobject C89 work; frontier advances past floatobject)
|
||||
## Latest revision (generated compatibility patch refreshed; VC6 frontier in object.c)
|
||||
|
||||
CPython baseline: `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The incremental C89/VC6 port now compiles `memoryobject.c`, `methodobject.c`, and `moduleobject.c` directly with VC6. Focused checks cover their declaration, evaluation, allocation, reference, and type-initialization ordering. Additional C89 conversions and focused checks have been added for `object.c`; its direct VC6 compile still fails with 72 diagnostics, many likely cascading from late declarations and remaining C99 constructs. This is compile-only progress; no interpreter link or Windows 98 SE runtime test is verified.
|
||||
|
||||
The tracked compatibility patch `compat/msvc600/cpython-3.11.16-vc6-headers.patch` has been regenerated from the full nested CPython working-tree diff and the untracked `Include/internal/pycore_win9x_loadlibrary.h`. A byte-for-byte check confirmed the patch contains all 121 modified/new file diffs. The nested CPython checkout remains detached; its source changes are represented in the root repository by this patch, not by committing the nested checkout.
|
||||
|
||||
Next: finish `object.c`, rerun the forced source-list compile frontier and focused regressions, then tackle linking and real Windows 98 SE execution separately. No link/runtime success is claimed.
|
||||
|
||||
---
|
||||
|
||||
## Latest revision (`PyLong_FromUnsignedLongLong` uses VC6-compatible unsigned type spelling)
|
||||
|
||||
Date: 2026-10-03 14:15 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the invoked legacy-toolchain guidance before work. The on-disk `python-3-win9x-msvc6.md` reference was absent. Preserved all pre-existing outer and detached CPython work; no reset, clean, stash, discard, commit, push, or publication. CPython remains at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549` (the same hash as recorded previously). The prior recorded `_PyLong_FromLarge()` frontier was stale. Forced-fresh MSVC600 `cl.exe` via Wine re-probe confirmed the actual first blocker was C2632 at `Objects/longobject.c(374)` and `(376)`: `unsigned long long` is rejected by VC6 in the `PyLong_FromUnsignedLongLong` definition and `PYLONG_FROM_UINT` instantiation. The compiler probe output did not print a separate compiler version banner.
|
||||
|
||||
Used one focused Codex CLI lane (`codex-cli 0.153.4`, workspace-write) for one narrow TDD slice. Extended `scripts/vc6-longobject-c89.test.py`, observed RED against the original spelling, then changed only the function parameter and macro type argument to `unsigned PY_LONG_LONG`. This matches the public declaration in `Include/longobject.h` and the existing VC6 mapping to `__int64` in `PC/pyconfig.h`, preserving unsigned 64-bit intent. No other source declaration or behavior changed. The existing later C89 errors were left untouched.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- Initial forced-fresh probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`; first errors C2632 at `longobject.c(374)` and `(376)`, followed by line-407 C89 errors. Log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791036400-3732714-7090.log`.
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1, expected assertion that `PyLong_FromUnsignedLongLong` must use the public/VC6-compatible unsigned `PY_LONG_LONG` spelling.
|
||||
- GREEN: same focused test — exit 0; all six longobject assertions passed.
|
||||
- Applicable regression suite: `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The longobject checks and other applicable checks passed; two known unrelated failures remain: console type lookup/cleanup order and numeric dispatch (`ValueError: substring not found`). Log: `/tmp/vc6-longlong-slice/suite.log`.
|
||||
- Post-change forced-fresh probe (same command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. The C2632 errors at lines 374/376 are gone; first stable errors now occur at line 407 in `PyLong_FromDouble()` (C2275/C2065 on late `PyLongObject *v`, followed by C89 declaration errors). Later independent long-long/CRT diagnostics remain. Log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791036840-3732714-b110.log`.
|
||||
- `git -C cpython diff --check -- Objects/longobject.c` and `git diff --check -- scripts/vc6-longobject-c89.test.py` — exit 0. Preservation comparison confirmed only this source and focused test changed beyond the pre-run snapshot; `PORT_STATUS.md`, compatibility patch, and all unrelated local changes were preserved.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and this status entry. This is compiler-probe progress only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or actual Windows 98 SE execution. Next frontier: test-first address only the first late-local declaration family in `PyLong_FromDouble()` at line 407, preserving all fast-path and validation/evaluation order; keep subsequent long-long/CRT issues separate.
|
||||
|
||||
---
|
||||
|
||||
## Previous revision (`_PyLong_FromLarge` C89 locals hoisted; frontier advances within longobject)
|
||||
|
||||
Date: 2026-10-03 09:47 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the legacy-toolchain guidance first. The referenced on-disk `python-3-win9x-msvc6.md` file was not found in the active profile or repository; the invoked skill guidance was available. Preserved all pre-existing outer and detached CPython work; no reset, clean, stash, discard, commit, push, or publication. CPython remains at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The recorded `_PyLong_FromLarge()` frontier remained current on forced-fresh probe. Used one focused Codex CLI lane (`codex-cli 0.153.4`, workspace-write) for one narrow TDD slice. Extended `scripts/vc6-longobject-c89.test.py`, observed RED before the source edit, then hoisted only `twodigits abs_ival`, `twodigits t`, `Py_ssize_t ndigits`, `PyLongObject *v`, `digit *p`, and `int sign` to `_PyLong_FromLarge()`'s entry declarations in `cpython/Objects/longobject.c`. Initializers became assignments at their original execution points. Assertions, sign/absolute-value branches, digit-count loop, allocation, initialization, digit-write loop, and return ordering remain unchanged. Independently inspected the nested diff and confirmed only this function changed in the nested CPython slice.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- Initial forced-fresh compiler probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `_blake2/blake2s_impl.c` compiled. First errors were C2275/C2146/C2065 on late `twodigits t` at `longobject.c(239)`, followed by late `ndigits` at 240 and `v` at 245. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791020452-3685379-2910.log`.
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1 at the new `_PyLong_FromLarge` assertion; the prior get_small_int, `_PyLong_New`, and `_PyLong_FromMedium` checks passed.
|
||||
- GREEN: same focused command — exit 0; all four longobject regression checks passed.
|
||||
- Applicable broad regression: `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. Longobject checks and the rest of applicable checks run and pass. Two known unrelated failures remain: console type lookup/cleanup order and numeric dispatch (`ValueError: substring not found`).
|
||||
- Post-change forced-fresh probe (same command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `longobject.c` now compiles past `_PyLong_FromLarge`; first errors advanced to line 364 in `PyLong_FromLong()` (C2275/C2146/C2065 on a late `Py_ssize_t ndigits`, then cascading late `t`, `v`, and `p` declarations). Subsequent diagnostics include independent long-long/CRT blockers. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791020810-3685379-5b50.log`.
|
||||
- `git -C cpython diff --check -- Objects/longobject.c` and `git diff --check -- PORT_STATUS.md scripts/vc6-longobject-c89.test.py` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and this status entry. Compiler-probe progress only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or actual Windows 98 SE execution. Next frontier: test-first address only the first `PyLong_FromLong()` declaration family at line 364, retaining its small/medium fast paths and digit-count/allocation order; handle later `long long` and CRT issues separately.
|
||||
|
||||
---
|
||||
|
||||
## Previous revision (`_PyLong_FromMedium` C89 locals hoisted; frontier advances within longobject)
|
||||
|
||||
Date: 2026-10-03 07:39 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the legacy-toolchain reference before acting. Preserved the existing outer worktree and detached CPython changes; no reset, clean, stash, discard, commit, push, or publication. CPython remains at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`. The prior `_PyLong_New()` frontier was freshly rechecked: `_blake2/blake2s_impl.c` compiled, `_PyLong_New()`'s line-156 diagnostic was gone, and the first blocker was `_PyLong_FromMedium()` at line 205.
|
||||
|
||||
Used one focused Codex CLI coding lane (`codex-cli 0.153.4`, workspace-write). Strict TDD: extended `scripts/vc6-longobject-c89.test.py` for `_PyLong_FromMedium()` declarations and statement order, observed RED before the production edit, then hoisted only `PyLongObject *v`, `Py_ssize_t sign`, and `digit abs_x` to the opening declaration group in `cpython/Objects/longobject.c`. Assignments remain at their original points; assertions, allocation, NULL/error/return, initialization, digit write, and return order are preserved. The agent made no other changes; independently inspected the narrow diff.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- Initial forced-fresh probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `_blake2/blake2s_impl.c` compiled. First blocker was C2143 at `longobject.c(205)` on the late `PyLongObject *v`; dependent errors included C2065 `v` and late `Py_ssize_t sign` / `digit abs_x`. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791012585-3658734-75d0.log`.
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1, expected assertion that `_PyLong_FromMedium` declarations and order did not match; prior `get_small_int` and `_PyLong_New` checks passed.
|
||||
- GREEN: same command — exit 0; all three longobject checks passed, including the new `_PyLong_FromMedium` check.
|
||||
- Applicable regression suite: `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The broad suite ran; this slice's source behavior assertion passed when run directly. Two known unrelated failures remain: console type lookup/cleanup order and numeric dispatch (`ValueError: substring not found`).
|
||||
- Post-change forced-fresh probe (same command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `_PyLong_FromMedium()` passed its former diagnostics. First stable diagnostics now occur in `_PyLong_FromLarge()` at `longobject.c(239)` on late `twodigits t` (C2275/C2146, with C2065 `t`), followed by late `Py_ssize_t ndigits` at line 240 and late `PyLongObject *v` at line 245. Full log: `build/current-recheck/longobject-frommedium-post.log`.
|
||||
- `git diff --check -- PORT_STATUS.md scripts/vc6-longobject-c89.test.py && git -C cpython diff --check -- Objects/longobject.c` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and this status entry. This is compiler-probe progress only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or actual Windows 98 SE execution. Next frontier: test-first hoist only the first `_PyLong_FromLarge()` declaration family in function-entry order, preserving assertions, sign/absolute-value decisions, digit-count loop, allocation, initialization, and digit-write order; keep later `long long`/CRT blockers separate.
|
||||
|
||||
---
|
||||
|
||||
## Previous revision (_PyLong_New ndigits declaration hoisted; frontier remains longobject)
|
||||
|
||||
Date: 2026-10-03 05:16 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the CPython/Win9x/MSVC6 reference before acting. Preserved existing outer and detached CPython edits; no reset, clean, stash, discard, commit, push, or publication. CPython remains detached at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`. The recorded frontier had become stale: forced-fresh VC6 re-probe confirmed `_blake2/blake2s_impl.c` compiles and first blocked at `Objects/longobject.c(156)` inside `_PyLong_New()`.
|
||||
|
||||
Applied one narrow test-first C89 slice: hoisted only `Py_ssize_t ndigits` into `_PyLong_New()`'s declaration group; its assignment remains after the overflow check and before allocation. The regression `scripts/vc6-longobject-c89.test.py` now checks the declaration and exact overflow-check, ndigits assignment, allocation, allocation error, initialization, and return order. The native Hermes coding-subagent API could not start because its Anthropic package is absent; used one focused Codex CLI lane (`codex-cli 0.153.4`, workspace-write) and independently checked results. Existing uncommitted `get_small_int()` changes were retained.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- Initial forced-fresh probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `_blake2/blake2s_impl.c` compiled; first blocker was C2275/C2146/C2065 at `longobject.c(156)` for late `Py_ssize_t ndigits`. Full output: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791004605-3636193-e850.log`.
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1, expected `_PyLong_New` assertion failed; existing `get_small_int` check passed.
|
||||
- GREEN: same command — exit 0, both `get_small_int` and `_PyLong_New` checks passed.
|
||||
- Post-change forced-fresh probe (same command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. The `_PyLong_New()` line-156 diagnostic is gone. First remaining stable diagnostics start at `longobject.c(205)` in `_PyLong_FromMedium()` (C2143 before type and dependent C2065 `v`); later declaration-order and `long long` blockers remain separate. Full output: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791004999-3636193-ef50.log`.
|
||||
- Applicable regression command `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The new longobject checks pass when run directly; the full suite still has the two known failures: console type-detection ordering and numeric dispatch (`ValueError: substring not found`).
|
||||
- `bash -n scripts/vc6-probe-pythoncore-frontier.sh scripts/vc6-probe-pythoncore-frontier.test.sh && git diff --check -- PORT_STATUS.md scripts/vc6-longobject-c89.test.py && git -C cpython diff --check -- Objects/longobject.c` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and `PORT_STATUS.md`. Compile-frontier evidence only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or actual Windows 98 SE execution. Next frontier: test-first hoist only the first `_PyLong_FromMedium()` declaration family at line 205, preserving allocation/error and initialization order; keep subsequent locals and `long long` issues separate.
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the invoked legacy-toolchain guidance before acting. The referenced on-disk `python-3-win9x-msvc6.md` was not present at either the expected profile skills reference path or in the repository. Preserved every pre-existing outer and detached CPython change; no reset, clean, stash, discard, commit, push, or publication. CPython remains detached at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The status-recorded listobject frontier was stale. A forced-fresh probe confirmed `Objects/listobject.c` and `_blake2/blake2s_impl.c` now compile; first blocker is `Objects/longobject.c`. Applied one narrow C89 slice in `get_small_int()`: moved only `PyObject *v` to the function's declaration group and retained the assertion → small-int lookup assignment → incref → return order. Added `scripts/vc6-longobject-c89.test.py`. Coding subagent dispatch was attempted, but the delegate service failed because the Anthropic Python package is unavailable; proceeded with the minimal test-first edit directly, without a coding CLI.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1 with the expected assertion that `get_small_int` must declare `v` at function entry and preserve evaluation order.
|
||||
- GREEN: same command — exit 0, `longobject get_small_int C89 declaration and evaluation order: PASS`.
|
||||
- Applicable shell regression: `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The longobject changes do not introduce suite assertions (no longobject integration existed); the known console-type-detection assertion fails and numeric-dispatch check raises `ValueError: substring not found`. The listobject and other targeted checks pass.
|
||||
- Initial fresh probe before the slice: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`. First diagnostics in `longobject.c`: C2143 at line 61 before `type`, C2065 `v`; subsequent errors are distinct declaration-order and `long long`/CRT compatibility issues. Log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790996934-3608344-9090.log`.
|
||||
- Post-change forced fresh probe (same command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `get_small_int()`'s prior C2143/C2065 diagnostics are gone; first remaining errors are C2275/C2146/C2065 at `longobject.c(156)` for late `Py_ssize_t ndigits` in `_PyLong_New()`. Later declaration-order and VC6 64-bit type issues remain separate. Log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790997084-3608344-5490.log`.
|
||||
- `bash -n scripts/vc6-probe-pythoncore-frontier.sh scripts/vc6-probe-pythoncore-frontier.test.sh`, focused/nested/outer scoped `git diff --check` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and `PORT_STATUS.md`. Compiler-probe progress only: no `pythoncore.dll`/`python.exe` link, Wine interpreter execution, or actual Windows 98 SE execution. Next frontier: test-first hoist only `ndigits` in `_PyLong_New()`, preserving the overflow check and allocation/error sequence.
|
||||
|
||||
---
|
||||
|
||||
## Latest revision (expanded listobject VC6/C89 fixes; forced recheck in progress)
|
||||
|
||||
Date: 2026-10-03 03:05 UTC
|
||||
|
||||
Preserved all pre-existing outer and detached CPython changes; no reset, clean, stash, discard, commit, or push. CPython remains on the v3.11.16 baseline.
|
||||
|
||||
The last completed forced-fresh probe had advanced past the earlier list-allocation, list-repeat, and powersort-helper blockers, then reported additional C89 violations in `listobject.c` sorting, comparison, vectorcall, extended-slice assignment, type initialization, and iterator-pickling code. Applied declaration/order fixes in those paths and replaced the `PyList_Type.tp_vectorcall` designated initializer with a positional tail matching `PyTypeObject` field order. Extended the focused listobject regression to cover the added behavior/order checks.
|
||||
|
||||
Verification:
|
||||
|
||||
- Focused regressions pass for listobject, frameobject, funcobject, genericaliasobject (including `object.c`), genobject, interpreteridobject, and iterobject.
|
||||
- Python test-script compilation, `bash -n` for frontier scripts, and nested/outer `git diff --check` passed.
|
||||
- Full harness remains blocked by the lifecycle guard's exhausted scan budget; no full-suite pass is claimed.
|
||||
- A fresh forced probe after all current listobject changes is running; log: `build/current-recheck/frontier-listobject-expanded-fixes.log`.
|
||||
|
||||
Compile-only evidence; no interpreter link or runtime execution. Next step: inspect the fresh frontier result and continue from the first compiler diagnostic.
|
||||
|
||||
---
|
||||
|
||||
## Previous latest revision (listobject repeat C89 declarations; forced recheck)
|
||||
|
||||
Date: 2026-10-03 00:57 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the active-profile `python-3-win9x-msvc6.md` reference before acting. Preserved the existing outer and detached CPython work; no reset, clean, stash, discard, commit, push, publication, or compatibility-patch regeneration. CPython remains at `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The recorded `_blake2/blake2s_impl.c` state was no longer the frontier. Forced-fresh probing found `Objects/genericaliasobject.c` as the first blocker. Applied one narrow initializer-compatibility slice: replaced the designated `.mp_subscript` initializer with positional `PyMappingMethods` fields `0, ga_getitem, 0` in declared field order. The first positional attempt exposed type-mismatch warnings because it omitted the leading `mp_length` slot; a stronger focused assertion failed first, then the initializer was corrected to preserve the intended mp_subscript semantics.
|
||||
|
||||
Exact commands/results:
|
||||
|
||||
- Initial forced-fresh probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2; `total=90 compiled=89 cached=0 skipped=0`. First diagnostic was C2059 at `genericaliasobject.c(583)` for `.mp_subscript = ga_getitem`.
|
||||
- TDD RED: `python3 scripts/vc6-genericaliasobject-c89.test.py cpython/Objects/genericaliasobject.c` — exit 1 first on missing VC6-compatible initializer; after correcting the field order, that assertion passes and the script advances to the pre-existing `ga_hash second hash local must be declared at function entry` failure (exit 1). A direct assertion of the exact `0, ga_getitem, 0` field layout passed (exit 0).
|
||||
- `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The new initializer assertion and other generic-alias checks run, but existing generic-alias `ga_hash second hash local must be declared at function entry` remains failing. Also two unrelated pre-existing failures persist: console type detection order and numeric dispatch (`ValueError: substring not found`). No unrelated changes made.
|
||||
- Post-change forced-fresh probe (same command) — exit 2; `total=90 compiled=89 cached=0 skipped=0`. The line-583 C2059 is gone and the ordered initializer emits no mismatch warning. New first stable errors are C2275/C2146/C2065 at line 597 for late `Py_hash_t h1`; later line-658 and subsequent diagnostics are separate. Full output: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790989338-3437483-1c50.log`.
|
||||
- Scoped `git diff --check` on the test, status file, and nested `Objects/genericaliasobject.c` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/genericaliasobject.c`, `scripts/vc6-genericaliasobject-c89.test.py`, and this status log. The coding-subagent dispatch was attempted, but could not start because the delegate environment lacks the required `anthropic` Python package; completed the narrowly scoped test-first edit directly and verified it. No linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or real Windows 98 SE execution is claimed. Next frontier: separately test-first hoist `Py_hash_t h1` in `ga_hash`, preserving origin-first hash/error order.
|
||||
|
||||
---
|
||||
|
||||
## Previous revision (`tuple_index` loop declaration hoisted; genericaliasobject frontier advances)
|
||||
|
||||
Date: 2026-10-02 22:56 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the loaded legacy-toolchain guidance before acting; the on-disk `references/python-3-win9x-msvc6.md` was not found. Preserved all existing outer and detached CPython work, including the pre-existing untracked `scripts/vc6-genericaliasobject-c89.test.py`. No reset, clean, stash, discard, commit, push, or publication. CPython remains at baseline tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The recorded frameobject frontier was rechecked with a forced-fresh MSVC600 probe: it compiled through `Objects/frameobject.c`; the active first blocker is `Objects/genericaliasobject.c`. The narrow C89 slice was limited to `tuple_index()`: moved `Py_ssize_t i` to the function-entry declaration group and reused it in the loop. Scan order and `return -1` behavior are unchanged. Used exactly one focused Codex CLI coding lane (0.153.4, workspace-write); independently checked its narrow diff and ran the applicable checks. The existing focused test failed before the source edit as expected.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- RED: `python3 scripts/vc6-genericaliasobject-c89.test.py cpython/Objects/genericaliasobject.c` — exit 1, `tuple_index loop variable must be declared at function entry`.
|
||||
- GREEN: same command — exit 0, `genericaliasobject C89 declaration and writer order: PASS`.
|
||||
- Forced fresh probe: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=90 compiled=89 cached=0 skipped=0`. `genericaliasobject.c` passes the `tuple_index()` diagnostic. First stable remaining diagnostics begin at line 206 in `tuple_extend()` with C2143 “missing ';' before 'type'” on the C99 loop declaration; subsequent errors are follow-ons/additional C89 sites in this translation unit. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790981507-3342471-aa90.log`.
|
||||
- Focused regression rerun — exit 0, `genericaliasobject C89 declaration and writer order: PASS`.
|
||||
- `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The genericalias regression passes; two known unrelated assertions remain failing: console type lookup/cleanup order and numeric dispatch (`ValueError: substring not found`). No unrelated fixes attempted.
|
||||
- Scoped `git diff --check` for `cpython/Objects/genericaliasobject.c`, the focused test and `PORT_STATUS.md` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/genericaliasobject.c` and this status log. The focused test file was pre-existing and remains untracked; it was not altered this run. The generated compatibility patch was not regenerated. This is compiler-probe progress only: no `pythoncore.dll`/`python.exe` link, Wine interpreter execution, or real Windows 98 SE execution. Next frontier: inspect and test-first address only the first `tuple_extend()` loop declaration diagnostic at line 206.
|
||||
|
||||
---
|
||||
|
||||
## Previous latest revision (`frame_setlineno` C89 declarations hoisted; frameobject frontier advances)
|
||||
|
||||
Date: 2026-10-02 20:33 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the loaded legacy-toolchain porting guidance before editing. The on-disk `references/python-3-win9x-msvc6.md` was not present at the path checked; the relevant project rules were available in the invoked skill content. Preserved all pre-existing outer and detached CPython work. No reset, clean, stash, discard, commit, push, or publication. CPython remains at baseline tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
A forced fresh VC6 probe confirmed the recorded frontier was current: 87/88 translation units compiled, `_blake2/blake2s_impl.c` compiled, and `Objects/frameobject.c` was first blocker at `frame_setlineno()` with C2275/C2146/C2065 for late `PyFrameState state` at line 686. Used one focused Codex CLI coding lane after confirming `codex-cli 0.153.4` was available. Following strict TDD, it extended `scripts/vc6-frameobject-c89.test.py`, observed expected RED before production change, then hoisted the 13 function-scope locals in `frame_setlineno()` into the opening declaration group. Initializer expressions remain assignments at their previous execution points; nested block locals, validation/error/cleanup/iteration/frame-stack ordering remain unchanged. Independently verified the diff and reran checks.
|
||||
|
||||
Exact commands/results:
|
||||
|
||||
- Initial forced probe `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, 87/88 compiled, zero cached. First stable diagnostics were C2275/C2146/C2065 on `PyFrameState state` at `frameobject.c(686)`; subsequent errors in that function were follow-ons. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790973232-3123322-1550.log`.
|
||||
- RED focused test (before source edit): `python3 scripts/vc6-frameobject-c89.test.py cpython/Objects/frameobject.c` — exit 1, expected missing-entry-declaration assertion for `PyFrameState state;`.
|
||||
- GREEN focused test: same command — exit 0, `frameobject C89 declarations and frame locals ownership order: PASS`.
|
||||
- `bash -n scripts/vc6-probe-pythoncore-frontier.sh scripts/vc6-probe-pythoncore-frontier.test.sh` and scoped nested/outer `git diff --check` — exit 0.
|
||||
- `bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1. The new frameobject regression passes; 250 checks pass overall. Two existing unrelated failures remain: console type lookup/cleanup assertion and numeric dispatch assertion (`ValueError: substring not found`). No unrelated fixes attempted.
|
||||
- Forced post-change probe, after preparing writable workspace runtime directory: `mkdir -p build/current-recheck/runtime && chmod 700 build/current-recheck/runtime && XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, 87/88 compiled, zero cached. `frame_setlineno()` now compiles past its prior diagnostics. First stable remaining diagnostic is C2143 at `frameobject.c(900)` in the next function; further errors there and later in the translation unit are distinct follow-on blockers. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1790973669-3123322-2e50.log`.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/frameobject.c`, `scripts/vc6-frameobject-c89.test.py`, and this log. Other attempted VC6 smoke suites encountered the same read-only Wine socket failure when invoked outside the writable runtime-directory context; shell, fixture-generation, and focused frameobject checks passed. This is compiler-probe progress only: no `pythoncore.dll`/`python.exe` link, Wine interpreter execution, or Windows 98 SE execution. Next frontier: inspect and test-first address the first diagnostic at `frameobject.c(900)`, without bundling later errors.
|
||||
|
||||
---
|
||||
|
||||
## Previous latest revision (frameobject C89 work; frontier advances past floatobject)
|
||||
|
||||
Date: 2026-10-02 19:09 UTC
|
||||
|
||||
@@ -7812,4 +8004,24 @@ Exact commands/results:
|
||||
Files changed by this slice: `cpython/Objects/codeobject.c`, `scripts/vc6-codeobject-c89.test.py`, and this status log. This is compiler-probe progress only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or real Windows 98 SE execution. Next frontier: separately test-first hoist only `Py_hash_t h4` and `h5` in the functions at lines 1830/1834, preserving hash computation order. Keep the existing outer regression failures explicit; compatibility patch synchronization remains unresolved.
|
||||
|
||||
---
|
||||
## Latest revision (`PYLONG_FROM_UINT` C89 locals hoisted; frontier reaches long-long syntax)
|
||||
|
||||
Date: 2026-10-03 12:05 UTC
|
||||
|
||||
Read `PORT_STATUS.md`, `README.md`, and the loaded legacy-toolchain guidance before acting; the referenced on-disk CPython reference remains unavailable. Preserved all pre-existing outer and detached CPython changes; no reset, clean, stash, discard, commit, push, publication, or compatibility-patch regeneration. CPython remains at tag `v3.11.16`, commit `41388c9cb160d0886d5ca00d2e6c878260a8a4549`.
|
||||
|
||||
The previous status named `PyLong_FromLong()` as the next frontier, but fresh compiler evidence showed the line-364 declarations were emitted from the `PYLONG_FROM_UINT` macro invoked by `PyLong_FromUnsignedLong()`. `PyLong_FromLong()` already had its function locals declared at entry. Used one focused Codex CLI coding lane (`codex-cli 0.153.4`, workspace-write) for a single test-first macro slice. Extended `scripts/vc6-longobject-c89.test.py`, observed expected RED before the source change, then hoisted only `Py_ssize_t ndigits`, `INT_TYPE t`, `PyLongObject *v`, and `digit *p` to the start of the macro's `do` block in `cpython/Objects/longobject.c`. Initializers became assignments at the previous evaluation points. Small-int fast return, digit-count loop, allocation/error path, value consumption/mutation, digit writes, and return order are unchanged. Independently inspected the complete nested diff: the macro is the only new nested source change in this slice; earlier uncommitted `longobject.c` edits are preserved.
|
||||
|
||||
Exact verification:
|
||||
|
||||
- Forced-fresh MSVC600 probe before the slice: `XDG_RUNTIME_DIR="$PWD/build/current-recheck/runtime" WINEPREFIX=/home/ubuntu/.wine-win9xport WINEDEBUG=-all VC6_FRONTIER_FORCE=1 bash scripts/vc6-probe-pythoncore-frontier.sh` — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `_blake2/blake2s_impl.c` compiled. The line-364 errors attributed to `PyLong_FromLong()` in the prior log were actually macro expansion diagnostics: late `Py_ssize_t ndigits`, `INT_TYPE t`, `PyLongObject *v`, and `digit *p` in `PYLONG_FROM_UINT`. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791028366-3708731-9a10.log`.
|
||||
- RED: `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c` — exit 1 before the source edit, expected `AssertionError: PYLONG_FROM_UINT must declare ndigits, t, v, and p at do-block entry`.
|
||||
- GREEN: same command after edit — exit 0; all five focused longobject checks passed, including macro declaration/evaluation/error order.
|
||||
- Applicable regression: `MSVC600_ROOT=/tmp/pylong-uint-no-toolchain bash scripts/vc6-probe-pythoncore-frontier.test.sh` — exit 1; regression run completed, with only the two known unrelated failures: console type detection/cleanup order and numeric dispatch (`ValueError: substring not found`). The live compiler integration check was intentionally skipped for this suite run; the separate forced-fresh probe below ran with the actual installed toolchain.
|
||||
- Independent forced-fresh post-change probe (same `XDG_RUNTIME_DIR`, `WINEPREFIX`, and `VC6_FRONTIER_FORCE=1` command) — exit 2, `total=95 compiled=94 cached=0 skipped=0`. `longobject.c` passed the `PYLONG_FROM_UINT` macro declaration diagnostics. First diagnostics now occur at `longobject.c(374)` / `(376)`: C2632, `long` followed by `long` is illegal in the `PyLong_FromUnsignedLongLong` signature and macro argument. Further longobject diagnostics (including C89 sites and missing 64-bit CRT names) remain separate. Full log: `/home/ubuntu/.hermes/profiles/maxwell/cache/terminal-output/out-1791028867-3708731-dc50.log`.
|
||||
- `python3 scripts/vc6-longobject-c89.test.py cpython/Objects/longobject.c`, nested `git diff --check -- Objects/longobject.c`, and outer `git diff --check -- scripts/vc6-longobject-c89.test.py` — exit 0.
|
||||
|
||||
Files changed by this slice: `cpython/Objects/longobject.c`, `scripts/vc6-longobject-c89.test.py`, and this status entry. This is compiler-probe progress only: no linked `pythoncore.dll`/`python.exe`, Wine interpreter execution, or real Windows 98 SE execution. Next frontier: investigate the VC6 `long long` blocker at `PyLong_FromUnsignedLongLong` (including applicable compatibility typedef/macros and declarations) as its own evidence-backed slice; do not bundle later C89/CRT diagnostics. No commit or push.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user