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

[asdf-devel] Detecting non-defsystem dependencies
by Zach Beane 08 Apr '15

08 Apr '15

Some system files look like this: ;;;; myproject.asd (asdf:load-system "some-prerequisite") (defsystem "myproject" ...) Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward? Zach

4 11

[asdf-devel] New OPERATION subclasses in ASDF 3
by Robert P. Goldman 08 Apr '15

08 Apr '15

Recent experience shows that changes leading to ASDF 3 have changed the way one must specify new operation classes, in a way that is not backward-compatible. Thanks to Faré for helping me diagnose problems in one such system. I will be looking into this, and hope to add at least one new test to ensure that we are probing this important aspect of ASDF going forward. Related to this, does anyone have a good sense of which quicklisp systems might contain new operation and component classes? thanks, R

3 3

[asdf-devel] ASDF testing for 3.1.0.24 begins...
by Dave Cooper 08 Apr '15

08 Apr '15

Running tests against 3.1.0.24. So far we have a failure for abcl on Windows. I plan to put all my asdf test failures here from now on: https://www.dropbox.com/home/Public/asdf-failures I'll try to send notifications when something new lands in there. Will it be useful to post the non-failure test results as well? By the way, as far as I know we can still use some test volunteers for the following commercial platforms: Allegro MacOS LispWorks Windows (Nick L, Fabrice P?) LispWorks Linux Scieneer (all its supported platforms) Genera (all its supported platforms) This is not to discourage additional testers on the platforms we already think we are covering (the more eyes the better). What am I missing? -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

1 1

[asdf-devel] New failures on Allegro Windows
by Dave Cooper 08 Apr '15

08 Apr '15

With latest pull (with 3.0.2.22) I'm getting one failure on mlisp windows and two on alisp windows (a few pulls ago, alisp windows was passing all tests and mlisp was unknown but apparently failing several which are apparently all fixed now, because the one mlisp failure does not appear casemode related): =========== mlisp: Above backtrace due to this condition: These two expressions fail comparison with equal: "ok 1" evaluates to "ok 1" (asdf-test::dewindowize (uiop/run-program:run-program "echo ok 1" :output :line)) evaluates to "ok 1" Script failed <The Lisp process exited with status 1 (0x1)> =========== alisp: Above backtrace due to this condition: These two expressions fail comparison with equal: "ok 1" evaluates to "ok 1" (asdf-test::dewindowize (uiop/run-program:run-program "echo ok 1" :output :line)) evaluates to "ok 1" Script failed <The Lisp process exited with status 1 (0x1)> Above backtrace due to this condition: These two expressions fail comparison with EQUAL: (ASDF-TEST::SANITIZE-LOG (ASDF-TEST::RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Script failed <The Lisp process exited with status 1 (0x1)>

3 4

[asdf-devel] module description option
by Mirko Vukovic 08 Apr '15

08 Apr '15

I find that defsystem accepts the :description keyword in modules and I use it for my asdf documentation. But I don't see it documented in the asdf manual (on http://common-lisp.net/project/asdf/asdf.html) Is this an undocumented feature? I would hate to see it go away. Mirko

1 0

[asdf-devel] Possible problem with check-compile-results
by Robert Goldman 08 Apr '15

08 Apr '15

