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

Warning: Computing just-done stamp in plan NIL for action
by Stas Boukarev 18 Oct '17

18 Oct '17

More new warnings from ASDF 3.3, this time I have no idea what it means. WARNING: Computing just-done stamp in plan NIL for action (ASDF/LISP-ACTION:LOAD-OP "system"), but dependency (ASDF/FIND-SYSTEM:DEFINE-OP "system") wasn't done yet! The .asd file is not public, but it looks perfectly normal without using any complicated features.

4 12

monolithic-concatenate-source-op misses a few dependencies
by Ben Vulpes 17 Oct '17

17 Oct '17

On SBCL 1.3.11, when producing a monolithic source concatenation with the library "Postmodern", asdf produces a file that needs a Lisp image to need manual calls to (require :usocket) and (require :md5) in order to load completely. Given: concatenatrix.asd as: (asdf:defsystem :concatenatrix :build-operation monolithic-concatenate-source-op :build-pathname "build/full-concatenation" :depends-on (:postmodern) :components ((:file "concatenatrix"))) concatenatrix.lisp as: (defpackage :concatenatrix (:use :cl :postmodern)) (in-package :concatenatrix) (defun wat (it) (format t "~A~%" it)) Concatenated sources produced with: (asdf:make :concatenatrix) Loading tested with: sbcl --noinform --disable-debugger --load build/full-concatenation.lisp Produces: Unhandled SB-C::INPUT-ERROR-IN-LOAD in thread #<SB-THREAD:THREAD "main thread" RUNNING {10027FE873}>: READ error during LOAD: Package SB-ROTATE-BYTE does not exist. Line: 221, Column: 29, File-Position: 8706 Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/b/quicklisp/local-projects/concatenatrix/build/full-concatenation.lisp" {1003CFCA03}> Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10027FE873}> 0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-C::INPUT-ERROR-IN-LOAD {1004014AC3}> #<unavailable argument>) 1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<SB-C::INPUT-ERROR-IN-LOAD {1004014AC3}>) 2: (INVOKE-DEBUGGER #<SB-C::INPUT-ERROR-IN-LOAD {1004014AC3}>) 3: (ERROR #<SB-C::INPUT-ERROR-IN-LOAD {1004014AC3}>) 4: (SB-C:COMPILER-ERROR SB-C::INPUT-ERROR-IN-LOAD :CONDITION #<SB-INT:SIMPLE-READER-PACKAGE-ERROR "Package ~A does not exist." {10040149E3}> :STREAM #<SB-INT:FORM-TRACKING-STREAM for "file /home/b/quicklisp/local-projects/concatenatrix/build/full-concatenation.lisp" {1003CFCA03}>) 5: (SB-C::%DO-FORMS-FROM-INFO #<CLOSURE (LAMBDA (SB-KERNEL:FORM &KEY :CURRENT-INDEX &ALLOW-OTHER-KEYS) :IN SB-INT:LOAD-AS-SOURCE) {1003D004FB}> #<SB-C::SOURCE-INFO {1003D004B3}> SB-C::INPUT-ERROR-IN-LOAD) 6: (SB-INT:LOAD-AS-SOURCE #<SB-INT:FORM-TRACKING-STREAM for "file /home/b/quicklisp/local-projects/concatenatrix/build/full-concatenation.lisp" {1003CFCA03}> :VERBOSE NIL :PRINT NIL :CONTEXT "loading") 7: ((FLET SB-FASL::LOAD-STREAM :IN LOAD) #<SB-INT:FORM-TRACKING-STREAM for "file /home/b/quicklisp/local-projects/concatenatrix/build/full-concatenation.lisp" {1003CFCA03}> NIL) 8: (LOAD #P"build/full-concatenation.lisp" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :DEFAULT) 9: (SB-IMPL::PROCESS-EVAL/LOAD-OPTIONS ((:LOAD . "build/full-concatenation.lisp"))) 10: (SB-IMPL::TOPLEVEL-INIT) 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-90 :IN SB-EXT:SAVE-LISP-AND-DIE)) 12: ((LABELS SB-IMPL::RESTART-LISP :IN SB-EXT:SAVE-LISP-AND-DIE)) There is another complaint about usocket, which is confusing, as cl-postgres explicitly doesn't require usocket on sbcl by my read ( http://marijnhaverbeke.nl/git/?p=postmodern;a=blob;f=cl-postgres.asd;h=683e… ). Loading is resolved by requiring both libraries in question, as: sbcl --eval "(require :md5)" --eval "(require :usocket)" --load build/full-concatenation.lisp Yours, Benjamin

3 5

asdf defsystem worked in 3.2.1 but not 3.3.0
by Raymond Toy 15 Oct '17

15 Oct '17

