[asdf-devel] pathname test

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 a

Re: [asdf-devel] ACL regression on latest ASDF

Yes, asdf-pathname-test is new, it's janderson's pathname test (thanks a lot, janderson). I don't have access to ACL 8 at this point, so I can't help. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Luser, n.: Human-like creature that doesn't dare to use ele

Re: [asdf-devel] Question about use of :unspecific

>> Should we use :unspecific based on a whitelist of known-working >> implementations, or should we just avoid it altogether? > > Either of those seems OK to me.  I think a blacklist is probably wrong, > just because it's too hard to update. > Agreed. > OTOH, I don't really understand the motivati

Re: [asdf-devel] Tests now leave files behind

On 3/15/10 Mar 15 -10:26 PM, Faré wrote: > The simplest way to do it would be something like > > export ASDF_OUTPUT_TRANSLATIONS=/:$PWD/../tmp/fasls/$command > > or maybe you'll prefer that at the end of defun load-asdf: > > (asdf::initialize-output-translations > `(:asdf-output-translations >

[asdf-devel] ACL regression on latest ASDF

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 res

Re: [asdf-devel] Question about use of :unspecific

On 3/15/10 Mar 15 -10:06 PM, Faré wrote: > On 15 March 2010 22:58, Robert Goldman wrote: >> 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-PA

Re: [asdf-devel] Tests now leave files behind

The simplest way to do it would be something like export ASDF_OUTPUT_TRANSLATIONS=/:$PWD/../tmp/fasls/$command or maybe you'll prefer that at the end of defun load-asdf: (asdf::initialize-output-translations `(:asdf-output-translations (:root (,(truename (asdf:merge-pathnames* #p"../tmp/fasl

Re: [asdf-devel] Tests now leave files behind

On 3/15/10 Mar 15 -10:11 PM, Faré wrote: > I think that we should turn relocation on, and make it happen in a > known temporary directory (e.g. tmp/fasls/) that we can remove > afterwards. > > janderson's test also creates files, that should be made to exist > under same tmp/ directory. > > Will

Re: [asdf-devel] Tests now leave files behind

I think that we should turn relocation on, and make it happen in a known temporary directory (e.g. tmp/fasls/) that we can remove afterwards. janderson's test also creates files, that should be made to exist under same tmp/ directory. Will you do that? Otherwise, I'll do it later this or next wee

[asdf-devel] Tests now leave files behind

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 eit

Re: [asdf-devel] Question about use of :unspecific

On 15 March 2010 22:58, Robert Goldman wrote: > 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

[asdf-devel] Question about use of :unspecific

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 unco

Re: [asdf-devel] 1.636 -> 1.639

>> What are pseudo-namestrings? > this is your term from earlier mail: Oh, OK. > in a separate message, you indicated that a complete absolute > pathname namestring should also appear in some test. > Yes, although that would probably only work on Unix, so should be made #+unix or some such. >> Wh

Re: [asdf-devel] 1.636 -> 1.639

On 2010-03-16, at 01:26 , Faré wrote: > On 15 March 2010 19:14, james anderson wrote: >> >> On 2010-03-16, at 00:46 , Faré wrote: >> >>> On 15 March 2010 18:10, james anderson >>> wrote: abcl has a distinct dislike for :unspecific pathname components. >>> I have disabled :unspecific for

Re: [asdf-devel] 1.636 -> 1.639

On 15 March 2010 19:14, james anderson wrote: > > On 2010-03-16, at 00:46 , Faré wrote: > >> On 15 March 2010 18:10, james anderson wrote: >>> abcl has a distinct dislike for :unspecific pathname components. >> I have disabled :unspecific for clisp and abcl. >> >> Can you try again with 1.639? >

Re: [asdf-devel] 1.636 -> 1.639

On 2010-03-16, at 00:46 , Faré wrote: > On 15 March 2010 18:10, james anderson wrote: >> abcl has a distinct dislike for :unspecific pathname components. > I have disabled :unspecific for clisp and abcl. > > Can you try again with 1.639? with pseudo namestrings : http:// ec2-204-236-204-89.com

Re: [asdf-devel] 1.636

On 15 March 2010 18:10, james anderson wrote: > abcl has a distinct dislike for :unspecific pathname components. I have disabled :unspecific for clisp and abcl. Can you try again with 1.639? I also have integrated your test-suite into the normal ASDF test suite, at rpg's suggestion, since it wor

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On Mon, Mar 15, 2010 at 5:19 PM, Robert Goldman wrote: > Isn't this a job for > > (defmethod output-files asdf:around ((op operation) (c component) > ...) > > Wrapping around a method that undoes the change that another around method was doing looks definitely like a bad hack to me. Instead, prov

Re: [asdf-devel] 1.636

