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

Return value of UIOP:CALL-WITH-CURRENT-DIRECTORY
by Kevin Zheng 02 Sep '24

02 Sep '24

Hi asdf developers, I recently was writing some code with UIOP:CALL-WITH-CURRENT-DIRECTORY and came across something slightly unexpected. In particular, running CALL-WITH-CURRENT-DIRECTORY or WITH-CURRENT-DIRECTORY forms evaluates to NIL, whereas one may expect that the form evaluates to the return value of THUNK or the macro body, respectively. In my program, I'm trying to do something like: (uiop:with-current-directory (dir) (uiop:run-program (list "some" "program") :output :string)) Which doesn't quite do what I want it to do. I believe this has to do with the definition, which ends in a trailing (chdir dir) form to get out of the directory which unfortunately returns NIL instead of the value from evaluating THUNK. So my question is: would it be acceptable if a future version of UIOP changes call-with-current-directory to return the value of evaluating THUNK? Thanks, Kevin

3 4

Running a binary on a server, ASDF wants to access the common-lisp/ directory and fails
by vindarel 29 Aug '24

29 Aug '24

Hi everyone, I built a binary, I run it on my server but I get an ASDF error: |;; Error while trying to load definition for system asdf from pathname ;; /home/vince/common-lisp/asdf/asdf.asd: ;; couldn't load #P"/home/vince/common-lisp/asdf/asdf.asd": file does not exist. | and my binary exits with an error code. ASDF looks for itself on the ~/common-lisp/ directory, which doesn't exist on my VPS, as expected. Do I have a way to tell ASDF to not do this, so that my binary can run? Actually my script doesn't exit right away, it does something, then exits. So, something in my program or in my dependencies are asking this operation to ASDF, when probably it shouldn't. I'm trying to figure it out. However if there was an easy way to gently ask ASDF not to fail, that would be a bliss. Thanks in advance! More details… --- I tried one thing. First, let's show you my .asd declaration. (in-package :asdf-user) (defsystem "observatoire" :version "0" :depends-on (:ciel :secret-values :progressons ) :components ((:module "src" :components ((:file "packages") (:file "common") (:file "extractor") (:file "stock") (:file "ventes") (:file "observatoire")))) :build-operation "program-op" :build-pathname "observatoire" :entry-point "observatoire::main" ) I built the binary with asdf:make. I tried adding these lines at the end of the .asd: #+asdf (asdf:clear-source-registry) #+asdf (defun asdf:upgrade-asdf () nil) This did not help, now I get: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION QL-DIST:INSTALLEDP (3)> when called with arguments (NIL) I had the same issue before, which I bypassed by using Deploy and a hook, containing those two lines: (deploy:define-hook (:deploy asdf) (directory) (declare (ignorable directory)) #+asdf (asdf:clear-source-registry) #+asdf (defun asdf:upgrade-asdf () NIL)) but unsurprisingly it doesn't help either. --- I see that ASDF is signaling a load-system-definition-error condition. Without knowing the root cause, I don't think handling it would help. I'll try to avoid the error: ;; ASDF, find-system.lisp #'(lambda (condition) (if (uiop:symbol-call :deploy :deployed-p) ;; added (warn "asdf: ignoring load-system-definition-error~&") ;; added (error 'load-system-definition-error :name (coerce-name s) :pathname pathname :condition condition))) Here, we use Deploy's (deploy:deployed-p) that tells us when the binary is running. It could be another flag. I'll try and see… Thanks for any pointers, Best regards, Vincent @vindarel SBCL 2.1.5 ASDF "3.3.4.15" on my development machine

1 1

Method combination and ASDF
by Robert Goldman 26 Apr '24

26 Apr '24

An issue that came up discussing ASDF-FLV with Didier has to do with outside modification to exported ASDF generic functions. I think it's unambiguously reasonable to say "if you mess with unexported functions, generic or otherwise, you're on your own, and could break things arbitrarily." But I don't think ASDF has established clear expectations about extending methods of exported ASDF generic functions. I think there's been an unspoken assumption that if ASDF generic functions are to be extended, particularly by `:around`, `:before`, and `:after` methods, there should be some novel class introduced that will be used to select extensions. So, for example, it's fine to wrap or write new methods for `perform`, but not for existing component and operation classes. Doing so means that a change one might think appropriate for one's own library bleeds out into other code that one has no way of predicting, and also has the potential to collide with ASDF's own code or other people's ASDF extensions. Those are good reasons for this convention -- no modification without introducing new classes for method dispatch -- but ASDF-FLV is an example of a system that wants to introspect about the entire running lisp image. I'd be interested in hearing what people think about this kind of case. Should we introduce, for example, an `ASDF` object that extenders could add mixins to in order to enable modifications to ASDF behavior that aren't limited to a single library? Please post any thoughts you have about this idea.

