asdf merge requestshttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests2024-02-20T03:04:45Zhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/233Start a history document2024-02-20T03:04:45ZFrançois-René RideauStart a history documentMove some documentation from the homepage to a history document.Move some documentation from the homepage to a history document.3.4.0François-René RideauFrançois-René Rideauhttps://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/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/1873.4: :import-from-reexport clause for uiop:define-package, as per #812022-01-05T18:10:09ZPhoebe Goldman3.4: :import-from-reexport clause for uiop:define-package, as per #81As per issue #81, I implemented a `uiop:define-package` clause which imports specified symbols from a specified package, and reexports those symbols but no others. For lack of a better name, the clause is called `:import-from-reexport`. ...As per issue #81, I implemented a `uiop:define-package` clause which imports specified symbols from a specified package, and reexports those symbols but no others. For lack of a better name, the clause is called `:import-from-reexport`. I'd still welcome other suggestions. Can we just use `:reexport-from`?
My guess/hope is that this will find its home in the 3.4 release.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/181Draft: `asdf:define-file-package` macro for `package-inferred-system`2022-01-07T22:41:08ZPhoebe GoldmanDraft: `asdf:define-file-package` macro for `package-inferred-system`As discussed in issue #68
I've rewritten the manual somewhat, but I don't have much experience with texinfo, so I'd appreciate reviews on that front.As discussed in issue #68
I've rewritten the manual somewhat, but I don't have much experience with texinfo, so I'd appreciate reviews on that front.3.4.0Phoebe GoldmanPhoebe Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/169Draft: More expressive version strings and constraints2022-08-02T19:32:13ZEric TimmonsDraft: More expressive version strings and constraintsThe goal of this MR is to make specifying both version strings and version constraints more expressive.
We would like version strings to carry additional information, such as pre-release status.
We would like to expand version constrai...The goal of this MR is to make specifying both version strings and version constraints more expressive.
We would like version strings to carry additional information, such as pre-release status.
We would like to expand version constraints so that system consumers can knock out known bad versions. Additionally, system developers should be able to communicate known incompatibilities to their users.
TODO:
- [x] Get confirmation that we want our default version strings to follow [Semver](https://semver.org/spec/v2.0.0.html) grammar and ordering semantics. If not, decide on and implement another.
- [ ] Get consensus that the version-related generic functions are extensible enough to allow someone to substitute their own version string grammar and semantics.
- [x] Implement version constraints (first take at documentation is complete).
- [x] Update ASDF's build scripts to support adding pre-release information to version strings.
- [x] Update ASDF self upgrade functions to account for new version string format.
- [x] Run ASDF upgrade tests to make sure older versions of ASDF believe that newer versions are actually newer.
Closes #503.4.0Eric TimmonsEric Timmonshttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/156WIP: Record and expose provenance info for source registry2022-01-18T04:43:35ZEric TimmonsWIP: Record and expose provenance info for source registryThere was some discussion on asdf-devel on how the source registry is nearly
impossible to debug as it looks in a lot of places for configuration
information. This is an attempt to rectify that.
Goals:
+ [x] Record the reason a directo...There was some discussion on asdf-devel on how the source registry is nearly
impossible to debug as it looks in a lot of places for configuration
information. This is an attempt to rectify that.
Goals:
+ [x] Record the reason a directory is being searched for .asd files.
+ [ ] For every .asd file found in the source registry, record provenance
information as to what part of the source registry config caused that
file to be found.
+ [ ] For every .asd file found in the source registry, record if the file was
found by traversing the directory tree or if it was found in a
`.cl-source-registry.cache` file.
+ [ ] Look for .asd caches in `cl-source-registry.cache`, falling back to the
hidden version if it does not exist.
+ [ ] Add a user exposed function to print the source registry in a moderately
nice way.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/133WIP: Debug helpers2022-01-05T18:10:39ZRobert GoldmanWIP: Debug helpersSome minor local refactoring to make some aspects of ASDF initialization easier to debug.
So far
* New error message.
* New local function to enable tracing.
/cc @frideauSome minor local refactoring to make some aspects of ASDF initialization easier to debug.
So far
* New error message.
* New local function to enable tracing.
/cc @frideau3.4.0Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86Minimal syntax control2022-01-05T18:12:02ZFrançois-René RideauMinimal syntax controlMinimally control the `*readtable*` and other syntax variables used while building.Minimally control the `*readtable*` and other syntax variables used while building.3.4.0Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/230Draft: Resolve "Metainformation in asdf.asd out of date"2024-02-13T05:54:01ZRobert GoldmanDraft: Resolve "Metainformation in asdf.asd out of date"Closes #154Closes #154Robert GoldmanRobert Goldmanhttps://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/229Draft: Resolve "Confusing behavior when using an empty string as a system name"2024-01-27T21:51:54ZRobert GoldmanDraft: Resolve "Confusing behavior when using an empty string as a system name"Closes #153Closes #153Robert GoldmanRobert Goldmanhttps://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/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/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/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/192uiop: terminate-process with :pid/:process-group target support2021-11-22T16:52:47ZAlberto Ferreirauiop: terminate-process with :pid/:process-group target supportThis branch implements the new optional parameter `target` for `uiop:terminate-process`.
The `target` variable can be :pid (default) or :process-group.
Changelog:
- Unix signalling: Add new target key parameter in `%posix-send-signal`. ...This branch implements the new optional parameter `target` for `uiop:terminate-process`.
The `target` variable can be :pid (default) or :process-group.
Changelog:
- Unix signalling: Add new target key parameter in `%posix-send-signal`. All Lisp implementations under Unix now can signal all the processes of a given process group.
- Implement new key parameter :target in `uiop:terminate-process`.
- `terminate-process` used to leave children running forever
- now all children can be killed too on most Lisp implementations.
- Tests added for the new functionality, including backwards-compatibility tests.https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/188Draft: Add with-compilation-unit*2021-07-17T21:18:01ZEric TimmonsDraft: Add with-compilation-unit*A macro that expands to a standard `with-compilation-unit`, wrapped in a
condition handler. The condition handler takes all warnings signaled upon exit
of the wrapped `w-c-u`, collects them in a `deferred-warnings-error` condition
and si...A macro that expands to a standard `with-compilation-unit`, wrapped in a
condition handler. The condition handler takes all warnings signaled upon exit
of the wrapped `w-c-u`, collects them in a `deferred-warnings-error` condition
and signals it with `error`.
This behavior can be controlled using the `:asdf-deferred-warnings-behavior`
option to `with-compilation-unit*`, which defaults to the value of
`*with-compilation-unit-deferred-warnings-behavior*`, which itself defaults to
`:error`.
This was inspired by the discussion in #80 and sidesteps the issue brought up by #82.
This solution is not as nifty as the current deferred warning support, but is very simple and should work on any implementation that supports deferred warnings. Notably, we lose the ability to map deferred warnings to the file that produced them (although that could probably be fixed with some implementation specific code) and this will not nicely transfer to using separate processes to compile.
Some implementations do not support deferred warnings at all, and some support deferring them but do not resignal upon exit of the compilation unit. I'm going to document what I discover in this table below. It affects ASDF only through our tests.
| impl | resignals undefined vars | resignals undefined functions |
| ----- | --------------------------- | ----------------------------- |
| abcl | no support | no, only prints |
| ccl | no support | yes |
| cmucl | yes | yes? |
| ecl | no support (w-c-u => progn) | no support (w-c-u => progn) |
| sbcl | yes | yes |https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/168Draft: Proposed solution to iss65 from fitzsim2021-06-02T17:26:05ZRobert GoldmanDraft: Proposed solution to iss65 from fitzsimSee #65 for description.See #65 for description.