most everything now has equivalent results.[1] abcl now loads asdf, but the test fails anomalously. looking... abcl fails in connection with a make-pathname operation of the sort (make-pathname :directory '(:relative) :name "file" :type :unspecific :host nil :device nil) which i suspect is

Re: [asdf-devel] 1.636

most everything now has equivalent results.[1] abcl now loads asdf, but the test fails anomalously. looking... abcl fails in connection with a make-pathname operation of the sort (make-pathname :directory '(:relative) :name "file" :type :unspecific :host nil :device nil) which i suspect i

Re: [asdf-devel] never ending component relative pathnames

Dear James, thanks. I've cloned your git repo and am using the tests there. sbcl and ccl seem to work without error. clisp seems to have trouble with logical pathnames. ecl 10.2.1 seems to hang. :-( Other implementations are not found (on my system at least). In test-init.lisp, I use (defvar *asd

Re: [asdf-devel] 1.636

most everything now has equivalent results.[1] abcl now loads asdf, but the test fails anomalously. looking... --- [1] : http://ec2-204-236-204-89.compute-1.amazonaws.com/test/ 20100315T221624/ On 2010-03-15, at 22:53 , Faré wrote: > I tagged ASDF 1.636. > * Can some ABCL user try it? It doe

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On 3/15/10 Mar 15 -3:48 PM, Faré wrote: > On 15 March 2010 15:37, Robert Goldman wrote: >> On 3/15/10 Mar 15 -3:20 PM, Faré wrote: >>> Meh, right at the moment I was considering getting rid of asdf:around... >> >> Right, but the programmer is likely to want to be able to have his/her >> own

[asdf-devel] 1.636

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 |

Re: [asdf-devel] never ending component relative pathnames

On 2010-03-15, at 21:07 , Faré wrote: On 14 March 2010 21:04, james anderson wrote: On 2010-03-15, at 01:36 , Faré wrote: Dear James, is there a tarball I can download with enough stuff to replace those tests or yours? ? the tests are all in the one asdf-pathname-test.lisp file. The a

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On 15 March 2010 15:37, Robert Goldman wrote: > On 3/15/10 Mar 15 -3:20 PM, Faré wrote: (defmethod output-files :around ((op operation) (c component))  "Translate output files, unless asked not to"   (values    (multiple-value-bind (files fixedp) (call-next-method)      (i

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On 3/15/10 Mar 15 -3:20 PM, Faré wrote: >>> (defmethod output-files :around ((op operation) (c component)) >>> "Translate output files, unless asked not to" >>> (values >>>(multiple-value-bind (files fixedp) (call-next-method) >>> (if fixedp >>> files >>> (mapcar #'app

Re: [asdf-devel] Cache? Translations? How to get rid of them?

>> (defmethod output-files :around ((op operation) (c component)) >>  "Translate output files, unless asked not to" >>   (values >>    (multiple-value-bind (files fixedp) (call-next-method) >>      (if fixedp >>          files >>          (mapcar #'apply-output-translations files))) >>    t)) >> >>

Re: [asdf-devel] never ending component relative pathnames

On 14 March 2010 21:04, james anderson wrote: > > On 2010-03-15, at 01:36 , Faré wrote: > >> Dear James, >> >> is there a tarball I can download with enough stuff to replace those >> tests or yours? > > ? > the tests are all in the one asdf-pathname-test.lisp file. > The amazon host is down. Also,

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On 3/15/10 Mar 15 -11:11 AM, Juan Jose Garcia-Ripoll wrote: > On Mon, Mar 15, 2010 at 4:47 PM, Faré > wrote: > > (defmethod output-files :around ((op operation) (c component)) > "Translate output files, unless asked not to" > (multiple-value-bind (files fixe

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On Mon, Mar 15, 2010 at 4:47 PM, Faré wrote: > (defmethod output-files :around ((op operation) (c component)) > "Translate output files, unless asked not to" > (multiple-value-bind (files fixedp) (call-next-method) >(if fixedp >files >(mapcar #'apply-output-translations file

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On 15 March 2010 10:56, james anderson wrote: > good afternoon; > > this does not sound like a case for specialization. it sounds more > like delegation. > what about hooking an output translator into the components. > if it is there, it is used. if it is not, no translation happens. > (as much as

Re: [asdf-devel] Cache? Translations? How to get rid of them?

good afternoon; this does not sound like a case for specialization. it sounds more like delegation. what about hooking an output translator into the components. if it is there, it is used. if it is not, no translation happens. (as much as i may regret this) the "standard" output translation is

Re: [asdf-devel] Cache? Translations? How to get rid of them?

Dear Juanjo, > Indeed. This or any other way that does not break current ASDF. What I would > like is seamless integration without imposing something that is prone to > break in the future. Another possibility would be for OUTPUT-FILES to return > two values: the list and an optional second value

Re: [asdf-devel] Cache? Translations? How to get rid of them?

On Mon, Mar 15, 2010 at 2:33 AM, Faré wrote: > > directory, the *.ASD file and the binaries, is just fine. > > > > It's your design choice. I believe that distributing together, in the > same > OK. But I don't see what is your problem, then? > > I mean, you can either write a new component type f