asdf-devel October 2017

asdf-devel@common-lisp.net

12 participants
12 discussions

uiop non-problems
by Faré 20 Oct '17

20 Oct '17

Dear Xach, I saw your blog post: http://lispblog.xach.com/post/166534341423/uiop-330-problems There are no comments on your blog, so I'll just clarify things on the asdf-devel list: * The situation you describe is not at all a problem specific to uiop 3.3.0, or any other version of uiop. uiop.asd hasn't changed since 3.2.0, and the "issue" already existed before, and exists when there is no uiop.asd available but only the builtin uiop. * The situation you describe, where some libraries are loaded multiple times, is a bug in ASDF, that was fixed in 3.3.0 --- actually, fixing this situation and other related situations was the very reason why I had to teach ASDF about build phases, which lead to the big refactoring done in 3.3.0. * All build systems have to either face the issue of build system extension, or put their head in the sand and do the wrong thing. At least ASDF 3.3.0 does the right thing now, whereas earlier versions put their head in the sand as far as that issue was concerned. (I also know that Bazel has a proper solution, though it involves using a non-extensible DSL for extensions). * At least in that case, the issue is not too bad: just some system recompiled, that will also cause more recompilation the next time, but don't cause an infinite loop, just a waste of CPU time. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In Italia i fascisti si dividono in due categorie: i fascisti e gli antifascisti. — Ennio Flaiano

3 4

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

18 Oct '17

ASDF keeps inventing good reasons all the time... On Wed, Oct 18, 2017 at 7:43 PM Faré <fahree(a)gmail.com> wrote: > Oh, is it a case where you're insisting on using a secondary system > name that doesn't follow the convention B/A when the primary system is > B ? That might explain it. There is also a warning against such a > thing, and for good reason. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > Doing well is the result of doing good. That's what capitalism is all > about. > — Ralph Waldo Emerson (1803–1882) > > > On Wed, Oct 18, 2017 at 12:15 PM, Stas Boukarev <stassats(a)gmail.com> > wrote: > > cat b.asd > > (defsystem A) > > > > (defsystem B > > :depends-on (A)) > > > > (asdf:load-system 'b) is enough to trigger it. > > > > On Wed, Oct 18, 2017 at 6:51 PM Faré <fahree(a)gmail.com> wrote: > >> > >> See section 4 of the ASDF 3.3 paper at ILC 2017 for a quick overview: > >> https://github.com/fare/asdf2017 > >> > >> To support proper phase separation, ASDF has a new operation, > >> define-op, that tracks the dependencies of loading a .asd file (i.e. > >> other systems you operate on, e.g., via load-system or > >> defsystem-depends-on, etc.) > >> > >> I don't know exactly what is your system A and how you use it, but > >> apparently it's unhappy about depending on the primary system for > >> define-op yet being earlier in the .asd file, so the other system > >> hasn't been defined yet. > >> > >> Maybe ASDF should refrain from registering a dependency here between > >> sibling systems. Or not. It was quite subtle to debug about a year > >> ago, and it fell out of my working cache. > >> > >> Is there anything special you do between A and B except a :depends-on ? > >> > >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > >> http://fare.tunes.org > >> You think war is economically beneficial? Then why share those benefits > >> with > >> dirty foreigners? Let's have a civil war — A war we're sure to win! > >> > >> > >> On Wed, Oct 18, 2017 at 11:34 AM, Stas Boukarev <stassats(a)gmail.com> > >> wrote: > >> > It’s a regular depends-on, but why did it work before without > problems? > >> > > >> > On Wed, 18 Oct 2017 at 18:32 Faré <fahree(a)gmail.com> wrote: > >> >> > >> >> On Wed, Oct 18, 2017 at 11:25 AM, Stas Boukarev <stassats(a)gmail.com> > >> >> wrote: > >> >> > B is primary, but A has to be loaded before it. It precedes B, and > B > >> >> > depends > >> >> > on it. > >> >> > > >> >> If it's a regular :depends-on, then B should be able to appear before > >> >> A, and that should actually work better. > >> >> > >> >> If it's a :defsystem-depends-on, it used to be that A must be before > >> >> B, but the new situation is that they have to be in separate files > for > >> >> define-op to work at all. > >> >> > >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > >> >> http://fare.tunes.org > >> >> For ultimately, the most visible trait of a just man is to have no > >> >> desire > >> >> at all to rule others, and only want to rule himself. This decides > >> >> everything. In other words, the worst people will rule. — Alain > >> >> > >> >> > >> >> > >> >> > On Wed, Oct 18, 2017 at 6:23 PM Faré <fahree(a)gmail.com> wrote: > >> >> >> > >> >> >> On Wed, Oct 18, 2017 at 11:13 AM, Stas Boukarev < > stassats(a)gmail.com> > >> >> >> wrote: > >> >> >> > Looks like this happens because I have two systems in B.asd, A > and > >> >> >> > B, > >> >> >> > and B > >> >> >> > depends on A. > >> >> >> Maybe changing the order of the two systems will help. > >> >> >> Which is primary? Which depends on the other? > >> >> >> > >> >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > >> >> >> http://fare.tunes.org > >> >> >> All honest people are welcome to come and live here. > >> >> >> All dishonest people are welcome to come and die here. > >> >> >> — Libertarian Open-Borders, Open-Skulls Policy >

2 4

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel October 2017