asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[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

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

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

05 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

[asdf-devel] More test failures on Mac OSX
by Robert Goldman 04 Feb '13

04 Feb '13

1. ecl ECL (Embeddable Common-Lisp) 12.12.1 -#--------------------------------------- Using ecl Ran 44 tests: 42 passing and 2 failing failing test(s): test-multiple.script test-run-program.script -#--------------------------------------- 2. abcl Armed Bear Common Lisp 1.1.0.2 -#--------------------------------------- Using abcl Ran 44 tests: 42 passing and 2 failing failing test(s): test-encodings.script test-logical-pathname.script -#--------------------------------------- I ran ccl clisp sbcl ecl abcl allegro allegromodern For allegro, I tested both 8.2 and 9.0. So this is pretty darn good! Best, Robert

1 0

[asdf-devel] Alternate take on the intended use of component-property
by Dan Lentz 04 Feb '13

04 Feb '13

I was always under the impression that the intent of C-P was to provide a means of annotation primarily to be used at runtime by the ”end-user". For example, say if one were interested in some type of statistic, say SLOC, for comparison and analysis of a (possibly large) number of systems, One might conveniently calculate and store that value as the :SLOC property within each component while being visited, and then aggregate the result at some later time. Deprecating the expectation of standardized property access for use by the actual day-to-day developer working with asdf systems would seem to lead to a profusion of half-baked off the cuff "solutions" reimplemented each time such a need presents itself. Also, the property slot is a direct slot of component, very early in the hierarchy, and so is transparently inherited by each increasingly complex subclass of component on upwards through the class hierarchy. Are you saying that if one needs it then one should subclass component to include some property slot, and also then subclass module likewise, and then system also, etc? So to get this scratchpad working space means essentially one needs to reimplement the whole asdf class hierarchy? FWIW, I think there are many situations in which the component-property provides a more sensible facility than would ad-hoc archetypal extension of ASDF's fundamental object model. Am I misunderstanding the proposed changes? Regards, Dan.

3 2

[asdf-devel] component-property
by Faré 02 Feb '13

02 Feb '13

Dear Red, I see that you're using component-property to add a website property to your .asd files. On the one hand, I am deprecating component-property in ASDF3, so you should stop using that. For the sake of backward-compatibility, I'll add dummy methods so your existing code keeps compiling, but they won't do anything if I can get away with it. On the other hand, now is a good time for me to add new slots to system objects. I will add a website slot in 2.26.171, though you'll have to #+asdf3 :website #+asdf3 "http://xxx" for now. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Keyboard is mightier than the Death Ray...

7 29

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel