asdf merge requestshttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests2023-07-05T22:23:10Zhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/220Draft: Fix the handling of wildcards in `uiop:ensure-directory-pathname`2023-07-05T22:23:10ZRobert GoldmanDraft: Fix the handling of wildcards in `uiop:ensure-directory-pathname`Construction of a directory-pathname (with `uiop:ensure-directory-pathname`) creates an escaped pathname instead of a plain pathname.
Need to determine what happens to wildcards (specifically asterisks) when `ensure-directory-pathname` ...Construction of a directory-pathname (with `uiop:ensure-directory-pathname`) creates an escaped pathname instead of a plain pathname.
Need to determine what happens to wildcards (specifically asterisks) when `ensure-directory-pathname` is invoked on a pathname with `"*"` as name that has been created by `ensure-pathname`.
Closes #140Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/219Resolve "uiop:dumplisp compiles with warning on Allegro 11"2024-01-04T19:03:30ZRobert GoldmanResolve "uiop:dumplisp compiles with warning on Allegro 11"Closes #141Closes #141Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/218Add support for Clasp bytecode2023-06-19T17:00:42ZTarn Burtontwburton@gmail.comAdd support for Clasp bytecodeClasp now has a bytecode compiler and can save bytecode into FASL files. The default build mode (non-bytecode) is FASO and has be used for over two years. Clasp no longer builds using object files and so much of the logic in `uiop:compil...Clasp now has a bytecode compiler and can save bytecode into FASL files. The default build mode (non-bytecode) is FASO and has be used for over two years. Clasp no longer builds using object files and so much of the logic in `uiop:compile-file*` and elsewhere concerning object files is no longer needed. Specifically, Clasp uses atomic (as much as possible) file renames in `cl:compile-file` and in the FASL linkers. This makes the temporary file creation and renaming in `uiop:compile-file*` unneeded. In fact, it actually causes problems when we run Cando on an HPC cluster. I've removed all that logic of the for Clasp, but left it for other implementations.
I've also fixed some other miscellaneous things like the regression testing for Clasp which had some incorrect command line options. It may interest you to know that we are running the ASDF tests as part of our own [regression testing](https://github.com/clasp-developers/clasp/blob/4b20e34501874e46ab01334a4772823ba090109b/.github/workflows/test.yml#L82-L85).
FYI @drmeisterhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/217Draft: Add test verifying issue 137.2023-03-03T16:58:57ZRobert GoldmanDraft: Add test verifying issue 137.Initially this simply has a test verifying the existence of #137. Eventually this MR should grow to include a fix.Initially this simply has a test verifying the existence of #137. Eventually this MR should grow to include a fix.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/215Catch non-existent packages in :LOCAL-NICKNAMES clause2022-10-20T14:34:31ZMaciej Katafiasz (mathrick)Catch non-existent packages in :LOCAL-NICKNAMES clauseFixes #127Fixes #1273.4.0https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/214Draft: Fix for issue 127.2022-09-12T14:43:44ZRobert GoldmanDraft: Fix for issue 127.If you give a bad argument list to the `:local-nicknames` option of `define-package` the error messages are generated by the implementation. Those can be confusing, so now we check them ourselves, and issue a bespoke error.
Fixes #127If you give a bad argument list to the `:local-nicknames` option of `define-package` the error messages are generated by the implementation. Those can be confusing, so now we check them ourselves, and issue a bespoke error.
Fixes #127Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/213Bind package to cl user2022-07-26T23:18:47ZRobert GoldmanBind package to cl userBind the value of `*package*` to `common-lisp-user` package when compiling or loading lisp code. This binding can be overridden, but avoids anomalies that happen when ASDF is executed in an odd `*package*` context. See #124Bind the value of `*package*` to `common-lisp-user` package when compiling or loading lisp code. This binding can be overridden, but avoids anomalies that happen when ASDF is executed in an odd `*package*` context. See #124Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/212Test for issue 124.2022-07-26T20:58:47ZRobert GoldmanTest for issue 124.If `*package*` is set to a package that does not import `defpackage`,
then loading the test system will fail.
This test, which is set as an expected failure right now, demonstrates the existence of #124If `*package*` is set to a package that does not import `defpackage`,
then loading the test system will fail.
This test, which is set as an expected failure right now, demonstrates the existence of #124https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/211Add clasp support for uiop/launch-program2022-06-28T21:27:38ZChristian SchafmeisterAdd clasp support for uiop/launch-programClasp now supports uiop/launch-program.
Copied source code from ecl into clasp to support uiop/launch-program
so API's between clasp and ecl are identical.Clasp now supports uiop/launch-program.
Copied source code from ecl into clasp to support uiop/launch-program
so API's between clasp and ecl are identical.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/210LAUNCH-PROGRAM: Support augmenting the child process's environment2022-06-28T21:27:36ZEric TimmonsLAUNCH-PROGRAM: Support augmenting the child process's environmentAdd :ADDITIONAL-ENVIRONMENT argument to LAUNCH-PROGAM and RUN-PROGRAM. This
must be an alist with string keys and values, representing environment
variables to add to the child's environment.
Supported on ABCL, Allegro, Clozure, CMUCL, ...Add :ADDITIONAL-ENVIRONMENT argument to LAUNCH-PROGAM and RUN-PROGRAM. This
must be an alist with string keys and values, representing environment
variables to add to the child's environment.
Supported on ABCL, Allegro, Clozure, CMUCL, ECL, Lispworks, and SBCL.
Called this the rather verbose :ADDITIONAL-ENVIRONMENT so as to not have any
collision with the corresponding argument in the implementation. This is for
backwards compatibility, so that if someone is augmenting the environment using
the implementation's native argument we don't stomp on their
toes. Additionally, it makes super clear that the environment is augmented
instead of replaced (something that's often ambiguous in the implementations).
Some quirks:
- If you provide this argument on ECL, then ECL no longer searches the path for
the COMMAND. PR
<https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/272>
submitted upstream to address this.
- On CMUCL, the default environment of the child is the same environment in
which CMUCL started, *not* the current environment. This behavior persists
when using :ADDITIONAL-ENVIRONMENT as well.
Documentation for supported implementations:
- ABCL: <https://www.abcl.org/releases/1.9.0/abcl-1.9.0.pdf> Page 84
- Allegro: <https://franz.com/support/documentation/10.0/doc/operators/excl/run-shell-command.htm>
- Clozure: <https://ccl.clozure.com/docs/ccl.html#running-other-programs-as-subprocesses>
- CMUCL: <https://cmucl.org/docs/cmu-user/html/Running-Programs-from-Lisp.html>
- ECL: Couldn't find. Needed to go into source code.
- Lispworks: <http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-708.htm>
- SBCL: <http://www.sbcl.org/manual/#Running-external-programs>
Notes on unsupported implementations:
- MKCL: Appears to have no support at the moment. See:
<https://gitlab.common-lisp.net/mkcl/mkcl/-/blob/cbb4c7c0e7a08aa95c0e864204b72a3aae59e8ef/src/c/unixsys.c#L808>
- SCL: Could probably be supported. Documentation at
<https://lisphub.jp/doc/scl/run-program.html> shows it has an :ENVIRONMENT
argument. But, there's not enough detail to know if it augments or replaces
the current environment. Given SCL's lineage (fork of CMUCL), I expect it to
replace the environment. But even if that were the case, I could not find any
equivalent to CMUCL's EXT:*ENVIRONMENT-LIST* variable in SCL documentation.
I did not attempt to extend this to implementations not already supported by
LAUNCH-PROGRAM, as those all currently fallback to something equivalent to
system(3). I think that any effort spent on those implementations is better
spent getting them to implement a proper API we can use via LAUNCH-PROGRAM
instead of figuring out how to assemble a shell command that robustly sets the
environment variables before running the user's command. Theoretically it
wouldn't be too hard on POSIX OSes (just use /usr/bin/env), but I have zero
clue on doing it properly in Windows.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/209Draft: Add test for :if-feature propagation.2022-05-18T15:51:11ZRobert GoldmanDraft: Add test for :if-feature propagation.The concern here is that ASDF has no way to detect that a feature has
changed and recompile files accordingly, potentially leaving users
with stale FASL files.The concern here is that ASDF has no way to detect that a feature has
changed and recompile files accordingly, potentially leaving users
with stale FASL files.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/208Modify tests for ABCL 1.9 release.2022-08-02T14:09:14ZRobert GoldmanModify tests for ABCL 1.9 release.Update for tests that can now be expected to pass instead of failing.
Also fix issue #115Update for tests that can now be expected to pass instead of failing.
Also fix issue #1153.3.6Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/207Doc fixes2024-01-27T18:57:25ZRobert GoldmanDoc fixesFix a number of issues in the discussion of how to create a custom operation, identified by Zaque and @gefjon
Discussion of `component-depends-on` and, to a lesser extent `input-files` were out of date.
Also, in passing, fixed a docst...Fix a number of issues in the discussion of how to create a custom operation, identified by Zaque and @gefjon
Discussion of `component-depends-on` and, to a lesser extent `input-files` were out of date.
Also, in passing, fixed a docstring typo.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/206Iss1082024-01-26T23:50:55ZRobert GoldmanIss108Address #108 by checking for presence of Allegro patch fixing the misbehavior.
Don't have any great ideas about how to test this, but it should be feasible. Complex, though.Address #108 by checking for presence of Allegro patch fixing the misbehavior.
Don't have any great ideas about how to test this, but it should be feasible. Complex, though.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/205Expand UIOP:DEFINE-PACKAGE docstring.2022-02-23T17:22:00ZRobert GoldmanExpand UIOP:DEFINE-PACKAGE docstring.Specify behavior of DEFINE-PACKAGE without specified USE.Specify behavior of DEFINE-PACKAGE without specified USE.3.3.6https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/204Add allegro to CI2022-01-20T23:31:15ZEric TimmonsAdd allegro to CII finally got the Allegro Express Docker image built (had some technical issues related to it being 32-bit only that were only recently resolved).
Some TODOs before this is ready for merging:
- [x] Make sure tests actually pass.
- [x] ...I finally got the Allegro Express Docker image built (had some technical issues related to it being 32-bit only that were only recently resolved).
Some TODOs before this is ready for merging:
- [x] Make sure tests actually pass.
- [x] Confirm with Franz that they're happy with the image. I reached out to them before doing it to explain my plans and got their approval, but I think it'll be nice to just touch bases again.
- [x] Confirm that using it for ASDF CI purposes is fine with the Express license. My read is that it's fine so long as the ASDF development is non-commercial. But I'll leave that decision up to @rgoldman.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/203Refine DEFINE-PACKAGE docstring.2022-01-17T21:08:35ZRobert GoldmanRefine DEFINE-PACKAGE docstring.Expand on the use of :UNINTERN keyword argument, based on discussion
around issue #85.
/cc @gefjonExpand on the use of :UNINTERN keyword argument, based on discussion
around issue #85.
/cc @gefjon3.3.6https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/202Draft: address issue 1022022-07-27T14:31:04ZRobert GoldmanDraft: address issue 102See #102
So far have only added a test to replicate the issue.
/cc @remexreSee #102
So far have only added a test to replicate the issue.
/cc @remexre3.3.6https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/201Adds FAQ item on customizing paths for sources and binaries, fixes typo2022-02-14T20:13:00ZNathan RingoAdds FAQ item on customizing paths for sources and binaries, fixes typoIt's my first time writing Texinfo, so if there's some additional linter or something to run, I can do so!
This adds a short FAQ item describing the small build script I use for building binaries as part of a larger (mostly non-CL) proj...It's my first time writing Texinfo, so if there's some additional linter or something to run, I can do so!
This adds a short FAQ item describing the small build script I use for building binaries as part of a larger (mostly non-CL) project. It hopefully conforms to best practices; if not, I'll change it such that it does.3.3.6https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/199Better handling of missing packages in DEFINE-PACKAGE :IMPORT-FROM2022-01-10T01:07:58ZEric TimmonsBetter handling of missing packages in DEFINE-PACKAGE :IMPORT-FROMCloses #98 #101
Signal a style warning if we `:import-from` using a package that does not exist and an empty symbol list. Remains an error to `:import-from` a package that does not exist with a non-empty symbol list.
Add some tests to...Closes #98 #101
Signal a style warning if we `:import-from` using a package that does not exist and an empty symbol list. Remains an error to `:import-from` a package that does not exist with a non-empty symbol list.
Add some tests to try and ensure `:uiop/package` and `:uiop/package-local-nicknames` are not modified.3.3.6Robert GoldmanRobert Goldman