From: Faré <fa...@gm...> - 2010-08-03 16:23:19
|
Dear CLISP maintainers, what should I do if I want to include ASDF 2 in CLISP? Should I send a patch that consists in creating a new subdirectory of modules? Would you accept it? If so, which existing module may I cargo-cult, considering that ASDF is one single lisp file? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "A true conservative is someone who explains to you that government doesn't work, gets elected and then proves it!" — Milton Friedman |
From: Sam S. <sd...@gn...> - 2010-08-03 17:04:32
|
Hi, Faré wrote: > > what should I do if I want to include ASDF 2 in CLISP? If you want to ship a modified CLISP which includes ASDF, the easiest way is to add an asdf module. note that asdf requires the syscalls module. > Should I send a patch that consists in creating a new subdirectory of > modules? Would you accept it? If so, which existing module may I > cargo-cult, considering that ASDF is one single lisp file? Oh, you want _us_ to ship asdf... do people want that? if yes, should it be a base module? (http://clisp.cons.org/impnotes/modules.html#base-modules) do other lisps come with asdf ootb? (I know sbcl does, how about gcl, ecl, abcl &c) Sam. PS. a quick look at #+clisp on asdf.lisp reveals the following: getenv: I suggest (import 'ext:genenv) instead of (defun getenv) get-uid: I suggest (setf fdefinition) instead of defun probe-file*: I suggest probe-pathname instead of (ignore-errors (truename p)) |
From: Raymond T. <toy...@gm...> - 2010-08-03 17:13:38
|
On 8/3/10 1:04 PM, Sam Steingold wrote: > > Oh, you want _us_ to ship asdf... > do people want that? > if yes, should it be a base module? > (http://clisp.cons.org/impnotes/modules.html#base-modules) > do other lisps come with asdf ootb? > (I know sbcl does, how about gcl, ecl, abcl &c) CMUCL has included asdf2 for about a month now and will be a part of the next release. (CMUCL also includes mk:defsys, like ecl (and ccl?) does.) Ray |
From: Sam S. <sd...@gn...> - 2010-08-03 17:25:11
|
Raymond Toy wrote: > On 8/3/10 1:04 PM, Sam Steingold wrote: >> do other lisps come with asdf ootb? >> (I know sbcl does, how about gcl, ecl, abcl &c) > CMUCL has included asdf2 for about a month now and will be a part of the > next release. (CMUCL also includes mk:defsys, like ecl (and ccl?) does.) clisp is not going to ship more than 1 system construction facilities. therefore the fact that some lisps come with two is an argument against including asdf with clisp. |
From: Raymond T. <toy...@gm...> - 2010-08-03 22:17:45
|
On 8/3/10 1:25 PM, Sam Steingold wrote: > Raymond Toy wrote: >> On 8/3/10 1:04 PM, Sam Steingold wrote: >>> do other lisps come with asdf ootb? >>> (I know sbcl does, how about gcl, ecl, abcl &c) >> CMUCL has included asdf2 for about a month now and will be a part of the >> next release. (CMUCL also includes mk:defsys, like ecl (and ccl?) >> does.) > > clisp is not going to ship more than 1 system construction facilities. > therefore the fact that some lisps come with two is an argument > against including asdf with clisp. > I don't see how that follows, but no matter. That CMUCL includes both is an historical political reason (perhaps no longer relevant). Ray |
From: Faré <fa...@gm...> - 2010-08-03 22:40:40
|
Dear Sam, thanks for the quick answer. On 3 August 2010 13:04, Sam Steingold <sd...@gn...> wrote: >> Should I send a patch that consists in creating a new subdirectory of >> modules? Would you accept it? If so, which existing module may I >> cargo-cult, considering that ASDF is one single lisp file? > > Oh, you want _us_ to ship asdf... Yes, that would be great. > do people want that? With asdf2, unlike asdf1, you can easily upgrade from some asdf to another one, so if someone isn't fully satisfied with the clisp-provided asdf, he can still use it to portably upgrade to his installed asdf as easily as: (require :asdf) (asdf:load-system :asdf) With asdf1, you were kind of stuck, and indeed the case for including yet another divergent version of asdf with the implementation was less compelling. > if yes, should it be a base module? > (http://clisp.cons.org/impnotes/modules.html#base-modules) I think it should be indeed. > do other lisps come with asdf ootb? > (I know sbcl does, how about gcl, ecl, abcl &c) At least ABCL, CCL, CMUCL, ECL, SBCL include asdf2 ootb. ASDF2 unlike ASDF1 now works with GCL 2.7 (but doesn't pass all regression tests), and I should indeed contact the authors for inclusion, too. > PS. a quick look at #+clisp on asdf.lisp reveals the following: > getenv: I suggest (import 'ext:genenv) instead of (defun getenv) I don't want to import in some implementations, not in others. For portability reasons, I prefer a symbol with uniform semantics everywhere, including symbol package and bound function semantics. Too bad if you can't (setf (asdf-utilities:getenv "FOO") "bar") on clisp - you shouldn't be relying on it portably, anyway. > get-uid: I suggest (setf fdefinition) instead of defun Same here. > probe-file*: I suggest probe-pathname instead of (ignore-errors (truename > p)) Oh, thanks a lot. Base on that feedback, I committed asdf 2.113. Can you test it? If it works for you, I'll release it as 2.005 so you may include the latest stable release to clisp. (Though I'll also offer the GCL guys to provide feedback.) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] None are more hopelessly enslaved than those who falsely believe they are free. — Johann Wolfgang von Goethe |
From: Faré <fa...@gm...> - 2010-08-03 23:14:24
|
While I'm at it - ABCL, CCL, CMUCL, ECL, SBCL all have a hook whereby cl:require will attempt loading modules via ASDF. It would be nice if CLISP offered the same facility. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré] On 3 August 2010 18:40, Faré <fa...@gm...> wrote: > Dear Sam, > > thanks for the quick answer. > > On 3 August 2010 13:04, Sam Steingold <sd...@gn...> wrote: >>> Should I send a patch that consists in creating a new subdirectory of >>> modules? Would you accept it? If so, which existing module may I >>> cargo-cult, considering that ASDF is one single lisp file? >> >> Oh, you want _us_ to ship asdf... > Yes, that would be great. > >> do people want that? > With asdf2, unlike asdf1, you can easily upgrade from some asdf to > another one, so if someone isn't fully satisfied with the > clisp-provided asdf, he can still use it to portably upgrade to his > installed asdf as easily as: > (require :asdf) > (asdf:load-system :asdf) > With asdf1, you were kind of stuck, and indeed the case for including > yet another divergent version of asdf with the implementation was less > compelling. > >> if yes, should it be a base module? >> (http://clisp.cons.org/impnotes/modules.html#base-modules) > I think it should be indeed. > >> do other lisps come with asdf ootb? >> (I know sbcl does, how about gcl, ecl, abcl &c) > At least ABCL, CCL, CMUCL, ECL, SBCL include asdf2 ootb. > ASDF2 unlike ASDF1 now works with GCL 2.7 (but doesn't pass all > regression tests), > and I should indeed contact the authors for inclusion, too. > >> PS. a quick look at #+clisp on asdf.lisp reveals the following: >> getenv: I suggest (import 'ext:genenv) instead of (defun getenv) > I don't want to import in some implementations, not in others. For > portability reasons, I prefer a symbol with uniform semantics > everywhere, including symbol package and bound function semantics. Too > bad if you can't (setf (asdf-utilities:getenv "FOO") "bar") on clisp - > you shouldn't be relying on it portably, anyway. > >> get-uid: I suggest (setf fdefinition) instead of defun > Same here. > >> probe-file*: I suggest probe-pathname instead of (ignore-errors (truename >> p)) > Oh, thanks a lot. > > Base on that feedback, I committed asdf 2.113. Can you test it? If it > works for you, I'll release it as 2.005 so you may include the latest > stable release to clisp. (Though I'll also offer the GCL guys to > provide feedback.) > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > None are more hopelessly enslaved than those who falsely believe they are free. > — Johann Wolfgang von Goethe > |
From: Sam S. <sd...@gn...> - 2010-08-09 20:18:36
|
Faré wrote: > > what should I do if I want to include ASDF 2 in CLISP? 1. clisp issues many more warnings than other lisps. a clisp warning during compilation in now way indicates that the compilation failed. for clisp, the right check is whether the fas file has been created. 2. these messages are confusing: WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL #x00033447F440> on #<CL-SOURCE-FILE "grid" "specification">. WARNING: COMPILE-FILE failed while performing #<COMPILE-OP NIL #x00033447F440> on #<CL-SOURCE-FILE "grid" "specification">. because no actual clisp warning is printed to the screen. I am not sure where I should report these bugs, so I am reporting them here to you. thanks. Sam. |
From: Faré <fa...@gm...> - 2010-08-11 15:29:13
|
Dear Sam, On 9 August 2010 16:18, Sam Steingold <sd...@gn...> wrote: >> what should I do if I want to include ASDF 2 in CLISP? > > 1. clisp issues many more warnings than other lisps. a clisp warning during > compilation in now way indicates that the compilation failed. > for clisp, the right check is whether the fas file has been created. > The way the spec reads, an outright WARNING shall be considered as a failure, though a STYLE-WARNING isn't. If there are CLISP WARNINGs that shouldn't be considered as failures, then they should probably be made into STYLE-WARNINGs instead. That said, if it is a policy that CLISP should issue lots of warnings, we could conditionally modify the defaults for *compile-file-warnings-behaviour* and *compile-file-failure-behaviour*. > 2. these messages are confusing: > > WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL > #x00033447F440> > on #<CL-SOURCE-FILE "grid" "specification">. > WARNING: COMPILE-FILE failed while performing #<COMPILE-OP NIL > #x00033447F440> > on #<CL-SOURCE-FILE "grid" "specification">. > > because no actual clisp warning is printed to the screen. > That's weird. When you trace COMPILE-FILE, what does it return as secondary and tertiary values? > I am not sure where I should report these bugs, so I am reporting them here > to you. asdf-devel and/or the launchpad.net for asdf are the places to report bugs about ASDF. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I've never been able to figure out for _whom_ we're saving the irreplaceable resources. If _we_ aren't allowed to use them, then the next generation shouldn't use them either, nor the one after that. — Harry Browne (HIFFIAUW) |
From: Sam S. <sd...@gn...> - 2010-08-11 15:40:37
|
Dear François-René, Faré wrote: > > On 9 August 2010 16:18, Sam Steingold <sd...@gn...> wrote: >>> what should I do if I want to include ASDF 2 in CLISP? >> 1. clisp issues many more warnings than other lisps. a clisp warning during >> compilation in now way indicates that the compilation failed. >> for clisp, the right check is whether the fas file has been created. >> > The way the spec reads, an outright WARNING shall be considered as a failure, > though a STYLE-WARNING isn't. If there are CLISP WARNINGs that shouldn't be > considered as failures, then they should probably be made into STYLE-WARNINGs > instead. the only reason for this assertion is the _name_ ("failure-p") of the tertiary return value. this does not sound like a solid foundation. > That said, if it is a policy that CLISP should issue lots of warnings, > we could conditionally modify the defaults for > *compile-file-warnings-behaviour* and > *compile-file-failure-behaviour*. fine. Sam. |
From: Faré <fa...@gm...> - 2010-08-11 16:07:04
|
On 11 August 2010 11:40, Sam Steingold <sd...@gn...> wrote: >> The way the spec reads, an outright WARNING shall be considered as a >> failure, >> though a STYLE-WARNING isn't. If there are CLISP WARNINGs that shouldn't >> be >> considered as failures, then they should probably be made into >> STYLE-WARNINGs >> instead. > > the only reason for this assertion is the _name_ ("failure-p") of the > tertiary return value. > this does not sound like a solid foundation. > Sometimes it's best to agree to disagree. I think your interpretation does merit an explicit explanation in the impnotes file, though. Reading the impnotes for COMPILE-FILE, I also notice that you have a :WARNINGS keyword. Maybe ASDF ought to #+clisp :warnings #+clisp (or *compile-verbose* *asdf-verbose*) or something. >> That said, if it is a policy that CLISP should issue lots of warnings, >> we could conditionally modify the defaults for >> *compile-file-warnings-behaviour* and >> *compile-file-failure-behaviour*. > > fine. > Should both be :ignore on CLISP? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey |
From: Sam S. <sd...@gn...> - 2010-08-11 18:28:30
|
Faré wrote: > On 11 August 2010 11:40, Sam Steingold <sd...@gn...> wrote: >>> The way the spec reads, an outright WARNING shall be considered as a >>> failure, >>> though a STYLE-WARNING isn't. If there are CLISP WARNINGs that shouldn't >>> be >>> considered as failures, then they should probably be made into >>> STYLE-WARNINGs >>> instead. >> the only reason for this assertion is the _name_ ("failure-p") of the >> tertiary return value. >> this does not sound like a solid foundation. >> > Sometimes it's best to agree to disagree. I think your interpretation > does merit an explicit explanation in the impnotes file, though. http://clisp.podval.org/impnotes/compilefile.html > Reading the impnotes for COMPILE-FILE, I also notice that you have a > :WARNINGS keyword. Maybe ASDF ought to #+clisp :warnings #+clisp (or > *compile-verbose* *asdf-verbose*) or something. whatever works for you. the point is that if asdf says that compilation failed (or warned) there should be errors (or warnings) on the screen. note that :WARNINGS has its own default variable. >>> That said, if it is a policy that CLISP should issue lots of warnings, >>> we could conditionally modify the defaults for >>> *compile-file-warnings-behaviour* and >>> *compile-file-failure-behaviour*. >> fine. > Should both be :ignore on CLISP? I don't know how they are used by asdf. Sam. |
From: Faré <fa...@gm...> - 2010-08-12 06:22:46
|
On 11 August 2010 14:28, Sam Steingold <sd...@gn...> wrote: >> Sometimes it's best to agree to disagree. I think your interpretation >> does merit an explicit explanation in the impnotes file, though. > http://clisp.podval.org/impnotes/compilefile.html I see it does have an explanation not present in my old 2.48 checkout. Thanks! >> Reading the impnotes for COMPILE-FILE, I also notice that you have a >> :WARNINGS keyword. Maybe ASDF ought to #+clisp :warnings #+clisp (or >> *compile-verbose* *asdf-verbose*) or something. > > whatever works for you. > the point is that if asdf says that compilation failed (or warned) there > should be errors (or warnings) on the screen. > > note that :WARNINGS has its own default variable. > I understand that, but the choice here is either to have a global default independent from ASDF verbosity, or to have ASDF set this parameter depending on its verbosity. >>>> That said, if it is a policy that CLISP should issue lots of warnings, >>>> we could conditionally modify the defaults for >>>> *compile-file-warnings-behaviour* and >>>> *compile-file-failure-behaviour*. >>> >>> fine. >> >> Should both be :ignore on CLISP? > > I don't know how they are used by asdf. > They are used to determine what to do when there's a failure and when there are warnings, respectively, as given from secondary and tertiary values. --#f Pyramid schemes are illegal. Social Security is a pyramid scheme. |
From: Sam S. <sd...@gn...> - 2010-08-12 13:41:10
|
Faré wrote: > On 11 August 2010 14:28, Sam Steingold <sd...@gn...> wrote: >>> Sometimes it's best to agree to disagree. I think your interpretation >>> does merit an explicit explanation in the impnotes file, though. >> http://clisp.podval.org/impnotes/compilefile.html > I see it does have an explanation not present in my old 2.48 checkout. Thanks! > >>> Reading the impnotes for COMPILE-FILE, I also notice that you have a >>> :WARNINGS keyword. Maybe ASDF ought to #+clisp :warnings #+clisp (or >>> *compile-verbose* *asdf-verbose*) or something. I think (or custom:*compile-warnings* *asdf-verbose*) is more reasonable >> whatever works for you. >> the point is that if asdf says that compilation failed (or warned) there >> should be errors (or warnings) on the screen. >> >> note that :WARNINGS has its own default variable. >> > I understand that, but the choice here is either to have a global > default independent > from ASDF verbosity, or to have ASDF set this parameter depending on > its verbosity. I can hardly imagine a situation when a warning or error issued by the implementation should be suppressed by asdf. >>>>> That said, if it is a policy that CLISP should issue lots of warnings, >>>>> we could conditionally modify the defaults for >>>>> *compile-file-warnings-behaviour* and >>>>> *compile-file-failure-behaviour*. >>>> fine. >>> Should both be :ignore on CLISP? >> I don't know how they are used by asdf. >> > They are used to determine what to do when there's a failure and when > there are warnings, respectively, as given from secondary and tertiary > values. what are the valid values for these *behavior* variables? ignore actually sounds fine as long as it means that the value is ignored while the warnings and errors are NOT suppressed. Sam. PS. why does asdf place compiled files in ~/.cache/common-lisp instead of the directory tree which contains the source code? |
From: Faré <fa...@gm...> - 2010-08-12 20:57:10
|
On 12 August 2010 09:41, Sam Steingold <sd...@gn...> wrote: > I think > (or custom:*compile-warnings* *asdf-verbose*) > is more reasonable OK. Or maybe I should leave it to custom:*compile-warnings*, which defaults to T anyway. What do you think? > I can hardly imagine a situation when a warning or error issued by the > implementation should be suppressed by asdf. ASDF certainly shouldn't suppress anything by default. >>>>>> That said, if it is a policy that CLISP should issue lots of warnings, >>>>>> we could conditionally modify the defaults for >>>>>> *compile-file-warnings-behaviour* and >>>>>> *compile-file-failure-behaviour*. >>>> Should both be :ignore on CLISP? >> They are used to determine what to do when there's a failure and when >> there are warnings, respectively, as given from secondary and tertiary >> values. > what are the valid values for these *behavior* variables? > ignore actually sounds fine as long as it means that the value is ignored > while the warnings and errors are NOT suppressed. The valid values are :ignore :warn :error. :error means ASDF will issue an (error ...) after the compilation (default failure behaviour on SBCL), :warn means ASDF will issue a (warn ...)ing , and :ignore means ASDF will proceed happily. In no case does ASDF suppress messages here. Does that change make ASDF 2.116 suitable to you? > PS. why does asdf place compiled files in ~/.cache/common-lisp instead of > the directory tree which contains the source code? > The cache is enabled by default, because that's what allows things to work out of the box with no configuration for most people in most installations, notably where multi-user shared sources or multiple implementations are involved. There's a FAQ on how to disable it. If CLISP needs some exceptions to these translations, for implementation-provided libraries, I can add an entry to the wrapping-output-translations function, according to your specifications. See also function module-provide-asdf if you want CLISP to hook into ASDF for requiring software. (Currently supported by ABCL, ClozureCL, CMUCL, ECL, SBCL.) --#f Being really good at C++ is like being really good at using rocks to sharpen sticks. — Thant Tessman |
From: Faré <fa...@gm...> - 2010-08-17 19:54:25
|
I just released ASDF 2.005. Hopefully, it's good enough to be included as is as part of the base modules of the next CLISP. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Democracy is but government of the busy, by the bully, for the bossy. — Arthur Seldon, "The Dilemma of Democracy" |
From: Sam S. <sd...@gn...> - 2010-09-13 14:55:36
|
Faré wrote: > I just released ASDF 2.005. Hopefully, it's good enough to be included > as is as part of the base modules of the next CLISP. is there a way to get asdf.lisp without cloning the repo? e.g., with svn I can do wget http://svn.gnome.org/svn/gtk+/trunk/m4macros/gtk-2.0.m4 to get the specific file. |
From: Sam S. <sd...@gn...> - 2010-09-13 15:39:04
|
Sam Steingold wrote: > Faré wrote: >> I just released ASDF 2.005. Hopefully, it's good enough to be included >> as is as part of the base modules of the next CLISP. > > is there a way to get asdf.lisp without cloning the repo? > e.g., with svn I can do > wget http://svn.gnome.org/svn/gtk+/trunk/m4macros/gtk-2.0.m4 > to get the specific file. forget it, http://common-lisp.net/project/asdf/asdf.lisp is all I need. |
From: Sam S. <sd...@gn...> - 2010-08-18 22:53:42
|
Faré wrote: > > See also function module-provide-asdf if you want CLISP to hook into > ASDF for requiring software. (Currently supported by ABCL, ClozureCL, > CMUCL, ECL, SBCL.) thanks. http://clisp.podval.org/impnotes/require.html#module-providers diff --git a/asdf.lisp b/asdf.lisp index 4c44af0..1b08beb 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -3435,7 +3435,7 @@ with a different configuration, so the configuration would be re-read then." ;;;; ----------------------------------------------------------------- ;;;; Hook into REQUIRE for ABCL, ClozureCL, CMUCL, ECL and SBCL ;;;; -#+(or abcl clozure cmu ecl sbcl) +#+(or abcl clozure clisp cmu ecl sbcl) (progn (defun* module-provide-asdf (name) (handler-bind @@ -3452,6 +3452,7 @@ with a different configuration, so the configuration would be re-read then." (pushnew 'module-provide-asdf #+abcl sys::*module-provider-functions* #+clozure ccl:*module-provider-functions* + #+clisp custom:*module-provider-functions* #+cmu ext:*module-provider-functions* #+ecl si:*module-provider-functions* #+sbcl sb-ext:*module-provider-functions*)) also, mk:defsystem provides :initially-do, :finally-do, system-source-size, files-in-system - any plans to add these to asdf? they are used in clocc/cllib/cllib.system to print the number of files which have to be recompiled. |
From: Sam S. <sd...@gn...> - 2010-08-18 22:55:00
|
Faré wrote: > See also function module-provide-asdf if you want CLISP to hook into > ASDF for requiring software. (Currently supported by ABCL, ClozureCL, > CMUCL, ECL, SBCL.) oops. diff --git a/asdf.lisp b/asdf.lisp index 4c44af0..f81f6b7 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -3433,9 +3433,9 @@ with a different configuration, so the configuration would be re-read then." :when file :return file)) ;;;; ----------------------------------------------------------------- -;;;; Hook into REQUIRE for ABCL, ClozureCL, CMUCL, ECL and SBCL +;;;; Hook into REQUIRE for ABCL, CLISP, ClozureCL, CMUCL, ECL and SBCL ;;;; -#+(or abcl clozure cmu ecl sbcl) +#+(or abcl clozure clisp cmu ecl sbcl) (progn (defun* module-provide-asdf (name) (handler-bind @@ -3452,6 +3452,7 @@ with a different configuration, so the configuration would be re-read then." (pushnew 'module-provide-asdf #+abcl sys::*module-provider-functions* #+clozure ccl:*module-provider-functions* + #+clisp custom:*module-provider-functions* #+cmu ext:*module-provider-functions* #+ecl si:*module-provider-functions* #+sbcl sb-ext:*module-provider-functions*)) |
From: Sam S. <sd...@gn...> - 2010-09-13 16:09:00
|
Faré wrote: > I just released ASDF 2.005. Hopefully, it's good enough to be included > as is as part of the base modules of the next CLISP. adding asdf increases base memory image size by 10%, from 3616k to 4024k. while this is not necessarily a show-stopper, it does give me a pause. [I don't think make(1) takes 10% of a unix system :-)] these 10% are not needed for users who run applications (distributed as an executable memory image), and removing asdf appears to be incomplete: after (delete-package "ASDF") and (setq *module-provider-functions* nil), GC reclaims only 3/4 of the additional space; the image is 3712k (Bruno, do you have any idea why this is happening?) Thus I am reluctant to add asdf as a base image. I see no problem with adding it as a regular image; then people who want to use it can just do (require "asdf") and it will be loaded. any thoughts? |
From: Faré <fa...@gm...> - 2010-09-14 23:46:10
|
> Thus I am reluctant to add asdf as a base image. > I see no problem with adding it as a regular image; then people who want to > use it can just do (require "asdf") and it will be loaded. > Yes, it's better if asdf is not in the base image but only available when you (require :asdf). That way, if someone for whatever reason wants to load his own incompatible replacement, he can. Also, I'd like to make (require :asdf) the "normal" way to load asdf. It's already the case on ccl sbcl ecl abcl cmucl scl. PS: current stable release is 2.008. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Corollaries to the Law of Bitur-Camember: The political process destroys the value of all known resources that are up for grabs. The socialist process of systematically denying legitimacy to property rights applies the political process universally and destroys the value of all available resources. |