asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] system reloading behavior
by Yuan Luo 10 Jan '12

10 Jan '12

Hi, I am new to asdf so this might be trivial. When I change a source file and reload the system using (asdf:load-system ...), the compiler re-compiles and re-loads all others source files in that system from scratch, rather than incrementally. Is there some switch to toggle this behavior? Thanks, Yuan

2 1

[asdf-devel] location-function-p.patch
by Сергей Катревич 19 Dec '11

19 Dec '11

Hello! Please review my patch. (and ... (length=n-p x 2) (or ... (and (equal (first x) 'lambda) (cddr x) ;;bug - if (length=n-p x 2) = t, then (cddr x) always = nil (length=n-p (second x) 2))))

2 1

[asdf-devel] Bugfix in split-absolute-pathnames - bad using split-string.
by Сергей Катревич 15 Dec '11

15 Dec '11

Hello! Please apply patch. P.S. This can cause the bug, which is mentioned in "Re: [asdf-devel] XDG_DATA_DIRS and colon separated things"?

2 1

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel