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

[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

[asdf-devel] Test error with latest asdf
by Raymond Toy 02 Feb '13

02 Feb '13

I grabbed the latest sources and ran make test with current cmucl. The basic tests pass but I get this: -#--------------------------------------- Using cmulisp Ran 44 tests: 44 passing and 0 failing all tests apparently successful -#--------------------------------------- ./test/run-tests.sh -c cmucl ./test/run-tests.sh -l cmucl fare-all Loading all these systems: fare-all [snip] Trying to load FARE-ALL TEST ABORTED: Component FARE-ALL not found Can I just ignore this? Ray

1 0

[asdf-devel] More backward compatibility needed
by Faré 01 Feb '13

01 Feb '13

Dear Bill, cl-glfw-opengl fails to build with the current ASDF 3 release candidates on CCL and SBCL, because of the following forward reference warnings: ; Undefined functions: ; CL-GLFW-OPENGL:ATTACH-OBJECT-ARB CL-GLFW-OPENGL:ATTACH-SHADER CL-GLFW-OPENGL:COMPILE-SHADER CL-GL FW-OPENGL:COMPILE-SHADER-ARB CL-GLFW-OPENGL:CREATE-PROGRAM CL-GLFW-OPENGL:CREATE-PROGRAM-OBJECT-ARB CL- GLFW-OPENGL:CREATE-SHADER CL-GLFW-OPENGL:CREATE-SHADER-OBJECT-ARB CL-GLFW-OPENGL:GET-INFO-LOG-ARB CL-GL FW-OPENGL:GET-OBJECT-PARAMETER-IV-ARB CL-GLFW-OPENGL:GET-PROGRAM-INFO-LOG CL-GLFW-OPENGL:GET-PROGRAM-IV CL-GLFW-OPENGL:GET-SHADER-INFO-LOG CL-GLFW-OPENGL:GET-SHADER-IV CL-GLFW-OPENGL:GET-STRING CL-GLFW-OPEN GL:LINK-PROGRAM CL-GLFW-OPENGL:LINK-PROGRAM-ARB CL-GLFW-OPENGL:SHADER-SOURCE CL-GLFW-OPENGL:SHADER-SOUR CE-ARB ; Undefined variables: ; CL-GLFW-OPENGL::*SYNCHRONIZING-SHADER-PROGRAMS* CL-GLFW-OPENGL:+COMPILE-STATUS+ CL-GLFW-OPENGL:+F RAGMENT-SHADER+ CL-GLFW-OPENGL:+FRAGMENT-SHADER-ARB+ CL-GLFW-OPENGL:+INFO-LOG-LENGTH+ CL-GLFW-OPENGL:+L INK-STATUS+ CL-GLFW-OPENGL:+OBJECT-COMPILE-STATUS-ARB+ CL-GLFW-OPENGL:+OBJECT-INFO-LOG-LENGTH-ARB+ CL-G LFW-OPENGL:+OBJECT-LINK-STATUS-ARB+ CL-GLFW-OPENGL:+VERTEX-SHADER+ CL-GLFW-OPENGL:+VERTEX-SHADER-ARB+ ; caught 15 WARNING conditions ; caught 24 STYLE-WARNING conditions It looks like there are a lot of undeclared dependencies in your systems. Are you still maintaining those libraries? Can you fix them? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org With freedom, no more One True Scale to rank people. Everyone pick his own. Why vie for a society of equals, when everyone can be superior?

2 2

Re: [asdf-devel] component-property
by Faré 01 Feb '13

01 Feb '13

(Replying in public to this private email; I hope this is not a faux-pas.) On Thu, Jan 31, 2013 at 11:23 PM, Daniel Herring <dherring(a)tentpost.com> wrote: >> :long-name "Another System Definition Facility" >> :website-url "http://common-lisp.net/projects/asdf/" >> :bug-tracker-url "https://launchpad.net/asdf/" >> :developers-email "asdf-devel(a)common-lisp.net" >> :source-control (:git "git://common-lisp.net/projects/asdf/asdf.git") > > Slight ribbing: (:git ...) has the same problem as the original properties > mechanism; it won't catch errors such as (:get ...) > Indeed. An external tool with a documented specification is required here. But at least there's a clear intent and the beginning of an actual convention, and it all makes sense. > You might have left the properties as-is and just added warnings when an > unknown property name was used. > Possibly. It's still time to have parse-component-form call a better validation function that does such checks, and otherwise have some &allow-other-keys mechanism. See also https://bugs.launchpad.net/asdf/+bug/1007335 Meh. A good project for ASDF4, if anyone is foolish enough to undertake it. Actually bug https://bugs.launchpad.net/asdf/+bug/953489 reminds me that one could use #-asdf3 :allow-other-keys #-asdf3 t to say "yeah, there are optional slots here that aren't defined before asdf3". —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No one has the right to a position; everyone has the right to positions being well filled. — Ernest Renan

1 0

[asdf-devel] API changes into ASDF 3
by Faré 31 Jan '13

31 Jan '13

Dear all, is anyone of you using any of these functions from ASDF, ASDF-UTILS or XCVB-DRIVER ? I've removed them and here are the alternatives I am using. Since previous code didn't have any numbered release API, I will only provide compatibility trampolines if there is a declared user base. These symbols are gone since ASDF 2.26 and corresponding ASDF-UTILS, and here are the alternatives: orf => latest-stamp-f (compares timestamp, not just booleans) aif, it => if-let (compatible with alexandria) remove-keys => remove-plist-keys (compare with EQL, not STRING=) remove-keyword => remove-plist-key (more consistent and descriptive name) split-pathnames* => split-native-pathnames-string (naming makes clear it's native-namestrings, not namestrings) ensure-pathname-absolute => ensure-absolute-pathname (API much enhanced with different error behavior) resolve-relative-location-component => resolve-relative-location resolve-absolute-location-component => resolve-absolute-location Backward-compatible wrappers are already provided for the below deprecated functions with known users: coerce-pathname => parse-unix-namestring component-name-to-pathname-components => split-unix-namestring-directory-components compile-file-keeping-object => compile-file* >From XCVB-DRIVER and ASDF-CONDITION-CONTROL, these have been renamed as they moved to ASDF/DRIVER: run-program/ => run-program with-controlled-compiler-conditions => with-muffled-compiler-conditions with-controlled-loader-conditions => with-muffled-loader-conditions with-xcvb-compilation-unit => with-saved-deferred-warnings eval-string => eval-input bork => handle-fatal-condition *debugging* => *lisp-interaction* For ASDF itself, these interfaces have been removed, and here are their replacements. :if-component-dep-fails => :if-feature :do-first => :in-order-to (:do-first wouldn't actually work in ASDF 1; :in-order-to does the right thing in ASDF 3 for both previous :in-order-to and previous :do-first). make-sub-operation => find-operation asdf-binary-locations configuration => enable-asdf-binary-locations-compatibility (ABL worked with ASDF 1; this compatibility layer exists since ASDF 2 and still supported, actually enhanced, with ASDF 3) These ASDF internals have compatibility wrappers, but are deprecated: run-shell-command => asdf/driver:run-program (used by many clients) load-sysdef => load-asd (used by slime) make-temporary-package => (find-package :asdf-user) (used by slime) operation-error => define your own error class compile-error => compile-file-error compile-failed => compile-failed-error, compile-failed-warning compile-warned => compile-warned-error, compile-warned-warning operation-on-warnings => *compile-file-warnings-behaviour* operation-on-failure => *compile-file-failure-behaviour* system-definition-pathname => system-source-directory, system-relative-pathname (since ASDF 2) component-property => no replacement yet, working on it. make-instance 'some-op => either just 'some-op or (make-operation 'some-op) (make-instance operation still works for now but is deprecated) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Skill without imagination is craftsmanship. Imagination without skill is contemporary art. — Tom Stoppard

1 0