- asdf-devel - mailman3.common-lisp.net

Announcing ASDF 3.3.7 Release
by Robert Goldman 29 Jan '24

29 Jan '24

Today we release ASDF 3.3.7, "Robbie Burns Night 2024 (belated)," the seventh bugfix release for the 3.3 release series. I had hoped that this would be the last bugfix release, but "the best laid schemes o' Mice an' Men Gang aft agley." We urge implementations that are currently bundling previous versions of ASDF to upgrade to 3.3.7 at their earliest convenience. This is particularly true for Allegro and SBCL. A primary purpose of the 3.3.7 was to give compatibility with Allegro 11.0. There is also a fix for multi-threaded vs. single-threaded FASLs that should be very useful to SBCL users. As maintainer, my primary role continues to be coordination and some limited quality control. Many contributors and bug-reporters have made this possible and the Common Lisp community owes them a vote of thanks. Their names are listed on the Changelog, appended below. The Changelog is in Debian format, for historical reasons: we used to release a Debian package, but have lost that capability (if you would like to volunteer to do this, please contact me directly or on the ASDF-devel mailing list). Hope springs eternal that the next release will be 3.4, that will introduce new functionality but, as its numbering suggests, will be backward compatible. Best, Robert cl-asdf (2:3.3.7-1) unstable; urgency=low * Fix bugs in UIOP:WITH-TEMPORARY-FILE, #142. * Fix bug in (SETF UIOP:GETENV). H/T to Michaël Le Barbier, #146. * Remember whether or not an SBCL build is single- or multi-threaded, since the two give incompatible FASLs. H/T to Philipp Marek, #143. * Remove unused UIOP:WITH-OPTIMIZATION-SETTINGS. This macro was never used, nor was its coding finished and debugged. H/T Yehouda Harpaz. #148. * Fix a number of issues with Allegro 11 compatibility. Many thanks to Duane Rettig and Kevin Layer. #152, #141 * Fix DEFPACKAGE code-walker for PACKAGE-INFERRED-SYSTEMs. Thanks to Alexander Fedorov. #147. * Thanks to Alexander Fedorov for assistance with the CI infrastructure. * Thanks to François-René Rideau for assistance in understanding past versions of ASDF and with miscellaneous repairs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun Jan 28 11:06:39 CST 2024

2 1

Plan to release ASDF 3.3.7
by Robert Goldman 27 Jan '24

27 Jan '24

I am planning to release the current version of ASDF, 3.3.6.7, as 3.3.7, most likely tomorrow or Monday. This version has a number of miscellaneous bug-fixes, but most significantly has been fixed to be compatible with the recent release of Allegro Common Lisp version 11.0. By releasing an Allegro 11-compatible version, we enable Franz to bundle a modern version of ASDF with the implementation, which will transparently give more of the community access to improved, more reliable ASDF functionality. I have tried to pull in some miscellaneous MRs before this release. If anyone knows of an MR that looks ready to go, please let me know and I will try to slip it in before the release. Best, R

1 0

Request for assistance: GitLab actions
by Robert Goldman 26 Jan '24

26 Jan '24

I have created a new docker image for Allegro CL version 11.0 (express/free), and put it on DockerHub: https://hub.docker.com/repository/docker/rpgoldman/allegro11express/general I have tried to add regression and upgrade tests using this Docker Image -- see [Regression test](https://gitlab.common-lisp.net/asdf/asdf/-/blame/allegro-resize-areas… and [Upgrade test](https://gitlab.common-lisp.net/asdf/asdf/-/blob/allegro-resize-areas/…. Unfortunately, these tests don't work! They print the right information at the head of [the job](): Regression test: [allegro, rpgoldman/allegro11express, modern] : But they pull the wrong docker image: ``` Using Docker executor with image containers.common-lisp.net/cl-docker-images/allegro:latest ... Authenticating with credentials from job payload (GitLab Registry) Pulling docker image containers.common-lisp.net/cl-docker-images/allegro:latest ... Using docker image sha256:d0fc75f61208fa39497f5ae2188d6d70d4b65ae513105dbdf80f85b41a45ffdc for containers.common-lisp.net/cl-docker-images/allegro:latest with digest containers.common-lisp.net/cl-docker-images/allegro@sha256:e16f3a55a2d82973… ... ``` Does anyone on the list understand GitLab pipelines well enough to tell me why my `image` variable binding in "Regression test" and "Upgrade test" doesn't clobber the value from the template? Or, even more oddly, why it seems to half-way clobber it, giving the right info print, but pulling the wrong image? Sorry to bother the list, but I'm at my wits end and the debugging tools and documentation are somewhere between horrible and non-existent. Thanks for any advice, R

