asdf issueshttps://gitlab.common-lisp.net/asdf/asdf/-/issues2019-04-02T00:10:49Zhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/5Review Vsevolod Dyomkin's extensions to system versioning2019-04-02T00:10:49ZRobert GoldmanReview Vsevolod Dyomkin's extensions to system versioningSee the [GitHub repository](https://github.com/vseloved/asdf2-versions) and see also the critiques of ASDF in [slides](https://european-lisp-symposium.org/static/2017/domkin.pdf).See the [GitHub repository](https://github.com/vseloved/asdf2-versions) and see also the critiques of ASDF in [slides](https://european-lisp-symposium.org/static/2017/domkin.pdf).https://gitlab.common-lisp.net/asdf/asdf/-/issues/12How to include UIOP (but not ASDF) in a build from monolithic fasls2021-07-26T16:19:52ZDave CooperHow to include UIOP (but not ASDF) in a build from monolithic faslsHi,
I'm making builds from monolithic-compile-bundles, and want to include UIOP in these builds but not ASDF.
Here's what I am doing to achieve it:
1. Place `asdf.lisp` version 3.3.3 (built from ASDF 3.3.3 tarball with `make`) in `qu...Hi,
I'm making builds from monolithic-compile-bundles, and want to include UIOP in these builds but not ASDF.
Here's what I am doing to achieve it:
1. Place `asdf.lisp` version 3.3.3 (built from ASDF 3.3.3 tarball with `make`) in `quicklisp/`
2. Edit `quicklisp/setup.lisp` to specify `*required-asdf-version* 3.3.3`
3. Place a copy of current uiop/ directory, with uiop/uiop.asd, from the ASDF 3.3.3 tarball, in quicklisp/local-projects/.
4. For the past couple years I've had to tweak the check-not-old-asdf-system function to return T for uiop. Otherwise,
(asdf:system-source-directory :uiop)
returns nil, and we get an assertion failure on
(asdf:output-file 'asdf:monolithic-compile-bundle-op :uiop)
I have to tweak the first line to be
```
;;(not (member name '("asdf" "uiop") :test 'equal))
(not (member name '("asdf") :test 'equal))
```
Is there a better way to go about getting UIOP but not ASDF included in a built executable?
Thanks,
Dave
Is there ahttps://gitlab.common-lisp.net/asdf/asdf/-/issues/19Test on non-standard platforms2020-02-27T16:25:50ZRobert GoldmanTest on non-standard platformsThe current ASDF tests only work on Unix-like systems, since they are based on `make` and `bash`.
For other lisps, including lisp on Windows, Mezzano's Lisp, and Genera, this is unsatisfactory (though on Windows, at least, we can work a...The current ASDF tests only work on Unix-like systems, since they are based on `make` and `bash`.
For other lisps, including lisp on Windows, Mezzano's Lisp, and Genera, this is unsatisfactory (though on Windows, at least, we can work around using Cygwin.
@frideau built a lisp-based test framework, but it relied on a library that essentially provided a partial implementation of shell scripting, and when it failed, I was simply unable to debug failures (which often involved a failure inside a lisp process started by another lisp process). Also, we didn't have the resources to develop a fully satisfactory scripting language for the purpose.
Working through a container system like Docker might work (although I don't believe that is necessarily feasible for either Mezzano or Genera), and @mherda suggests using SWANK as a way of communicating with the system under test.
/cc @mherdahttps://gitlab.common-lisp.net/asdf/asdf/-/issues/21test-bundle.script is unstable2020-05-18T21:34:10ZRobert Goldmantest-bundle.script is unstableSometimes it fails, and then succeeds on re-running.
I conjecture that it is not cleaning up after itself adequately.Sometimes it fails, and then succeeds on re-running.
I conjecture that it is not cleaning up after itself adequately.https://gitlab.common-lisp.net/asdf/asdf/-/issues/26Behavior of `ASDF:SYSTEM-RELATIVE-PATHNAME` counter-intuitive for secondary s...2020-02-09T17:42:53ZRobert GoldmanBehavior of `ASDF:SYSTEM-RELATIVE-PATHNAME` counter-intuitive for secondary systems`(ASDF:SYSTEM-RELATIVE-PATHNAME "FOO/BAR" "BAZ.LISP")` returns `"...FOO/BAZ.LISP"` rather than `"..FOO/BAR/BAZ.LISP"`.
When one thinks about the fact that what this function does might better be called `asdf:system-DEFINITION-relative-p...`(ASDF:SYSTEM-RELATIVE-PATHNAME "FOO/BAR" "BAZ.LISP")` returns `"...FOO/BAZ.LISP"` rather than `"..FOO/BAR/BAZ.LISP"`.
When one thinks about the fact that what this function does might better be called `asdf:system-DEFINITION-relative-pathname`, this behavior seems quite obvious and expected. But that is not what the function is called, and IMO it would be both more intuitive *and* more useful if its behavior was modified to return a pathname relative to the location of the *system* rather than the system *definition*, even at the expense of a little backwards-incompatibility.https://gitlab.common-lisp.net/asdf/asdf/-/issues/32Revitalize the syntax-control branch2021-03-03T21:46:47ZRobert GoldmanRevitalize the syntax-control branchUpdate !86 through rebasing and move towards including it.
Add global configuration of some sort so that ASDF defaults to *not* imposing syntax control, but users can turn it on.Update !86 through rebasing and move towards including it.
Add global configuration of some sort so that ASDF defaults to *not* imposing syntax control, but users can turn it on.https://gitlab.common-lisp.net/asdf/asdf/-/issues/33Add DEFSYSTEM option to load in a clean READTABLE2020-05-27T14:44:01ZRobert GoldmanAdd DEFSYSTEM option to load in a clean READTABLEThanks to Luis Oliveira for the suggestion:
> Let an ASDF system opt in for a pristine standard readtable. This seems similar to using named-readtables but it'd probably be more convenient and wouldn't require adding a dependency on na...Thanks to Luis Oliveira for the suggestion:
> Let an ASDF system opt in for a pristine standard readtable. This seems similar to using named-readtables but it'd probably be more convenient and wouldn't require adding a dependency on named-readtables.
/cc @loliveira @mherdahttps://gitlab.common-lisp.net/asdf/asdf/-/issues/36test-run-program fails on MacOS and ECL2021-03-21T18:44:11ZRobert Goldmantest-run-program fails on MacOS and ECLWhen I try to run this test, I robustly get this error:
```
TEST ABORTED: Reader error in file #<input stream #P"/Users/rpg/lisp/asdf/test/test-run-program.script" 0x1085383c0>, position 12148:
Unmatched right parenthesis, #\)
Backtrace...When I try to run this test, I robustly get this error:
```
TEST ABORTED: Reader error in file #<input stream #P"/Users/rpg/lisp/asdf/test/test-run-program.script" 0x1085383c0>, position 12148:
Unmatched right parenthesis, #\)
Backtrace:
0: (#:G2546 NIL)
1: (UIOP/STREAM:CALL-WITH-SAFE-IO-SYNTAX #(140732800802400 4432251840 140732800802336))
2: (UIOP/IMAGE:PRINT-BACKTRACE NIL)
3: (UIOP/IMAGE:PRINT-CONDITION-BACKTRACE #(1 4432255552 140732800803336))
4: (#<bytecompiled-function ASDF-TEST:ACALL 0x107994190> ((ASDF-TEST::ARGS #<a SI::SIMPLE-READER-ERROR 0x1088aa440> :COUNT 69 :STREAM #<output file "stdout" 0x1077ddc80>) (ASDF-TEST::NAME . :PRINT-CONDITION-BACKTRACE)))
5: (#<bytecompiled-function 0x107a56a00> ((416 . 0) (#:G133) (415 . #:G132) (ASDF-TEST::C . #<a SI::SIMPLE-READER-ERROR 0x1088aa440>) (:ASDF-TEST-DONE . :ASDF-TEST-DONE) (ASDF-TEST::THUNK . #<bytecompiled-closure #<bytecompiled-function 0x107c02870>>)))
6: (#<bytecompiled-function 0x107c02870> ((ASDF-TEST::NAME . "test-run-program.script") (ASDF-TEST::FILE . ASDF-TEST::|test-run-program.script|)))
7: (#<bytecompiled-function ASDF-TEST::CALL-WITH-TEST 0x107a56640> ((:ASDF-TEST-DONE . :ASDF-TEST-DONE) (ASDF-TEST::THUNK . #<bytecompiled-closure #<bytecompiled-function 0x107c02870>>)))
8: (#<bytecompiled-function ASDF-TEST:RUN-TEST-SCRIPT 0x107c02820> ((ASDF-TEST::FILE . ASDF-TEST::|test-run-program.script|)))
9: (#<bytecompiled-function SI:BYTECODES 0x108652190> NIL)
10: (#<bytecompiled-function SI:BYTECODES 0x107994870> ((SI::OUTPUT-FILE . T) (SI::C-FILE) (SI::H-FILE) (SI::DATA-FILE) (SI::VERBOSE . T) (SI::SYSTEM-P) (EXT:QUIT)))
11: (#<bytecompiled-function SI:BYTECODES 0x1079948c0> NIL)
12: (NIL NIL)
Above backtrace due to this condition:
Reader error in file #<input stream #P"/Users/rpg/lisp/asdf/test/test-run-program.script" 0x1085383c0>, position 12148:
Unmatched right parenthesis, #\)
Script failed
Using ecl, test-run-program.script failed
```
I do *not* get this error loading the file in the REPL with SLIME.
I *do* get it running the test through `make test l=ecl t=test-run-program.script` and `run-tests.sh ecl test-run-program.script`.
@frideau Any clues? This actually looks like some kind of error with parsing the .script file in ECL, but again, it does not happen in the REPL.https://gitlab.common-lisp.net/asdf/asdf/-/issues/43Suggestion for default validation in UIOP:DELETE-DIRECTORY-TREE2020-09-08T14:51:05ZLuís OliveiraSuggestion for default validation in UIOP:DELETE-DIRECTORY-TREEI think it would be safer if `uiop:delete-directory-tree` would refuse to delete relative pathnames such as `#p""`.
Also, could you clarify what sort of validation one might do with the `:validate` argument? It's unclear what it could b...I think it would be safer if `uiop:delete-directory-tree` would refuse to delete relative pathnames such as `#p""`.
Also, could you clarify what sort of validation one might do with the `:validate` argument? It's unclear what it could be used for.https://gitlab.common-lisp.net/asdf/asdf/-/issues/50The dictatorship of versioning2021-04-18T21:18:48ZEric TimmonsThe dictatorship of versioningApologies to Didier for stealing the subject of his [email chain from
2015](https://mailman.common-lisp.net/pipermail/asdf-devel/2015-June/004698.html),
but it pretty accurately sums up my feelings on the subject as well!
I'm very inter...Apologies to Didier for stealing the subject of his [email chain from
2015](https://mailman.common-lisp.net/pipermail/asdf-devel/2015-June/004698.html),
but it pretty accurately sums up my feelings on the subject as well!
I'm very interested in getting the changes over the finish line needed to allow
more expressive version strings in ASDF systems. From what I can gather on that
email thread and the [discussion on
launchpad](https://bugs.launchpad.net/asdf/+bug/1465709), the approach proposed
at the time was basically:
1. Add a new GF (`normalize-component-version`). The ASDF supplied method would
fall back to the existing `normalize-version` and it could be overridden by
user's system classes.
2. There would be no constraint that `normalize-component-version` returned a
string; it could be an arbitrary object that would also be returned by
`component-version`.
3. A new GF (`aesthetic-version` or `version-display-string`) would be added to
provide a stringified form of the contents of the `version` slot.
4. `version-satisifes` is already a GF and doesn't need any changes.
I think such a protocol could still work, but I'm hesitant, as since then
`component-version` was explicitly documented to provide a string of dot
separated natural numbers or nil (by 156a8013). So having `component-version`
return an arbitrary object may break user code that analyzes versions and
they'd be (rightfully) upset.
To deal with that, I'm wondering if we should add a GF named
`component-raw-version` that returns the contents of the `version` slot. Then
`component-version` would either return the output of `version-display-string`
if it meets the requirements or nil otherwise. Then in ASDF4,
`component-version` would go back to just returning the value of the slot and
`component-raw-version` would be removed.https://gitlab.common-lisp.net/asdf/asdf/-/issues/58ASDF:LOAD-ASD does not fail on non-existent paths2021-02-23T22:49:05ZTim LeeASDF:LOAD-ASD does not fail on non-existent paths`ASDF:LOAD-ASD` does not fail when I give it non-existent paths. For example:
```
$ sbcl --noinform
* (require :asdf)
("ASDF" "asdf" "U...`ASDF:LOAD-ASD` does not fail when I give it non-existent paths. For example:
```
$ sbcl --noinform
* (require :asdf)
("ASDF" "asdf" "UIOP" "uiop")
* (asdf:asdf-version)
"3.3.1"
* (asdf:load-asd "/bla/bla/bla")
#<ASDF/FIND-SYSTEM:DEFINE-OP >
#<ASDF/PLAN:SEQUENTIAL-PLAN {10027E94B3}>
*
```https://gitlab.common-lisp.net/asdf/asdf/-/issues/59Cannot pass a binary stream as :INPUT to UIOP:RUN-PROGRAM2021-03-18T23:16:00ZSean WhittonCannot pass a binary stream as :INPUT to UIOP:RUN-PROGRAMHello,
I am on Debian "bullseye", SBCL 2.1.1.
If I call UIOP:RUN-PROGRAM like this
(with-open-file (s "foo.gz" :element-type '(unsigned-byte 8))
(run-program "cat >/home/spwhitton/tmp/blah" :force-shell t :input s))
then ...Hello,
I am on Debian "bullseye", SBCL 2.1.1.
If I call UIOP:RUN-PROGRAM like this
(with-open-file (s "foo.gz" :element-type '(unsigned-byte 8))
(run-program "cat >/home/spwhitton/tmp/blah" :force-shell t :input s))
then I get an error, however it works fine if I do this:
(run-program "cat >/home/spwhitton/tmp/blah" :force-shell t :input #P"foo.gz")
It seems to me like it ought to be possible to provide a binary stream if it possible to provide a binary file. I believe :ELEMENT-TYPE is irrelevant here as that is for output streams, but I did try setting it and it does not help.
Taking a look at the source, the cause of this seems to be that UIOP:RUN-PROGRAM calls UIOP:COPY-STREAM-TO-STREAM with no :ELEMENT-TYPE argument, so UIOP:COPY-STREAM-TO-STREAM tries to read characters from the provided binary stream.
Thanks!https://gitlab.common-lisp.net/asdf/asdf/-/issues/60[Feature request] Allow specifying minimum ASDF version in a .asd file2021-03-02T01:06:45ZStelian Ionescu[Feature request] Allow specifying minimum ASDF version in a .asd fileI propose adding a new top-level form allowed in .asd files, preferably as the first form:
(require-version min &optional max)
MIN and MAX are version strings and represent the lower and upper bounds permitted. If MAX is NIL then the u...I propose adding a new top-level form allowed in .asd files, preferably as the first form:
(require-version min &optional max)
MIN and MAX are version strings and represent the lower and upper bounds permitted. If MAX is NIL then the upper bounds check is skipped. If the ASDF version falls outside this interval then a user-friendly error will be signalled.
This proposal is backwards-compatible, because older ASDF versions won't recognize the form and signal an error nevertheless (even though perhaps not user-friendly).https://gitlab.common-lisp.net/asdf/asdf/-/issues/63Avoid complaining about unknown component types, when unused2021-03-19T15:42:40ZDidier VernaAvoid complaining about unknown component types, when unusedHello,
Consider a component defined as follows:
`(:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks))`
In a Lisp which is not going to use it (e.g. SBCL here), ASDF will still complain that the component ty...Hello,
Consider a component defined as follows:
`(:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks))`
In a Lisp which is not going to use it (e.g. SBCL here), ASDF will still complain that the component type is unknown, so you still need to guard this component with
`#+(or allegro clisp lispworks)`
In principle, ASDF should be able to parse the system definition, see the if-feature here and avoid complaining, as there is no read-time problem for parsing.https://gitlab.common-lisp.net/asdf/asdf/-/issues/65collect-sub*directories fails on a tree with a symlink to a parent directory2021-04-22T01:50:24Zfitzsimcollect-sub*directories fails on a tree with a symlink to a parent directoryHello,
I was trying to use `collect-sub*directories` to traverse a _Yocto_
build tree. The older _SBCL_ I was using crashed, so I started
investigating.
It turns out the _Yocto_ tree contained valid/necessary directory
structures like...Hello,
I was trying to use `collect-sub*directories` to traverse a _Yocto_
build tree. The older _SBCL_ I was using crashed, so I started
investigating.
It turns out the _Yocto_ tree contained valid/necessary directory
structures like this:
```
.../dir/
.../dir/subdir -> .
```
This pattern causes `collect-sub*directories` to recurse until a
resource limit is hit. For example, _CLISP_ produces:
```
[...]
Running test/test-symlink-loop-2.script with clisp-2.49.92-unix-ppc64le
Testing sub-directory linking to its parent directory.
*** - Program stack overflow. RESET
Aborted
```
The attached patch set introduces a failing test case to demonstrate
the issue, then fixes it. It turns out a similar issue was already
solved for `collect-sub*directories-asd-files`
(https://bugs.launchpad.net/asdf/+bug/1533766); these patches move the
visited file tracking logic to `collect-sub*directories`.
As a prerequisite, I attempted to improve symlink handling in
`directory*` and `subdirectories` for _CLISP_.
I tested these patches with: `make -f Makefile-lisp-scripting t l=$L`
on _GNU CLISP 2.49.92 (2018-02-18)_ and _SBCL 2.1.1.debian_.
I'm interested to run them through the CI/CD pipeline to see how
portable the changes are to other implementations.
[0001-Add-a-test-for-directory-symlink-handling.patch](/uploads/0dd3d32547d132df26f6f9c8395951a1/0001-Add-a-test-for-directory-symlink-handling.patch)
[0002-Improve-directory-symlink-handling-on-CLISP.patch](/uploads/7ba163569cc8851218d41065df4d97d8/0002-Improve-directory-symlink-handling-on-CLISP.patch)
[0003-Add-a-collect-sub-directories-symlink-test.patch](/uploads/b05b1683366e3be6ac9a30d3fb87e1a9/0003-Add-a-collect-sub-directories-symlink-test.patch)
[0004-Fix-subdirectories-wildcard-on-CLISP.patch](/uploads/fb2eb293236598232607148edab57523/0004-Fix-subdirectories-wildcard-on-CLISP.patch)
[0005-Track-visited-subdirectories-in-collect-sub-director.patch](/uploads/e8aca0a8aa9d862ef439c3e4a6c43dda/0005-Track-visited-subdirectories-in-collect-sub-director.patch)
[0006-Simplify-collect-sub-directories-asd-files.patch](/uploads/284eca3191ecd9493f3d5e1e450dd96e/0006-Simplify-collect-sub-directories-asd-files.patch)https://gitlab.common-lisp.net/asdf/asdf/-/issues/67"keywords" parameter in ASDF defsystem?2021-05-03T14:05:06ZMariano Montone"keywords" parameter in ASDF defsystem?Hello,
is there any chance of introducing a 'keywords' parameter to ASDF system definitions?
It is present in almost every package system.
I mean, this: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#keywords
I have plans...Hello,
is there any chance of introducing a 'keywords' parameter to ASDF system definitions?
It is present in almost every package system.
I mean, this: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#keywords
I have plans to use it for documentation, and discoverability of Lisp packages.https://gitlab.common-lisp.net/asdf/asdf/-/issues/68package-inferred-system: declaring external dependencies2022-01-07T22:28:28ZAntonis Kanouraspackage-inferred-system: declaring external dependenciesHello,
when using package-inferred-system and (uiop:define-package), I would like to be able to declare that a subsystem depends on an external system without :using/:mixing/:importing-from the external system's package and, if possible...Hello,
when using package-inferred-system and (uiop:define-package), I would like to be able to declare that a subsystem depends on an external system without :using/:mixing/:importing-from the external system's package and, if possible, not using (asdf:register-system-packages) in the main .asd file.
I'm abusing :import-from like "(:import-from :cxml) (:import-from :xpath)" atm, but the problem is that import-from refers to packages, not systems, apart from the fact that it's abusing the liberal syntax of the declaration.
Would a patch adding support for (uiop:define-package ... (:depends-on(-system?) <external-system>) ...) to UIOP and ASDF be acceptable?
Thank you for your work!https://gitlab.common-lisp.net/asdf/asdf/-/issues/69Defsystem grammar ill-formatted in Info2021-05-06T17:08:48ZRobert GoldmanDefsystem grammar ill-formatted in InfoThe cross-references here are done wrong so that the defsystem grammar does not display properly in Info. For example:
![image](/uploads/b8d75e94083f55f79e022cad92da648b/image.png)
Pay particular attention to the bottom three lines.The cross-references here are done wrong so that the defsystem grammar does not display properly in Info. For example:
![image](/uploads/b8d75e94083f55f79e022cad92da648b/image.png)
Pay particular attention to the bottom three lines.https://gitlab.common-lisp.net/asdf/asdf/-/issues/70Support multi-line strings in defsystem metadata with FORMAT's tilde operator2021-05-11T15:27:13ZRobert GoldmanSupport multi-line strings in defsystem metadata with FORMAT's tilde operatorPutting multi-line metadata into an ASDF defsystem, if you don't want hard line breaks, is ugly. We could get around this by adding support for tilde-newline sequences a la `format`.
Alternatively, we could just accept multi-line strin...Putting multi-line metadata into an ASDF defsystem, if you don't want hard line breaks, is ugly. We could get around this by adding support for tilde-newline sequences a la `format`.
Alternatively, we could just accept multi-line strings and reflow them, but that seems harder -- we would need to be careful to honor double-newlines.
Request for comments.https://gitlab.common-lisp.net/asdf/asdf/-/issues/71Defsystem grammar dependency-def bug2021-05-13T15:22:25ZEric TimmonsDefsystem grammar dependency-def bugI think the rule for dependency-def is incorrect.
```
# This is used in :depends-on, as opposed to "dependency", which is used
# in :in-order-to
dependency-def := simple-component-name
| ( :feature feature-expression dep...I think the rule for dependency-def is incorrect.
```
# This is used in :depends-on, as opposed to "dependency", which is used
# in :in-order-to
dependency-def := simple-component-name
| ( :feature feature-expression dependency-def ) # see Feature dependencies
| ( :version simple-component-name version-specifier )
| ( :require module-name )
```
As far as I know, there is no requirement that `simple-component-name` (no slashes allowed) must be used for a system level `:depends-on`. I can believe there's such a requirement for component level `:depends-on`, though.https://gitlab.common-lisp.net/asdf/asdf/-/issues/73Tests occasionally hang in CI2021-06-04T00:53:59ZEric TimmonsTests occasionally hang in CILet's consolidate the various discussions about this issue here.
When running in CI, some regression tests occasionally stop making progress and sit there until the job times out (1 hour). If this happens, a single retry is typically en...Let's consolidate the various discussions about this issue here.
When running in CI, some regression tests occasionally stop making progress and sit there until the job times out (1 hour). If this happens, a single retry is typically enough to get the job to finish. This happens the most frequently with CCL:
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/11721>
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/13812>
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/13768>
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/13987>
It also happens occasionally with ECL:
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/13499>
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/13441>
- <https://gitlab.common-lisp.net/asdf/asdf/-/jobs/15746>
CCL seems to stop making progress at <https://gitlab.common-lisp.net/asdf/asdf/-/blob/3e24bb1cda1a5de7349604841588d08681ebd6c6/test/test-program.script#L120> and ECL seems to stop making progress at <https://gitlab.common-lisp.net/asdf/asdf/-/blob/3e24bb1cda1a5de7349604841588d08681ebd6c6/test/test-run-program-unix.script#L447>
I've been unable to reproduce locally by running `make td l=ccl t=test-program.script` over 400 times (after removing the `--pull always` from the Makefile so I don't run afoul of Docker Hub rate limiting) under both light and heavy loads. This suggests it's something specific about the CI runner environment.
Both of them hang when child processes are started. One known issue about running in Docker is that the default configuration sets an extremely high `ulimit -n` (file descriptors). We previously had issues with this and SBCL because SBCL iterates over all possible file descriptors and tries to close them. This resulted in new processes taking a very long time to spawn (see: c248f41d). It would not surprise me if we're running into a similar issue here with a combination of host characteristics and Docker defaults interacting badly with some implementations.
I propose we focus on CCL first since that happens the most frequently. Plus if we get it fixed by changing the test environment, it may fix ECL as well.https://gitlab.common-lisp.net/asdf/asdf/-/issues/75Add :default-module-class property to systems2021-06-03T14:34:18ZRobert GoldmanAdd :default-module-class property to systemsThis would be a parallel to `:default-component-class` See !176
Make sure that a cross-reference appears in the documents for `class-for-type`.This would be a parallel to `:default-component-class` See !176
Make sure that a cross-reference appears in the documents for `class-for-type`.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/76Export system parsing functions from :asdf/interface2021-10-18T13:54:52ZEric TimmonsExport system parsing functions from :asdf/interfaceExport the functions used to parse systems from the `:asdf/interface` package.
That currently consists of:
+ `parse-component-form`
+ `compute-component-children`
+ `class-for-type`
Make sure to remove the experimental warning from `P...Export the functions used to parse systems from the `:asdf/interface` package.
That currently consists of:
+ `parse-component-form`
+ `compute-component-children`
+ `class-for-type`
Make sure to remove the experimental warning from `Parsing system definitions` section of documentation.
See !1763.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/77Rename default branch to main?2021-06-04T15:59:49ZEric TimmonsRename default branch to main?There's work to make it the default in many places, including Gitlab and git itself. If we're going to do it, the start of 3.4 development seems like a perfect time.There's work to make it the default in many places, including Gitlab and git itself. If we're going to do it, the start of 3.4 development seems like a perfect time.https://gitlab.common-lisp.net/asdf/asdf/-/issues/78`uiop/filesystem` functions pass string arguments to `cl:pathname` instead of...2021-06-07T02:19:38ZPhoebe Goldman`uiop/filesystem` functions pass string arguments to `cl:pathname` instead of `ensure-pathname`It's unclear to me whether this is intended behavior or not, but in either case it appears undocumented:
If you have a directory named `/[foo`, which is a valid unix path but an invalid `logical-pathname`, then `(uiop:subdirectories "/[...It's unclear to me whether this is intended behavior or not, but in either case it appears undocumented:
If you have a directory named `/[foo`, which is a valid unix path but an invalid `logical-pathname`, then `(uiop:subdirectories "/[foo")` will signal an error (of type `sb-kernel:namestring-parse-error` on sbcl), whereas `(uiop:subdirectories (uiop:ensure-pathname "/[foo"))` will work without issue.
This appears to be because various functions e.g. `uiop:ensure-absolute-pathname` have `cond` clauses like
```
((stringp path) (ensure-absolute-pathname (pathname path) defaults on-error))
```
which calls `cl:pathname` on string arguments. I believe this to be a bug.https://gitlab.common-lisp.net/asdf/asdf/-/issues/79with-expected-failure correct?2021-06-06T00:28:20ZRobert Goldmanwith-expected-failure correct?I don't think that `with-expected-failure` (in "script-support.lisp") does what it should -- at least not what I expect it should (and that's the only criterion, since there's no docstring).
Here's the macro and its expansion:
```
(def...I don't think that `with-expected-failure` (in "script-support.lisp") does what it should -- at least not what I expect it should (and that's the only criterion, since there's no docstring).
Here's the macro and its expansion:
```
(defmacro with-expected-failure ((&optional condition) &body body)
`(call-with-expected-failure ,condition (lambda () ,@body)))
(defun call-with-expected-failure (condition thunk)
(if condition
(handler-case (funcall thunk)
(:no-error (&rest x) (declare (ignore x)) (error "Unexpected success: ~A" condition))
(t (x) (declare (ignore x)) t))
(funcall thunk)))
```
AFAICT if `condition` is `nil`, then `call-with-expected` failure *does not check for an expected failure*. So at the very least, I believe that the "else" branch should have the same `handler-case` wrapped around it, just without the `condition`. Otherwise ... it's just behaving like `progn`, which doesn't make sense, at least not to me.
Or... oh, gosh, the `condition` argument is expected to evaluate to `nil` if the test is *not* expected to fail, and is expected to be non-`nil` if the test is expected to fail.
But then... what am I supposed to make of this?
```
(with-expected-failure ()
(assert-pathnames-equal (directory-files (getcwd)) (list (subpathname *build-directory* "deleteme/a/1.x")))
```
AFAICT that means that we *never* expect this to fail, and if it *does* fail, we do nothing to quash the failure, and so `with-expected-failure` is just there to confuse the reader.Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/81Unintuitive and stupid (but documented and consistent) behavior of :REEXPORT ...2021-08-09T14:40:47ZPhoebe GoldmanUnintuitive and stupid (but documented and consistent) behavior of :REEXPORT in UIOP:DEFINE-PACKAGEI had assumed that the `:reexport` clause of `uiop:define-package` would export only symbols already present in the newly-defined package. That is, given a package like:
```
(uiop:define-package :foo
(:import-from :alexandria #:array-l...I had assumed that the `:reexport` clause of `uiop:define-package` would export only symbols already present in the newly-defined package. That is, given a package like:
```
(uiop:define-package :foo
(:import-from :alexandria #:array-length)
(:reexport :alexandria))
```
my expectation is that:
```
(find-symbol "ARRAY-LENGTH" :foo) ; => ALEXANDRIA:ARRAY-LENGTH, :EXTERNAL
(find-symbol "ARRAY-INDEX" :foo) ; => NIL, NIL
```
Instead, the second `find-symbol` does:
```
(find-symbol "ARRAY-INDEX" :foo) ; => FOO:ARRAY-INDEX, :EXTERNAL
(eq 'foo:array-index 'alexandria:array-index) ; => NIL
```
This behavior is described in the documentation, as:
> REEXPORT -- Takes a list of package designators. For each package, p, in the list,
> export symbols with the same name as those exported from p. Note that in the case
> of shadowing, etc. the symbols with the same name may not be the same symbols.
That is, `:reexport PACKAGE` behaves like:
```
(iter (for SYM in-package PACKAGE external-only t)
(export (symbol-name SYM) NEW-PACKAGE))
```
I believe it should instead be:
```
(iter (for SYM in-package PACKAGE external-only t)
(when (find-symbol (symbol-name SYM) NEW-PACKAGE)
(export (symbol-name SYM) NEW-PACKAGE)))
```
That is, it should export any symbol that exists in NEW-PACKAGE that shares the name as one exported from PACKAGE (regardless of whether they're the same symbol), but it should not intern anything into NEW-PACKAGE. (Note that the `:use-reexport` and `:mix-reexport` clauses exist to both intern and reexport all the symbols from a package.)
Do y'all agree with my proposed behavior? Is this a breaking change, and would it be too breaking for a minor release like 3.4?
Somewhat relatedly, I'd like to define an `(:import-from-reexport PACKAGE &rest SYMBOLS)` clause for `uiop:define-package`, and would appreciate feedback on the name/keyword/head.https://gitlab.common-lisp.net/asdf/asdf/-/issues/82Unreadable deferred-warning causes error on load2021-07-16T22:06:53ZPaul RodriguezUnreadable deferred-warning causes error on loadIf you enable deferred warnings, and load the current version of [command-line-arguments](https://github.com/fare/command-line-arguments) (fbac862) on SBCL, when ASDF attempts to load the deferred warnings for `parse.lisp`, you get an er...If you enable deferred warnings, and load the current version of [command-line-arguments](https://github.com/fare/command-line-arguments) (fbac862) on SBCL, when ASDF attempts to load the deferred warnings for `parse.lisp`, you get an error about a comma outside a quasiquote.
The file containing the deferred warning looks like this:
```
((SB-C::*UNDEFINED-WARNINGS*
(:FUNCTION COMMAND-LINE-ARGUMENTS:SHOW-OPTION-HELP 1
(:%ENCLOSING-SOURCE NIL :%SOURCE NIL :ORIGINAL-FORM
(COMMAND-LINE-ARGUMENTS:SHOW-OPTION-HELP COMMAND-LINE-ARGUMENTS::OPTS
:SORT-NAMES T :STREAM COMMAND-LINE-ARGUMENTS::STR :DOCSTRING T)
:CONTEXT
((DEFMACRO COMMAND-LINE-ARGUMENTS:DEFINE-COMMAND)
(DEFUN ,COMMAND-LINE-ARGUMENTS::NAME))
:FILE-NAME #P"/root/common-lisp/command-line-arguments/parse.lisp"
:FILE-POSITION 15697 :ORIGINAL-SOURCE-PATH (3 3 5 1 2 2 2 4 24)))))
```
As you can see there is indeed an invalid comma present.https://gitlab.common-lisp.net/asdf/asdf/-/issues/86uiop:delete-file-if-exists doesn't signa an error when it should2021-08-10T22:09:47ZPascal J. Bourguignonuiop:delete-file-if-exists doesn't signa an error when it shouldWhy does a name such as delete-file-if-exists starts the red alert in my mind?
```
(uiop:delete-file-if-exists "/etc/passwd") -> nil
```
which is wrong, you want a file-error in that case!
note:
```
(progn (uiop:delete-file-if-exists "...Why does a name such as delete-file-if-exists starts the red alert in my mind?
```
(uiop:delete-file-if-exists "/etc/passwd") -> nil
```
which is wrong, you want a file-error in that case!
note:
```
(progn (uiop:delete-file-if-exists "/etc/passwd") (probe-file "/etc/passwd")) #| --> #P"/private/etc/passwd" |#
```
but no other process created it in between!
ie. the fundamental post-condition of delete-file-if-exists is not respected.
Please, either signal the error when the file cannot be deleted, or rename it `uiop:delete-file-if-you-can`.
Also, hint: cl has ignore-errors: (ignore-errors (delete-file foo)) is as good and should be used instead.https://gitlab.common-lisp.net/asdf/asdf/-/issues/88abcl-1.8.0 fails asdf test-around-compile.script2021-08-25T19:11:21ZMark Evensonabcl-1.8.0 fails asdf test-around-compile.scriptRobert Goldman wrote in a polite email:
On the Mac at least, with 1.8.0 I am still seeing failures in test-around-compile.script […]
[This] seems to have something to do with handling lambda expressions that establish dynamic variable...Robert Goldman wrote in a polite email:
On the Mac at least, with 1.8.0 I am still seeing failures in test-around-compile.script […]
[This] seems to have something to do with handling lambda expressions that establish dynamic variable bindings (notably *read-base* in this case). I think this is an ABCL thing, and not an ASDF issue, but I'd be happy to work with you to get it tidied up.Mark EvensonMark Evensonhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/90uiop:call-with-current-directory broken on Linux2021-09-04T02:36:44ZSteveuiop:call-with-current-directory broken on LinuxI think I've discovered a bug in `call-with-current-directory` on Linux, demonstrated below.
First, a quick background:
The intention is to have ASDF automatically compile custom C code on system load for CFFI wrappers. The C code is c...I think I've discovered a bug in `call-with-current-directory` on Linux, demonstrated below.
First, a quick background:
The intention is to have ASDF automatically compile custom C code on system load for CFFI wrappers. The C code is conditionalised by platform, so all we need to do is invoke `make`. This is going to be a common pattern and I'm trying to develop a good examplar to use as 'best practice' going forward.
Here's what I've tried:
```lisp
(run-program (format nil "cd ~S && make" (namestring lib-dir)) :output t) ; works with slime, Linux
```
But that doesn't work from PowerShell nor MSYS2 bash.
```lisp
(call-with-current-directory (native-namestring lib-dir)
(lambda ()
(run-program "make" :output t)))
```
works with MS Windows CLI and slime, but not Linux, and the problem appears to be that on Linux the current directory isn't being changed. By changing the `run-program` command from `make` to `pwd`, we can see this (output of debugging statements included):
```lisp
CL-USER(1): (asdf:load-system :cephes)
namestring: "/home/symbolics/common-lisp/cephes/scipy-cephes"
native namestring: "/home/symbolics/common-lisp/cephes/scipy-cephes"
Building #P"/home/symbolics/common-lisp/cephes/scipy-cephes/libmd.so"
/home/symbolics/common-lisp/cephes <-- this is the output of 'pwd'
```
The only way I can make this reliably work is:
```lisp
(uiop:chdir (native-namestring lib-dir))
(run-program "make" :output t)
```
which fine, but `call-with-current-directory` does seem broken. Tested on Ubuntu 18.
System definition:
```lisp
;; Define a makefile as a kind of source file in ASDF
(defclass makefile (source-file) ((type :initform "m")))
(defmethod perform ((o load-op) (c makefile)) t)
(defmethod perform ((o compile-op) (c makefile))
(let* ((lib-dir (system-relative-pathname "cephes" "scipy-cephes"))
(lib (make-pathname :directory `(:relative ,(namestring lib-dir))
:name "libmd"
:type #+unix "so" #+(or windows win32) "dll"))
(built (probe-file (namestring lib))))
(format t "namestring: ~S~%" (namestring lib-dir))
(format t "native namestring: ~S~%" (native-namestring lib-dir))
(if built
(format *error-output* "Library ~S exists, skipping build" lib)
(format *error-output* "Building ~S~%" lib))
(unless built
;; (run-program (format nil "cd ~S && make" (namestring lib-dir)) :output t)))) ;works with slime and Linux
;; (call-with-current-directory (native-namestring lib-dir) (lambda () (run-program "make" :output t))) ;works with Windows CLI & slime
;; Works on MS Windows CLI, slime and Linux
(uiop:chdir (native-namestring lib-dir))
(run-program "make" :output t))))
(defsystem "cephes"
:description "Wrapper for the Cephes Mathematical Library"
:version "1.0.0"
:license :MS-PL
:depends-on ("cffi")
:serial t
:components ((:module "libmd"
:components ((:makefile "makefile")))
(:file "package")
(:file "init")
(:file "cephes")))
```https://gitlab.common-lisp.net/asdf/asdf/-/issues/91Symbol & warning for license field in system definition2021-09-15T02:53:40ZSteveSymbol & warning for license field in system definitionAlthough the recommendation for the `:license` field states this should be a string, I have found that a keyword symbol works as well.
How do people feel about changing the recommendation to use a symbol identifier from the [SPDX licens...Although the recommendation for the `:license` field states this should be a string, I have found that a keyword symbol works as well.
How do people feel about changing the recommendation to use a symbol identifier from the [SPDX license list](https://spdx.org/licenses/) and issuing a warning if it's not found? E.g. `:BSD-1-Clause`
One use case is preparing manifests for software deliveries. Typically all included software, including all the transient dependencies, must be listed and have an approved license. At the moment it seems folks use the string in the license field randomly and it's a manual process to work out exactly what license the library is under. Using an SPDX identifier would eliminate any ambiguity.https://gitlab.common-lisp.net/asdf/asdf/-/issues/92Bug: uiop:terminate-process - doesn't terminate2021-09-20T18:57:58ZAlberto FerreiraBug: uiop:terminate-process - doesn't terminateHello,
# Context
I'm using `(uiop:launch-program "bash some_script.sh" :input :stream :output :stream)` to launch scripts and programs asynchronously.
However, very often this does not kill the program, only the parent shell that spaw...Hello,
# Context
I'm using `(uiop:launch-program "bash some_script.sh" :input :stream :output :stream)` to launch scripts and programs asynchronously.
However, very often this does not kill the program, only the parent shell that spawns it.
I'm using SBCL 2.1.8 on Ubuntu 20.04.
## Bug
Internally `uiop:terminate-process` calls `%posix-send-signal` on UNIX, and in turn SBCL's process-kill (for SBCL) - which uses the "kill" system call instead of "killpg", closing the shell and leaving the child processes running.
There is even a comment about it but it's not even correct, as it fails with both SIGTERM and SIGKILL to kill all the spawned processes, killing only the shell:
```lisp
;; WARNING: For signals other than SIGTERM and SIGKILL this may not
;; do what you expect it to. Sending SIGSTOP to a process spawned
;; via LAUNCH-PROGRAM, e.g., will stop the shell /bin/sh that is used
;; to run the command (via `sh -c command`) but not the actual
;; command.
#+os-unix
(defun %posix-send-signal (process-info signal)
#+allegro (excl.osi:kill (slot-value process-info 'process) signal)
#+clozure (ccl:signal-external-process (slot-value process-info 'process)
signal :error-if-exited nil)
#+(or cmucl scl) (ext:process-kill (slot-value process-info 'process) signal)
#+sbcl (sb-ext:process-kill (slot-value process-info 'process) signal)
#-(or allegro clozure cmucl sbcl scl)
(if-let (pid (process-info-pid process-info))
(symbol-call :uiop :run-program
(format nil "kill -~a ~a" signal pid) :ignore-error-status t)))
```
# Proposal to fix UNIX implementations:
**Proposal 1:** (don't think it's a good idea)
Instead of `uiop:%posix-send-signal` calling `kill` on UNIX, call `killpg`.
- Pros: At least for SIGTERM everything closes.
- Cons: Brute force. Too aggressive? This suffers from lack of granularity for some use cases and other signals?
**Proposal 2:**
Like SBCL, add to `uiop:%posix-send-signal` an extra optional parameter `whom` to %posix-send-signal, which by default is `:pid`, but can also be `:process-group` - in which case the `killpg` system call should be used instead of `kill`.
Don't think it's a good idea to start sending signals to the group all the time right?
In such case, terminate-process could have another parameter `whom` as well.
- Pros: Remains generic, gains functionality, and it's possible to use `killpg` when calling with `terminate-process`, fixing the current bug on UNIX.
- Cons: More effort than 1? (but it's very small anyway); Could be too aggressive? and not let the application manage the child processes shutdown?
**Proposal 2+ / 3:**
Another option would be to kill the shell and the process it spawns with separate `kill` commands, but it might not be trivial to figure out which PID that the subprocess has. That would however grant the program the chance to correctly shutdown itself and its child processes.
- Pros: Compatible and synergistic with 2 - when using `kill`. Allows apps that are well built to gracefully shutdown along with their children.
- Cons: For badly behaved apps, implementing this and not having proposal 2's `killpg` might not be enough to close all resources.
If you're interested I can gladly submit a patch.
I've never contributed to any CL project and would love to do so, thank you :)https://gitlab.common-lisp.net/asdf/asdf/-/issues/95Standard self upgrade does not work on Clasp2022-02-14T20:15:25ZEric TimmonsStandard self upgrade does not work on ClaspThe standard instructions to perform an ASDF self-upgrade do not work on Clasp. If you put asdf.asd somewhere ASDF can find it, the standard `(upgrade-asdf)` (called as part of any operation) does not upgrade ASDF. This was not caught ea...The standard instructions to perform an ASDF self-upgrade do not work on Clasp. If you put asdf.asd somewhere ASDF can find it, the standard `(upgrade-asdf)` (called as part of any operation) does not upgrade ASDF. This was not caught earlier because prior to !194 the upgrade tests only tested basic functionality and did not compare version numbers to ensure the upgrade did what was expected.
The problem seems to be that ASDF is marked as immutable:
```
clasp -n -N -e '(require :asdf)' -e '(format t "Immutable?: ~S~%" (gethash "asdf" asdf::*immutable-systems*))'
Starting cclasp-boehm-0.4.2-3852-gb14e329f4-cst ... loading image...
Immutable?: T
```
Even if this were fixed, we'd probably run into another issue. It seems Clasp actually ships asdf.asd (instead of just the fasls like most other implementations do). And Clasp's `wrapping-source-registry` results in their bundled asdf.asd being found and added to the registry.
```
clasp -n -N -e '(require :asdf)' -e '(asdf:ensure-source-registry)' -e '(format t "asdf in registry: ~S~%" (gethash "asdf" asdf::*source-registry*))'
Starting cclasp-boehm-0.4.2-3852-gb14e329f4-cst ... loading image...
asdf in registry: #P"SYS:MODULES;ASDF;ASDF.ASD"
```
This won't affect the tests because they push the asdf.asd under test to the `*central-registry*` which overrides the source registry. However, the standard instructions say to drop an updated asdf.asd into ~/common-lisp, which is searched as part of the source registry.
Seems to me we either need to update our manual and say that the only way to update ASDF on Clasp is to `load` asdf.lisp, or see if we can get the Clasp maintainers to both not mark ASDF as immutable and make sure the bundled asdf.asd (and likely uiop.asd) either do not go into the source-registry or go at the back of the registry so that users can override it.https://gitlab.common-lisp.net/asdf/asdf/-/issues/97Use of change-class interferes with system class default initargs2021-12-23T23:02:00ZRobert GoldmanUse of change-class interferes with system class default initargsAttila Lendvai writes:
> i wanted to set the default-component-class of our own system subclass using `:default-initargs`, but it's ignored because the slot has a `:initform` (as opposed to setting the default value using a `:default-in...Attila Lendvai writes:
> i wanted to set the default-component-class of our own system subclass using `:default-initargs`, but it's ignored because the slot has a `:initform` (as opposed to setting the default value using a `:default-initargs` entry).
> in the current ASDF setup, i need to override the slot (or the accessor method), which involves messing with internal symbols.
> if ASDF used `:default-initargs` then i could just override that using a `:default-initargs` entry on my own subclass (IIUC).
This behavior was anomalous, because `:default-initargs` is supposed to override `:initform`, rather than _vice versa_.
Further investigation reveals that this is because `change-class` is invoked when parsing `defsystem` forms. See https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/parse-defsystem.lisp#L447-L453 and https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/system.lisp#L114-L118
This process (I have not investigated further) appears to change the initialization protocol, so that the initforms are clobbering the default initargs.
/cc @alendvaihttps://gitlab.common-lisp.net/asdf/asdf/-/issues/102initialize-source-registry's :inherit-configuration has confusing semantics2023-01-20T19:41:25ZNathan Ringoinitialize-source-registry's :inherit-configuration has confusing semanticsIt seems like if the source registry has already been initialized, `:inherit-configuration` ought to inherit that configuration; or at least, there should be _some_ way to additively construct the source registry configuration other than...It seems like if the source registry has already been initialized, `:inherit-configuration` ought to inherit that configuration; or at least, there should be _some_ way to additively construct the source registry configuration other than
```lisp
(asdf:ensure-source-registry
'(:source-registry :inherit-configuration))
(asdf:initialize-source-registry
`(:source-registry
my-new-stuff
,@(cdr asdf:*source-registry-parameter*)))
```
To simply reproduce:
```console
$ mkdir /tmp/asdf102
$ cd /tmp/asdf102
$ echo '(defsystem "foo")' >foo.asd
$ cat >foo.lisp <<EOF
(require :asdf)
(asdf:initialize-source-registry
'(:source-registry
(:tree #p"/tmp/asdf102/")
:inherit-configuration))
#+nil
(asdf:initialize-source-registry
'(:source-registry
:inherit-configuration))
(format t "~s~%" (asdf:find-system "foo"))
EOF
$ sbcl --quit --load foo.lisp
...
#<ASDF/SYSTEM:SYSTEM "foo">
$ sed -i '/#+nil/d' foo.lisp
$ sbcl --quit --load foo.lisp
...
While evaluating the form starting at line 12, column 0
of #P"/tmp/asdf102/foo.lisp":
debugger invoked on a ASDF/FIND-COMPONENT:MISSING-COMPONENT in thread
#<THREAD "main thread" RUNNING {100151C103}>:
Component "foo" not found
...
```
For debugging:
```
(require :asdf)
(asdf:load-system "alexandria")
(defmacro dbg (expr)
(alexandria:with-gensyms (vals)
`(let ((,vals (multiple-value-list ,expr)))
(format t "~s =~{ ~s~}~%" ',expr ,vals)
(values-list ,vals))))
(asdf:initialize-source-registry
'(:source-registry
(:tree #p"/tmp/asdf102/")
:inherit-configuration))
(dbg asdf:*source-registry-parameter*)
(dbg (alexandria:hash-table-alist asdf/source-registry::*source-registry*))
(dbg (trace asdf/source-registry::process-source-registry
asdf/source-registry::process-source-registry-directive
asdf/source-registry::inherit-source-registry
asdf/source-registry::initialize-source-registry))
(asdf:initialize-source-registry
'(:source-registry
:inherit-configuration))
(dbg asdf:*source-registry-parameter*)
(dbg (alexandria:hash-table-alist asdf/source-registry::*source-registry*))
(dbg (asdf:find-system "foo"))
```
prints:
<details><pre><code>ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY-PARAMETER* = (:SOURCE-REGISTRY
(:TREE #P"/tmp/asdf102/")
:INHERIT-CONFIGURATION)
(ALEXANDRIA:HASH-TABLE-ALIST ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY*) = (("asdf"
. #P"/nix/store/15hsmpcwsrwgighsxp28dx03yzzbr32g-cl-wrapper-script/lib/common-lisp/asdf/asdf.asd")
("foo"
. #P"/tmp/asdf102/foo.asd")
("sb-sprof"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-sprof.asd")
("sb-simple-streams"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-simple-streams.asd")
("sb-rt"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-rt.asd")
("sb-rotate-byte"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-rotate-byte.asd")
("sb-queue"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-queue.asd")
("sb-posix"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-posix.asd")
("sb-mpfr"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-mpfr.asd")
("sb-md5"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-md5.asd")
("sb-introspect"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-introspect.asd")
("sb-grovel"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-grovel.asd")
("sb-graph"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-graph.asd")
("sb-gmp"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-gmp.asd")
("sb-executable"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-executable.asd")
("sb-cover"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-cover.asd")
("sb-concurrency"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-concurrency.asd")
("sb-cltl2"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-cltl2.asd")
("sb-capstone"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-capstone.asd")
("sb-bsd-sockets"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-bsd-sockets.asd")
("sb-aclrepl"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-aclrepl.asd"))
(TRACE ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY
ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE
ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY
ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY) = (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY
ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE
ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY
ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY)
0: (ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY (:SOURCE-REGISTRY :INHERIT-CONFIGURATION))
1: (ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY (ASDF/SOURCE-REGISTRY:WRAPPING-SOURCE-REGISTRY (:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
2: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:WRAPPING-SOURCE-REGISTRY :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}> :INHERIT ((:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY))
3: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (:SOURCE-REGISTRY (:TREE #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/") :INHERIT-CONFIGURATION) :INHERIT ((:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
4: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE (:TREE #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/") :INHERIT ((:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
4: ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE returned
NIL
4: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE :INHERIT-CONFIGURATION :INHERIT ((:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
5: (ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY ((:SOURCE-REGISTRY :INHERIT-CONFIGURATION) ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
6: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (:SOURCE-REGISTRY :INHERIT-CONFIGURATION) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}> :INHERIT (ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY))
7: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE :INHERIT-CONFIGURATION :INHERIT (ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
8: (ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY (ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
9: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}> :INHERIT (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY))
10: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY "/nix/store/15hsmpcwsrwgighsxp28dx03yzzbr32g-cl-wrapper-script/lib/common-lisp/asdf/" :INHERIT (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
11: (ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (:SOURCE-REGISTRY (:DIRECTORY "/nix/store/15hsmpcwsrwgighsxp28dx03yzzbr32g-cl-wrapper-script/lib/common-lisp/asdf/") (:IGNORE-INHERITED-CONFIGURATION)) :INHERIT (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
12: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE (:DIRECTORY "/nix/store/15hsmpcwsrwgighsxp28dx03yzzbr32g-cl-wrapper-script/lib/common-lisp/asdf/") :INHERIT (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
12: ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE returned
NIL
12: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE (:IGNORE-INHERITED-CONFIGURATION) :INHERIT (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #<FUNCTION (LAMBDA (DIRECTORY &KEY :RECURSE :EXCLUDE) :IN ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10047DE7EB}>)
12: ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE returned
NIL
11: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned
NIL
10: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned
NIL
9: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned NIL
8: ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY returned NIL
7: ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE returned
NIL
6: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned NIL
5: ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY returned NIL
4: ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE returned
NIL
3: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned NIL
2: ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY returned NIL
1: ASDF/SOURCE-REGISTRY:INHERIT-SOURCE-REGISTRY returned NIL
0: ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY returned
ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY-PARAMETER* = (:SOURCE-REGISTRY
:INHERIT-CONFIGURATION)
(ALEXANDRIA:HASH-TABLE-ALIST ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY*) = (("asdf"
. #P"/nix/store/15hsmpcwsrwgighsxp28dx03yzzbr32g-cl-wrapper-script/lib/common-lisp/asdf/asdf.asd")
("sb-sprof"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-sprof.asd")
("sb-simple-streams"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-simple-streams.asd")
("sb-rt"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-rt.asd")
("sb-rotate-byte"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-rotate-byte.asd")
("sb-queue"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-queue.asd")
("sb-posix"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-posix.asd")
("sb-mpfr"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-mpfr.asd")
("sb-md5"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-md5.asd")
("sb-introspect"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-introspect.asd")
("sb-grovel"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-grovel.asd")
("sb-graph"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-graph.asd")
("sb-gmp"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-gmp.asd")
("sb-executable"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-executable.asd")
("sb-cover"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-cover.asd")
("sb-concurrency"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-concurrency.asd")
("sb-cltl2"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-cltl2.asd")
("sb-capstone"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-capstone.asd")
("sb-bsd-sockets"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-bsd-sockets.asd")
("sb-aclrepl"
. #P"/nix/store/wjaraq6qygaabavbzr71idlif4g5bxwv-sbcl-2.1.11/lib/sbcl/contrib/sb-aclrepl.asd"))
While evaluating the form starting at line 32, column 0
of #P"/tmp/asdf102/foo.lisp":
debugger invoked on a ASDF/FIND-COMPONENT:MISSING-COMPONENT in thread
#<THREAD "main thread" RUNNING {1004D80173}>:
Component "foo" not found
</code></pre></details>3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/103CMUCL error in print-backtrace2022-02-14T20:14:44ZRobert GoldmanCMUCL error in print-backtraceGot an error in `print-backtrace` running the test for #102
See [error transcript](https://gitlab.common-lisp.net/asdf/asdf/-/jobs/27247)
See !202
/cc @etimmons @remexreGot an error in `print-backtrace` running the test for #102
See [error transcript](https://gitlab.common-lisp.net/asdf/asdf/-/jobs/27247)
See !202
/cc @etimmons @remexrehttps://gitlab.common-lisp.net/asdf/asdf/-/issues/104DEFINE-PACKAGE :RECYCLE use cases2022-01-19T21:19:38ZMichał Herdaphoe@disroot.orgDEFINE-PACKAGE :RECYCLE use casesA shorter question this time: is `:RECYCLE` also useful mostly when upgrading from older versions of software, so that a symbol naming e.g. a class can be "transparently" moved from an older package to a newer one, and then possibly reex...A shorter question this time: is `:RECYCLE` also useful mostly when upgrading from older versions of software, so that a symbol naming e.g. a class can be "transparently" moved from an older package to a newer one, and then possibly reexported?
Also, the TODO mentions:
```
*** document that THOU SHALT NOT USE :RECYCLE with packages previously
defined by define-package when building from scratch.
```
What is the reason behind this comment? Why does `DEFINE-PACKAGE` get the "special" treatment, and not the standard `DEFPACKAGE`?https://gitlab.common-lisp.net/asdf/asdf/-/issues/105ASDF website2022-05-19T22:21:18ZEric TimmonsASDF websiteDue to a combination of Gitlab changes, reducing maintenance overhead, and adopting best practices, all of the common-lisp.net/project sites have been moved to PROJECT-NAME.common-lisp.dev. So, ASDF's new website is <https://asdf.common-...Due to a combination of Gitlab changes, reducing maintenance overhead, and adopting best practices, all of the common-lisp.net/project sites have been moved to PROJECT-NAME.common-lisp.dev. So, ASDF's new website is <https://asdf.common-lisp.dev>. All of the old URLS are forwarded so existing bookmarks should continue to work.
I took a look at the new site and couldn't find any broken links with a quick glance (AFAIK, the only way to get a broken link in the move is if the href is an absolute path without hostname).
I believe next up on the "reducing maintenance overhead" TODO list is to move every site onto Gitlab pages (so no more shell access to common-lisp.net is needed to update a website). I don't know the timeline for that, but figured we should start planning for it now.
In order to move to pages, we need to create a repo asdf/asdf.common-lisp.dev and copy the current contents of the site into the public/ folder. Additionally, we need to add a very simple .gitlab-ci.yml file that has a `pages` job in it. I believe Erik will do that for us if we ask (or take too long).
AFAICT, the current procedure for updating the website is to run `make website` after a release. We'd need to change those jobs to instead copy the files into the new repo and push (instead of rsync).
I'd like to propose that at the same time (or instead of that) we add a new Gitlab CI job to this repo that handles all of that when a release tag is pushed. I've done a similar thing with cl-tar, so would be happy to set it up here as well. (I'm also likely going to write a News entry at some point for common-lisp.net that describes how to do it).https://gitlab.common-lisp.net/asdf/asdf/-/issues/106Add a machine readble listing of ASDF versions to website2022-01-21T04:38:26ZEric TimmonsAdd a machine readble listing of ASDF versions to websiteThere is interest in automating the download and install of ASDF. We can trivially support these desires by adding some file to the archives folder of the website that lists all released versions of ASDF and their URLs.
Supersedes #93
...There is interest in automating the download and install of ASDF. We can trivially support these desires by adding some file to the archives folder of the website that lists all released versions of ASDF and their URLs.
Supersedes #93
Would help support the end result of #100https://gitlab.common-lisp.net/asdf/asdf/-/issues/107ABCL expands compiler macros overeagerly2022-02-14T20:14:11ZEric TimmonsABCL expands compiler macros overeagerlySometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/l...Sometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/lw50/CLHS/Body/03_bbac.htm) this *must* prevent compiler macro expansion.
However, ABCL still expands the compiler macros in generic functions, potentially resulting in warnings when compiling ASDF.
I noticed when prepping for ASDF 3.4. Reported at <https://abcl.org/trac/ticket/487>. I figured this is worth tracking, so I'm making a new issue category for ~"implementation-bug"3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/108Allegro expands compiler macros overeagerly2022-02-14T20:13:58ZEric TimmonsAllegro expands compiler macros overeagerlySometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/l...Sometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/lw50/CLHS/Body/03_bbac.htm) this *must* prevent compiler macro expansion.
However, Allego still expands the compiler macros, potentially resulting in warnings when compiling ASDF.
I noticed when prepping for ASDF 3.4. In addition to failing the same test as ABCL (at <https://abcl.org/trac/ticket/487>), it appears Allegro also expands compiler macros for regular functions as well.
I have not reported. @rgoldman maybe you'd be able to report this to Franz? No rush since we still haven't officially started 3.4 development yet, though.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/109Create new asdf-installer repo?2022-01-28T05:19:06ZEric TimmonsCreate new asdf-installer repo?For better or worse, it's unlikely the major open source CL implementation (SBCL) will upgrade their bundled version of ASDF. Additionally, some people may want to use an older CL (any implementation) and use a newer ASDF than it bundles...For better or worse, it's unlikely the major open source CL implementation (SBCL) will upgrade their bundled version of ASDF. Additionally, some people may want to use an older CL (any implementation) and use a newer ASDF than it bundles. While it's already pretty trivial to install a newer version of ASDF, it'd be nice to have a way to do it completely within Common Lisp.
@mherda and I have been chatting about this and think it'd be nice to have a project similar to [quicklisp-slime-helper](https://github.com/quicklisp/quicklisp-slime-helper). It could be quickloaded and then a single command would update your Lisp init file to load any particular version of ASDF. The bare minimum would include every release of ASDF in the project repo so it doesn't even need to use git or an HTTPS client to download ASDF.
We haven't talked about it yet, but I think it would also be cool to optionally add git and/or HTTPS support so you could install the latest updates even if Quicklisp hasn't updated the installer project yet. It would also be nice to expose functionality to just install and compile ASDF somewhere (and not modify your init file), for use in projects that want to easily bundle a copy of ASDF for distribution.
@mherda has agreed to maintain the project (at least the parts I described above as "bare minimum"). But we think it would be best to host it under the asdf group on this Gitlab install. That way the ASDF team can help move things along if needed and it's easier to tie into our CI (so that whenever we push a new tag the installer project gets auto-updated as well).
Thoughts?https://gitlab.common-lisp.net/asdf/asdf/-/issues/110Hook REQUIRE on Allegro2022-02-14T20:13:42ZRobert GoldmanHook REQUIRE on AllegroIn other lisp implementations, we modify `require` to use ASDF as an alternative loading method. This would be possible on Allegro, as well, if we wrapped `cl:require` using Allegro fwrappers.
Open to comments telling me this is not a ...In other lisp implementations, we modify `require` to use ASDF as an alternative loading method. This would be possible on Allegro, as well, if we wrapped `cl:require` using Allegro fwrappers.
Open to comments telling me this is not a good idea, if anyone knows why it would be bad.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/111Automatic self upgrades broken on ECL2022-02-14T20:13:25ZEric TimmonsAutomatic self upgrades broken on ECLIf the ASDF repo is checked out into `~/common-lisp` (or another place the source registry searches), then the first time ASDF automatically upgrades itself will work, but subsequent times will fail.
The proximate cause is that there's ...If the ASDF repo is checked out into `~/common-lisp` (or another place the source registry searches), then the first time ASDF automatically upgrades itself will work, but subsequent times will fail.
The proximate cause is that there's an unbound slot in `action-status` that should *never* be unbound. This also exhausts the stack because when printing the slot-unbound error, it triggers another slot-unbound error ad infinitum.
The root cause is that when loading a fasl, ECL eagerly interns symbols into packages, instead of delaying the intern until the top-level form it appears in is processed. This results in the package of the `stamp` slot name changing at an inopportune time, causing the slot to become unbound in existing instances.
A contributing factor is that the bug is only seen if ASDF locates itself using the source registry. If the `*central-registry*` is used instead, the bug doesn't seem to appear during the self upgrade. There may still be other issues after the self upgrade, however.
I believe that the difference between the central and source registries is likely due to ECL bundling a very old version of ASDF. But I have not been able to prove that yet. It also means that our tests would never catch this because the upgrade tests only use the central registry for configuration.
This is likely an ~"implementation-bug" and has been reported upstream: <https://gitlab.com/embeddable-common-lisp/ecl/-/issues/676>, but they have yet to determine for sure if their current behavior is allowed by the spec or not.
As for remediation on our end: I think if we export `stamp` from the `asdf/action` package that the upgrade will succeed (because the package for the slot name won't change). However, I'm hesitant to do that because there might be other hidden traps after the upgrade has finished.
Another option is to prevent self upgrades on ECL from using a fasl and force them to `cl:load` asdf.lisp. But I'm uncertain how to do that.
The best option is probably just to tell folks running ECL that if they want to upgrade ASDF, they should manually `cl:load` asdf.lisp. Alternatively they can load a fasl, so long as they never load ECL's bundled ASDF.https://gitlab.common-lisp.net/asdf/asdf/-/issues/112UIOP:RUN-PROGRAM and UIOP:LAUNCH-PROGRAM insist on /bin/sh2022-04-12T19:25:20ZEric TimmonsUIOP:RUN-PROGRAM and UIOP:LAUNCH-PROGRAM insist on /bin/shOriginally opened by @rgoldman (see <https://mailman.common-lisp.net/pipermail/clo-devel/2022-April/001567.html>)
On Linux, I believe that /bin/sh and /bin/bash might be the same, but on the Mac it seems like /bin/bash, /bin/sh, and /bi...Originally opened by @rgoldman (see <https://mailman.common-lisp.net/pipermail/clo-devel/2022-April/001567.html>)
On Linux, I believe that /bin/sh and /bin/bash might be the same, but on the Mac it seems like /bin/bash, /bin/sh, and /bin/zsh are all different.
Should UIOP adopt the user's shell instead of always using /bin/sh? Perhaps this should be an option controlled by a keyword argument?https://gitlab.common-lisp.net/asdf/asdf/-/issues/116Does RUN-PROGRAM-UNIX.SCRIPT properly check for unsupported / unimplemented p...2022-05-09T14:33:13ZRobert GoldmanDoes RUN-PROGRAM-UNIX.SCRIPT properly check for unsupported / unimplemented parts of the API?When I look in the tests, there are only 2 places where we have `expected-unimplemented`, but I see a bunch of `"NOT IMPLEMENTED"` and `"NOT SUPPORTED"`.
I suspect these tests should be modified to check for expected versus unexpected s...When I look in the tests, there are only 2 places where we have `expected-unimplemented`, but I see a bunch of `"NOT IMPLEMENTED"` and `"NOT SUPPORTED"`.
I suspect these tests should be modified to check for expected versus unexpected support or lack thereof.https://gitlab.common-lisp.net/asdf/asdf/-/issues/117Do IF-FEATURE dependencies correctly get updated over feature changes?2023-01-20T19:37:44ZRobert GoldmanDo IF-FEATURE dependencies correctly get updated over feature changes?A discussion on ASDF-devel suggested this as something to worry about.
Here is the case:
1. We compile a system with a feature present, triggering compilation of a file with an `:if-feature` dependency. This file changes the state of t...A discussion on ASDF-devel suggested this as something to worry about.
Here is the case:
1. We compile a system with a feature present, triggering compilation of a file with an `:if-feature` dependency. This file changes the state of the packages, a change that will affect the code in downstream files.
2. We recompile with the feature present in a way that does not change the filesystem. ASDF has no way of knowing that the relevant feature has been removed after the compilation of the dependent file, and this causes FASL loading of the dependent file to fail. This happens because the fasl of the dependent file has captured a state dependency, and ASDF does not know that it needs recompilation.
I have attempted to create a test for this issue: !209
This test appears to confirm the above conjecture, but what I had to do in the test code was so sketchy that I am not confident.https://gitlab.common-lisp.net/asdf/asdf/-/issues/118Document the dependency propagation classes2022-06-28T14:48:43ZRobert GoldmanDocument the dependency propagation classesFrom @gefjon :
> ideally I'd like to see a description of each of the direction-OPERATION classes that describes how it propagates dependencies.
Rather than hold up the existing doc fixes MR, just caching this for further work.From @gefjon :
> ideally I'd like to see a description of each of the direction-OPERATION classes that describes how it propagates dependencies.
Rather than hold up the existing doc fixes MR, just caching this for further work.https://gitlab.common-lisp.net/asdf/asdf/-/issues/120Question on compile-system vs. load-system2022-08-25T14:55:29ZPierre NeidhardtQuestion on compile-system vs. load-systemWhile maintaining more than 650 Common Lisp packages for Guix, I've seen only two packages fail with the current build system which uses `asdf:compile-system`.
- https://github.com/Shirakumo/cl-gamepad/issues/8
- https://github.com/s-ex...While maintaining more than 650 Common Lisp packages for Guix, I've seen only two packages fail with the current build system which uses `asdf:compile-system`.
- https://github.com/Shirakumo/cl-gamepad/issues/8
- https://github.com/s-expressionists/Cleavir (More specifically the cleavir-abstract-interpreter)
To be more concrete, here is a recipe to reproduce the problem (works without Guix too):
- git clone https://github.com/s-expressionists/Cleavir
- cd Cleavir
- guix shell sbcl sbcl-acclimation sbcl-concrete-syntax-tree sbcl-closer-mop -- sbcl
- (asdf:initialize-source-registry `(:source-registry (:tree ,(uiop:getcwd)) :inherit-configuration))
- (asdf:compile-system :cleavir-abstract-interpreter)
```
debugger invoked on a SB-PCL:CLASS-NOT-FOUND-ERROR in thread
#<THREAD "main thread" RUNNING {100B598173}>:
There is no class named CLEAVIR-ABSTRACT-INTERPRETER:STRATEGY.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [TRY-RECOMPILING ] Recompile control and try loading it again
1: [RETRY ] Retry
loading FASL for #<CL-SOURCE-FILE "cleavir-abstract-interpreter" "control">.
2: [ACCEPT ] Continue, treating
loading FASL for #<CL-SOURCE-FILE "cleavir-abstract-interpreter" "control">
as having been successful.
3: Retry ASDF operation.
4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
configuration.
5: Retry ASDF operation.
6: Retry ASDF operation after resetting the
configuration.
7: [ABORT ] Exit debugger, returning to top level.
```
If I replace `asdf:compile-system` with `asdf:load-system`, it works like a charm.
I'd like to understand what's going on.
In the above, `STRATEGY` is defined in `strategy.lisp` which is gets compiled before that as part of the system. So why does it fail?
Any idea?https://gitlab.common-lisp.net/asdf/asdf/-/issues/123[Feature Request] Defer loading of specified files until dependency system is...2022-08-25T12:09:20ZL Szos[Feature Request] Defer loading of specified files until dependency system is loadedHello,
I had some issues with account creation so the original of this issue got removed, and I am recreating it.
I and some others desire an ability to defer the loading of a file until a dependency system is loaded, with said file n...Hello,
I had some issues with account creation so the original of this issue got removed, and I am recreating it.
I and some others desire an ability to defer the loading of a file until a dependency system is loaded, with said file not being loaded at all if the dependency system never gets loaded. For example:
```lisp
(defsystem :foo
:serial t
:components ((:file "foo")
(:file "bar-compatibility" :load-after (:bar))))
```
In the above example, loading the system `:foo` would load the file `foo.lisp`, and then check if the system `:bar` is already loaded. If it is, the file `bar-compatibility.lisp` would be loaded. If it is not, then the file `bar-compatibility.lisp` would be registered to be loaded if/when the system `:bar` is loaded. This is different from the normal asdf dependencies in that it does not try to load `:bar` in order to load `bar-compatibility.lisp`, rather it waits until `:bar` is loaded either manually or as an explicit dependency of another system before loading `bar-compatibility.lisp`, and may never load the file at all if `:bar` is never loaded. While this simple example above says to load a file after `:bar` is loaded, it would be nice if this could be specified for all components (systems, modules, etc). In addition, this should not depend upon the system `:bar` already being known by asdf (I am unsure of how practical this is).
I am unsure what the best way of implementing this functionality would be. I've played around a little bit with asdf, and my current approach is to add an after method to the `operate` generic function, which specializes upon `load-op` and `system`. This method runs a hook with the system being loaded as its only argument. Then instead of adding files which should be loaded after another system to the system definition, functions are defined to load the files if the system being loaded is the denoted system, and the function is hung on the aforementioned hook. This approach is clunky, inelegant, and results in files sometimes being loaded multiple times when they dont need to be. There is likely a better solution, but I'm not familiar enough with how asdf operates internally to implement it at this point.
If this is already described in the manual, please point me towards the appropriate section or subsection, as in my reading I couldn't find it.L SzosL Szoshttps://gitlab.common-lisp.net/asdf/asdf/-/issues/125Common version patterns fail in UIOP:PARSE-VERSION2022-08-04T01:02:18ZRobert GoldmanCommon version patterns fail in UIOP:PARSE-VERSIONIt's common to have some extraneous information in a hyphen-separated suffix of a version number. For example, I have a copy of ABCL 1.8 that gives me this:
```
CL-USER(2): (uiop:lisp-version-string)
"1.8.0-fasl43"
```
Unfortunately, t...It's common to have some extraneous information in a hyphen-separated suffix of a version number. For example, I have a copy of ABCL 1.8 that gives me this:
```
CL-USER(2): (uiop:lisp-version-string)
"1.8.0-fasl43"
```
Unfortunately, this causes `uiop:parse-version` to fail and return `NIL`.
Fixing this on the caller side is unpleasant:
(subseq (uiop:lisp-version-string) 0 (position #\- (uiop:lisp-version-string)))
I suggest that we modify `parse-version` as follows:
1. Keep the current behavior, controlled by a `strict` argument.
2. Remove any hyphen-prefixed suffix, and return that as a second value.
So we would get
(1 8 0)
"fasl43"
unless `strict` is true. If `strict` was true and `on-error` was `nil`, then we would just get `NIL`.
I would also like to add the option to pass `:error` to `on-error`, so that programmers do not have to remember to use `#'error`, which is awkward.https://gitlab.common-lisp.net/asdf/asdf/-/issues/127Confusing error message when :LOCAL-NICKNAMES is given an unknown package2022-09-12T02:21:40ZMaciej Katafiasz (mathrick)Confusing error message when :LOCAL-NICKNAMES is given an unknown packageMinimal repro:
```lisp
(uiop:define-package confusing
(:local-nicknames (#:foo #:this-package-doesnt-exist)))
=>
The name NIL does not designate any package.
[Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]
Restarts:
0: [RETRY]...Minimal repro:
```lisp
(uiop:define-package confusing
(:local-nicknames (#:foo #:this-package-doesnt-exist)))
=>
The name NIL does not designate any package.
[Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]
Restarts:
0: [RETRY] Retry SLY mREPL evaluation request.
1: [*ABORT] Return to SLY's top level.
2: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1003AA4EB3}>)
Backtrace:
0: (SB-IMPL::SIGNAL-PACKAGE-ERROR "CONFUSING" "The name ~S does not designate any package." NIL)
1: (SB-IMPL::%ADD-PACKAGE-LOCAL-NICKNAME "FOO" NIL #<PACKAGE "CONFUSING">)
2: (ADD-PACKAGE-LOCAL-NICKNAME "FOO" NIL #<PACKAGE "CONFUSING">)
```
This is SBCL's (in this case) built-in error, so the wording is slightly different between implementations. It seems to be caused by `UIOP:INSTALL-PACKAGE-LOCAL-NICKNAMES` calling `FIND-PACKAGE` and blindly passing its return value to `ADD-PACKAGE-LOCAL-NICKNAME`.https://gitlab.common-lisp.net/asdf/asdf/-/issues/128print-backtrace standard-io-syntax2022-09-28T13:20:35ZPascal J. Bourguignonprint-backtrace standard-io-syntaxThe use by `print-backtrace` of `with-standard-io-syntax` clobbers settings such as `*print-right-margin*` which lead to formatting and readability problems of the output.
https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/imag...The use by `print-backtrace` of `with-standard-io-syntax` clobbers settings such as `*print-right-margin*` which lead to formatting and readability problems of the output.
https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/image.lisp#L157
https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/stream.lisp#L153
Some variables, such as `*print-right-margin*` (but probably others such as `*print-miser-length*` and why not, `*print-base*`, etc), should be left for the user to configure, and used as-is.https://gitlab.common-lisp.net/asdf/asdf/-/issues/130Add UIOP/CONFIGURE:XDG-STATE-HOME2022-10-14T15:13:01ZSamuel HunterAdd UIOP/CONFIGURE:XDG-STATE-HOMEAccording to the [XDG basedir-spec v0.8](https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html):
> There is a single base directory relative to which user-specific state data should be written. This directory is defi...According to the [XDG basedir-spec v0.8](https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html):
> There is a single base directory relative to which user-specific state data should be written. This directory is defined by the environment variable $XDG_STATE_HOME.
>
> $XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.
>
> The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:
>
> - actions history (logs, history, recently used files, …)
>
> - current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
`XDG_STATE_HOME` is the only base directory that ASDF/CONFIGURE does not implement. I think it ought to be straightforward:
```lisp
(defun xdg-state-home (&rest more)
"The base directory relative to which user specific state files should be saved.
Returns an absolute directory pathname.
MORE may contain specifications for a subpath relative to this directory: a
subpathname specification and keyword arguments as per RESOLVE-LOCATION \(see
also \"Configuration DSL\"\) in the ASDF manual."
(resolve-absolute-location
`(,(or (getenv-absolute-directory "XDG_STATE_HOME")
(os-cond
((os-windows-p) (xdg-data-home "state/"))
(t (subpathname* (user-homedir-pathname) ".local/state/"))))
,more)))
```
I'm open to feedback on this. The only problem running through my head is that introducing a new symbol to UIOP/CONFIGURE has the potential to break systems `:use`ing this package, though I don't know ASDF's policy on this.https://gitlab.common-lisp.net/asdf/asdf/-/issues/131Add :asdf3.4 to features2022-10-21T21:06:27ZRobert GoldmanAdd :asdf3.4 to featuresSince we assume that ASDF 3.4 may have features that will not be backwards compatible, we should add a new feature. Put this here so as not to forget.Since we assume that ASDF 3.4 may have features that will not be backwards compatible, we should add a new feature. Put this here so as not to forget.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/132"Computing just-done stamp" warning for system which has package-inferred dep...2022-11-07T13:29:31ZAlexander Artemenko"Computing just-done stamp" warning for system which has package-inferred dependency in the defsystem-depends-on listThis behavior was experienced on ASDF version 3.3.5.3.
Here is the full code for reproducing the problem:
https://github.com/svetlyak40wt/asdf-just-done-bug
This is the smallest possible example how to reproduce this problem:
* `bar` ...This behavior was experienced on ASDF version 3.3.5.3.
Here is the full code for reproducing the problem:
https://github.com/svetlyak40wt/asdf-just-done-bug
This is the smallest possible example how to reproduce this problem:
* `bar` defsystem-depends-on `foo` and `foo` is a package-inferred system.
* `minor` defsystem-depends-on `blah` and `blah` is not package-inferred.
When you'll call `(asdf:load-system "bar")` in the REPL a few times, you'll see these two warnings:
```
WARNING:
Computing just-done stamp for action (ASDF/LISP-ACTION:LOAD-OP "foo/foo"
"file-type"), but dependency (ASDF/LISP-ACTION:COMPILE-OP
"foo/foo"
"file-type") wasn't done yet!
WARNING:
Computing just-done stamp for action (ASDF/LISP-ACTION:COMPILE-OP
"foo/foo"), but dependency (ASDF/LISP-ACTION:COMPILE-OP
"foo/foo"
"file-type") wasn't done yet!
```
but nothing like that happens when you are doing `(asdf:load-system "minor")`.
The similar warnings happen when you have:
`bar` defsystem-depends-on `foo` and `foo` is usual system but depends on some other package-inferred system.https://gitlab.common-lisp.net/asdf/asdf/-/issues/133DEFINE-PACKAGE does not accept strings2022-11-13T01:10:46ZMichał Herdaphoe@disroot.orgDEFINE-PACKAGE does not accept stringsASDF 3.3.6.
```lisp
(uiop:define-package #:foo
(:use #:cl)
(:import-from #:alexandria "DEFINE-CONSTANT"))
The value
"DEFINE-CONSTANT"
is not of type
SYMBOL
[Condition of type TYPE-ERROR]
```
I guess that strings not being a...ASDF 3.3.6.
```lisp
(uiop:define-package #:foo
(:use #:cl)
(:import-from #:alexandria "DEFINE-CONSTANT"))
The value
"DEFINE-CONSTANT"
is not of type
SYMBOL
[Condition of type TYPE-ERROR]
```
I guess that strings not being accepted in `DEFINE-PACKAGE` is a bug since `DEFINE-PACKAGE` is meant to be a drop-in replacement for `DEFPACKAGE`; it's just possible that no one reported that bug because using strings in package designators is kind of a thing of the past whereas `DEFINE-PACKAGE` is a thing of the future.
Did I get it right, or did strings get explicitly dropped from `DEFINE-PACKAGE`, at which point it should be documented somewhere?https://gitlab.common-lisp.net/asdf/asdf/-/issues/134Trouble specializing generic functions to act on child systems of an instance...2022-11-15T05:00:39ZAdrian FullmerTrouble specializing generic functions to act on child systems of an instance of package-inferred-systemSince the default system definition search function which concerns package inferred systems defines child systems exclusively with `package-inferred-system` as their class, it is not clear how to specialize generic functions such as `aro...Since the default system definition search function which concerns package inferred systems defines child systems exclusively with `package-inferred-system` as their class, it is not clear how to specialize generic functions such as `around-compile-hook` for those systems without touching asdf internals or defining a method on a built-in asdf class.
The search function already allows subclasses of package-inferred-system to be the primary system, so one solution would be to replace `:class package-inferred-system` with `:class ,(class-of top)` in `sysdef-package-inferred-system-search` (top is the instantiated primary system)https://gitlab.common-lisp.net/asdf/asdf/-/issues/135Add WHEN-LET to UIOP2022-11-14T15:52:32ZRobert GoldmanAdd WHEN-LET to UIOPUIOP has the `if-let` macro, lifted from Alexandria, which is generally helpful. But it makes code hard to read when there is only an if-then and not an if-then-else. For the former case, I would like to add `when-let` and replace sing...UIOP has the `if-let` macro, lifted from Alexandria, which is generally helpful. But it makes code hard to read when there is only an if-then and not an if-then-else. For the former case, I would like to add `when-let` and replace single-sided uses of `if-let` with `when-let`.Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/136Sign ASDF releases and tags2022-11-18T23:36:21ZNikolaos ChatzikonstantinouSign ASDF releases and tagsASDF releases could be signed with gpg. I also recommend that annotated tags are used instead of lightweight git tags; the tags themselves can also be signed.
e.g. with contents in `.gitconfig` such as
```
[user]
name = <name>
email ...ASDF releases could be signed with gpg. I also recommend that annotated tags are used instead of lightweight git tags; the tags themselves can also be signed.
e.g. with contents in `.gitconfig` such as
```
[user]
name = <name>
email = <email>
signingKey = <fingerprint>
[commit]
gpgSign = true
[tag]
gpgSign = true
[push]
gpgSign = if-asked
```
The key could be listed in the common-lisp.net web page but also on the key servers such as https://keyserver.ubuntu.com/ and https://keys.openpgp.org/ and so on. I believe they propagate automatically so listing on one of them is enough, e.g. I find my key on https://pgp.mit.edu/ even though I never uploaded it.https://gitlab.common-lisp.net/asdf/asdf/-/issues/137import-from behaves differently when imported symbol does not exist in the so...2023-03-03T16:58:55ZEmir Unerimport-from behaves differently when imported symbol does not exist in the source packageTried in SBCL:
```lisp
(uiop:define-package #:P0)
(uiop:define-package #:P1 (:import-from #:P0 #:sym0))
```
Executing above interns `SYM0` into `P0`.
```lisp
(defpackage #:P0)
(defpackage #:P1 (:import-from #:P0 #:sym0))
```
Executi...Tried in SBCL:
```lisp
(uiop:define-package #:P0)
(uiop:define-package #:P1 (:import-from #:P0 #:sym0))
```
Executing above interns `SYM0` into `P0`.
```lisp
(defpackage #:P0)
(defpackage #:P1 (:import-from #:P0 #:sym0))
```
Executing above raises an error with the option to intern. Shouldn't `uiop:define-package` behave same as `defpackage`?3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/138Feature enhancement: add OPERATION-FAILED-CONDITION2023-04-01T19:59:10ZRobert GoldmanFeature enhancement: add OPERATION-FAILED-CONDITIONParticularly for `test-op`, it would be helpful to have a special condition for operation failures.
Then in testing scripts we could add code that would watch for this handler, and exit with a non-zero exit status when it is observed. ...Particularly for `test-op`, it would be helpful to have a special condition for operation failures.
Then in testing scripts we could add code that would watch for this handler, and exit with a non-zero exit status when it is observed. Right now there's a lot of custom-scripting that must be done for this...https://gitlab.common-lisp.net/asdf/asdf/-/issues/139serial dependency spec and individual `:depends-on` can appear in the same sy...2023-06-02T01:55:06ZRobert Goldmanserial dependency spec and individual `:depends-on` can appear in the same system definitionI just found this in [cl-async.asd](https://github.com/orthecreedence/cl-async/blob/909c691ec7a3bfe98bbec536ab55d7eac8990a81/cl-async.asd#L29-L63).
It never occurred to me that this would be possible. I believe that this should be an er...I just found this in [cl-async.asd](https://github.com/orthecreedence/cl-async/blob/909c691ec7a3bfe98bbec536ab55d7eac8990a81/cl-async.asd#L29-L63).
It never occurred to me that this would be possible. I believe that this should be an error condition, since either the explicit `:depends-on` specs will be vacuous, or they will contradict the serial specification.
I haven't thoroughly checked, but I don't see that ASDF checks dependency graphs for consistency. If the dependencies don't make an _acyclic_ digraph, then ASDF should probably signal an error.https://gitlab.common-lisp.net/asdf/asdf/-/issues/140uiop:ensure-directory-pathname mangles pathname with wildcard2023-07-04T22:47:59ZSome Oneuiop:ensure-directory-pathname mangles pathname with wildcardHello, using UIOP 3.3.5 on SBCL 2.3.5, I'm getting the following results:
```
CL-USER> (uiop:ensure-pathname "*")
#P"\\*"
CL-USER> (uiop:ensure-directory-pathname *)
#P"\\\\\\*/"
```
which can't be used to address a directory named "*" a...Hello, using UIOP 3.3.5 on SBCL 2.3.5, I'm getting the following results:
```
CL-USER> (uiop:ensure-pathname "*")
#P"\\*"
CL-USER> (uiop:ensure-directory-pathname *)
#P"\\\\\\*/"
```
which can't be used to address a directory named "*" anymore. I suspect that replacing `file-namestring` with `pathname-name` at https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/pathname.lisp#L333 would do the trick; at least for SBCL.Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/144Kill ABCL 1.7.1 test2023-08-28T16:06:09ZRobert GoldmanKill ABCL 1.7.1 testThis version is so old we shouldn't have to bother with it any more.This version is so old we shouldn't have to bother with it any more.Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/145Documented way of upgrading ASDF using (require "asdf") doesn't work2024-01-02T17:38:11ZHraban LuyatDocumented way of upgrading ASDF using (require "asdf") doesn't workHi all,
With latest master checked out to ~/code/common-lisp/asdf, when I do this:
```
$ CL_SOURCE_REGISTRY=$HOME/code/common-lisp/asdf sbcl
This is SBCL 2.3.9.nixos, an implementation of ANSI Common Lisp.
More information about SBCL i...Hi all,
With latest master checked out to ~/code/common-lisp/asdf, when I do this:
```
$ CL_SOURCE_REGISTRY=$HOME/code/common-lisp/asdf sbcl
This is SBCL 2.3.9.nixos, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (require "asdf")
NIL
* asdf::*asdf-version*
"3.3.1"
* (asdf:load-system "asdf")
; compiling file "/Users/user/code/common-lisp/asdf/build/asdf.lisp" (written 17 OCT 2023 03:06:55 PM):
; wrote /Users/user/.cache/common-lisp/sbcl-2.3.9.nixos-macosx-arm64/Users/user/code/common-lisp/asdf/build/asdf-tmpAAURSO1.fasl
; compilation finished in 0:00:01.994
T
* asdf::*asdf-version*
"3.3.6.1"
*
```
It's good that it loads the new ASDF explicitly at least on `(asdf:load-system "asdf")`, but shouldn't it just load it straight away on the first `(require "asdf")`?
The documentation states:
> 3.3 Upgrading ASDF
>
> If your implementation already provides ASDF 3 or later (and it should), but you want a more recent ASDF version than your implementation provides, then you just need to ensure the more recent ASDF is installed in a configured path, like any other system. We recommend you download an official tarball or checkout a release from git into ~/common-lisp/asdf/. (see Configuring ASDF to find your systems).
>
> Once the source code for ASDF is installed, you don’t need any extra step to load it beyond the usual (require "asdf"): ASDF 3 will automatically look whether an updated version of itself is available amongst the regularly configured systems, before it compiles anything else.
>
> If your implementation fails to provide ASDF 3 or later, see Replacing your implementation’s ASDF.
- https://asdf.common-lisp.dev/asdf.html#Upgrading-ASDF
Should that be changed to instructing `(require "asdf") (asdf:load-system "asdf")`?https://gitlab.common-lisp.net/asdf/asdf/-/issues/149Add repaired version of UIOP:WITH-OPTIMIZATION-SETTINGS2023-12-12T17:05:28ZRobert GoldmanAdd repaired version of UIOP:WITH-OPTIMIZATION-SETTINGSFaré writes:
> it was originally meant to ensure that the optimization settingsused by ASDF should not be affected by those used outside of it, nor
affect them, so as to avoid weird side-effects wherein the behavior of a system depends ...Faré writes:
> it was originally meant to ensure that the optimization settingsused by ASDF should not be affected by those used outside of it, nor
affect them, so as to avoid weird side-effects wherein the behavior of a system depends on which other systems you did or did not build
before it, which was causing "interesting" effects at times.
I didn't have the ability to repair it (see #148), so am removing it from UIOP. But rewriting it, and then using it ASDF `compile-op` would be a worthy thing to do to avoid the above issues.https://gitlab.common-lisp.net/asdf/asdf/-/issues/150On Allegro CL, UPGRADE-ASDF loads ASDF multiple times2024-01-04T23:00:44ZRobert GoldmanOn Allegro CL, UPGRADE-ASDF loads ASDF multiple times# Description
Initially loading ASDF with `(require :asdf)`, putting the ASDF source on `*central-registry*` and then invoking `(asdf:upgrade-asdf)` results in `asdf.fasl` being loaded multiple times, as shown here:
```
; Fast loading
...# Description
Initially loading ASDF with `(require :asdf)`, putting the ASDF source on `*central-registry*` and then invoking `(asdf:upgrade-asdf)` results in `asdf.fasl` being loaded multiple times, as shown here:
```
; Fast loading
; /Users/rpg/.cache/common-lisp/acl-11.0-macosx-64-bit_apple_silicon/Users/rpg/lisp/asdf/build/asdf.fasl
Warning: FIRST-FEATURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: IMPLEMENTATION-TYPE is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: *IMPLEMENTATION-TYPE* is defined more than once as `variable'
in file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: OPERATING-SYSTEM is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: ARCHITECTURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
; Upgrading ASDF from version 3.2.0 to version 3.3.6.2
; Loading /Users/rpg/lisp/asdf/asdf.asd
; Fast loading
; /Users/rpg/.cache/common-lisp/acl-11.0-macosx-64-bit_apple_silicon/Users/rpg/lisp/asdf/build/asdf.fasl
Warning: FIRST-FEATURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: IMPLEMENTATION-TYPE is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: *IMPLEMENTATION-TYPE* is defined more than once as `variable'
in file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: OPERATING-SYSTEM is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: ARCHITECTURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
; Loading /Users/rpg/lisp/asdf/asdf.asd
; Fast loading
; /Users/rpg/.cache/common-lisp/acl-11.0-macosx-64-bit_apple_silicon/Users/rpg/lisp/asdf/build/asdf.fasl
Warning: FIRST-FEATURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: IMPLEMENTATION-TYPE is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: *IMPLEMENTATION-TYPE* is defined more than once as `variable'
in file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: OPERATING-SYSTEM is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: ARCHITECTURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
; Loading /Users/rpg/lisp/asdf/asdf.asd
; Fast loading
; /Users/rpg/.cache/common-lisp/acl-11.0-macosx-64-bit_apple_silicon/Users/rpg/lisp/asdf/build/asdf.fasl
Warning: FIRST-FEATURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: IMPLEMENTATION-TYPE is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: *IMPLEMENTATION-TYPE* is defined more than once as `variable'
in file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: OPERATING-SYSTEM is defined more than once as `operator' in
file /Users/rpg/lisp/asdf/build/asdf.lisp.
Warning: ARCHITECTURE is defined more than once as `operator' in file
/Users/rpg/lisp/asdf/build/asdf.lisp.
; Loading /Users/rpg/lisp/asdf/asdf.asd
```
# Replication
I attach a shell script, [allegro-replication.sh](/uploads/a66c4ece77bf8193a6863f1a6698f216/allegro-replication.sh), that can be used to replicate the issue. To run it, assign the environment variables `ALISP` and `ASDF_DIR` appropriately, e.g.:
ALISP=/Applications/AllegroCL64.app/Contents/Resources/alisp ASDF_DIR=/Users/rpg/lisp/asdf/ source allegro-replication.sh
# Platforms
I have verified this on Allegro 10.1 and 11. I don't *believe* it's happening on other lisps. It seems to happen on the Express edition, as well, so is replicable by people who don't have a paid Allegro license.
/cc @frideauhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/153Confusing behavior when using an empty string as a system name2024-01-29T16:04:25ZAlexander FedorovConfusing behavior when using an empty string as a system nameWhen quicklisp is loaded or `*central-registry*` is not empty, asdf can locate the system named `""`:
```lisp
;; if quicklisp is loaded
* (asdf:locate-system "")
T
NIL
#P"/home/user/quicklisp/quicklisp/"
NIL
NIL
```
```lisp
;; if quickl...When quicklisp is loaded or `*central-registry*` is not empty, asdf can locate the system named `""`:
```lisp
;; if quicklisp is loaded
* (asdf:locate-system "")
T
NIL
#P"/home/user/quicklisp/quicklisp/"
NIL
NIL
```
```lisp
;; if quicklisp is not loaded
;; $ sbcl --no-userinit
* (require :asdf)
("ASDF" "asdf" "UIOP" "uiop")
* (push #P"~/common-lisp/" asdf:*central-registry*)
(#P"~/common-lisp/")
* (asdf:locate-system "")
T
NIL
#P"/home/user/common-lisp/"
NIL
NIL
```
This leads to a confusing error message when a trying to load a system named `""`:
```lisp
* (asdf:load-system "")
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD tid=1802466 "main thread" RUNNING {1001460003}>: Error while trying to load definition for system from pathname /home/user/common-lisp/: Can't LOAD a directory: #P"/home/user/common-lisp/".
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry #<DEFINE-OP > on #<UNDEFINED-SYSTEM "">.
1: [ACCEPT ] Continue, treating #<DEFINE-OP > on #<UNDEFINED-SYSTEM ""> as having been successful.
2: Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
4: Retry ASDF operation.
5: Retry ASDF operation after resetting the configuration.
6: [ABORT ] Exit debugger, returning to top level.
((LAMBDA (CONDITION) :IN PERFORM) #<SB-INT:SIMPLE-FILE-ERROR "Can't LOAD a directory: ~s." {1004508A43}>)
source: (ERROR (QUOTE LOAD-SYSTEM-DEFINITION-ERROR) :NAME (COERCE-NAME S) :PATHNAME PATHNAME :CONDITION CONDITION)
0]
```
This also manifests when loading a system that has `:depends-on ("")`
```lisp
;; test.asd
(defsystem "test"
:depends-on (""))
```
```lisp
;; $ sbcl --no-userinit
* (require :asdf)
("ASDF" "asdf" "UIOP" "uiop")
* (push "~/common-lisp/" asdf:*central-registry*)
("~/common-lisp/")
* (asdf:load-asd (merge-pathnames "test.asd"))
#<ASDF/FIND-SYSTEM:DEFINE-OP >
#<ASDF/PLAN:SEQUENTIAL-PLAN {10014C0BD3}>
* (asdf:load-system :test)
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD tid=1802775 "main thread" RUNNING {1004840093}>: Error while trying to load definition for system from pathname /home/user/common-lisp/: Can't LOAD a directory: #P"/home/user/common-lisp/".
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry #<DEFINE-OP > on #<UNDEFINED-SYSTEM "">.
1: [ACCEPT ] Continue, treating #<DEFINE-OP > on #<UNDEFINED-SYSTEM ""> as having been successful.
2: Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
4: Retry ASDF operation.
5: Retry ASDF operation after resetting the configuration.
6: [ABORT ] Exit debugger, returning to top level.
((LAMBDA (CONDITION) :IN PERFORM) #<SB-INT:SIMPLE-FILE-ERROR "Can't LOAD a directory: ~s." {100188BC23}>)
source: (ERROR (QUOTE LOAD-SYSTEM-DEFINITION-ERROR) :NAME (COERCE-NAME S) :PATHNAME PATHNAME :CONDITION CONDITION)
0]
```https://gitlab.common-lisp.net/asdf/asdf/-/issues/154Metainformation in asdf.asd out of date2024-02-29T18:24:25ZMarkus KlinkMetainformation in asdf.asd out of dateThe metainformation in `asdf.asd` is out of date:
```
(defsystem "asdf/defsystem"
:licence "MIT"
:description "The defsystem part of ASDF"
:long-name "Another System Definition Facility"
:description "The portable defsystem for ...The metainformation in `asdf.asd` is out of date:
```
(defsystem "asdf/defsystem"
:licence "MIT"
:description "The defsystem part of ASDF"
:long-name "Another System Definition Facility"
:description "The portable defsystem for Common Lisp"
:long-description "ASDF/DEFSYSTEM is the de facto standard DEFSYSTEM facility for Common Lisp,
a successor to Dan Barlow's ASDF and Francois-Rene Rideau's ASDF2.
For bootstrap purposes, it comes bundled with UIOP in a single file, asdf.lisp."
:homepage "http://common-lisp.net/projects/asdf/"
:bug-tracker "https://launchpad.net/asdf/"
:mailto "asdf-devel@common-lisp.net"
:source-control (:git "git://common-lisp.net/projects/asdf/asdf.git")
:version (:read-file-form "version.lisp-expr")
:build-operation monolithic-concatenate-source-op
:build-pathname "build/asdf" ;; our target
:around-compile call-without-redefinition-warnings ;; we need be the same as uiop
:depends-on ("asdf/prelude" "asdf/driver")
:encoding :utf-8
:components
...
```
At least the homepage (now https://asdf.common-lisp.dev/), the bug-tracker (now https://gitlab.common-lisp.net/asdf/asdf/-/issues), the source-control (now git@common-lisp.net:asdf/asdf.git) are not reflecting the status quo.