#248 register-image-restore-hook toplevel calls die with nested "; Error: ; Error: No package named UIOP" (2 sites in asdf load)
closedTwo with-upgradability blocks fail identically during (load "./asdf.lisp"):
- asdf.lisp:5150-5156 (uiop/image): (map () (quote register-image-restore-hook) (quote (setup-stdin setup-stdout setup-stderr setup-command-line-arguments setup-temporary-directory)))
- after compute-user-cache (asdf.lisp:7752, uiop/configuration): (register-image-restore-hook (quote compute-user-cache) …)
Both report the DOUBLED prefix "; Error: ; Error: No package named UIOP | in: WITH-UPGRADABILITY" — an error raised while handling/reporting another error. The UIOP umbrella package is defined much later (uiop/driver, asdf.lisp:~7860), so something in the hook-registration path (register-hook-function calls the hook immediately via call-now-p) or in the loader error reporter does find-package "UIOP" at a point where it does not exist yet.
Not yet root-caused — needs the gdb trap treatment (break on the package-error raise). Probes show reader conditionals with unknown-package symbols in skipped branches are NOT the cause (#+clisp (nosuchpkg:foo 1) skips cleanly).
Found triaging the 24 residual asdf-load errors under #205.
Comments (2)
PORTED (user decision: patch the vendored asdf). compat/asdf/asdf-funcl.patch (commits 1d1ca35 + bd0207f; asdf.lisp itself is gitignored so the patch is the tracked artifact):
- implementation guard: funcl in the supported list — kills the "ASDF is not supported" report
- getenv: #+funcl (%getenv x) — REAL environ access (funcl stdlib already had the primitive; (uiop/os::getenv "HOME") => "/home/green")
- raw-command-line-arguments: #+funcl nil until the runtime exposes argv beyond argv1
Result: both nested "No package named UIOP" errors GONE (the not-implemented-error reports no longer fire). Census 19 -> 18. Hooks setup-stdin/stdout/stderr/setup-command-line-arguments now run clean.
Residue (NOT this issue): setup-temporary-directory + compute-user-cache still fail — both chains die at parse-native-namestring, whose fn CELL holds a non-function while the defun source is healthy and portable. That is the same cell-vs-tables door-split family as component-name on #244 (see today's layer-7 comment there). Closing this issue; the residue rides #244/#205.
Root-caused via a hook-instrumented copy of asdf.lisp (each register-image-restore-hook call individually marked):
Both failing sites are hooks that funcl cannot implement yet:
The "No package named UIOP" is an error-during-error-report: not-implemented-error's :report lambda calls (symbol-call :uiop :implementation-type) (asdf.lisp:1786), and the umbrella UIOP package is only defined by uiop/driver much later in the file — so find-package* :uiop signals no-such-package-error while printing the original condition. Hence the doubled "; Error: ; Error:" prefix. register-image-restore-hook invokes hooks eagerly (call-now-p defaults T), which is why this fires at load time.
So this pair is EXPECTED-on-funcl, same family as the "ASDF is not supported on your implementation" guard: it goes away when the asdf port adds #+funcl branches for raw-command-line-arguments / get-folder-path (or provides argv + xdg equivalents). Decision needed: patch the vendored asdf.lisp with #+funcl branches now (standard route every implementation takes, upstreamable later) vs. accept these 3 report lines until then. Leaving open as the marker for that port decision.