On 15 June 2011 14:12, Nikodemus Siivola nikodemus@random-state.net wrote:
On 15 June 2011 21:00, Faré fahree@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