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

[asdf-devel] Feature Request: Better Error Reporting
by Seth Burleigh 11 Sep '10

11 Sep '10

I was wondering if it was possible for some better error reporting. For example, when i was compiling kenny's cl-opengl, this is what i get: ; compiling (DEFVAR *OPENGL-DLL* ...) ; compiling (DEFUN CL-OPENGL-LOAD ...) ; compiling (CL-OPENGL-LOAD) ; compiling (DEFUN GL-BOOLEAN-TEST ...) ; compiling (DFENUM STORAGETYPE ...) ; compiling (DFENUM FILTERTYPES ...) ; /home/seth/install/lisp/cello/cl-opengl/sbcl-1.0.38-linux-x86/cl-opengl.fasl written ; compilation finished in 0:00:00.045 WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {CB49DA9}> on #<CL-SOURCE-FILE "cl-opengl" {BD132C1}>. And then i get thrown into the slime debugger with a very nonhelpful error: compile-opp nil? Cant asdf give us the actual error thrown? This has happened multiple times on many libraries.

4 14

[asdf-devel] CMUCL error
by Devon Sean McCullough 06 Sep '10

06 Sep '10

Today's bleeding-edge ASDF fails to compile in CMUCL 1 compiler notes: ../asdf/asdf.lisp:3371:1: error: (during macroexpansion) Error in FDEFINITION: the function MODULE-COMPONENTS-BY-NAME is undefined. Compilation failed. Peace --Devon /~\ \ / Health Care X not warfare / \ PS: compiles fine in ACL

2 1

[asdf-devel] spurious warnings patch for CMUCL
by Devon Sean McCullough 06 Sep '10

06 Sep '10

