refactor: follow the cl-prolog-kit / cl-dataflow-kit rename - #2
Open
takeokunn wants to merge 5 commits into
Open
refactor: follow the cl-prolog-kit / cl-dataflow-kit rename#2takeokunn wants to merge 5 commits into
takeokunn wants to merge 5 commits into
Conversation
nerima-lisp/cl-prolog was renamed to cl-prolog-kit (v1.5.0) and cl-dataflow to cl-dataflow-kit (v1.2.0). The ASDF system names and CL package names moved with the repositories, so `cl-prolog:` no longer resolves and `:depends-on "cl-prolog"` no longer finds a system. Updated here: the flake input's Nix variable name and URL, the ASDF :depends-on entries, every package-qualified symbol reference, and the prose that names either package. flake.lock was regenerated with `nix flake lock`, not hand-edited. This also moves the pin forward to the current release rather than carrying the old one, since the tag the old pin named no longer contains a system under the old name.
The cl-cc revision pinned here predates cl-cc's rename migration, so the sibling sources it brings into CL_SOURCE_REGISTRY still declared :depends-on (... :cl-prolog ...). ASDF resolves system names across the whole registry, so one stale tree was enough to fail the build with Component :CL-PROLOG not found even though this repository's own sources had already been migrated. An aggregating repository cannot move to the -kit names until every tree it aggregates has moved; that ordering constraint lives at the ASDF layer, so nothing in the flake input graph expresses it. Pinned to cl-cc's current main, which carries the migration. A raw revision was already the form used here.
Commit 063bd42 bumped the cl-cc pin past cl-cc's own repository split to clear a `Component :CL-PROLOG not found`. At the new revision cl-cc.asd says of cl-cc-bootstrap/-vm/-ast/-type/-binary/-runtime/-mir/-target that they "are deliberately absent... live in the standalone repositories" and "reach this build as flake.nix inputs" -- and the same turns out to hold for -parse, -cps, -expand, -optimize and -codegen-native, which that comment does not name. This repository materialises cl-cc's source tree into its own source registry, so it has to supply every one of them itself; it supplied none, hence `Component :CL-CC-AST not found`. The set was derived empirically rather than guessed: each candidate was materialised at a pinned revision and loaded with a real sbcl --script, letting each `Component not found` name the next one. That produced 20 new inputs -- the twelve standalone cl-cc-* repositories plus a cl-log-kit -> cl-date-kit/cl-concurrent-kit/cl-boundary-kit chain and cl-codec-kit/cl-process-kit/cl-regex-kit/cl-tty-kit -- and one bump of an existing input: cl-host-kit 0.2.5 -> 0.3.1, which cl-log-kit's (:version "cl-host-kit" "0.3.1") floor requires. cl-cc-optimize is pinned to main rather than its v0.5.1 tag: the tag predates cl-cc-optimize's own rename and still asks for :cl-prolog, which no longer exists anywhere reachable. NOT VERIFIED LOCALLY. GitHub returned 429/502/503 for the new inputs' tarballs with Nix backing off past eight minutes per retry, so `nix flake check` could not complete here. CI is the first real verification; this must not merge until it is green.
c048ec9 wired cl-cc-ast/bootstrap/parse/vm/type/binary/runtime/mir/ codegen-native/expand/cps/optimize plus cl-log-kit's own transitive closure (cl-date-kit, cl-concurrent-kit, cl-boundary-kit, cl-codec-kit, cl-process-kit) and cl-regex-kit/cl-tty-kit into flake.nix, but could not regenerate flake.lock locally ("GitHub returned 429/502/503... nix flake check could not complete here") and left that commit marked NOT VERIFIED LOCALLY. Persisted through the same 429s here across three `nix flake lock` attempts with cool-down waits between them (this is the org-wide GitHub tarball rate-limit contention already on record, not a defect in the wiring) and got a lock file. `nix flake check --all-systems` then ran for real: every previously-missing-component error is gone, and checks.aarch64-darwin.default fails on exactly one thing -- FAIL cl-cc-php/test: no symbol named "REGISTER-BACKEND-PARSER" in "CL-CC/BOOTSTRAP" cl-cc-php's src/package.lisp and src/runtime-bridge-provider.lisp still import register-backend-parser/register-backend-bridge-provider from cl-cc/bootstrap. cl-cc-bootstrap's own CHANGELOG records removing them as "dead code superseded by backend-protocol.lisp's registry and never referenced anywhere in this repository" -- true only from cl-cc-bootstrap's side; cl-cc-php (and cl-cc-javascript, which has the identical two calls) still reference them. The replacement is a CLOS-generic-function-based backend-object registry (cl-cc/backend-protocol:register-backend plus the backend-bridge-symbols hook, in cl-cc-bootstrap's src/backend-protocol.lisp) with a different shape, not a mechanical rename -- porting to it is a separate, real source change to cl-cc-php's own files and is out of scope here.
cl-cc-bootstrap v0.1.0 is the release that removed register-backend-parser, register-backend-bridge-provider and their six siblings as "dead code never referenced anywhere in this repository" -- true of that repository, false of this one, which calls them at load time from src/runtime-bridge-provider.lisp. Building against v0.1.0 therefore fails with no symbol named "REGISTER-BACKEND-PARSER" in "CL-CC/BOOTSTRAP" cl-cc-bootstrap has since restored all eight, with tests, so this pins its current main. That is a raw revision because the restoration postdates v0.1.0 and no newer tag exists yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nerima-lisp/cl-prologwas renamed tocl-prolog-kit(v1.5.0) andcl-dataflowtocl-dataflow-kit(v1.2.0). The ASDF system names and CL package names moved with the repositories, socl-prolog:no longer resolves and:depends-on "cl-prolog"no longer finds a system.Updated: the flake input's Nix variable name and URL, the ASDF
:depends-onentries, every package-qualified symbol reference, and prose naming either package.flake.lockwas regenerated withnix flake lock, never hand-edited.The pin also moves forward to the current release rather than carrying the old one — the tag the old pin named no longer contains a system under the old name.
Verification before pushing: a residual grep for
cl-prolog/cl-dataflownot followed by-kit(and the uppercase andCL_…_env-var spellings) returns zero hits, nokit-kitdouble suffix was produced, and(/)counts are byte-identical per.lisp/.asdfile before and after — so the source change is rename-only. CI here is the build verification.