I would be grateful if someone could confirm this for me. I see this in quickloading BABEL on a relatively recent SBCL 1.1.7.112.master.104-d62278d Babel crashes on compiling: caught ERROR: ; (during macroexpansion of (DEFINE-UCS :UCS-2LE ...)) ; #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression. ; Wanted one of (STRING SIMPLE-STRING). ; in: DEFINE-UCS :UCS-2BE ; (BABEL-ENCODINGS::DEFINE-UCS :UCS-2BE 2 :BE 65536) After that, some logic in UIOP'S CHECK-LISP-COMPILE-RESULTS goes pear-shaped. I believe the problem starts here: (with-upgradability () (defmacro define-convenience-action-methods (function formals &key if-no-operation if-no-component operation-initargs) (let* ((rest (gensym "REST")) (found (gensym "FOUND")) (keyp (equal (last formals) '(&key))) (formals-no-key (if keyp (butlast formals) formals)) (len (length formals-no-key)) (operation 'operation) (component 'component) (opix (position operation formals)) (coix (position component formals)) (prefix (subseq formals 0 opix)) (suffix (subseq formals (1+ coix) len)) (more-args (when keyp `(&rest ,rest &key &allow-other-keys)))) (assert (and (integerp opix) (integerp coix) (= coix (1+ opix)))) (flet ((next-method (o c) (if keyp `(apply ',function ,@prefix ,o ,c ,@suffix ,rest) `(,function ,@prefix ,o ,c ,@suffix)))) `(progn (defmethod ,function (,@prefix (,operation symbol) component ,@suffix ,@more-args) (if ,operation ,(next-method (if operation-initargs ;backward-compatibility with ASDF1's operate. Yuck. `(apply 'make-operation ,operation :original-initargs ,rest ,rest) `(make-operation ,operation)) `(or (find-component () ,component) ,if-no-component)) ,if-no-operation)) (defmethod ,function (,@prefix (,operation operation) ,component ,@suffix ,@more-args) (if (typep ,component 'component) (error "No defined method for ~S on ~/asdf-action:format-action/" ',function (cons ,operation ,component)) (if-let (,found (find-component () ,component)) ,(next-method operation found) ,if-no-component)))))))) The ERROR created here, with its embedded funcall to ASDF-ACTION:FORMAT-ACTION seems to do something bad when the format string is repackaged in UIOP/LISP-BUILD:CHECK-LISP-COMPILE-RESULTS: (unless output (error 'compile-file-error :context-format context-format :context-arguments context-arguments)) possibly in this REPORT-FUNCTION: (:report (lambda (c s) (format s (compatfmt "~@<~A~@[ while ~?~]~@:>") (or (compile-condition-description c) (type-of c)) (compile-condition-context-format c) (compile-condition-context-arguments c))))) I am not particularly adept in the SBCL debugger wrapped by SLDB, especially where one of these error-wrapped-in-error-wrapped-in-ASDF-wrapped-in-quicklisp contexts, so I would be grateful if someone would try to replicate this (try a clean QL install of BABEL). Note that the error comes with SBCL's built-in ASDF, not bleeding-edge ASDF. Thanks! r -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

3 2

Re: [asdf-devel] Cannot use latest git ECL (asdf/quicklisp are involved)
by Robert Goldman 08 Apr '15

08 Apr '15

