asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Re: [asdf-devel] [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp
by Nikodemus Siivola 18 Aug '10

18 Aug '10

On 18 August 2010 14:49, James Fleming <lisp(a)electronic-quill.net> wrote: > The very short version of the question: what changed between 1.0.39 and > 1.0.40, regarding the expected locations of source files, and when/how > they're expected to be copied there during asdf::perform operations? ASDF version supplied with SBCL changing is the probable culprit for at least some of this -- adding asdf-devel to CC. (It seems the NEWS entry for ASDF2 was forgotten, oops...) However, this bit right here > ; compiling file > "/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/def-to-lisp.lisp" (written 15 indicates that something else is wrong too: loading SB-GROVEL should not cause it to be compiled. If your ASDF-LOAD uses :FORCE, that's a the obvious reason, but if not I suspect something funny is going on with timestamps on those files since ASDF feels the need to recompile them. Cheers, -- Nikodemus > The context: I'm writing a wiki (yes, yet another one), and its back-end > consists of plain-text files while I get to grips with writing a parser. > > The text-file wrangling calls on cl-fad, which uses sb-posix, which in > turn makes use of sb-grovel. > Somewhere between 1.0.39 and 1.0.40, a change was made that broke > sb-posix, at least on the two machines I use - both run 64-bit Linux, one > on AMD and one on Intel. > > The symptom: sb-grovel's def-to-lisp fails to compile at line 244, where > it tries to evaluate (compile-file tmp-constants :output-file output-file) > after defining 'tmp-constants in this manner: > (let ((tmp-constants (merge-pathnames #p"constants.lisp-temp" > real-output-file))) > > It seems to come down to where source-files are expected to be, i.e. the > ~/.cache tree, and how they're copied there. The problem can be reproduced > on cue by invoking (asdf:oos 'asdf:load-op :sb-posix). This appears as > (asdf-load :sb-posix) below because I'm a lazy git and defined that > abbreviation in my .sbclrc. > > I've been trying to follow along in the source-code, and the nearest > relevant changes appear to be in contrib/asdf/asdf.lisp, but my thinking > has been addled by a nasty head-cold. Could somebody please give me a > pointer to what I need to look at next? What have I missed? Help! > > > Thanks in advance for any useful tips, > James > > > P.S. For those who'd like to see exactly what happens, a bleeding great > copy-and-paste follows... > > * (asdf-load :sb-posix) > > ; compiling file > "/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/def-to-lisp.lisp" (written 15 > AUG 2010 07:51:57 PM): > ; compiling (IN-PACKAGE #:SB-GROVEL) > ; compiling (DEFVAR *DEFAULT-C-STREAM* ...) > ; compiling (DEFUN ESCAPE-FOR-STRING ...) > ; compiling (DEFUN SPLIT-CFLAGS ...) > ; compiling (DEFUN C-ESCAPE ...) > ; compiling (DEFUN AS-C ...) > ; compiling (DEFUN PRINTF ...) > ; compiling (DEFUN C-FOR-ENUM ...) > ; compiling (DEFUN C-FOR-STRUCTURE ...) > ; compiling (DEFUN PRINT-C-SOURCE ...) > ; compiling (DEFUN C-CONSTANTS-EXTRACT ...) > ; compiling (DEFCLASS GROVEL-CONSTANTS-FILE ...) > ; compiling (DEFINE-CONDITION C-COMPILE-FAILED ...) > ; compiling (DEFINE-CONDITION A-DOT-OUT-FAILED ...) > ; compiling (DEFMETHOD PERFORM ...) > > ; > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-grovel/ASDF-TMP-def-to-lisp.fasl > written > ; compilation finished in 0:00:00.558 > (/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.fasl > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.fasl > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/foo.c > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/a.out > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp) > > debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD > "initial > thread" RUNNING > {1002AC20A1}>: > failed to find the TRUENAME of > /home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp: > No such file or directory > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [TRY-RECOMPILING] Try recompiling constants > 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL > {1003B23C31}> on > #<SB-GROVEL:GROVEL-CONSTANTS-FILE > "sb-posix" "constants">. > 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {1003B23C31}> > on > #<SB-GROVEL:GROVEL-CONSTANTS-FILE > "sb-posix" "constants"> > as having been successful. > 3: [ABORT ] Exit debugger, returning to top level. > > (SB-IMPL::SIMPLE-FILE-PERROR > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 0] backtrace > > 0: (SB-IMPL::SIMPLE-FILE-PERROR > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 1: ((FLET SB-IMPL::FAIL) > "failed to find the TRUENAME of ~A" > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > 2) > 2: (SB-IMPL::QUERY-FILE-SYSTEM > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > :TRUENAME > T) > 3: (TRUENAME > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp") > 4: ((FLET SB-C::TRY-WITH-TYPE) > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp" > "lisp" > T) > 5: (SB-C::VERIFY-SOURCE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp") > 6: (SB-C::VERIFY-SOURCE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp")[:EXTERNAL] > 7: (COMPILE-FILE > #P"/home/james/.cache/common-lisp/sbcl-1.0.41-linux-x86-64/opt/pkgs/sbcl-1.0.41/lib/sbcl/sb-posix/constants.lisp-temp")[:EXTERNAL] > 8: ((SB-PCL::FAST-METHOD ASDF:PERFORM > (ASDF:COMPILE-OP SB-GROVEL:GROVEL-CONSTANTS-FILE)) > #<unavailable argument> > #<unavailable argument> > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 9: ((LAMBDA > (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. > SB-PCL::.ARG1.)) > #<unavailable argument> > #<unavailable argument> > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 10: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS > (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) > #<unavailable argument> > #S(SB-PCL::FAST-METHOD-CALL > :FUNCTION #<FUNCTION #> > :PV NIL > :NEXT-METHOD-CALL NIL > :ARG-INFO (2)) > #<ASDF:COMPILE-OP NIL {1003B23C31}> > #<SB-GROVEL:GROVEL-CONSTANTS-FILE "sb-posix" "constants">) > 11: ((LAMBDA ())) > 12: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) > 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]324)) > 14: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK > #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {7FFFF79AB6C9}> > #S(SB-THREAD:MUTEX > :NAME "World Lock" > :%OWNER #<SB-THREAD:THREAD "initial thread" RUNNING {1002AC20A1}> > :STATE 1)) > 15: ((FLET SB-C::WITH-IT)) > 16: ((SB-PCL::FAST-METHOD ASDF:OPERATE (T T)) > #<unavailable argument> > #<unavailable argument> > ASDF:LOAD-OP > :SB-POSIX)[:EXTERNAL] > 17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF-LOAD :SB-POSIX) #<NULL-LEXENV>) > 18: (INTERACTIVE-EVAL (ASDF-LOAD :SB-POSIX))[:EXTERNAL] > 19: (SB-IMPL::REPL-FUN NIL) > 20: ((LAMBDA ())) > 21: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002EBD309}>) > 22: (SB-IMPL::TOPLEVEL-REPL NIL) > 23: (SB-IMPL::TOPLEVEL-INIT) > 24: ((LABELS SB-IMPL::RESTART-LISP)) > > 0] > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Sbcl-help mailing list > Sbcl-help(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sbcl-help >

3 3

[asdf-devel] create temporary Lisp files in fasl directory
by Robert Brown 06 Aug '10

06 Aug '10

I'm using ASDF to build an open source implementation of Google's protocol buffer data serialization library. The code is here: http://github.com/brown/protobuf I've defined a new component type that allows developers to include protobuf message definition files in their Lisp ASDF files: (defclass protobuf-source-file (cl-source-file) ((relative-proto-pathname ... ) (search-path ... ) (:documentation "A protocol buffer definition file.")) When used like this in a system definition: :components ((:protobuf-source-file "foo")) executing the ASDF:LOAD-OP operation causes the file called foo.proto to be translated into foo.lisp by a C++ program, and then compiled into foo.fasl and loaded. Note that foo.lisp is created in the same directory as the system definition, but I would prefer it to be created in the same directory as foo.fasl, which for me is in a subdirectory of ~/.cache/common-lisp. What's the easiest way to accomplish this? I initially tried overriding INPUT-FILES when applied to CL-SOURCE-FILE instances, but ASDF::PERFORM is defined like this: (defmethod perform ((operation compile-op) (c cl-source-file)) (let ((source-file (component-pathname c)) ... ) ... ) Since it calls COMPONENT-PATHNAME to find Lisp source, it will always look in the system definition directory. bob

3 4

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

[asdf-devel] [Fwd: Re: Is this a bug? or my error?]
by Louis A. Turk 30 Jun '10

30 Jun '10

-------- Forwarded Message -------- > From: Louis A. Turk <lou(a)dayspringpublisher.com> > Reply-to: lou(a)dayspringpublisher.com > To: Faré <fahree(a)gmail.com> > Subject: Re: [asdf-devel] Is this a bug? or my error? > Date: Thu, 01 Jul 2010 03:58:40 +0800 > > On Wed, 2010-06-30 at 15:11 -0400, Faré wrote: > > Yup. Also, tell us in what directories things are, and whether you > > made > > any changes to ASDF default settings. > > /home/lat/.sbcl/site/iterate-1.4.3/iterate.lisp > /home/lat/clbuild/source/iterate/iterate.lisp > > /home/lat/lisp/collate/collate.lisp > > /home/lat/lisp/il/laturk-unique.asd > /home/lat/lisp/il/laturk-unique.lisp > /home/lat/lisp/il/packages.lisp > > Thanks for looking at this problem! > > Louis >

1 0

[asdf-devel] Proposal for improved support for versions of systems
by Vsevolod Dyomkin 29 Jun '10

29 Jun '10

Hi! Approximately after the release of ASDF 2 I've got interested in creating yet another system distribution management system on top of ASDF, and that made me investigate ASDF internals. Through that investigation, I've understood 2 things: * ASDF has support for much more, than is well known and in ordinary use by most Common Lisp programmers :) * still it's support for versioning (which is essential to distribution management) is lacking due to: - possibility to specify only exact version - somewhere in the depths of code version checking is lost (for example, there's no condition signaled, if in the process of system definitions traversal we load ASD file with different version for some system, that was already loaded, which actually causes errors in some situations, i.e. its a bug) - the syntax is not very friendly So, during last month I was developing ASDF in the direction of more robust version support. I've started with 2.000, but fortunately there's no intersection between my work and recent developments up to version 2.106 (except for new DEFGENERIC*, which is trivial). Attached is the proposed patch to ASDF, that, in my view, solves the aforementioned versioning problems. It does the following: * Unifies internal version representation format in the form of a list of integers: (for example, ASDF 2.106 will have an internal version of '(2 106 0), while ASDF 2.005 — '(2 5 0)). At the same time, the users are given quite a lot of freedom in specifying versions, for example they can do that as before in string form (like "1.2.3"), so it's backwards compatible. This new format is more programming-friendly and several utility functions are added: PROPER-VERSION (to transform to it), V> (version-greater-or-equal), MAJOR-VERSION and MINOR-VERSION,— while VERSION-SATISFIES is much improved in the manner, that is explained below. Also a method for SLOT-UNBOUND is added to VERSION slot on a SYSTEM class, to return version '(0 0 0), which is considered (on par with NIL) to be a wildcard version spec, so to say. * Adds VERSION-P (version-predicate) parameter to different ASDF functions, that need to deal with versions. This specifies in which way to match versions with VERSION-SATISFIES and currently has the following variants: :EXACT (nil also translates to :EXACT), :ABOVE, :MAJOR+, :MINOR+, and also a second version spec, which means that version should be in the interval from the given version to version-p itself. This is the change, that I had had in mind, when I started looking at ASDF * Adds a continuable error of type SYSTEM-VERSION-CONFLICT, when we try to read ASD file with a different version of some system, that is already in memory * Adds new format of version specification in :DEPENDS-ON clause of DEFSYSTEM. Besided (:version <system> <version>), which is retained and extended with version-p, i.e. (:version <system> <version> <version-p>) — example: (:version :hunchentoot "1.2.3" :above) ,— there's now also a simpler (<system> <version> <version-p>) — example: (:hunchentoot "1.2.3" :above) A final note about versioning: I needed to use pre-reading of ASD files in order to know their versions without arising version conflicts. This works, except for the fact, that READ-EVAL is turned off in the process, so such version specifiers as: * :version #.*hunchentoot-version* * :version #.(with-open-file (vers (merge-pathnames "version.lisp-expr" *load-truename*)) (read vers)) do not produce expected results and are treated as empty versions. There will be a need to make a note about that to library developers. Besides, an incompatible change is introduced to FIND-SYSTEM. The ERROR-P optional argument is removed, so plain NIL is unconditionally returned, when system is not found, and VERSION and VERSION-P optional arguments are added instead. I'd like to argue, that this is justified by two things: * there's no substantial use of ERROR-P argument neither in ASDF itself, nor anywhere in dependent code (at least I can tell that after a brief look at google search results) * more importantly, although there's another option to add version/version-p: add VERSION and VERSION-P as keyword arguments and leave ERROR-P also as keyword argument — I don't think, that overall the use of such argument is a proper architectural decision, because it's not an error actually, when system is not found — it's a common situation and should be dealt with in the caller appropriately to the context My last note concerning this patch is about testing. After syncing with the development branch of ASDF, I see the addition of TEST directory. When I'd started my experiments, I had somehow missed it (or it had not been there?). Anyway, I have supplied a number of unit tests to the functions, that I have added. This is done with a very simple unit testing library of my own (a microframework so to say) MUTEST, that can be found at: http://github.com/vseloved/mutest/. The tests are specified right in the code side-by-side with functions definitions, but are protected with #+mutest guards, so effectively can be ignored. They also have the benefit of showing, how each of the functions can be called. There's also a dummy directory structure under TEST, that is used in the tests and should be reproduced in the same directory, where ASDF-VERSION.LISP is located. I have also done functional testing of the changes with the systems, that I have got installed already (around 70 libraries), and have verified, that there are no problems. At the same time I would not claim, that there will not be any problems with some system definitions, that use obscure ASDF features (although, I have acquainted myself with ASDF to the point, that I quite well understand most of the features as well as internals now). So I ask anyone interested in this set of changes to thoroughly test them. At the same time I'd be glad to know more about utilizing the current ASDF test-suite. Finally, the patch can be applied by simply loading ASDF-VERSION.LISP on top of the loaded ASDF 2.106. I hope, this work proves useful and is integrated into ASDF. Anyway I'm willing to answer any questions and/or improve the implementation, if needed. Vsevolod Dyomkin

3 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel