asdf issueshttps://gitlab.common-lisp.net/groups/asdf/-/issues2024-01-28T17:15:18Zhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/152On Allegro 11 test-deferred-warnings fails2024-01-28T17:15:18ZRobert GoldmanOn Allegro 11 test-deferred-warnings failsIt looks like Allegro is writing something unreadable into the `.allegro-warnings` file or possibly it's encountering an error trying to write something into that file that cannot be printed readably.It looks like Allegro is writing something unreadable into the `.allegro-warnings` file or possibly it's encountering an error trying to write something into that file that cannot be printed readably.3.3.7Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/151How to declare arbitrary CLI tasks in an asdf configuration?2024-01-11T15:20:11ZAndrew PennebakerHow to declare arbitrary CLI tasks in an asdf configuration?Hi,
I would like to replace the old `make` UNIX tool in my Common Lisp projects with asdf. But I am having trouble finding documentation for how to declare arbitrary shell command tasks in an asdf configuration. Can you please provide a...Hi,
I would like to replace the old `make` UNIX tool in my Common Lisp projects with asdf. But I am having trouble finding documentation for how to declare arbitrary shell command tasks in an asdf configuration. Can you please provide a link to this documentation?
For example, in addition to building and testing my projects, I often declare a task hierarchy of linting steps.https://gitlab.common-lisp.net/asdf/asdf/-/issues/148With-optimization-settings has wrong backquote/comma2024-01-28T17:19:10ZYehouda HarpazWith-optimization-settings has wrong backquote/commahttps://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/lisp-build.lisp#L114
This line has a backquote where it needs a quote (before **(optimize**) and a redundant comma (before **settings**). It should be:
```
,@(when settings `(...https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/lisp-build.lisp#L114
This line has a backquote where it needs a quote (before **(optimize**) and a redundant comma (before **settings**). It should be:
```
,@(when settings `((proclaim '(optimize ,@settings))))
```
On LispWorks, without the fix:
```
CL-USER 3 > (pprint (macroexpand '(uiop/lisp-build:with-optimization-settings (((debug 2) (safety 1))) body)))
(LET ((COMPILER::*OPTIMIZATION-LEVEL* COMPILER::*OPTIMIZATION-LEVEL*)) (PROCLAIM `(OPTIMIZE ,@((DEBUG 2) (SAFETY 1)))) BODY)
```
with the fix:
```
CL-USER 24 > (pprint (macroexpand '(uiop/lisp-build:with-optimization-settings (((debug 2) (safety 1))) body)))
(LET ((COMPILER::*OPTIMIZATION-LEVEL* COMPILER::*OPTIMIZATION-LEVEL*)) (PROCLAIM '(OPTIMIZE (DEBUG 2) (SAFETY 1))) BODY)
```3.3.7https://gitlab.common-lisp.net/asdf/asdf/-/issues/147Parsing non-standard clauses for defpackage in package inferred systems2024-01-28T17:16:17ZAlexander FedorovParsing non-standard clauses for defpackage in package inferred systemsWhen using package inferred systems, if the `defpackage` form has a non-standard clause that is not one of `uiop:define-package` clauses, an error is signaled. This doesn't seems to be useful, especially since such extensions to defpacka...When using package inferred systems, if the `defpackage` form has a non-standard clause that is not one of `uiop:define-package` clauses, an error is signaled. This doesn't seems to be useful, especially since such extensions to defpackage seem to be explicitly allowed by the standard.
Example:
```lisp
;;; test.asd
(defsystem "test"
:class :package-inferred-system
:depends-on ("test/test"))
```
```lisp
;;; test.lisp
(defpackage #:test/test
#+sbcl (:lock t) ; this is sbcl specific extension
(:use #:cl))
```
Trying to load the system:
```
$ sbcl --noinform --load test.asd
* (asdf:test-system :test)
debugger invoked on a SB-KERNEL:CASE-FAILURE @53540A5D in thread
#<THREAD tid=2102596 "main thread" RUNNING {10047A0113}>:
:LOCK fell through ECASE expression.
Wanted one of (:USE :MIX :REEXPORT :USE-REEXPORT :MIX-REEXPORT :IMPORT-FROM
:SHADOWING-IMPORT-FROM :NICKNAMES :DOCUMENTATION :SHADOW
:EXPORT :INTERN ...).
;; behavior doesn't change when using ASDF:LOAD-ASD instead of LOAD
```3.3.7Phoebe GoldmanPhoebe Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/146(SETF (UIOP:GETENV VAR) NIL) should unset environment variable VAR2023-10-30T15:21:20ZMichaël Le Barbier(SETF (UIOP:GETENV VAR) NIL) should unset environment variable VARWhen an environment variable is not set, then UIOP:GETENV returns NIL when trying to retrieve the value of that variable. However NIL is not a supported value for (SETF UIOP:GETENV) so that the following code does not work as expected:
...When an environment variable is not set, then UIOP:GETENV returns NIL when trying to retrieve the value of that variable. However NIL is not a supported value for (SETF UIOP:GETENV) so that the following code does not work as expected:
```common-lisp
(flet ((some-action (value)
(declare (ignore value)))
(ensure-environment-is-clean ()
(unless (eq nil (uiop:getenv "VAR"))
(error "The variable VAR should not be bound."))))
(let ((saved-value
(uiop:getenv "VAR")))
(ensure-environment-is-clean)
(setf (uiop:getenv "VAR") "alternative value")
(unwind-protect (some-action (uiop:getenv "VAR"))
(setf (uiop:getenv "VAR") saved-value))
(ensure-environment-is-clean)))
```
The expected behaviour is that the snippet of code above completes successfully but on SBCL it returns an error. I am not sure what is the behaviour of other implementations.https://gitlab.common-lisp.net/asdf/asdf/-/issues/143uiop: Remember single/multi-threaded in the implementation-identifier.2023-09-19T18:29:47ZPhilipp Marekuiop: Remember single/multi-threaded in the implementation-identifier.I'm comparing performance for single- and multi-threaded builds.
The FASL files for SBCL are dependent on ST/MT, though; so I can't just switch the SBCL binary and re-test, because the FASLs are incompatbile, get rejected, and need to b...I'm comparing performance for single- and multi-threaded builds.
The FASL files for SBCL are dependent on ST/MT, though; so I can't just switch the SBCL binary and re-test, because the FASLs are incompatbile, get rejected, and need to be recompiled every time.
I have a proof-of-concept patch at https://github.com/sbcl/sbcl/commit/1269dab756151b4d8c6347a0ca52e83b7926a68e that adds the ST/MT information to the implementation-identifier - then the FASLs land in different trees, and the binary just chooses the matching files.
I'm not sure whether the string `"singlethreaded"` is too long, as it gets added to the tree structure depth which is limited to 255 characters - but it's at least a starting point for discussion.https://gitlab.common-lisp.net/asdf/asdf/-/issues/142WITH-TEMPORARY-FILE gives warnings when pathname variable is not used2023-08-14T15:07:17ZRobert GoldmanWITH-TEMPORARY-FILE gives warnings when pathname variable is not usedI had some code with `with-temporary-file` that did not use its `pathname` variable in the block after `:close-stream`. Specifically, I had code in the block before that took the `namestring` of the pathname and used *that* in the suffi...I had some code with `with-temporary-file` that did not use its `pathname` variable in the block after `:close-stream`. Specifically, I had code in the block before that took the `namestring` of the pathname and used *that* in the suffix.
This caused an "unused variable" warning to be raised.
This can be fixed by declaring the pathname variable to be `ignorable` in the suffix (the "after function").Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/141uiop:dumplisp compiles with warning on Allegro 112024-01-28T17:18:23ZRobert Goldmanuiop:dumplisp compiles with warning on Allegro 11When it is loaded, ASDF defines a portable `dumplisp` with the following snippet of code for Allegro:
```
(progn
(sys:resize-areas :global-gc t :pack-heap t :sift-old-areas t :tenure t) ; :new 5000000
(excl:dumplisp :name ...When it is loaded, ASDF defines a portable `dumplisp` with the following snippet of code for Allegro:
```
(progn
(sys:resize-areas :global-gc t :pack-heap t :sift-old-areas t :tenure t) ; :new 5000000
(excl:dumplisp :name filename :suppress-allegro-cl-banner t))
```
On the current Allegro beta for version 11 this yields the following warning:
```
Warning: SYSTEM:RESIZE-AREAS: :OLD argument not given when expanding or packing heap. If minimal oldspace is desired add an explicit :OLD 0 argument pair. For minimal change to oldspace size, specify :NO-CHANGE as the value of :OLD.
Problem detected when processing
(SYS:RESIZE-AREAS :GLOBAL-GC T :PACK-HEAP T :SIFT-OLD-AREAS T :TENURE T)
inside <...>
inside (BLOCK DUMP-IMAGE ...)
inside (COMP::NAMED-FUNCTION-1 ...)
inside (EXCL:COMPILER-LET ...)
inside (THE EXCL::KNOWN-FUNCTION ...)
inside (EXCL:NAMED-ANNOTATED-FUNCTION ...)
inside (LET ...)
inside (LET* ((#:G188535 (LET (#) ...))) ...)
Warning: SYSTEM:RESIZE-AREAS: :OLD-CODE argument
```
This breaks test-clean-build.
For now, the solution seems to be to add `:old :no-change` to the arguments.3.3.7Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/129Handle :IMPORT-FROM in DEFINE-PACKAGE :MIX2024-01-28T17:20:24ZMichał Herdaphoe@disroot.orgHandle :IMPORT-FROM in DEFINE-PACKAGE :MIXIs it possible to modify the algorithm used by `UIOP:DEFINE-PACKAGE` `:MIX` option to handle explicit `:IMPORT-FROM`s in a meaningful manner?
Reason: I have attempted to define a package which mixes my own package with Closer MOP's `CLO...Is it possible to modify the algorithm used by `UIOP:DEFINE-PACKAGE` `:MIX` option to handle explicit `:IMPORT-FROM`s in a meaningful manner?
Reason: I have attempted to define a package which mixes my own package with Closer MOP's `CLOSER-COMMON-LISP` package, but the package `CLOSER-COMMON-LISP` uses explicit `:IMPORT-FROM`s in https://github.com/pcostanza/closer-mop/blob/master/closer-mop-packages.lisp#L269.
The smallest reproducible case I've found is `(DEFINE-PACKAGE #:FOO (:MIX :C2CL))`.
It should be a backwards-compatible change, since the current behavior is to signal a compile-time error.https://gitlab.common-lisp.net/asdf/asdf/-/issues/126Local Nicknames error2022-08-05T02:03:17ZHannah MillerLocal Nicknames errorI am trying to install Lisp Stat, and the lead dev of Lisp Stat says that I have discovered a bug in UIOP. Relevant code snippets are below, and our full discussion thread from Lisp Stat is here: <https://github.com/Lisp-Stat/lisp-stat/i...I am trying to install Lisp Stat, and the lead dev of Lisp Stat says that I have discovered a bug in UIOP. Relevant code snippets are below, and our full discussion thread from Lisp Stat is here: <https://github.com/Lisp-Stat/lisp-stat/issues/13>
Let me know if you need more information for debugging.
## Code
```lisp
(ql:quickload :alexandria)
(uiop:define-package my-package
(:use #:cl)
(:local-nicknames (#:a #:alexandria.dev.0)))
```
## Error
```lisp
unrecognized define-package keyword :LOCAL-NICKNAMES
[Condition of type SIMPLE-ERROR]
Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1002051593}>)
Backtrace:
0: (UIOP/PACKAGE:PARSE-DEFINE-PACKAGE-FORM MY-PACKAGE ((:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))))
1: ((MACRO-FUNCTION UIOP/PACKAGE:DEFINE-PACKAGE) (UIOP/PACKAGE:DEFINE-PACKAGE MY-PACKAGE (:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))) #<unused argument>)
2: (MACROEXPAND-1 (UIOP/PACKAGE:DEFINE-PACKAGE MY-PACKAGE (:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))) #<NULL-LEXENV>)
3: (MACROEXPAND (UIOP/PACKAGE:DEFINE-PACKAGE MY-PACKAGE (:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))) #<NULL-LEXENV>)
4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (UIOP/PACKAGE:DEFINE-PACKAGE MY-PACKAGE (:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))) #<NULL-LEXENV>)
5: (EVAL (UIOP/PACKAGE:DEFINE-PACKAGE MY-PACKAGE (:USE #:CL) (:LOCAL-NICKNAMES (#:A #:ALEXANDRIA.DEV.0))))
--more--
```
## My software version info
```text
OS: Debian GNU/Linux 10 (buster) x86_64
$ sbcl --version
SBCL 2.2.6
; SLIME 2.27
CL-USER> (ql:client-version)
"2021-02-13"
CL-USER> asdf::*asdf-version*
"3.3.2"
```https://gitlab.common-lisp.net/asdf/asdf/-/issues/124Should `compile-op` bind `*package*` to CL-USER?2022-07-26T23:18:35ZPhoebe GoldmanShould `compile-op` bind `*package*` to CL-USER?I'm working with some packages that do not `(:use :cl)`, and compiling some systems which have bare, non-package-prefixed `defpackage` forms. (Sadly, I haven't convinced people to use `uiop:define-package` yet, as the SBCL distributed ve...I'm working with some packages that do not `(:use :cl)`, and compiling some systems which have bare, non-package-prefixed `defpackage` forms. (Sadly, I haven't convinced people to use `uiop:define-package` yet, as the SBCL distributed version doesn't have `:local-nicknames` support :disappointed: .) When my REPL is `in-package :SOME-PACKAGE-THAT-DOESNT-USE-CL`, doing `asdf:load-system` to compile and load a file like:
```
(defpackage #:foo
;; some defpackage clauses
)
(in-package #:foo)
;; some code or whatever
```
fails with an error, because the `defpackage` form reads as `some-package-that-doesnt-use-cl::defpackage`, which is assumed to be a call to an undefined function, `#:foo` is treated as a read from a variable, and everything falls apart. What's worse, I can't just `in-package :cl-user` at the repl and then re-run the `asdf:load-system`, because the compiled fasls are cached, so I have to change back to a cl-using package and then `asdf:load-system` with `:force t` or `:force :all`.
The obvious solution, in my mind, is to have the `perform compile-op lisp-source-file` method locally bind `*package*` to `cl-user`, with the assumption that either:
- The file intends to use `in-package` to specify the package it actually should be in, or
- The file expects to be compiled in the default package, i.e. `cl-user`.
Probably this local binding should be put in place outside of `call-with-around-compile-hook`, so that it's still possible to use `:around-compile` to locally bind `*package*`. (I hope no one does that, though. Ew.)
Would this break anything?https://gitlab.common-lisp.net/asdf/asdf/-/issues/121Question on how to cleanly refer to extension system classes2022-08-25T15:01:19ZPierre NeidhardtQuestion on how to cleanly refer to extension system classesFrom the manual, section "6.2 A more involved example":
> You should only use 'in-package' (and before it, a 'defpackage') when you're
> going to define new classes, functions, variables, macros, etc., in the '.asd'
> file, and want to...From the manual, section "6.2 A more involved example":
> You should only use 'in-package' (and before it, a 'defpackage') when you're
> going to define new classes, functions, variables, macros, etc., in the '.asd'
> file, and want to thereby avoid name clashes. Manuals for old versions of ASDF
> recommended use of such an idiom in '.asd' files, but as of ASDF 3, we recommend
> that you don't do that anymore, and instead define any ASDF extensions in their
> own system, on which you can then declare a dependency using
> ':defsystem-depends-on
But to use custom system classes, we must
> For such class names in the ASDF package, we recommend that the ':class' option
> be specified using a keyword symbol, such as
>
> :class :MY-NEW-SYSTEM-SUBCLASS
>
> This practice will ensure that package name conflicts are avoided.
> Otherwise, the symbol 'MY-NEW-SYSTEM-SUBCLASS' will be read into the
> current package _before_ it has been exported from the ASDF extension
> loaded by ':defsystem-depends-on', causing a name conflict in the
> current package.
From that, I understand that to use the `my-extension-system` custom class, we should be in the `my-extension-asdf` package, which goes against the first quotation.
Did I miss something? What's the recommended practice then?https://gitlab.common-lisp.net/asdf/asdf/-/issues/119asdf:load-asd sometimes leads to ASDF failing to find components2022-08-25T12:09:19ZPierre Neidhardtasdf:load-asd sometimes leads to ASDF failing to find componentsLet's explain this with a recipe:
- Check out https://github.com/takagi/cl-reexport
- `cd cl-reexport`
- `sbcl`
- `(asdf:load-asd "/absolute-path/to/cl-reexport-test.asd")`
- `(asdf:load-asd "/absolute-path/to/cl-reexport.asd")`
- `(asd...Let's explain this with a recipe:
- Check out https://github.com/takagi/cl-reexport
- `cd cl-reexport`
- `sbcl`
- `(asdf:load-asd "/absolute-path/to/cl-reexport-test.asd")`
- `(asdf:load-asd "/absolute-path/to/cl-reexport.asd")`
- `(asdf:test-system :cl-reexport)`
This last step succesfully runs the test but _then_ fails with ASDF complaining that the "cl-reexport-test" component cannot be found.
If I replace the `asdf:load-asd` with
```lisp
(asdf:initialize-source-registry
`(:source-registry (:tree ,(uiop:getcwd))
:inherit-configuration))
```
then it works.
Any idea what's going on? Is `asdf:load-asd` discouraged?https://gitlab.common-lisp.net/asdf/asdf/-/issues/115ABCL and unicode support2022-08-02T14:09:18ZRobert GoldmanABCL and unicode supportLooking at some of the tests for ASDF, I see that ABCL is flagged as not having Unicode support. See https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/common-lisp.lisp#L32-40
TBQH, I'm not sure what the feature `asdf-unicode`...Looking at some of the tests for ASDF, I see that ABCL is flagged as not having Unicode support. See https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/common-lisp.lisp#L32-40
TBQH, I'm not sure what the feature `asdf-unicode` is supposed to signal. The only use of this feature that I can find is here: https://gitlab.common-lisp.net/asdf/asdf/-/blob/master/uiop/stream.lisp#L94-103 In this context the variable `*utf-8-external-format*` is set to `:utf-8` when the feature is present or, when it's not (as on ABCL), it's set to `:default`.
@mevenson Will you please have a look at this and let me know if you think I should push that feature for ABCL? And if so, if there's a version at which you consider such support to be added?Mark EvensonMark Evensonhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/114How to make asdf prefer load fasl!2022-05-09T02:19:32ZjidibinlinHow to make asdf prefer load fasl!I want to know some ways to make asdf prefer to load fasl. If no fasl compiled load lisp file.I want to know some ways to make asdf prefer to load fasl. If no fasl compiled load lisp file.https://gitlab.common-lisp.net/asdf/asdf/-/issues/113consider enhance :class :precompiled-system :fasl ()2022-05-09T02:04:53Zjidibinlinconsider enhance :class :precompiled-system :fasl ():class :precompiled-system :fasl ("foo"); This code only load "foo" at last. But we may need load foo as a dependence for our system.
Usually we load a system because our system need it. So "foo" should loaded in a high priority against...:class :precompiled-system :fasl ("foo"); This code only load "foo" at last. But we may need load foo as a dependence for our system.
Usually we load a system because our system need it. So "foo" should loaded in a high priority against to the other system components.
I got this problem when i want to use common lisp develop a protocol test tool for our game project. I use cl-protobufs to generate the CL version protobuf file. But load this file is very slowly (generated protobuf code is large). Most time is wasted on compile.
So i consider to precompile the file to "fasl". I find it`s not easy to let asdf treat a fasl file as a dependence.
Eventually i find :precompiled-system :fasl can load fasl file. But it`s not what i want.https://gitlab.common-lisp.net/asdf/asdf/-/issues/101Add test to ensure `uiop/package` and `uiop/package-local-nicknames` are not ...2023-01-17T00:54:54ZEric TimmonsAdd test to ensure `uiop/package` and `uiop/package-local-nicknames` are not modifiedIt's happened at least twice now. Can either be a check on the actual text of the file or by examining the packages in an image where package.lisp is only loaded once (since the consequences of changing the package definition are undefin...It's happened at least twice now. Can either be a check on the actual text of the file or by examining the packages in an image where package.lisp is only loaded once (since the consequences of changing the package definition are undefined).3.3.6https://gitlab.common-lisp.net/asdf/asdf/-/issues/100Save how ASDF was loaded2022-01-21T04:38:34ZEric TimmonsSave how ASDF was loadedI'm annoyed that in SBCL `save-lisp-and-die` kills the image, as it makes it a bit of a pain to interactively develop an executable. Additionally, you can't do any tricks with `fork()` to work around that in multi-threaded code like SLIM...I'm annoyed that in SBCL `save-lisp-and-die` kills the image, as it makes it a bit of a pain to interactively develop an executable. Additionally, you can't do any tricks with `fork()` to work around that in multi-threaded code like SLIME/Sly.
I've been working on a library that provides an ASDF operation which spawns a new process to build the executable. It's inspired by CFFI's [`static-image-op`](https://github.com/cffi/cffi/blob/master/toolchain/static-link.lisp#L37). It loads ASDF in the new process using `(require "asdf")`, setting the source registry, and then letting ASDF self upgrade.
This *mostly* works well, but I've recently come to the conclusion that the only sane way to load ASDF is to `cl:load` it directly, with no `require` or self upgrade allowed. This lets me finely control the version of ASDF used (as ASDF won't downgrade if you `require` a newer version than you want to use) and it avoids self upgrade issues like #94 and #95.
If I load ASDF this way in the parent process, then I currently have no way to sync the version of ASDF in the child process. I plan to add an option to my system that lets you specify exactly how to load ASDF, but it'd be nice to have it do the "Right Thing" most of the time (load the exact same version of ASDF in the child as is present in the parent).
So, can we add some way for ASDF to record how it was loaded? I imagine it'd involve looking at `*asdf-session*` to determine if ASDF is doing a self upgrade. If it is, record the location of asdf.asd (or build/asdf.lisp). If it's not doing a self upgrade (heck, even if it is), then save the value of `*compile-file-pathname*` and/or `*load-pathname*`.https://gitlab.common-lisp.net/asdf/asdf/-/issues/99Need to call asdf:load-system (or equivalent) from asdf:test-system2021-12-29T03:50:47ZAlbus PirogluNeed to call asdf:load-system (or equivalent) from asdf:test-systemHi,
I'm trying to test a functionality that depends on loading systems. Thusly I ended up writing some tests that need to load a "test-system" during the tests, and I clear the system afterwards.
A simplified code for the test in questi...Hi,
I'm trying to test a functionality that depends on loading systems. Thusly I ended up writing some tests that need to load a "test-system" during the tests, and I clear the system afterwards.
A simplified code for the test in question is:
(test check-the-system-is-loaded-as-expected ()
(asdf:load-system "my-test-system-under-test-folder")
(is --check that the system loaded as expected--)
(asdf:clear-system "my-test-system-under-test-folder")
(delete-package "PACKAGE-FROM-TEST-SYSTEM"))
and, to clarify, another test relies on the same system not being loaded, so I don't think a dependency would solve the issue, it is rather a dynamic decision to load or not.
Now, I know that this feature is deprecated and may not work. What I'm wondering if there's a safer way to achieve this. Wouldn't some tests for asdf itself need loading some test systems for example? (hmm it actually might be a good idea to go check them now). OK, for example there's a hello-world-example.asd in test, which looks similar to my my-test-system-under-test-folder.
So, instead of asdf:load-system in the above test code, should I be using a lower-level operation call?
Thanks!
Albushttps://gitlab.common-lisp.net/asdf/asdf/-/issues/98UIOP:DEFINE-PACKAGE signals a TYPE-ERROR when trying to IMPORT-FROM a non-exi...2022-01-10T01:08:06ZMichał Herdaphoe@disroot.orgUIOP:DEFINE-PACKAGE signals a TYPE-ERROR when trying to IMPORT-FROM a non-existent packageOn ASDF 3.3.4.7, I just attempted to evaluate this:
```lisp
(uiop:define-package #:amb
(:use #:cl)
(:shadow #:require)
(:import-from #:alexandria
#:with-gensyms #:shuffle #:when-let #:define-constant)
(:export #:...On ASDF 3.3.4.7, I just attempted to evaluate this:
```lisp
(uiop:define-package #:amb
(:use #:cl)
(:shadow #:require)
(:import-from #:alexandria
#:with-gensyms #:shuffle #:when-let #:define-constant)
(:export #:amb #:amb-failure #:amb-failure-stack #:+empty-stack+))
```
Without Alexandria loaded via ASDF. This results in a type error and an unfriendly error message:
```
The value of UIOP/PACKAGE::FROM-PACKAGE is COMMON-LISP:NIL, which is not of type COMMON-LISP:PACKAGE.
[Condition of type COMMON-LISP:SIMPLE-TYPE-ERROR]
Restarts:
0: [STORE-VALUE] Supply a new value for UIOP/PACKAGE::FROM-PACKAGE.
1: [ABORT] Abort compilation.
2: [*ABORT] Return to SLIME's top level.
3: [ABORT] abort thread (#<THREAD "worker" RUNNING {1010F1D1B3}>)
Backtrace:
0: (SB-KERNEL:CHECK-TYPE-ERROR UIOP/PACKAGE::FROM-PACKAGE COMMON-LISP:NIL COMMON-LISP:PACKAGE COMMON-LISP:NIL)
1: (UIOP/PACKAGE::ENSURE-IMPORT "WITH-GENSYMS" #<COMMON-LISP:PACKAGE "AMB"> #<unavailable argument> #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 1 {1010F915E3}> #<COMMON-LISP:HASH-TABLE :TEST ..
Locals:
IMPORTED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 0 {1010F916A3}>
NAME = "WITH-GENSYMS"
SHADOWED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 1 {1010F915E3}>
TO-PACKAGE = #<COMMON-LISP:PACKAGE "AMB">
2: (UIOP/PACKAGE:ENSURE-PACKAGE #:AMB :NICKNAMES COMMON-LISP:NIL :DOCUMENTATION COMMON-LISP:NIL :USE (#:CL) :SHADOW (#:REQUIRE) :SHADOWING-IMPORT-FROM COMMON-LISP:NIL :IMPORT-FROM ((#:ALEXANDRIA #:WITH-G..
Locals:
#:.DEFAULTING-TEMP. = COMMON-LISP:NIL
EXPORT = (#:AMB #:AMB-FAILURE #:AMB-FAILURE-STACK #:+EMPTY-STACK+)
EXPORTED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 4 {1010F91763}>
IMPORT-FROM = ((#:ALEXANDRIA #:WITH-GENSYMS #:SHUFFLE #:WHEN-LET #:DEFINE-CONSTANT))
IMPORTED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 0 {1010F916A3}>
INHERITED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 0 {1010F91823}>
INTERN = COMMON-LISP:NIL
LOCAL-NICKNAMES = COMMON-LISP:NIL
MIX = COMMON-LISP:NIL
MIX#1 = COMMON-LISP:NIL
NAME = #:AMB
NICKNAMES = COMMON-LISP:NIL
PACKAGE = #<COMMON-LISP:PACKAGE "AMB">
PP#2 = COMMON-LISP:NIL
RECYCLE = (#:AMB)
RECYCLE#1 = (#<COMMON-LISP:PACKAGE "AMB">)
REEXPORT = COMMON-LISP:NIL
SHADOW = (#:REQUIRE)
SHADOWED = #<COMMON-LISP:HASH-TABLE :TEST COMMON-LISP:EQUAL :COUNT 1 {1010F915E3}>
SHADOWING-IMPORT-FROM = COMMON-LISP:NIL
TO-DELETE = COMMON-LISP:NIL
UNINTERN = COMMON-LISP:NIL
USE = (#:CL)
USE#1 = (#<COMMON-LISP:PACKAGE "COMMON-LISP">)
```3.3.6Robert GoldmanRobert Goldman