Didier Verna wrote: > Robert Goldman <rpgoldman(a)sift.info> wrote: > >> Can you get a backtrace from the failed call to delete the directory? > > OK. So I restarted ecl -norc and then did a (load ".clrc") with the > contents mentioned in my previous message. This is what I get. FWIW, > the directory in which UIOP is trying to delete the non-existent > asdf.fas file contains 2 files: asdf.o and asdf-ASDF-TMP.fas. Thanks, Didier. Would you please file a launchpad ticket? I am afraid I cannot be very helpful in the near future -- my neighborhood lost power last Friday in a storm, so I am having a bit of trouble staying on top of things. The name of Faré's function (delete-file-if-exists) suggests that Faré expects the deletion to fail gracefully, instead of raising an error. He attempts to catch a FILE-ERROR there. I note that ECL seems to be raising a SIMPLE-ERROR instead of a FILE-ERROR. The hyperspec states of DELETE-FILE: If the deletion operation is not successful, an error of type file-error is signaled. So if ECL is raising a SIMPLE-ERROR instead, that would be a bug in ECL, and not in ASDF. One thing that seems odd is that it seems ECL is claiming that it's asked to delete a directory, not a file. Can you trap the argument to DELETE-FILE-IF-EXISTS? Best, r > > > didier(pts/1)% ecl -norc 14:48 06/24/13 > ECL (Embeddable Common-Lisp) 12.7.1 (git:52ca46e054d72cb0b0802e376890fcfbdfc96e5a) > Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya > Copyright (C) 1993 Giuseppe Attardi > Copyright (C) 2000 Juan J. Garcia-Ripoll > ECL is free software, and you are welcome to redistribute it > under certain conditions; see file 'Copyright' for details. > Type :h for Help. > Top level in: #<process TOP-LEVEL>. >> (load ".clrc") > > ;;; Loading #P"/home/didier/.clrc" > ;;; Loading "/usr/local/share/common-lisp/source/asdf/build/asdf.lisp" > > Condition of type: SIMPLE-ERROR > Cannot delete the directory #P"/home/didier/.cache/common-lisp/ecl-12.7.1-52ca46e0-linux-x86/usr/local/share/common-lisp/source/asdf/build/asdf.fas". > C library explanation: No such file or directory. > Available restarts: > > 1. (RETRY) Retry compiling #<cl-source-file "asdf" "build" "asdf">. > 2. (ACCEPT) Continue, treating compiling #<cl-source-file "asdf" "build" "asdf"> as having been successful. > 3. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > Broken at UIOP/FILESYSTEM:DELETE-FILE-IF-EXISTS. In: #<process TOP-LEVEL>. > File: #P"/usr/local/share/common-lisp/source/asdf/build/asdf.lisp" (Position #139589) >>> :b > > Backtrace: > > UIOP/FILESYSTEM:DELETE-FILE-IF-EXISTS > > uiop/lisp-build:compile-file* > > lambda > > uiop/utility:call-with-muffled-conditions > > uiop/lisp-build:call-with-muffled-compiler-conditions > > lambda > > uiop/utility:call-function > > uiop/lisp-build:call-around-hook > > lambda > > asdf/lisp-action:perform-lisp-compilation > > lambda > > lambda > > lambda > > lambda > > lambda > > lambda > > call-next-method > > lambda > > asdf/cache:call-with-asdf-cache > > asdf/find-system::call-with-system-definitions > > lambda > > lambda > > call-next-method > > lambda > > asdf/cache:call-with-asdf-cache > > asdf/find-system::call-with-system-definitions > > lambda > > asdf/operate:load-system > > uiop/package:symbol-call > > asdf/upgrade:upgrade-asdf > > lambda > > asdf/operate:oos > > si:bytecodes [Evaluation of: (let ((*compile-print* nil) (*compile-verbose* nil) (*load-verbose* nil) (*load-print* nil)) (asdf/operate:oos 'asdf/lisp-action:load-op "quicklisp" :verbose nil))] > > si:bytecodes [Evaluation of: (let ((quicklisp-init "/usr/local/share/common-lisp/source/quicklisp/setup.lisp")) (when (probe-file quicklisp-init) (load quicklisp-init)))] > > si:bytecodes [Evaluation of: (load ".clrc")] > > si:bytecodes [Evaluation of: (si:top-level t)] > >

1 0

[asdf-devel] Structure of ASDF directory
by Robert Goldman 08 Apr '15

08 Apr '15

I was wondering if it would be possible to bump the uiop.asd file up to be a sibling of asdf.asd. It seems odd to me that asdf.asd is at the top level, and has build/asdf.lisp under it, but that uiop.asd is in uiop/. Odd + it means I need now to do (push "home:lisp;asdf;" asdf:*central-registry*) and (push "home:lisp;asdf;uiop;" asdf:*central-registry*) to upgrade.... Any reason why uiop.asd couldn't be at the top level? thanks, r

2 1

[asdf-devel] using uiop standalone
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. If I want to use uiop tools, for example run-program, can I use the newest uiop without upgrading ASDF, or it should be only used with corresponding ASDF version? I mean, uiop is included in Quicklisp, I can add :depends-on uiop, but will it affect the ASDF version shipped with my CL implementation? Is it safe to load new uiop with any ASDF? BTW, is the uiop-3.0.3.tgz included into the recent Quicklisp 2014-02-11 is the latest version of uiop? Best regards, - Anton

2 1

[asdf-devel] Version 3.0.2.9 available
by Robert Goldman 08 Apr '15

08 Apr '15

Minor test tweak only. But one item off my todo list! ;-)

1 0