The following defsystem worked in asdf 3.2.1 but no longer works in 3.3.0. The error message doesn't really help in figuring out what's circular. And I just can't see what's circular. The system: (asdf:defsystem :pcl-test :pathname "pcl/" :components ((:file "pkg") #+gerds-pcl (:file "ctor" :depends-on ("pkg")) (:file "defclass" :depends-on ("pkg")) (:file "make-instance" :depends-on ("pkg" #+gerds-pcl "ctor")) (:file "reinitialize-instance" :depends-on ("pkg" "make-instance")) (:file "slot-value" :depends-on ("pkg" "make-instance")) (:file "slot-boundp" :depends-on ("pkg" "make-instance")) (:file "slot-missing" :depends-on ("pkg" "make-instance")) (:file "slot-accessors" :depends-on ("pkg" "make-instance")) (:file "slot-type" :depends-on ("pkg" "slot-value")) (:file "inline-access" :depends-on ("pkg" "slot-type")) (:file "method-combination" :depends-on ("pkg")) (:file "pv" :depends-on ("pkg")) (:file "defgeneric" :depends-on ("pkg")) (:file "defmethod" :depends-on ("pkg")) (:file "find-method" :depends-on ("pkg")) (:file "methods" :depends-on ("pkg")))) -- Ray

3 5

syntax-control
by Faré 14 Oct '17

14 Oct '17

Due to the readtable bug in ASDF 3.3.0 I updated the "syntax-control" branch that for the last three years was supposed to solve all readtable bugs when building with ASDF. I merged 3.3.0.1 into the branch, but the branch itself is not ready for merging into master: it does either too much or too little, and must be either completed or simplified. I think it stands a better chance of bieng merged soon if it is simplified, so I re-read and re-wrote the documentation for what this branch should be doing, and detailed a "Proposal 1" for minimal changes to ASDF that would go a long way towards bringing sanity in builds of software that modify the syntax. I sollicit your feedback: https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-con… —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Problem of the day: finding suction cups that don't suck.

2 1

Debian package: signing-key.asc
by Kambiz Darabi 13 Oct '17

13 Oct '17

Hello, there are questions from the Debian dev who helps publishing the package about the signing key which is in the debian/ subtree. Can someone please comment? Thank you Kambiz ----- Forwarded Message ----- From: "Sébastien Villemot" <sebastien(a)debian.org> To: "Kambiz Darabi" <darabi(a)m-creations.com> Cc: 878167(a)bugs.debian.org Sent: Friday, 13 October, 2017 5:07:45 PM Subject: Re: Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility Also, there is a GPG key under debian/upstream/signing-key.asc, but I see no signature on upstream website (https://common-lisp.net/project/asdf/archives/) Am I missing something? Or should the key be removed? Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org

2 1

new compiler error re: SET-DISPATCH-MACRO-CHARACTER
by Konstanski, Carlos 13 Oct '17

13 Oct '17

This is a bug report. I'm using puri as an example, but it's not a puri bug. With the latest version of asdf (3.3.0) puri no longer compiles. The following compiler error is thrown: SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable. [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] In: 0: (SET-DISPATCH-MACRO-CHARACTER #\# #\u #<FUNCTION PURI::SHARP-U> #<READTABLE {100002D6C3}>) The code: (defun sharp-u (stream chr arg) (declare (ignore chr arg)) (let ((arg (read stream nil nil t))) (if *read-suppress* nil (if* (stringp arg) then (parse-uri arg) else (internal-reader-error stream "#u takes a string or list argument: ~s" arg))))) (set-dispatch-macro-character #\# #\u #'puri::sharp-u) What puri is doing re: SET-DISPATCH-MACRO-CHARACTER is totally by the book. Why is this suddenly an error? Is there a workaround? Backing up to the next most recent release of asdf makes the problem go away: dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1 dev-lisp/uiop-3.2.1:0 I tried to find the asdf changelog to see if this is a documented change. But the link is broken. https://common-lisp.net/project/asdf/Changelog uiop seems to be closely tied to asdf. Not sure which package is actually at fault. -- Carlos Konstanski

4 12

Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER
by Robert Goldman 12 Oct '17

12 Oct '17

On 12 Oct 2017, at 12:53, Konstanski, Carlos wrote: > All signs point at puri being the culprit. I am absolutely not > disagreeing > with that. I provided the offending code in the bug report myself. The > question is: what to do about it? The project is dead. The home page > is > gone. Here is what I will do: I'll see if I can get drakma to steer > clear > of it. They will undoubtedly be interested in not having their fine > code > dragged down by a dead library. > > The only other option is to fix puri. I don't even know how to begin > doing > that with a dead project. Where did Kevin Rosenberg disappear off to? > > 2017-10-12 11:45 GMT-06:00 Robert Goldman <rpgoldman(a)sift.info>: > >> >> >> Forwarded message: >> >>> From: 73budden . <budden73(a)gmail.com> >>> To: Robert Goldman <rpgoldman(a)sift.info> >>> Cc: Faré <fahree(a)gmail.com>, ASDF-devel >>> <asdf-devel(a)common-lisp.net> >>> Subject: Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER >>> Date: Thu, 12 Oct 2017 20:09:44 +0300 >>> >>> Warning about modifying standard readtable is issued by SBCL (at >>> least >>> in my SBCL 1.3.18), please grep for the message in SBCL sources, and >>> it seem to be introduced in 1.0.24. I took a look at puri's >>> definition >>> (maybe old, in my local copy of quicklisp) and it looks like it >>> actually tries to modify standard readtable. But here it does not >>> happen when it is being loaded via my patched asdf 3.1.6 and my own >>> IDE with forked SLIME with many systems pre-loaded. I don't know why >>> and have no time to investigate further. Obviously, my insights >>> would >>> be of limited use because my environment is very different from that >>> of OP. >>> >>>> So we might be able to help you debug this >>> It'd be very nice to have instructions on how to trace what happens >>> while system is being built:that is, which files are compiled, which >>> are loaded and what is a readtable in the beginning of each load >>> operation. >>> >>> Running builds in old and new asdf versions and comparing logs it >>> would be relatively easy to figure out what is wrong. >>> >>> I guess that in OP's setup something had changed readtable before, >>> but >>> this does not happen anymore. And obviously many people would face >>> similar problems. >>> >>> This tracing tool should help a lot. >>> >>> I believe this tool should be supplied by asdf team. Even I begin to >>> be more positive towards efforts of ASDF team to clean up all the >>> mess >>> that was in ASDF initially, but obviously society is not quite happy >>> with breaking changes, so some small tool with a good manual would >>> make life easier. >>> >>> Printing readtable before loading, I think, requires just a line or >>> two. Dumping log of operations might be one (trace) call, so that's >>> trivial for the person who knows how ASDF is organized. Writing a >>> small two-paragraph addition to manual would relief a lot of pain >>> and >>> stress for all. >>> >>> WBR, Budden >>> >>> 2017-10-12 18:46 GMT+03:00, Robert Goldman <rpgoldman(a)sift.info>: >>>> I'm with Faré on this one. I don't see evidence that this change >>>> is >>>> because ASDF is doing something bad. I believe it's consistent >>>> with the >>>> hypothesis that there was some imperfectly-controlled aspect of >>>> building >>>> that is done differently now (e.g., files loaded in a different >>>> order >>>> where both orders are compatible with the constraints in the system >>>> definitions). >>>> >>>> This doesn't even look like an ASDF error to me -- it looks like an >>>> error that occurred while loading a system that ASDF has >>>> re-packaged. >>>> >>>> So we might be able to help you debug this, but without more >>>> evidence, >>>> there's no reason to believe that ASDF has done anything to you: it >>>> looks like the change in ASDF just reveals a pre-existing bug. >>>> >>>> >>>> >> > > > > -- > Carlos Konstanski > MTS IV Cslt > Verizon Cloud Platform > carlos.konstanski(a)verizonwireless.com > Cell: 15126218301 > Slack: vzw-vsi.slack.com username: @ckonstanski That may be, but it was unfair to get angry at the ASDF maintainers about this. This is just a pre-existing error that was *manifested* because of a change in ASDF. It's not our fault that this error appeared, it's not our fault that the puri library is no longer maintained, and we can't be expected to avoid releasing improved versions of ASDF because there exists buggy, unmaintained code in Quicklisp. An apology from you would be appropriate at this point.

3 2

WARNING: System definition file ...
by Stas Boukarev 12 Oct '17

12 Oct '17

3.3.0 issues a barrage of new warnings about something it has decided is uncouth now. I really have no wish to stare at these warnings coming from third party libraries, especially since they're never going to be fixed. Is the old behavior posing problems? Is the old behavior going away soon? This is why I don't update ASDF, I don't want to change anything in my code because of a new version.

2 5

Uploaded 3.3.0 Debian package
by Kambiz Darabi 10 Oct '17

10 Oct '17

Hello, just FYI. I uploaded the Debian package, now awaiting mentors' feedback. Cheers Kambiz ----- Forwarded Message ----- From: "Kambiz Darabi" <darabi(a)m-creations.net> To: "Submit Bugs" <submit(a)bugs.debian.org> Sent: Tuesday, 10 October, 2017 7:14:39 PM Subject: RFS: cl-asdf/3.3.0 - Another System Definition Facility Package: sponsorship-requests Severity: normal Dear mentors, I have packaged the new upstream release 3.3.0 of the Common Lisp ASDF software: Package name : cl-asdf Version : 2:3.3.0-1 Upstream Author : Robert P. Goldman <rpgoldman(a)sift.info> URL : https://common-lisp.net/project/asdf/ License : Expat Section : lisp The cl-asdf source package builds this binary package: cl-asdf - Another System Definition Facility The package appears to be lintian clean apart from a orig-tarball-missing-upstream-signature warning which I cannot fix due to building the package from git with gbp. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cl-asdf Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.3.0-1.dsc Changes since the last upload: cl-asdf (2:3.3.0-1) unstable; urgency=medium Package changes: * Update Standards-Version to 4.1.1 New upstream milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. Thank you Kambiz Darabi -- m-creations gmbh Acker 2 55116 Mainz Germany

2 1

ASDF 3.3.0 is released!
by Robert Goldman 08 Oct '17

08 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500 Best, R

2 1