[asdf-devel] pathname case issue ...

Faré fahree at gmail.com
Thu Jun 16 18:37:12 UTC 2011

On 15 June 2011 14:12, Nikodemus Siivola <nikodemus at random-state.net> wrote:
> On 15 June 2011 21:00, Faré <fahree at gmail.com> wrote:
>> Another thing is that on some implementations (notably SBCL),
>> you can't undo a defgeneric and if the signature changed,
> This is not intentional. If (fmakunbound 'foo) doesn't nuke your
> defgeneric properly, it's an SBCL bug that I'm happy to fix.
> What goes wrong if you do that?
It's been a while, I don't know the answer.

And so I retried with fmakunbound instead of unintern. I found another
problem, which is not specific to sbcl, but to the fact that several
ASDF functions the signature of which was redefined were used in the
continuation of compile-file, in the path to load'ing the compiled
asdf fasl, so that if they were fmakunbound rather than unintern'ed,
asdf was unable to load itself after having compiled the new version.

I solved that by making sure ASDF is first loaded as source via
load-source-op before it is compiled via compile-op. Therefore, when
it is compiled, the package frobbing has already been done and
resolved, and since no version discrepancy is detected at
compile-time, no further package frobbing will be done. This is done
with a special eql-defmethod on the component for the asdf.lisp file,
in asdf.asd.

Conclusion: there's no bug in SBCL that's affecting ASDF. Instead, it
was suboptimial design in ASDF's self-ugrade procedure. I must have
been confused with some other problem I had with fmakunbound and type
information hardwired into SBCL's infodb, probably from time I was
dealing with defining methods on CLOSE or redefining some SBCL

Apologies for the mistake, thanks for prompting me to dig into it and
fix it, and soon 2.016.3 with a more robust upgrade procedure that
doesn't unintern more than it should.

Zach: so now I can replace *system-definition-search-functions* with
something else that I defvar instead of defparameter. Problem being
backward compatibility, which pretty much requires squashing the old
symbol or its contents. I propose I create a new variable that is
defvar'ed, and either use it and ignore the old variable, or append
its content in front of the previous variable, or use (or new-var
old-var) to prefer it, or put at the proper end of one a function that
chains into the other. What do you think for the sake of Quicklisp?


More information about the asdf-devel mailing list