Bug report: Loading a FASL into a package which doesn't import SETQ

Mark Evenson evenson at panix.com
Wed Nov 11 09:40:23 UTC 2020

> On Nov 11, 2020, at 03:44, Robert Munyer <2433647181 at munyer.com> wrote:


> It's conceivably possible that _all_ of the manipulation of *PACKAGE*
> that happens during COMPILE-FILE could be removed, because the user is
> already required to have *PACKAGE* set correctly when invoking LOAD.

I don’t think this is true:  COMPILE-FILE should actually capture the current package when COMPILE-FILE is invoked, arranging to have this package present when LOAD occurs.  [An example of this][1] works on SBCL/CCL but fails on ABCL even with all of your suggestions.  Please correct me if you believe this isn’t the case.

[1]: <https://github.com/armedbear/abcl/pull/353/files#diff-886c987127185fcb79c86d6531feefaf00c1365126fc63afa248096f1da49e6eR12>

By [explicitly putting an IN-PACKAGE form in our fasl prologue which includes the value of the package that COMPILE-FILE is invoked within, I am able to make all my current tests pass.

[2]: https://github.com/armedbear/abcl/pull/353/files#diff-ccaa655ebf1432951ff70b34dcd6e82428cba2c5035e8077c7b183a6551bba3dR810

The new behavior is present in [pull][353].  I am going for a walk while I let the CI do its thing, pondering if I am really testing all the cases, but anticipate merging a consolidated version later today.

[353]: https://github.com/armedbear/abcl/pull/353/


"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."

More information about the armedbear-devel mailing list