asdf-devel

asdf-devel@common-lisp.net

2 participants
1378 discussions

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 13 Feb '13

13 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 07 Feb '13

07 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 06 Feb '13

06 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

[asdf-devel] can't run quicklisp with asdf 2.28 on CCL (upgrage issue?)
by Anton Vodonosov 06 Feb '13

06 Feb '13

I placed new asdf.lisp into quicklisp and changed (defvar *required-asdf-version* "2.28") in quicklisp/setup.lisp to the lates version - 2.28. lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp > Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments ("2012112500" #<SYSTEM "quicklisp">) . > While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to ("2012112500" #<SYSTEM "quicklisp">). > Type :? for other options.

2 9

[asdf-devel] load-op
by Faré 06 Feb '13

06 Feb '13

For those who are interested, lp#515807 contains a discussion about how we'd like to customize LOAD-OP so that on some files it would load the source (but what on ECL and MKCL?), whereas on some systems it would load a bundle, etc. https://bugs.launchpad.net/asdf/+bug/515807 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Living your life is a task so difficult, it has never been attempted before.

1 0

[asdf-devel] clisp 2.49 still fails tests ...
by Robert Goldman 04 Feb '13

04 Feb '13

On Mac OS X I get: BAD: Loading ASDF on clisp produces messages make[1]: *** [test-clean-load] Error 1 make: *** [test-all-noupgrade] Error 1 But I think it passes all the actual tests: -#--------------------------------------- Using clisp Ran 44 tests: 44 passing and 0 failing all tests apparently successful -#--------------------------------------- Maybe makefile testing needs to be modified to ignore these messages for clisp? IIRC you were saying they were not avoidable... best, r

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel