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

Re: [asdf-devel] Question about use of :unspecific
by Faré 17 Mar '10

17 Mar '10

On 17 March 2010 05:20, james anderson <james.anderson(a)setf.de> wrote: > > On 2010-03-17, at 02:50 , Faré wrote: > >> ECL & LispWorks work for me, > > that's nice. ecl has some sort of problem with the test mechanism[0], which > it does not have when i run the pathname tests as originally structured. > > in order to run lispworks in batch mode i must trash the x library and feed > the tests through stdin. that's a problem with their free version. > You should ask for a test license from LispWorks, then you can obtain the "lispworks" binary suitable for testing with, e.g. # echo '(hcl:save-image "lispworks" :environment nil)' > /tmp/build.lisp ; # ./lispworks-6-0-0-x86-linux -siteinit - -init - -build /tmp/build.lisp > i was hoping they would release something prebuilt in order that i can avoid > having to install the entire java dev world just in order to build abcl. > > their report must be missing some details: the leave-lisp operator is > missing a clause for abcl, which prevents the tests from running. it needs > something like > > #+abcl > (extensions:quit :status return) > > before they get off the ground. in any case, the transcript[1] reads as if > there is some problem with the test mechanics not with the test content. if > you have any insight into that aspect of the problem, that would help. > >> You can either export ASDF_OUTPUT_TRANSLATIONS= something >> or after loading asdf you can asdf:initialize-output-translations with >> a proper SEXP. > > what would a proper value be? one which still can claim to test asdf's > "normal" configuration? > In run-tests.sh I currently use export ASDF_OUTPUT_TRANSLATIONS="${asdfdir}:${asdfdir}/tmp/fasls/$(basename $command):" The whole point of that value is to short-circuit the "normal" configuration. But the last ":" in said variable is so you can still see said normal configuration when you print (asdf::output-translations). >> I'd be most happy if it [ASDF tests] converted to using Stefil or 5AM >> or some such thing, >> with proper asdf::*variable* rebinding and package deletion. >> But I'm probably not going to do it myself. > [0] : > http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/20100316T233422/e… > [1] : > http://ec2-174-129-63-37.compute-1.amazonaws.com/test/log/20100316T233422/a… [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Mathematicians are like lovers. Grant a mathematician the least principle, and he will draw from it a consequence which you must also grant him, and from this consequence another. — Bernard Le Bouyer de Fontenelle

2 1

[asdf-devel] Windows pathnames on ACL
by Robert Goldman 16 Mar '10

16 Mar '10

I don't see much that's helpful in the ACL manual http://preview.tinyurl.com/y8nfazw --- how user-homedir-pathname behaves on windows Beyond that, I'd suggest sending email to bugs(a)franz.com to ask for advice. For that matter, Gary King was kinda deputized to speak for Allegro in this forum. Gary, are you there? Could you help Faré dig up information about where to dump special files in Windows with ACL?

3 2

[asdf-devel] Question about use of :unspecific
by Robert Goldman 16 Mar '10

16 Mar '10

Isn't supplying :unspecific as the value of :type always to be avoided? The CLHS says: "Portable programs should not supply :unspecific for any component." [documentation for function MAKE-PATHNAME] and in section 19.2.2.2.3 :UNSPECIFIC as a component value "A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations." So instead of supplying this for a couple of cases and then trying to avoid it for others, shouldn't we be avoiding it altogether? I confess that I don't fully understand this issue, since it seems like the CLHS makes it clear that NIL is /not/ fully equivalent to :unspecific (since the latter is not "overwritten" in a merge), and yet tells us not to use the latter.... If anyone can clarify this, it would be great.... Best, r

3 5

[asdf-devel] Windows support?
by Faré 16 Mar '10

16 Mar '10

Does anyone here use ASDF on a Windows-native (as opposed to cygwin) platform? Can you help me configure the default path for user and system directories under Windows? for LispWorks, it would use (sys:get-folder-path :common-appdata) and (sys:get-folder-path :local-appdata) -- is there the equivalent in other implementations? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Death is only a milestone - albeit one that is dropped on you from a very great height — Terry Pratchett.

2 1

[asdf-devel] 1.636
by Faré 16 Mar '10

16 Mar '10

I tagged ASDF 1.636. * Can some ABCL user try it? It doesn't have asdf-method-combination and magic asdf:around anymore. * James Anderson, can you re-test it, particularly with allegro? * Juanjo, does it satisfy you wrt output-files protocol? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The only way to have a friend is to be one. — Ralph Waldo Emerson

3 10

[asdf-devel] pathname test
by Faré 16 Mar '10

