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

[asdf-devel] asdf 2.30.2, (upgrage?) problem on ECL
by Anton Vodonosov 22 Feb '13

22 Feb '13

I decided to continue testing on other lisps. On ECL bytecode compiler there is a problem: /home/testgrid/lisps/ecl-bin-12.12.1/bin/ecl -norc -eval '(ext::install-bytecodes-compiler)' -eval '(LOAD #P"/home/testgrid/quicklisp-patched2/setup.lisp")' (ql:quickload :alexandria) Condition of type: UNDEFINED-FUNCTION The function ASDF/SYSTEM:FIND-SYSTEM is undefined. Available restarts: 1. (ABORT) Give up on "alexandria" 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at QUICKLISP-CLIENT::RECURSE. In: #<process TOP-LEVEL>. File: (1 . #P"/home/testgrid/quicklisp-patched2/quicklisp/setup.lisp") (Position #2087)

2 4

[asdf-devel] help needed with asdf internals knowledge
by Attila Lendvai 21 Feb '13

21 Feb '13

dear asdf devels, i want to conditionally compile and load some lisp files on-demand at runtime, and i would like to use the asdf machinery for that. the set of files are not known at development time. the code in question is load-resource-file here: http://common-lisp.net/cgi-bin/darcsweb.cgi?r=cl-l10n-cl-l10n;a=headblob;f=… the current implementation is broken on asdf3 due to the assert (and a kludge in general): (defun load-resource-file (resource-file) (bind ((output-files (asdf:output-files (make-instance 'asdf::compile-op) (make-instance 'asdf:cl-source-file :pathname resource-file :parent (asdf:find-system :cl-l10n))))) (assert (length= 1 output-files)) (bind ((output-file (first output-files))) (ensure-directories-exist output-file) (when (or (not (cl-fad:file-exists-p output-file)) (> (file-write-date resource-file) (file-write-date output-file))) (compile-file resource-file :output-file output-file)) (load output-file)))) any help, pointers, thoughts are welcome! -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39

2 2

[asdf-devel] Fwd: possible to include a few "model" systems?
by Dan Lentz 21 Feb '13

21 Feb '13

Apologies I mistakenly sent this to sbcl-Devel rather than asdf-Devel list thanks to my pudgy fingers and iPhone... The changes to upcoming asdf sound amazing. I know there has been a huge investment in Devel/debugging etc, and full documentation is not a reasonable expectation at this point, but I wonder if it might be possible to include a few model systems which demonstrate what will be considered basic best practice with the new ASDF and exemplifying recommended usage of some of these new and replacement features/practices. Basically I'm just hoping to avoid any future situation where I build systems and layered functionality in a manner which seems reasonable but may contradict the popular opinion of what constitutes good system design. For example, in the past I used asdf component properties quite a bit as my local transient annotation slot for working on systems dynamically at runtime. If there are a few examples demonstrating proper use of the new functionalities (perhaps referencing the prior usage it supersedes when appropriate) It would probably be even more helpful to facilitate migration to exploit the new ASDF capabilities than formal reference style documentation... From such examples it will then be a simple matter to focus in for study of the relevant portions of the new asdf source code. Thanks to all the asdf volunteers for all of the work done to improve this important facility which in turn seems likely to substantially improve the whole common-lisp ecosystem as a viable, modern choice for development platform.

1 0

Re: [asdf-devel] [armedbear-devel] ASDF 2.29 released
by Mark Evenson 16 Feb '13

16 Feb '13

On 2/16/13 4:08 PM, Faré wrote: > Dear ABCL developers, > > ASDF 2.27 was a major rewrite of ASDF, and everything since then > should be considered as candidate releases for ASDF 3: > http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… > > ASDF 2.28 was released shortly after 2.27, without an announcement, > to fix an issue found by Stelian Ionescu using TEST-OP on some systems. > > ASDF 2.29 is a stability release, with which I'm once again > inviting implementers to update the ASDF they distribute. > > Please update ABCL to use ASDF 2.29. […] ABCL trunk has now been updated to [asdf-2.29][r14395] N.b.: I had to remove/recompile my SLIME fasls to get ASDF-2.29 to load. [r14395]: http://trac.common-lisp.net/armedbear/changeset/14395 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[asdf-devel] ASDF 2.29 released
by Faré 16 Feb '13

16 Feb '13

Dear Lisp hackers, ASDF 2.27 was a major rewrite of ASDF, and everything since then should be considered as candidate releases for ASDF 3: http://lists.common-lisp.net/pipermail/asdf-announce/2013-February/000014.h… ASDF 2.28 was released shortly after 2.27, without an announcement, to fix an issue found by Stelian Ionescu using TEST-OP on some systems. ASDF 2.29 is a stability release, with which I'm once again inviting implementers to update the ASDF they distribute. Since ASDF 2.27, ASDF 2.29 further brings: * deferred-warnings support for Allegro, CMUCL, SCL; fixes to the CCL support. * Upgrade fixes regarding fallback system versions; making it possible (via massive use of eval-when) to compile ASDF without loading it first. * Compatibility with private use of :D package nickname by not claiming it for package ASDF/DRIVER anymore. Also explicitly handle NIL in safe-file-write-date, in case the implementation doesn't issue a file-error in that case; make UTF-8 the default encoding for with-input-file. Be portable to #+(and sbcl (not sb-eval)). * Bugfixes to old bugs: inline-methods can now be unqualified (lp#485393), defsystem-depends-on accepts arbitrary specs, not just names (lp#1027521). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it.