4 7

Loading only fasl files
by Greg Bennett 21 Apr '24

21 Apr '24

Hello from Greg Bennett who is trying to debug some compilation issues in Allegro. I have what I believe to be a completely compiled project, consisting of several systems, and I would like to load only its fasl files. Specifically I do not want to re-compile the source files which would replace those fasls. I have looked at the manual in the hope that load-bundle-op might work, but I see that this requires *compiling* the source into a single fasl. Perhaps (probably!) I'm missing something. Any advice/assistance much appreciated. Cheers Greg

3 2

Loading only fasl files
by Greg Bennett 21 Apr '24

21 Apr '24

This may be a duplicate query. I posted from another account which bounced. This may be the account with which I an 'registered'. Apologies for the noise. Hello from Greg Bennett who is trying to debug some compilation issues in Allegro. I have what I believe to be a completely compiled project, consisting of several systems, and I would like to load only its fasl files. Specifically I do not want to re-compile the source files which would replace those fasls. I have looked at the manual in the hope that load-bundle-op might work, but I see that this requires *compiling* the source into a single fasl. Perhaps (probably!) I'm missing something. Any advice/assistance much appreciated. Cheers Greg

1 0

Documentation "The defsystem form"
by Mirko Scholz 22 Mar '24

22 Mar '24

