Of all the lisp implementations, CLISP has given me the most trouble with ASDF upgrade. Unlike all other Lisps, it won't let me undefine functions and redefine them in the same fasl file. Somehow, I always end up with CLISP either complaining that a function signature doesn't match (was or wasn't a generic function with an incompatible lambda-list), because I couldn't undefine it, or that it is undefined and never redefined, because I undefined it and CLISP throws away my redefinition somehow. I tried to selectively unintern symbols for functions thus upgraded, but that also fails. Yet all these things work in about all other Lisps.
In the end, I punted: I just rename the old ASDF package to ASDF-${version} early on, but that messes with any package that :use's ASDF, and then CLISP will complain again, unless ASDF is the very first thing upgraded before anything uses it.
Could CLISP be made more upgrade-friendly?
(another thing I don't understand that may or may not be related is the .lib output files produced together with a fasl, when and how they are used, and what I should or should not do with them.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Nostalgia isn’t what it used to be.
- Faré snuerr@tznvy.pbz [2013-01-20 22:46:35 -0500]:
Of all the lisp implementations, CLISP has given me the most trouble with ASDF upgrade. Unlike all other Lisps, it won't let me undefine functions and redefine them in the same fasl file. Somehow, I always end up with CLISP either complaining that a function signature doesn't match (was or wasn't a generic function with an incompatible lambda-list), because I couldn't undefine it, or that it is undefined and never redefined, because I undefined it and CLISP throws away my redefinition somehow. I tried to selectively unintern symbols for functions thus upgraded, but that also fails. Yet all these things work in about all other Lisps.
In the end, I punted: I just rename the old ASDF package to ASDF-${version} early on, but that messes with any package that :use's ASDF, and then CLISP will complain again, unless ASDF is the very first thing upgraded before anything uses it.
Could CLISP be made more upgrade-friendly?
When you actually do change function signatures, a warning is, IMO, quite appropriate. I am not really sure why you want to silence them.
(another thing I don't understand that may or may not be related is the .lib output files produced together with a fasl, when and how they are used, and what I should or should not do with them.)
http://clisp.org/impnotes/require.html#lib-files
On Mon, Jan 21, 2013 at 11:51 AM, Sam Steingold sds@gnu.org wrote:
- Faré snuerr@tznvy.pbz [2013-01-20 22:46:35 -0500]:
Of all the lisp implementations, CLISP has given me the most trouble with ASDF upgrade. Unlike all other Lisps, it won't let me undefine functions and redefine them in the same fasl file. Somehow, I always end up with CLISP either complaining that a function signature doesn't match (was or wasn't a generic function with an incompatible lambda-list), because I couldn't undefine it, or that it is undefined and never redefined, because I undefined it and CLISP throws away my redefinition somehow. I tried to selectively unintern symbols for functions thus upgraded, but that also fails. Yet all these things work in about all other Lisps.
In the end, I punted: I just rename the old ASDF package to ASDF-${version} early on, but that messes with any package that :use's ASDF, and then CLISP will complain again, unless ASDF is the very first thing upgraded before anything uses it.
Could CLISP be made more upgrade-friendly?
When you actually do change function signatures, a warning is, IMO, quite appropriate. I am not really sure why you want to silence them.
A warning when the signature changes is quite OK. My problem is the unability to override the previous signature. If I fmakunbound the function then redefine it in the same file, it looks like the new definition never appears.
I will try to extract some reduced example.
(another thing I don't understand that may or may not be related is the .lib output files produced together with a fasl, when and how they are used, and what I should or should not do with them.)
Oh, that's cool. Does the .lib also include the user-supplied (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) side-effects? If so, that's great -- it's like the CFASLs of SBCL (except it probably pre-dates them).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Die Mathematiker sind eine Art Franzosen: redet man zu ihnen, so übersetzen sie es in ihre Sprache, und dann ist es alsobald ganz etwas anderes. [Les mathématiciens sont comme les Français: quoiqu'on leur dise, ils le traduisent dans leur propre langue, et cela devient alors quelque chose de complètement différent.] — Johann Wolfgang von Goethe
- Faré snuerr@tznvy.pbz [2013-01-21 14:14:44 -0500]:
(another thing I don't understand that may or may not be related is the .lib output files produced together with a fasl, when and how they are used, and what I should or should not do with them.)
Oh, that's cool. Does the .lib also include the user-supplied (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) side-effects?
Sorry, I don't remember. Could you please test it and file an RFE if you are unhappy?
Thanks.
-
Faré -
Sam Steingold