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

[asdf-devel] oddity in operation-times...
by Robert Goldman 14 Dec '11

14 Dec '11

I think I have found an oddity in ASDF operation times…. If you have a system that doesn't contain any files, then the OPERATION-TIMES never get populated, even if the system is loaded. How can this happen? If you have a system that is loaded simply in order to make a component-dependent-pathname available, then it might not have any files in it. If such a system is loaded, I would expect that the (PERFORM COMPILE-OP SYSTEM) and (PERFORM LOAD-OP SYSTEM) methods should run (well, at least the latter, and that the operation-times for the system should be set. Unfortunately, it seems that if you have an empty system, then the LOAD-OP is never performed on that system object. My guess is that there's some logic that says that you only need to perform an operation on a module if the operation is performed on at least one of its components. I can imagine how we got here, but it seems like a bad fit for this case. <sigh> the semantics of operations on modules never cease to cough up oddities. </sigh> r

1 0

[asdf-devel] XDG_DATA_DIRS and colon separated things
by Rupert Swarbrick 13 Dec '11

13 Dec '11

Hi, TL;DR: Confusing error message. Is it possible to make it less confusing and/or ignore the silly input I inadvertently gave asdf? I'm writing because I've just spent ages debugging a confusing niggle with interaction between ASDF and my linux box. Basically, running sbcl in a terminal and then trying to (require 'foo) gave me this rather confusing error message: > This is SBCL 1.0.54.0.debian, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (require :cl-fad) > ASDF could not load cl-fad because > Invalid designator for an absolute pathname: #P"common-lisp/systems/". > > debugger invoked on a SIMPLE-ERROR in thread > #<THREAD "initial thread" RUNNING {AB1B781}>: > Invalid designator for an absolute pathname: #P"common-lisp/systems/" > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system cl-fad after > reinitializing the > source-registry. > 1: [ABORT ] Exit debugger, returning to top > level. > > (ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT > #P"common-lisp/systems/" > :DIRECTORY > T > :WILDEN > NIL) I finally worked out what was going on by looking at default-source-directory: > * (default-source-registry) > > (:SOURCE-REGISTRY (:DIRECTORY #P"/home/rupert/.sbcl/systems/") > (:DIRECTORY #P"/home/rupert/src/mine/atonews/") > (:DIRECTORY #P"/home/rupert/.local/share/common-lisp/systems/") > (:TREE #P"/home/rupert/.local/share/common-lisp/source/") > (:DIRECTORY #P"common-lisp/systems/") (:TREE #P"common-lisp/source/") > (:DIRECTORY #P"/opt/gnome/share/common-lisp/systems/") > (:TREE #P"/opt/gnome/share/common-lisp/source/") > (:DIRECTORY #P"/usr/local/share/common-lisp/systems/") > (:TREE #P"/usr/local/share/common-lisp/source/") > (:DIRECTORY #P"/usr/share/common-lisp/systems/") > (:TREE #P"/usr/share/common-lisp/source/") :INHERIT-CONFIGURATION) Note the #P"common-lisp/systems/" line! Tracing further, I found that this comes from a mistake I made when setting up my shell. $XDG_DATA_DIRS is :/opt/gnome/share/:/usr/local/share/:/usr/share/ Because of the leading colon, the split-string call on line 4020 of asdf.lisp gives me a leading "", resulting in path names that aren't fully qualified. Now, I'll fix my setup, since it's my own silly fault, but do any of you have an idea for how to make this error less perplexing for the next person who does something similar? (Maybe just drop "" components?) Rupert

3 3

[asdf-devel] asdf with-compilation-unit
by Mark H. David 13 Dec '11

13 Dec '11

Is there any way to have ASDF compile several files with with-compilation-unit wrapped around the compilation?

3 7

[asdf-devel] flatten-source-registry bugfix
by Сергей Катревич 12 Dec '11

12 Dec '11

Hi lispers! Please review my patch.

3 5

[asdf-devel] load order of dependencies
by Attila Lendvai 09 Dec '11

09 Dec '11

dear list, my use-case: i want to make sure that when a system is loaded (compiled) due to its test suite being invoked, then a full-blown optional dependency be loaded first, and only then the system itself (which checks for #+(cl:find-package :foo) at compile time). to be more specific, it's about whether to load or not a full logging library with heavy dependencies. when the test suite is invoked, then debugging will most probably follow, so load logging first that affects the compilation of the system itself. and to be even more specific, we have a custom develop-op, that does all kind of things, including the seeking and loading of all the optional swank integration systems we have, etc. (note: i was doing the experiments below using plain 'asdf:load-system invoked on :hu.dwim.reiterate+hu.dwim.logger, and AFAICS there are no customizations that should interfere, but hit me on the head with the ASDF manual if you believe otherwise, and i should go back and try to synthesize a stripped down test case.) this is how i wanted to achieve it: CL-USER> (asdf:asdf-version) "2.017" try #1 (in any order, reiterate is compiled before the logger): :in-order-to ((load-op (load-op :hu.dwim.logger :hu.dwim.reiterate)) (compile-op (compile-op :hu.dwim.logger :hu.dwim.reiterate))) without any :depends-on entry, which as far as i understand compiles into :in-order-to entries. try #2 (the before methods seem to get invoked too late when logger has fasls and reiterate doesn't?! but seems to work when neither have fasls?!): (defsystem :hu.dwim.reiterate+hu.dwim.logger :class hu.dwim.system :description "Loads hu.dwim.logger first, so that proper logging is available when developing, but not making the extra dependency mandatory." :depends-on (:hu.dwim.reiterate :hu.dwim.logger)) (defmethod perform :before ((op operation) (system (eql (find-system :hu.dwim.reiterate+hu.dwim.logger)))) (load-system :hu.dwim.logger)) (defmethod perform :before ((op operation) (system (eql (find-system :hu.dwim.reiterate)))) (load-system :hu.dwim.logger)) (defmethod perform :before ((op operation) (system (eql (find-system :hu.dwim.reiterate.test)))) (load-system :hu.dwim.logger)) but to the point: what's the contract regarding the load/compile order of dependencies? and if there's any, then how can i tell ASDF to load hu.dwim.logger first? (i couldn't find anything in the manual, but i welcome a "try again in chapter 6", because asdf sources are not too easy on my parser...) and if the order is not specified in the ASDF contract, then can we apply a randomizer to the otherwise equal dependencies? i've seen it many times before that unrecorded dependencies showed up as filesystem order changed (or something else, it's just an assumption, but the missing dependency often materialized when deploying the system on a different machine). -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06

3 7

[asdf-devel] component-class for files selected on basis of *features*
by Nikodemus Siivola 08 Dec '11

08 Dec '11

I want to define a component class PORT-FILE, to be used like this: :components ((port-file "ccl" :when :ccl) (port-file "clisp" :when :clisp) (port-file "sbcl-x86" :when (and :sbcl :x86)) ...) The implementation I have adds AROUND methods for PERFORM (LOAD-OP PORT-FILE) PERFORM (LOAD-SOURCE-OP PORT-FILE) PERFORM (COMPILE-OP SOURCE-FILE) and does CALL-NEXT-METHOD only if the feature test passes -- which seems to work well enough, but is there a better place to hook into? Cheers, -- Nikodemus

3 2

[asdf-devel] Which are the highest-maintenance CL implementations?
by Faré 28 Nov '11

28 Nov '11

Xach was deriding on twitter my inserting a last-minute patch to ASDF for the sake of Genera compatibility. Sure it's a pain to support, but is it *that* much worse than other implementations? grep '#[-+]' asdf.lisp > /tmp/a for i (abcl allegro clisp clozure cmu cormanlisp ecl gcl genera lispworks mcl sbcl scl xcl) { echo "$(grep -c $i < /tmp/a) $i" } | sort -nr 22 scl 21 genera 20 sbcl 20 lispworks 19 abcl 18 cmu 18 clisp 18 allegro 16 gcl 16 ecl 15 xcl 15 cormanlisp 13 clozure 12 mcl All implementations seem to be in the same ballpark, as far as hacks required to support them go. Yes, Genera is old and quirky. I still works better than either GCL (that I've stopped supporting, because I can't compile a version recent enough to not have the multiple-value compile bug), or CormanLisp, for instance. Indeed, supporting 14 implementations is a huge pain. I don't feel like doing it again. And I feel less and less like keeping doing it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Engineering is not the art of constructing. It is rather the art of not constructing: or, it is the art of doing well with one dollar what any bungler can do with two. — Arthur Mellen Wellington

2 2

[asdf-devel] Please test asdf 2.018.20
by Faré 22 Nov '11

22 Nov '11

Thanks a lot to all who have tested 2.018.x and found bugs (Nikodemus Siivola, Desmond O. Chang, Robert Goldman, Douglas Crosher). Here is ASDF 2.018.20, the latest release candidate for 2.019, that I'd like to release this weekend. Changes since previous release candidate 2.018.15: * Bug fix: don't redefine reinitialize-instance in ways that break its contract and its clients (such as asdf-dependency-grovel). Use change-class to reset slots (.16), but not to 'standard-object, which breaks ecl, rather to a proto-system class (.19). * Bug fix: don't drop pathname components without a / at the end when reading a path using GETENV (.18). Fixes debbugs #647544. * Portability: fix type declaration for SCL (.17). * Upgrade: unintern some more functions that have changed signature (.20). And since 2.018: * Portability: debugged CormanLisp support (.1) * Usability: when a system can't be found, there's now a restart to retry finding a system after reinitializing the source-registry (.10). * UI: Create and use a load-systems abstraction, in view of using it in a system-granular parallelizing backend. (.15) * Feature: :around-compile now accepts lambda expressions, and also strings, so you can specify future wrappers that can't even be read yet. (.11, .12). * Filesystem: recursing through logical pathnames in LispWorks (.2, .3), on SBCL as on CMUCL, have asdf:subdirectories follow symlinks (.8., .9) * Internals: strcat (.5), split locate-systems from find-systems (.6) * Configuration: modify user-configuration-directories and system-configuration-directories to return all valid directory names even when they don't exist yet so you may create them (.6), also output name of non-existing configuration file when opening them for writing (.7), * Fixed bugs: buglet in maybe-add-tree (.4) * Upgrade: unintern internals of signature changed in 2.017.12 (.13), have *system-definition-search-functions* not be a defparameter, but a defvar with a fixup (.14), clear *systems-being-defined* when upgrading asdf but re-find them immediately because they may be needed as part of a higher operation (.14). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Feynman problem solving Algorithm 1) Write down the problem 2) Think real hard 3) Write down the answer Murray Gell-mann in the NY Times

2 5

[asdf-devel] Please test asdf 2.018.15
by Faré 21 Nov '11

21 Nov '11

I'd like to release ASDF 2.019 next week. Can you test 2.018.15? Here are the changes since 2.018: * Portability: debugged CormanLisp support (.1) * Usability: when a system can't be found, there's now a restart to retry finding a system after reinitializing the source-registry (.10). * UI: Create and use a load-systems abstraction, in view of using it in a system-granular parallelizing backend. (.15) * Feature: :around-compile now accepts lambda expressions, and also strings, so you can specify future wrappers that can't even be read yet. (.11, .12). * Filesystem: recursing through logical pathnames in LispWorks (.2, .3), on SBCL as on CMUCL, have asdf:subdirectories follow symlinks (.8., .9) * Internals: strcat (.5), split locate-systems from find-systems (.6) * Configuration: modify user-configuration-directories and system-configuration-directories to return all valid directory names even when they don't exist yet so you may create them (.6), also output name of non-existing configuration file when opening them for writing (.7), * Fixed bugs: buglet in maybe-add-tree (.4) * Upgrade: unintern internals of signature changed in 2.017.12 (.13), have *system-definition-search-functions* not be a defparameter, but a defvar with a fixup (.14), clear *systems-being-defined* when upgrading asdf but re-find them immediately because they may be needed as part of a higher operation (.14). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To converse at the distance of the Indes by means of sympathetic contrivances may be as natural to future times as to us is a literary correspondence. — Joseph Glanvill, 1661

2 3

[asdf-devel] Recent pull of ASDF fails tests on ECL
by Robert Goldman 21 Nov '11

21 Nov '11

Running make test-all, I get the following: Using ecl -norc -load sys:cmp Ran 36 tests: 5 passing and 31 failing failing test(s): asdf-pathname-test.script test-around-compile.script test-builtin-source-file-type.script test-compile-file-failure.script test-configuration.script test-force.script test-missing-lisp-file.script test-module-depend.script test-module-excessive-depend.script test-module-pathnames.script test-multiple.script test-nested-components.script test-package.script test-redundant-recompile.script test-retry-loading-component-1.script test-samedir-modules.script test-source-file-type.script test-static-and-serial.script test-sysdef-asdf.script test-system-pathnames.script test-touch-system-1.script test-touch-system-2.script test-try-recompiling-1.script test-version.script test-xach-update-bug.script test1.script test2.script test3.script test4.script test9.script wild-module.script -#--------------------------------------- ECL: > (lisp-implementation-version) "11.1.1" > (software-version) "10.8.0" > (machine-type) "intel-mac" Mac OS X 10.6.8 Could this be an error that comes from getting rid of VERSION somehow in the latest patch? Tried this using run-test on asdf-pathname-test.script and see a lot of lines like the following: sysdef: (ASDF:DEFSYSTEM :SYSTEM1 :PATHNAME #P"ASDFTEST:SYSTEM1;" :COMPONENTS ((:MODULE :MODULE1 :PATHNAME #P"ASDFTEST:SYSTEM2;MODULE4;" :COMPONENTS ((:FILE "file" :PATHNAME #P"ASDFTEST:SYSTEM2;MODULE4;FILE.LISP") (:FILE "module2/file" :PATHNAME #P"ASDFTEST:SYSTEM2;MODULE4;FILE.LISP"))))) error! Not a non-negative fixnum SI:UNBOUND non-negative fixnum just seemed to me that it might be a version number.... I suppose it could be a file-write-date.... Oddly, despite the -d flag on run-test, I didn't get thrown into the debugger. Same test passes on SBCL. Best, r

2 1