#287 alexandria via asdf: non-fatal load errors — %deftype-register 'not a byte-vector' (double-float predicates) + defpackage alexandria-2 '(RES) is not a SYMBOL'

open
Opened by atgreen

(asdf:load-system "alexandria") now COMPLETES (post ADR-0028 + eql-specializers + macro-aware eval) and alexandria:flatten et al. work. Residual non-fatal errors during the component loads:

  1. '; Error: the value is not a byte-vector | in: %DEFTYPE-REGISTER' — ×2, plus the same under DEFUN NEGATIVE-DOUBLE-FLOAT-P / NON-POSITIVE- / NON-NEGATIVE- / POSITIVE-DOUBLE-FLOAT-P (alexandria types.lisp double-float predicate/deftype registrations; likely a compound deftype spec shape %deftype-register doesn't expect).
  2. '; Error: The value (RES) is not a SYMBOL (symbol access). | in: DEFPACKAGE ALEXANDRIA-2' — defpackage option parse hits a (RES) list where it expects a symbol.

Neither aborts the load; filing to burn down for full alexandria fidelity (alexandria-2 package likely partially unusable).

Comments (1)

atgreen3992811157

STILL OPEN, now hit via BOTH asdf load routes (central-registry AND the new ocicl.csv path, 5f63ac0): alexandria types.lisp double-float predicates -> '%DEFTYPE-REGISTER: not a byte-vector', and defpackage alexandria-2 -> '(RES) is not a SYMBOL'. cl-base64 shows the same 'not a byte-vector' in its def--to-base64- macro. Non-fatal (systems load + core functions work), but these are the next fidelity targets for real ecosystem use. Likely one root: a deftype/defpackage-time macro producing a non-bv where a name bv is expected (cave#190 frob family).