Hello, using asdf with quicklisp it seems that the :version component is not optional but actually required. Maybe this can be mentioned in §6.1 "The defsystem form" The documentation reads - This system also defines a bunch of metadata. While it is optional to define these fields (and other fields like :bug-tracker, :mailto, :long-name, :long-description, :source-control), it is strongly recommended to define the fields :description, :version, :author, and :licence, especially if you intend your software to be eventually included in Quicklisp. If I try to ql:quickload: ====================================================== (asdf:defsystem #:foo-pkg :description "foo pkg" :author "MS" :components ((#:file "package"))) ====================================================== I get ====================================================== Error while trying to load definition for system foo-pkg from pathname /home/mirko/quicklisp/local-projects/foo-pkg/foo-pkg.asd: don't recognize component type #:FILE [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] ====================================================== with the :version component it works ====================================================== (asdf:defsystem #:foo-pkg :description "foo pkg" :author "MS" :author "0.0.1" :components ((#:file "package"))) ====================================================== ====================================================== CL-USER> (ql:quickload "foo-pkg") To load "foo-pkg": Load 1 ASDF system: foo-pkg ; Loading "foo-pkg" ("foo-pkg") ====================================================== Regards

2 1

Readtable not bound to standard around compilation
by Scott＠sympoiesis.com 28 Feb '24

28 Feb '24

Hi all! I just ran into something surprising. This is with ASDF 3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' set to a nonstandard readtable, then did quickload of a system unrelated to the one that defines and uses that readtable. The compilation failed; after I did '(in-readtable :common-lisp)' and tried again, it succeeded. A quick glance at the ASDF source code shows that it binds '*readtable*' to a standard readtable in some cases, such as to read a '.asd' file, but not in 'uiop/lisp-build/compile-file*', nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do that? -- Scott

6 10

Fwd: Readtable not bound to standard around compilation
by Scott L. Burson 27 Feb '24

27 Feb '24

[Oops — just noticed that I had sent this only to Faré, not the list.] Oh wow, that was even more of an earful than I was expecting :-) ... I've now read your syntax-control document. Before I found it, I tried to think of solutions, and came up with something very much like your Proposal 2. You say that it depends on Proposal 1 (which you had hoped to put into effect immediately), but I'm not sure about that; I think it could stand alone. Seems like it would require fewer changes to existing systems, which might make it more politically doable. WDYT? -- Scott On Thu, Feb 22, 2024 at 8:32 AM Faré <fahree(a)gmail.com> wrote: > Oh, and as for binding variables around files, this has subtly different > meanings when compiling a file, loading its fasl or loading its source. And > if done wrong it can easily break fasl concatenation or linking on ecl and > mkcl, where you just can't bind around the loading of individual fasls, > whereas with source loading you can't not bind, so now the user is > responsible to make sure his code works both ways and the binding only > really matters at compile-time—which kind of is already a development > constraint, just unarticulated, unenforced, and undetected until a subtle > bug hits someone. > > In the end you can only protect the developer from himself so much, when > you can't change the semantics of CL itself across twenty implementations > many unmaintained. > > On Thu, Feb 22, 2024, 11:16 Faré <fahree(a)gmail.com> wrote: > >> In the past, to introduce changes a fraction as compatibility-breaking >> (e.g. making utf-8 the default, or changing the internals of OPERATION), I >> would write up an explanation why the change is desired that anyone can >> read, discuss on the mailing list, write the code but keep it unmerged or >> disabled, make an announcement for the intended future breaking change, go >> over all of Quicklisp with Anton Vodonosov's cl-test-grid, locate all the >> offenders there, and send patches to each and everyone, wait a year if the >> old behavior used to be officially documented and supported, only a few >> weeks if it was a forbidden internals dependency, run the test again, give >> a last warning to those who didn't merge the patches, sometimes fork the >> systems left unmaintained to a new home, then finally make the change and >> announce it. And be ready to handle all the angry authors of proprietary >> code not in Quicklisp that you failed to previously contact. >> >> For syntax-control (see my branch, that needs much love merging with >> 3.3.7), we never reached that point, if only because we were never >> satisfied with the complexity of the code (speaking for myself at least, I >> suspect for RPG also to a point, but he can opine otherwise if needed). >> There are many special variables beside *readtable* that control syntax >> (e.g. some systems try to make double-float the default—with "interesting" >> side effects to other systems compiled later, more subtle than the big >> obvious breakage when the readtable is wrong or corrupted). And users >> define more such variables as they extend the language. So now you want to >> maintain a dynamic list of symbols, some in packages not yet defined, that >> you want to track, save and restore. Next your users will want to bind the >> values of some of these variables around some systems, modules or >> components. The code is big and messy, and it isn't even obviously "the >> right thing" overall, though a lot of elements of it are, and every piece >> is needed somehow. >> >> There's also the question of whether the default readtable should be THE >> "standard" readtable (immutable on some implementations, not on others), or >> some shared mutable readtable copied from it (will break many CCL >> extensions), or from the magic initial readtable that is not standard and >> that some will mutate (the most backward compatible option, so probably the >> one ASDF should pick, though it's ugly, unless you want to wrestle some >> more with the community). >> >> Should we merge the whole messy thing that solves the entire problem? >> Only the small and clean part that is obviously right but clearly >> insufficient? Each time we make such a change, we have to pay a lot to >> overcome a big incompatibility hurdle. If the solution isn't fully >> satisfactory, then we are setting ourselves up for yet another round (or >> several) of such costly change(s). >> >> I'm out of the Common Lisp community (moved to Gerbil Scheme), but >> whoever wants to tackle this challenge for good better makes sure they (and >> the community!) are ready to pay the price for the transition, and multiple >> times so if they don't get it right on the first try. Oh, and once you take >> on the job, you'll be hated by some part of the community whether you >> subsequently make the change or don't. >> >> Good luck! >> >> On Thu, Feb 22, 2024, 10:15 Robert Goldman <rpgoldman(a)sift.info> wrote: >> >>> I think this is still true, but... we cannot be discussing ASDF 3.2.1 >>> here. It was released almost 7 years ago, and for whatever reason Zach >>> refuses to update. The current version is 3.3.7 >>> >>> Please get a more recent ASDF and try again. I *believe* that this >>> behavior is still in place: Faré proposed the "syntax control" patch to fix >>> this, but we decided we had no easy path to introducing it, because it >>> would break other code (admittedly not of good style) that relies on the >>> old behavior of having the readtable setting leak out of one file into >>> another. See >>> https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86 >>> >>> Any non-backwards compatible modification to ASDF -- even to the extent >>> of raising a deprecation warning -- has led to temper-tantrums in the CL >>> community... >>> >>> On 21 Feb 2024, at 22:14, Scott(a)sympoiesis.com wrote: >>> >>> Hi all! I just ran into something surprising. This is with ASDF 3.2.1, >>> packaged with Quicklisp. I am using Named-Readtables. I had '*readtable*' >>> set to a nonstandard readtable, then did quickload of a system unrelated to >>> the one that defines and uses that readtable. The compilation failed; after >>> I did '(in-readtable :common-lisp)' and tried again, it succeeded. >>> >>> A quick glance at the ASDF source code shows that it binds '*readtable*' >>> to a standard readtable in some cases, such as to read a '.asd' file, but >>> not in 'uiop/lisp-build/compile-file*', nor in >>> 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it make sense to do >>> that? >>> >>> -- Scott >>> >>>

1 0

historical question
by cage 06 Feb '24

06 Feb '24

Hi! Some person (including me) was wondering when the ASDF project started; on the fediverse someone guessed that the 25th anniversary could be near. Is that true? Bye! C.

5 12

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