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

[asdf-devel] Branches to merge (I hope)
by Faré 08 Apr '15

08 Apr '15

Dear Robert, please consider merging these two branches before release: * renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018 * build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292 I can do the merging, if you want. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The fundamental class division in any society is not between rich and poor, or between farmers and city dwellers, but between tax payers and tax consumers. — David Boaz, CATO Institute

2 5

[asdf-devel] :depends-on to load-system or require-system?
by John Morrison 08 Apr '15

08 Apr '15

Hi All; tl:dr - AFAICT post-version-2.26-ish versions of ASDF systems listed in :depends-on are unconditionally loaded rather than required - ditto for asdf:load-system. If this is correct (both in intent and my understanding), then how to create a GUI for quicklisp in McCLIM which can quickload any system which :depends-on McCLIM? Apologies in advance in the likely event this is Pilot Error. Am trying to write a gui<https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui>for quicklisp. Testing on various platforms (Raspberry Pi, linux/SBCL, linux/CCL) with various vintages of ASDF produces differing behavior. In particular, quickloading a system which depends upon McCLIM from the McCLIM-based gui screws up (I haven't tracked down the exact problem, but I could understand why unconditionally reloading McCLIM while it's running could get weird). After some digging (and rebuilding various versions of SBCL up to 1.1.9), I got as far as seeing asdf:load-system behavior diverging from 2.26 (SBCL 1.0.9) to both 2.32 (CCL 1.9) and 3.0.2 (both SBCL and CCL). AFAICT 2.26 load-system does not unconditionally load an already-loaded system (behaving like and perhaps redundant to asdf:require-system). 2.32 and 3.0.2 load-system unconditionally load systems, and require-system does not. I think I understand why the newer vintages do this. The issue for me is loading systems that :depend-on McCLIM from inside a McCLIM frame command. In my naivety, I would think that the :depends-on systems should be required rather than loaded (if you've patched them, say, you wouldn't want the patch hammered). For my own stuff, I guess I could require prerequisite systems within the asd file rather than :depending-on them, but this seems wrong (breaks introspection?) - so wrong I feel I may be going about this entirely the wrong way. Would anybody please be so kind as to throw some advice my way? -jm

4 9

[asdf-devel] Please test for ASDF 3.0.2
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, next release of ASDF will be 3.0.2, and be done shortly by Robert Goldman. Please test. Changes since 3.0.1: * Tweaks to RUN-PROGRAM so it works better on ACL, and to RUN-SHELL-COMMAND so it's more backward-compatible. * Tweaks for XCVB: better CFASL support on SBCL and easier default-encoding. * Tweaks of TRAVERSE: have it always return a list of actions, deprecate it. Have OPERATE use MAKE-PLAN instead, that always returns a plan object. * Fixes to debian package. We're into tweaking, which is a good sign: it means the ASDF code base is stable indeed. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An extreme optimist is a man who believes that humanity will probably survive even if it doesn't take his advice. — John McCarthy

3 5

[asdf-devel] The issue at hand
by Robert P. Goldman 08 Apr '15

08 Apr '15