1 0

[asdf-devel] Example of deferred warnings?
by Raymond Toy 14 Feb '13

14 Feb '13

Is there an example of deferred warnings support? I have a possible implementation for cmucl, but I'd like to test it somehow before I propose a patch. Ray

2 3

[asdf-devel] maybe hot-upgrade of ASDF is not needed anymore
by Anton Vodonosov 14 Feb '13

14 Feb '13

07.02.2013, 07:02, "Faré" <fahree(a)gmail.com>: >> On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >> I have impression that the code upgrade support is one of the most expensive features in ASDF. > > It is, and by far. > > Maybe I should have stuck with deleting the package ASDF and all > packages that depend on it. If the hot upgrade is difficult to support due to CL limitations, maybe we should not fight the language and just do not support hot upgrade? Even if it's possible to overcome the language limitations (even in C it is possible to switch implementation at run-time, if you use some indirection, like Bridge Pattern; in CL maybe other possibilities exit, like Pascal proposes to use only generic functions). But anyway, maintaining the hot upgrade requires efforts, I do not understand what is the justification. I have read in the ASDF texts [1] that hot-upgrade of ASDF was necessary to overcome a social problem of distributing of new ASDF version with all the CL implementation. Today it seems that collaboration is established between ASDF and CL implementation developers and CL implementations update ASDF often. Also, if user wants to use newer version of ASDF than is provided with hist CL implementations, he just loads the newer ASDF. After this, even if he does (require :asdf) the ASDF version provided by the CL implementation is not loaded, because ASDF registers itself in cl:*modules*. And Quicklisp could avoid (require :asdf). Instead it could just check if ASDF is already loaded. If it is, then use the version is loaded. If it isn't then immediately load the ASDF version shipped with Quicklisp. I am testing now CCL and SBCL with Quicklisp patched in this manner and ASDF 2.28.6. I may be missing something about the hot-upgrade. If it is the case, I would appreciate an explanation. 1 - http://common-lisp.net/project/asdf/ilc2010draft.pdf

3 9

[asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?
by Robert Goldman 11 Feb '13

11 Feb '13

I was having a case where some package wrangling in one of our systems behaved differently with new ASDF than with the ASDF 2 that ships with ACL. It seemed like there was an :AFTER method on one of my modules that simply wasn't being called. I took my usual resort and did (TRACE ASDF:PERFORM). I was very surprised to see that my (asdf:load-system "circa-csm" :force t) resulted in only four calls to perform, and all of them had to do with ASDF: CL-USER> (asdf:load-system "circa-csm" :force t) ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Loading /Users/rpg/lisp/asdf/asdf-driver.asd 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP > #<ASDF/SYSTEM:SYSTEM "asdf">) 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)> #<STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)>) #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP > #<ASDF/COMPONENT:MODULE "asdf" "build">) 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)> #<STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)>) #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "asdf" "build" "asdf">) 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)> #<STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:PREPARE-OP ASDF/COMPONENT:COMPONENT)>) #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>) 0[7]: returned NIL 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:LOAD-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "asdf" "build" "asdf">) 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD ASDF/ACTION:PERFORM :BEFORE (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)> #<STANDARD-METHOD ASDF/ACTION:PERFORM (ASDF/LISP-ACTION:LOAD-OP ASDF/LISP-ACTION:CL-SOURCE-FILE)>) #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>) ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl 0[7]: returned T ;;; from here on down there's lots of loading, but no recompilation (as I ;;; expected from :force t) and no calls to PERFORM. ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/circa/code/csm/musliner-tools.fasl ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/circa/code/csm/stochastic.fasl Or -- oh, wait! Did the recompilation of ASDF killed the tracing? If so, I don't think that :force t should be causing ASDF itself to rebuild. I understand why it's a dependency, but this shows why it's inappropriate: rebuilding asdf destroys our ability to inspect its behavior. Oh, and maybe it's also killing the PERFORM :after method in my system definition? I'd suggest :force t should stop before it gets to ASDF itself. Maybe we need to add :force :omg to do that! ;-) Cheers, r

3 7

[asdf-devel] testing asdf 2.28 [was: can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)] [was: sbcl results for quicklisp + asdf 2.28]
by Anton Vodonosov 08 Feb '13

08 Feb '13

Diff between unpatched quicklisp 2013-01-28 and quicklisp 2013-01-28 + asdf 2.28.6 for SBCL and CCL: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-9.html 07.02.2013, 07:16, "Faré" <fahree(a)gmail.com>: > On Thu, Feb 7, 2013 at 3:36 AM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > >> Meantime the SBCL results for ASDF 2.28.4 >> >> Diff comparing to 2.28: >> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-7.html >> (don't pay attention to weblocks-test, it crushes sometimes when SBCL runs out of heap) > > OK, so that's (small) progress. Note that unicly system started to fail.

2 1

[asdf-devel] sbcl results for quicklisp + asdf 2.28
by Anton Vodonosov 07 Feb '13

07 Feb '13

Fare, here are the results for quicklisp 2013-01-28 patched with asdf 2.28 and new version of asdf-system-connections: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-6.html As you see there are failures. One of the most often errors is "Unhandled SERIOUS-CONDITION of type COMPILE-FAILED-ERROR is signaled: Lisp compilation failed", but there are some other errors. Best regards, - Anton

3 4