asdf-devel February 2013

asdf-devel@common-lisp.net

15 participants
28 discussions

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

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

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

01 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é 31 Jan '13

31 Jan '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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel February 2013