Fix two unreachable code removal warnings in CMUCL: diff -Bbdur old/asdf/asdf.lisp new/asdf/asdf.lisp --- old/asdf/asdf.lisp 2010-05-21 17:18:04.000000000 -0400 +++ new/asdf/asdf.lisp 2010-05-22 17:01:06.000000000 -0400 @@ -492,7 +492,7 @@ (let* ((specified (pathname specified)) (defaults (pathname defaults)) (directory (pathname-directory specified)) - #-sbcl (directory (if (stringp directory) `(:absolute ,directory) directory)) + #-(or cmu sbcl) (directory (if (stringp directory) `(:absolute ,directory) directory)) (name (or (pathname-name specified) (pathname-name defaults))) (type (or (pathname-type specified) (pathname-type defaults))) (version (or (pathname-version specified) (pathname-version defaults)))) @@ -734,7 +734,7 @@ (directory (pathname-directory p))) (when (typep p 'logical-pathname) (return p)) (ignore-errors (return (truename p))) - #-sbcl (when (stringp directory) (return p)) + #-(or cmu sbcl) (when (stringp directory) (return p)) (when (not (eq :absolute (car directory))) (return p)) (let ((sofar (ignore-errors (truename (pathname-root p))))) (unless sofar (return p)) Peace --Devon /~\ \ / Health Care X not warfare / \ PS: Is this a good venue for patches?

2 1

Re: [asdf-devel] Performance hit in TRUENAMIZE
by Juan Jose Garcia-Ripoll 25 Jul '10

25 Jul '10

On Fri, Jul 16, 2010 at 12:54 AM, edgar <edgar-rft(a)web.de> wrote: > I think the main problem here is that some implementations > (notably CLISP) differ between files and directories, so > PROBE-FILE cannnot be used to probe files AND directories. Well, SBCL and ECL do not have that problem, AFAIK. But TRUENAMIZE also seems to be used with files, not directories, from what I could gather during the debugging of ASDF. I would abstract those calls into a function PROBE-FILE-AND-DIRECTORY and use PROBE-FILE internally in this function. The purpose would be clear and sensible implementations might profit from that -- maybe the terrible startup times for ASDF might be decreased this way. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 4

[asdf-devel] Performance hit in TRUENAMIZE
by Juan Jose Garcia-Ripoll 15 Jul '10

15 Jul '10

Why using TRUENAME + ERROR + HANDLER-CASE instead of PROBE-FILE? I have been tracking a completely unrelated bug in ECL but found that for loading all files ASDF calls TRUENAME with the names of FASLs that do not exist. It finds out that by catching the corresponding error and then tries something else. Throwing and catching errors is costly. Why doing that instead of using PROBE-FILE? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 2

[asdf-devel] ASDF:LOAD-SYSTEM always recompiles some files
by Benjamin Benninghofen 13 Jul '10

13 Jul '10

Look at the following Symbolics System Definition: ;;;(sct:defsystem :foo ;;; (:default-pathname "scratch/" ;;; :default-module-type :lisp) ;;; ;;; (:module foo ("FOO")) ;;; ;;; (:module bar ("BAR") ;;; (:in-order-to (:compile :load) (:load foo))) ;;; ;;; ) I translated this to ASDF as follows: (ASDF:DEFSYSTEM :FOO :COMPONENTS ((:MODULE FOO :PATHNAME "" :COMPONENTS ((:FILE "foo"))) (:MODULE BAR :PATHNAME "" :COMPONENTS ((:FILE "bar")) :IN-ORDER-TO ((ASDF:COMPILE-OP (ASDF:LOAD-OP FOO)) (ASDF:LOAD-OP (ASDF:LOAD-OP FOO)))))) This is not exactly equivalent, because the semantics of :IN-ORDER-TO is different in Symbolics SCT and ASDF. However I get a very strange behavior of the ASDF System. I write the ASDF:DEFSYSTEM form in a file "scratch/sysdcl.lisp" I compiled the system and then restarted Lisp in order to load the system: CL-USER(2): (load "scratch/sysdcl") ; Loading /home/usr/benni/lisp/scratch/sysdcl.lisp T CL-USER(3): (asdf:find-system :foo) #<ASDF:SYSTEM "foo"> CL-USER(4): (asdf:load-system :foo) ; Fast loading /home/usr/benni/lisp/scratch/foo.fasl ;;; Compiling file /home/usr/benni/lisp/scratch/bar.lisp ;;; Writing fasl file /home/usr/benni/lisp/scratch/ASDF-TMP-bar.fasl ;;; Fasl write complete ; Fast loading /home/usr/benni/lisp/scratch/bar.fasl #<ASDF:LOAD-OP NIL @ #x7292bc42> CL-USER(5): As you see it recompiles one of the files. This happens after each restart of Lisp (Allegro CL 8.1). ASDF:LOAD-SYSTEM each time recompiles "bar.lisp" even if no file is changed. Output Translations were disabled by calling (ASDF:DISABLE-OUTPUT-TRANSLATIONS) -- Benjamin Benninghofen Systemanalytiker EADS Defence & Security Military Air Systems Application Software and Processes - OPEM22 Rechliner Straße 85077 Manching - Germany Telephone: +49 (0) 8459 81 78125 Telephone: +49 (0) 89607 78125 Fax: +49 (0) 8459 81 78105 e-Mail: Benjamin.Benninghofen(a)eads.com EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB 107 648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht NOTICE: This message, together with any attachments, may contain privileged and/or confidential information. If you have received this e-mail in error or are not an intended recipient, you may not use, reproduce, disseminate or distribute it; do not open nor save any attachments, delete it immediately from your system and notify the sender promptly by e- mail that you have done so. Thank you.

2 3

[asdf-devel] ASDF 2.004
by Faré 13 Jul '10

13 Jul '10

I blessed 2.111 as 2.004 and released it all. Several minor bugs have been fixed, and implementation vendors are recommended to upgrade. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is a miracle that curiosity survives formal education. — Albert Einstein

1 0

[asdf-devel] Semantic of ASDF Dependencies
by Benjamin Benninghofen 06 Jul '10

06 Jul '10

Assume we have files "packages" "macros" "classes" "methods" "functions" and we want the following dependencies: 1. In order to compile or load any of the other files the file "packages.fasl" must be loaded. 2. In order to compile or load "methods" the file "classes.fasl" must be loaded. 3. The file "macros" contains macros used in "methods" and "functions" and hence "macros.fasl" must be loaded before any of these 2 files is compiled or loaded. Furthermore when "macros" is changed also "methods" and "functions" have to be recompiled even if they are unchanged. 4. There shall be no more dependencies, i.e. when a file different from "macros" is changed, only this file shall be recompiled. With the Symbolics System Construction Tool (SCT) one would use (:USES-DEFINITIONS-FROM macros) for methods and functions and (:IN-ORDER-TO (:COMPILE :LOAD) (:LOAD packages ...)) for the other dependencies. (asdf:defsystem :test1 :description "Test Dependency Processing" :components ( (:file "packages") (:file "macros" :in-order-to ((asdf:compile-op (asdf:load-op "packages")) (asdf:load-op (asdf:load-op "packages")))) (:file "classes" :in-order-to ((asdf:compile-op (asdf:load-op "packages")) (asdf:load-op (asdf:load-op "packages")))) (:file "methods" :depends-on ("macros") :in-order-to ((asdf:compile-op (asdf:load-op "packages" "classes")) (asdf:load-op (asdf:load-op "packages" "classes")))) (:file "functions" :depends-on ("macros") :in-order-to ((asdf:compile-op (asdf:load-op "packages")) (asdf:load-op (asdf:load-op "packages")))) )) Unfortunately this does not work. All of the ASDF dependencies :DEPENDS-ON and :IN-ORDER-TO seem to behave like the SCT :USES-DEFINITIONS-FROM. For example when "classes" is changed it will recompile "methods" too. Is there anything in ASDF that provides the functionality of the SCT :IN-ORDER-TO ? -- Benjamin Benninghofen Systemanalytiker EADS Defence & Security Military Air Systems Application Software and Processes - OPEM22 Rechliner Straße 85077 Manching - Germany Telephone: +49 (0) 8459 81 78125 Telephone: +49 (0) 89607 78125 Fax: +49 (0) 8459 81 78105 e-Mail: Benjamin.Benninghofen(a)eads.com EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB 107 648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht NOTICE: This message, together with any attachments, may contain privileged and/or confidential information. If you have received this e-mail in error or are not an intended recipient, you may not use, reproduce, disseminate or distribute it; do not open nor save any attachments, delete it immediately from your system and notify the sender promptly by e- mail that you have done so. Thank you.

2 1

[asdf-devel] Is this a bug? or my error?
by Louis A. Turk 01 Jul '10

01 Jul '10

asdf version 2.104 invalid method error for #1=#<STANDARD-METHOD ASDF:OPERATION-DONE-P ASDF::AROUND (ASDF:COMPILE-OP T) {AAE52D1}> method: The method #1# on #<STANDARD-GENERIC-FUNCTION ASDF:OPERATION-DONE-P (5)> has an invalid qualifier. Standard method combination requires all methods to have one of the single qualifiers :AROUND, :BEFORE and :AFTER or to have no qualifier at all. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {B558181}>) Backtrace: 0: (SB-PCL::STANDARD-COMPUTE-EFFECTIVE-METHOD ..) 1: (SB-PCL::GET-SECONDARY-DISPATCH-FUNCTION2 ..) 2: (SB-PCL::GET-SECONDARY-DISPATCH-FUNCTION1 ..) 3: (SB-PCL::CACHE-MISS-VALUES-INTERNAL ..) 4: (SB-PCL::CACHE-MISS-VALUES #<STANDARD-GENERIC-FUNCTION ASDF:OPERATION-DONE-P (5)> (#<ASDF:COMPILE-OP NIL {B87D2B9}> #<ASDF:CL-SOURCE-FILE "iterate" "package">) SB-PCL::ACCESSOR) 5: (SB-PCL::INITIAL-DFUN #<STANDARD-GENERIC-FUNCTION ASDF:OPERATION-DONE-P (5)> (#<ASDF:COMPILE-OP NIL {B87D2B9}> #<ASDF:CL-SOURCE-FILE "iterate" "package">)) 6: ((SB-PCL::FAST-METHOD ASDF::DO-TRAVERSE (ASDF:OPERATION ASDF:COMPONENT T)) ..) 7: ((SB-PCL::FAST-METHOD ASDF::DO-TRAVERSE (ASDF:OPERATION ASDF:COMPONENT T)) ..) 8: (ASDF::DO-ONE-DEP #<ASDF:LOAD-OP NIL {B879DC1}> #<ASDF:SYSTEM "iterate"> #<CLOSURE (FLET ASDF::COLLECT) {B87A76D}> ASDF:COMPILE-OP "iterate" NIL) 9: ((FLET ASDF::DEP) ASDF:COMPILE-OP "iterate" NIL) 10: (ASDF::DO-DEP #<ASDF:LOAD-OP NIL {B879DC1}> #<ASDF:SYSTEM "iterate"> #<CLOSURE (FLET ASDF::COLLECT) {B87A76D}> ASDF:COMPILE-OP ("iterate")) 11: ((SB-PCL::FAST-METHOD ASDF::DO-TRAVERSE (ASDF:OPERATION ASDF:COMPONENT T)) ..) 12: ((SB-PCL::FAST-METHOD ASDF::TRAVERSE (ASDF:OPERATION ASDF:COMPONENT)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {B879DC1}> #<ASDF:SYSTEM "iterate">) 13: ((SB-PCL::FAST-METHOD ASDF:OPERATE (T T)) #<unavailable argument> #<unavailable argument> ASDF:LOAD-OP #<ASDF:SYSTEM "iterate">)[:EXTERNAL] 14: (ASDF::MODULE-PROVIDE-ASDF :ITERATE) 15: ((LAMBDA (#:G[REQUIRE]13)) ASDF::MODULE-PROVIDE-ASDF) 16: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 #<CLOSURE (LAMBDA #) {B873E1D}> (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 17: (REQUIRE :ITERATE NIL) 18: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE :ITERATE) #<NULL-LEXENV>) 19: (SWANK::%EVAL-REGION "(require :iterate)\n") 20: ((LAMBDA ())) 21: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {B873A9D}>) 22: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<CLOSURE (LAMBDA #) {B873A85}>) 23: (SWANK::%LISTENER-EVAL "(require :iterate)\n") 24: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(require :iterate)\n") #<NULL-LEXENV>) 25: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(require :iterate)\n") "COMMON-LISP-USER" 8) 26: (SWANK::PROCESS-REQUESTS NIL) 27: ((LAMBDA ())) 28: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {B740E9D}>) 29: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {B740E9D}>) 30: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #) (*STANDARD-INPUT* . #) (*TRACE-OUTPUT* . #) (*ERROR-OUTPUT* . #) (*DEBUG-IO* . #) (*QUERY-IO* . #) ...) #<CLOSURE (LAMBDA #) {B740EB5}>) 31: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {AD5A301}> #<CLOSURE (LAMBDA #) {B740E9D}>) 32: (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {AD5A301}> NIL) 33: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B55B08D}>) 34: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK351]356)) 35: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 36: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]293)) 37: (SB-THREAD::CALL-WITH-MUTEX ..) 38: (SB-THREAD::INITIAL-THREAD-FUNCTION) 39: ("foreign function: #x8066EDB") 40: ("foreign function: #x8052A6D") 41: ("foreign function: #x805DD30") 42: ("foreign function: #xB7FB380E")

3 11