James Anderson has asked for a "concise statement of the issue at hand." Faré has had to change the semantics of the OPERATION class. Previously, the OPERATION class would automatically trigger dependencies downward (notably, if you did an OPERATION on a system, then you had to do that OPERATION as well on that OPERATION's children), "leftward," and onto itself ("selfward"). The implementation of this left holes, and also caused problems for extensions (e.g., for TEST-OP, one typically had to define a default PERFORM that did nothing, since testing a system necessarily tested all of the files). To fix this, Faré had to add new mixin classes, DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, and SELFWARD-OPERATION. In order to preserve the integrity of the code, OPERATION remained as the superclass of all operation objects. But its semantics has changed. This is not a problem for anyone with a "vanilla" ASDF system. The only programmers who are vulnerable to this change are those who have defined their own subclasses of OPERATION (or those who use libraries whose programmers have defined subclasses of OPERATION). For those cases, I have pushed a change that checks to make sure that all operations that are instantiated are subclasses of either DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, SELFWARD-OPERATION, or a new NON-PROPAGATING-OPERATION. If this run-time test fails, an error will be signaled and the programmer will have to fix the offending OPERATION subclass's definition.

8 28

[asdf-devel] force vs force-not
by Faré 08 Apr '15

08 Apr '15

As I am writing a parting article (for ELS 2014? ILC 2014?) on the what and wherefore of ASDF3, I tackled the question of force and force-not, and was reminded about that discussion whether I got it right or backward when I gave force precedence over force-not. https://bugs.launchpad.net/asdf/+bug/1184002 Then I retold how force-not was implemented at the request of Erik Pearson, who wanted to be able to declare some systems as "builtin" and not to be reloaded; their code not expensively scanner for upgrades (or worse, for downgrades). Then it came to me: duh, of course force-not should take precedence over force. The use case is clear and clearly legitimate: extending the "base" system such that you can extend it, but not redefine the locked package; yet being able to force some or all of the rest of the system. I don't see a clear cut case in the the opposite side. Maybe one of you can tell. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The weak terrorist who predictably loses, causing death for those he claims to defend is infinitely more evil than the strong one who wins.

2 2

[asdf-devel] Recompiling SBCL contribs
by Zach Beane 08 Apr '15

08 Apr '15

I've saved an executable SBCL image that includes asdf and calls load-system. If the system it's loading depends-on sbcl contribs, e.g. sb-bsd-sockets, it is recompiling the contrib sources. What causes contribs to get recompiled? Is there an easy way to inhibit it? Thanks, Zach

4 11

[asdf-devel] Alternate default lisp system location
by Robert P. Goldman 08 Apr '15

08 Apr '15

How would you all feel about an alternate default location for lisp systems, in addition to ~/.local/share/common-lisp/source/ I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a. After all, these are systems, not configuration files. What about ~/asdf-systems which doesn't make the poor user play peekaboo? I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care. Cheers, r

14 79

[asdf-devel] :cwd pathname designator for source registry configuration?
by Mirko Vukovic 08 Apr '15

08 Apr '15

This is a follow-up to my previous post regarding asdf searching for a system in the current working directory. I resolved this to my satisfaction with something like this: (let ((asdf:*central-registry* (push directory asdf:*central-registry*))) (apply #'asdf:load-system system keys))) My question here is two-fold: - Am I misusing ASDF if I have asdf files for local projects sprinkled around, in addition to having them under centralized locations specified in the configuration file? - What about adding a :CWD keyword to the configuration file DSL to specify the current working directory? The new keyword seems to require a minor modification to ``resolve-absolute-location''. I don't know if this would conflict with output translations as it uses the same DSL and presumably code. Thanks, Mirko

2 2

[asdf-devel] Patch for UIOP/UTILITY:ENSURE-FUNCTION
by Mark Evenson 08 Apr '15

08 Apr '15

Without the attached patch, I believe the use of a function for output translations is hosed from post asdf-3.0.2 onwards. I think ABCL is the only implementation actively using the ability to specify an output translation as a function, as indeed Faré expressly introduced this for us. ABCL uses a specialized output translation to translate the location of FASLs for ASDF systems stored in jar files (like ABCL’s contribs) which can’t otherwise be expressed in the translation DSL. I have [committed an asdf-3.0.3.0.1 including this patch][r14583] to ABCL trunk, which I will sync in the near future to ASDF master if this is indeed the correct way to patch the problem. [r14583]: http://abcl.org/trac/changeset/14583 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 9

[asdf-devel] Retest
by Robert P. Goldman 08 Apr '15

08 Apr '15

Now all tests pass on Linux for me (but I'm not testing ABCL there). ABCL on the Mac fails test-stamp-propagation: TEST ABORTED: These two expressions fail comparison with EQUAL: (SANITIZE-LOG (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)) 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 Using abcl, test-stamp-propagation.script failed Does this work on Linux? cheers, r

2 3