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.