16 Mar '10

This is invalid as a pathname to an actual file, only valid as something that you can merge with a pathname that has a type: (make-pathname :directory directory :name "typed-file.type" :type nil) Conversely, this is probably not a good idea for naming a file to load, as many implementations will add a type of .lisp or .lsp (or .fas) before trying to load such a file: (make-pathname :directory directory :name "untyped-file" :type nil) Or maybe they shouldn't? Not clear from the spec, but common practice is there. In other words, you need a different set of valid values for static-file and file components (though there might be a common subset). Can you work on the test as now part of the official testsuite? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] When everything seems to be going against you, remember that the airplane takes off against the wind, not with it. — Henry Ford

3 3

[asdf-devel] It's been fun, but my plate is full
by Nikodemus Siivola 16 Mar '10

16 Mar '10

On reflection I've decided to resign my ASDF commit bit. It's not like I've been doing much anything for ASDF lately, and I'm not even remotely on the ball when it comes to ASDF2. I'll probably lurk around on the mailing list still, though. Cheers, -- Nikodemus

1 0

[asdf-devel] ACL regression on latest ASDF
by Robert Goldman 16 Mar '10

16 Mar '10

ACL 8.1 and 8.2 now fail three tests, in both modern and ANSI modes: asdf-pathname-test.script test-module-pathnames.script test-utilities.script It /always/ failed test-utilities (there's a launchpad bug about this --- it's not clear to me that the test is right), but it used to pass all the rest. I think asdf-pathname-test is new, right? So maybe there's only the one regression. More as I get a chance to look into this. cheers, r

2 1

[asdf-devel] Tests now leave files behind
by Robert Goldman 16 Mar '10

16 Mar '10

I find that the tests don't clean up after themselves. The tests now leave behind .fasl files in ~/.cache/common-lisp/**/... This is not a directory structure I ever used before, nor is it one I ever intended to use. I /believe/ that the tests used to tidy up the fasls they created. I think either the ASDF fasl relocation facility should be turned off, or we need to provide a new clean up facility. I would prefer the former (except for tests that explicitly test the facility, preferably into /tmp rather than into the user's homedir). Best, r

2 4

[asdf-devel] Cache? Translations? How to get rid of them?
by Juan Jose Garcia-Ripoll 15 Mar '10

15 Mar '10

I must admit that after four hours fighting with this I am right now a bit pissed off, so please forgive the tone of the message. ASDF has introduced a new caching system which alters the names of all output files. This is making me mad because I am trying to implement pre-built ASDF components for ECL and ASDF insists on changing the value of output-files and input-files, looking for those prebuilt files at the location of the cache. What I have added so far is an extension to the system class, with hardcoded locations for prebuilt files (see below), so that I can store a single file $ cat ~/lib/ecl-10.3.1/serve-event.asd (DEFSYSTEM "serve-event" :CLASS ASDF::PREBUILT-SYSTEM :LIB "SYS:serve-event" :COMPONENTS ((:COMPILED-FILE "serve-event"))) Now the problem is that when I try to use these systems ASDF insists on translating the library file pathname "SYS:serve-event" to a cached name which does not exist. I have tried adding a TRUENAME around the output of OUTPUT-FILES, so that the return value reflects the full path, but ASDF insists in changing the name. I have tried hardcoding a system location, like SBCL does, but ASDF insists on appending its own translation > (asdf::output-translations) ((#P"/Users/jjgarcia/lib/ecl-10.3.1/" #P"/Users/jjgarcia/lib/ecl-10.3.1/") (#P"/**/*.*" #P"/Users/jjgarcia/.cache/common-lisp/ecl-10.3.1-darwin-x86/**/*.*")) Is there no rational way to prevent the translation of system directories without breaking the cache system? (defclass prebuilt-system (system) ((static-library :accessor prebuilt-system-static-library :initarg :lib))) (defmethod output-files ((o lib-op) (c prebuilt-system)) (list (compile-file-pathname (prebuilt-system-static-library c) :type :lib))) (defmethod perform ((o lib-op) (c prebuilt-system)) (car (output-files o c))) (defmethod component-depends-on ((o lib-op) (c prebuilt-system)) nil) (defmethod bundle-sub-operations ((o lib-op) (c prebuilt-system)) nil) (defmethod bundle-sub-operations ((o monolithic-lib-op) (c prebuilt-system)) (error "Prebuilt system ~S shipped with ECL can not be used in a monolithic library operation." c)) (defmethod bundle-sub-operations ((o monolithic-bundle-op) (c prebuilt-system)) nil) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 21