4 4

Re: ASDF: could use some help with ECL issue
by Daniel Kochmański 10 Jan '24

10 Jan '24

Hey Robert, I've looked into this issue and it seems that it is a bug in ECL. Even on idempotent defpackage definitions it first removes use-list and then re-adds it, while the different part of the code enforces the lock. I've added the ticket to our tracker: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/730 Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi On Tuesday, January 9th, 2024 at 16:48, Robert Goldman <rpgoldman(a)sift.net> wrote: > In the regression test results for a bug fix to ASDF (https://gitlab.common-lisp.net/asdf/asdf/-/jobs/63801) I see this error which I don't understand at all: > > Cannot unuse package #<"COMMON-LISP" package> from locked package #<"PACKAGE-INFERRED-SYSTEM-TEST/SBCL-EXT-LOCK" package>. > > The line that seems to be causing this is the following (in a test system): > > (defpackage package-inferred-system-test/sbcl-ext-lock > (:use :cl) > #+(or sbcl ecl) (:lock t) > (:export #:implemented-by-other-package)) > > More discussion about this is in ASDF Merge Request 226: https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/226 > > The underlying issue is to try to make sure that implementation specific defpackage extensions (like :lock) don't cause ASDF's defpackage groveler to fail when working with package-defined systems. > > Thanks for any advice!

2 1

Request for information: Implementation-specific DEFPACKAGE extensions
by Robert Goldman 08 Jan '24

08 Jan '24

@gefjon has proposed ASDF MR [!226](https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/226) that extends ASDF's package inferred system dependency groveler to handle SBCL's extension to the set of `defpackage` options, addressing [Issue #147](https://gitlab.common-lisp.net/asdf/asdf/-/issues/147). Before merging this, it would be nice to know of other implementations' extensions to `defpackage`. I'd be obliged if those in the know would post information about `defpackage` extensions their favored implementations have added, if any, or let us know if tfi leaves `defpackage` un-extended. That would make it quicker to get this fix merged and issued, and would help the community as a whole. Feel free to respond by email, or to post your answer in the comments to the merge request, whichever is most convenient. Thanks, R

3 2

Past discussion on ASDF loading
by Robert Goldman 04 Jan '24

04 Jan '24

I am finding that ASDF loads itself multiple times, unnecessarily, at least on Allegro 11. E.g., it reloads when I simply invoke `(asdf:component-pathname (asdf:find-system "foo"))` for one of my systems. This is annoying because I get redefinition style warnings every time I do this, which makes it hard to tell when a system loads cleanly. I have a vague memory of a discussion that addressed the question of why this happens. Does anyone recall the answer, or have a pointer to the discussion? Interestingly, when I load ASDF and then invoke `(asdf/component:component-operation-times (asdf:find-system "asdf"))` the only time listed is for `define-op` Thanks, R

2 3

Removal of feature from UIOP library
by Robert Goldman 12 Dec '23

12 Dec '23

[Issue 48](https://gitlab.common-lisp.net/asdf/asdf/-/commits/iss148) on the ASDF GitLab repo concerns a bug in the `with-optimization-settings` macro in UIOP's lisp-build.lisp I did some investigation and as far as I can tell: 1. There's no clear description of what this is supposed to do 2. There's no use of it anywhere in the ASDF + UIOP code base 3. It has never worked -- at least when I tried to test it, the tests failed all over the place. Rather than trying to write a new implementation out of whole cloth, my [Merge Request](https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/224) to address this issue simply rips this macro and some supporting functions and variables out of UIOP. Doing so breaks no tests (unlike trying to test it). I feel a little uncomfortable removing functionality, but as I said, I cannot find any evidence that this has ever been used. Absent any pushback -- and likely even *with* pushback, unless that pushback is accompanied by a MR that supplies a working implementation, I will make that merge, and this feature will vanish from UIOP. Best, R

2 2

How to use the current directory?
by Blake McBride 29 Sep '23

29 Sep '23

Greetings all! Asdf noob here. I have spent hours on what I would think would be incredibly simple. Help would sure be appreciated. I cloned a repo for a package that is available on quicklisp. I modified it. However, everytim I do: (asdf:load-asd "thepackage.asd") (asdf:load-system "thepackage") It loads the standard distribution rather than the copy I am editing. I have tried stuff like: (asdf:load-asd (concatenate 'string (namestring (truename ".")) "parenscript.asd")) with no luck. I tried many other things too with no luck. How can I force asdf to load and use the package in the local directory rather than the cached standard distribution? Thank you! Blake McBride

8 13

Re: How to use the current directory?
by Blake McBride 23 Sep '23

23 Sep '23

Thanks for the great suggestions, Richard! I'll definitely give it a try! Blake ------- Original Message ------- On Saturday, September 23rd, 2023 at 3:48 PM, Richard Westhaver <richard.westhaver(a)gmail.com> wrote: > Hey Blake, > > I am relatively new to Common Lisp and agree that figuring out a decent dev ecosystem can be challenging, the suggestions above are the best portable solution IMO though - using SBCL, I added a single line to ~/.sbclrc : (push #P"~/dev/" ql:*local-project-directories*). > > I think scaling this to really large and distributed systems is a challenge though - you basically have ASDF and Quicklisp and it's up to you how you want to make use of them. here's a couple ways I've seen others manage this: > > - fukamachi's qlot: https://github.com/fukamachi/qlot - project-local library installer, currently being integrated into the Lem text editor > - nyxt (just use sub-repos): https://github.com/atlas-engineer/nyxt/tree/master/_build > > It's Lisp so the perfect solution for your purposes does in fact exist, you just gotta start hacking :). > > For example, I'm currently working on a very different approach which may not pay off - dropping Quicklisp and all external dependencies, [ab]using the compiler (SBCL) as much as possible and adding contribs which are distributed with the compiler instead of separate systems. > > On Sat, Sep 23, 2023 at 10:56 AM Blake McBride <blake(a)mcbridemail.com> wrote: > >> Thanks for all of the replies! Although I have been playing with Lisp for many years, I do not have much experience with ASDF or QuickLisp. >> >> I appreciate all of the suggestions and explanations, however, with respect, they all seem like work-arounds or hacks for my purposes. I am not suggesting, however, that your input wasn't valid, helpful, or there is a better way. >> >> I understand the idea that QuickLisp is not a package manager but a system manager. In that case, it delivers completed system easily and conveniently. It's a great tool. >> >> I think a true package manager option in QuickLisp would be incredibly useful. Here is the scenario. >> >> I am building a system. It has dependencies X, Y, and Z. I complete my system and package it up as a QuickLisp system. Later, I'd like to work on my system. I'd like to work on a local copy in a directory of my choosing. I'd like it to load its dependencies (X, Y, and Z) yet work on my part of the system without loading the version in the QuickLisp repo. >> >> While some of your suggestions will allow me to do that, they are real clunky. Either I have to work in specific directories or I have to have special code specific to the particular directory I choose to work in. >> >> All of this is contrary to the way all other system I've used work. In general, I can clone a repo to any directory and do: >> >> ./configure >> make >> sudo make install >> >> and it works! I can put the clone anywhere I want. I can change it anyway I want. The system doesn't fight me. >> >> I wouldn't think this would be hard at all to make ASDF and QuickLisp have this capability. >> >> Blake McBride

1 0

Question about UIOP:ENSURE-DIRECTORY-PATHNAME
by Robert Goldman 07 Jul '23

07 Jul '23

While addressing ASDF [issue #140](https://gitlab.common-lisp.net/asdf/asdf/-/issues/140) I stumbled on what seems to me to be an error. That is that (ensure-directory-pathname "") at least on SBCL, returns a `pathname` that has `NIL` in all its slots except `HOST`. To me, this seemed wrong, and looking further, I found that `directory-pathname-p` returns `T` when given this pathname, because `directory-pathname-p` is defined (in its docstring) as: > A directory-pathname is a pathname _without_ a filename. I would have assumed that a directory pathname was *also* a pathname with a non-`NIL` `directory` component. I am considering making this (incompatible) change, but am interested in any feedback about whether this is the correct thing to do.

2 1