[asdf-devel] pathname case issue ...

[Faré]

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
internals.

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?

--#f