[asdf-devel] SBCL 1.0.49 / ASDF 2.015.3 doesn't load my asdf systems anymore
Hi, See subject line. Here is a trace from the listener: This is SBCL 1.0.49, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (asdf:load-system :closer-mop) debugger invoked on a ASDF:MISSING-COMPONENT: Component "closer-mop" not found Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((LAMBDA ())) 0] :backtrace 0: ((LAMBDA ())) 1: ((LAMBDA ())) 2: (ASDF::CALL-WITH-SYSTEM-DEFINITIONS #<CLOSURE (LAMBDA #) {1003E98CA9}>) 3: ((SB-PCL::FAST-METHOD ASDF:OPERATE (T T)) #<unused argument> #<unused argument> ASDF:LOAD-OP :CLOSER-MOP) 4: ((SB-PCL::EMF ASDF:OPERATE) #<unused argument> #<unused argument> ASDF:LOAD-OP :CLOSER-MOP) 5: (ASDF:LOAD-SYSTEM :CLOSER-MOP) 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:LOAD-SYSTEM :CLOSER-MOP) #<NULL-LEXENV>) 7: (EVAL (ASDF:LOAD-SYSTEM :CLOSER-MOP)) 8: (INTERACTIVE-EVAL (ASDF:LOAD-SYSTEM :CLOSER-MOP) :EVAL NIL) 9: (SB-IMPL::REPL-FUN NIL) 10: ((LAMBDA ())) 11: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1003E982F9}>) 12: (SB-IMPL::TOPLEVEL-REPL NIL) 13: (SB-IMPL::TOPLEVEL-INIT) 14: ((FLET #:WITHOUT-INTERRUPTS-BODY-[RESTART-LISP]30)) 15: ((LABELS SB-IMPL::RESTART-LISP)) 0] This happens with other systems as well. (I haven't been able to load any system anymore, but I haven't tried all that I have installed.) What information do you need from me to be able to fix this? Best, Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 10 June 2011 23:48, Pascal Costanza <pc@p-cos.net> wrote:
* (asdf:load-system :closer-mop)
debugger invoked on a ASDF:MISSING-COMPONENT: Component "closer-mop" not found
I can't reproduce this, so I'm guessing this has to do with your specific setup. Can you email the relevant bits of your lisp initialization files / ASDF setup? Cheers, -- nikodemus
On 10 Jun 2011, at 23:00, Nikodemus Siivola wrote:
On 10 June 2011 23:48, Pascal Costanza <pc@p-cos.net> wrote:
* (asdf:load-system :closer-mop)
debugger invoked on a ASDF:MISSING-COMPONENT: Component "closer-mop" not found
I can't reproduce this, so I'm guessing this has to do with your specific setup.
Can you email the relevant bits of your lisp initialization files / ASDF setup?
Cheers,
-- nikodemus
Here is my .sbclrc (setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*"))) ;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (when (probe-file quicklisp-init) (load quicklisp-init))) And here is my source-registry.conf (:source-registry (:directory "costanza:lisp;asdf-integration") (:directory "costanza:lisp;develop;cl-scheme") (:directory "costanza:lisp;develop;cl-zeroconf-0-2") (:directory "costanza:lisp;develop;closer;aspectl") (:directory "costanza:lisp;develop;closer;closer-function") (:directory "costanza:lisp;develop;closer;closer-mop") (:directory "costanza:lisp;develop;closer;contextl") (:directory "costanza:lisp;develop;closer;delegation-classes") (:directory "costanza:lisp;develop;closer;filtered-functions") (:directory "costanza:lisp;develop;closer;hash-classes") (:directory "costanza:lisp;develop;closer;mop-features") (:directory "costanza:lisp;develop;core-lisp") (:directory "costanza:lisp;develop;lw-compat") (:directory "costanza:lisp;develop;Pico;CL-Pico") (:directory "costanza:lisp;develop;Pico;Pico-0-1") (:directory "costanza:lisp;develop;PP;Lonestar-1-1;DelaunayRefinement-001;src;lisp") #-mcl :inherit-configuration #+mcl :ignore-inherited-configuration) Thanks for taking care of this. Best, Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Here is my .sbclrc
(setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*")))
;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (when (probe-file quicklisp-init) (load quicklisp-init)))
And here is my source-registry.conf
(:source-registry
(:directory "costanza:lisp;asdf-integration")
(:directory "costanza:lisp;develop;cl-scheme") (:directory "costanza:lisp;develop;cl-zeroconf-0-2") (:directory "costanza:lisp;develop;closer;aspectl") (:directory "costanza:lisp;develop;closer;closer-function") (:directory "costanza:lisp;develop;closer;closer-mop") (:directory "costanza:lisp;develop;closer;contextl") (:directory "costanza:lisp;develop;closer;delegation-classes") (:directory "costanza:lisp;develop;closer;filtered-functions") (:directory "costanza:lisp;develop;closer;hash-classes") (:directory "costanza:lisp;develop;closer;mop-features") (:directory "costanza:lisp;develop;core-lisp") (:directory "costanza:lisp;develop;lw-compat") (:directory "costanza:lisp;develop;Pico;CL-Pico") (:directory "costanza:lisp;develop;Pico;Pico-0-1") (:directory "costanza:lisp;develop;PP;Lonestar-1-1;DelaunayRefinement-001;src;lisp")
Looks like a SBCL bug in how you setup logical pathnames, that SBCL is catching: (in-package :asdf) (setf (logical-pathname-translations "fare") `(("**;*.fasl.*" ,(format nil "/home/fare/.cache/common-lisp/~A/**/*.fasl" (implementation-identifier))) ("**;*.*.*" "/home/fare/**/*.*"))) ;; emulating what directory-asd-files does. (merge-pathnames* *wild-asd* #P"FARE:CL;FARE-UTILS;") ;;=> value: #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST" (directory* #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST") ;;=> error: Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME did not match: NIL "FASL" ;; If you translate the logical pathname, it works: (directory* (translate-logical-pathname #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST")) ;;=> value: (#P"/home/fare/cl/fare-utils/fare-utils.asd") ;; BTW (directory* x) is just (directory x :resolve-symlinks nil) So logical-pathnames do not commute with directory in SBCL. Note that I'll also be surprised if those dual-case pathnames work. "Pico" will be read in uppercase as "PICO" as per the CLHS, and then attempted as "pico" on the filesystem side. Unless of course you add another translation rule for each physical pathname that doesn't fit the logical-pathname portability restrictions. NB: why don't you just use the following? (:source-registry (:tree #-mcl "/Users/costanza/lisp/" #+mcl "Macintosh HD:Users:costanza:lisp:")) Good luck!
Thanks for taking care of this.
Best, Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Would it be the classic "missing a directory separator at the end of the namestring"? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
On 11 Jun 2011, at 00:27, Faré wrote:
Here is my .sbclrc
(setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*")))
;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (when (probe-file quicklisp-init) (load quicklisp-init)))
And here is my source-registry.conf
(:source-registry
(:directory "costanza:lisp;asdf-integration")
(:directory "costanza:lisp;develop;cl-scheme") (:directory "costanza:lisp;develop;cl-zeroconf-0-2") (:directory "costanza:lisp;develop;closer;aspectl") (:directory "costanza:lisp;develop;closer;closer-function") (:directory "costanza:lisp;develop;closer;closer-mop") (:directory "costanza:lisp;develop;closer;contextl") (:directory "costanza:lisp;develop;closer;delegation-classes") (:directory "costanza:lisp;develop;closer;filtered-functions") (:directory "costanza:lisp;develop;closer;hash-classes") (:directory "costanza:lisp;develop;closer;mop-features") (:directory "costanza:lisp;develop;core-lisp") (:directory "costanza:lisp;develop;lw-compat") (:directory "costanza:lisp;develop;Pico;CL-Pico") (:directory "costanza:lisp;develop;Pico;Pico-0-1") (:directory "costanza:lisp;develop;PP;Lonestar-1-1;DelaunayRefinement-001;src;lisp")
Looks like a SBCL bug in how you setup logical pathnames, that SBCL is catching:
Not sure how to parse that sentence. Is this my bug, or an SBCL bug? Anyway, the setup above worked in SBCL 1.0.48, and works in every other Common Lisp implementation that I'm dealing with.
(in-package :asdf) (setf (logical-pathname-translations "fare") `(("**;*.fasl.*" ,(format nil "/home/fare/.cache/common-lisp/~A/**/*.fasl" (implementation-identifier))) ("**;*.*.*" "/home/fare/**/*.*")))
;; emulating what directory-asd-files does. (merge-pathnames* *wild-asd* #P"FARE:CL;FARE-UTILS;") ;;=> value: #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST" (directory* #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST") ;;=> error: Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME did not match: NIL "FASL"
;; If you translate the logical pathname, it works: (directory* (translate-logical-pathname #P"FARE:CL;FARE-UTILS;*.ASD.NEWEST")) ;;=> value: (#P"/home/fare/cl/fare-utils/fare-utils.asd") ;; BTW (directory* x) is just (directory x :resolve-symlinks nil)
So logical-pathnames do not commute with directory in SBCL.
I don't understand what you're talking about. I thought ASDF doesn't do anything with logical pathnames?
Note that I'll also be surprised if those dual-case pathnames work. "Pico" will be read in uppercase as "PICO" as per the CLHS, and then attempted as "pico" on the filesystem side. Unless of course you add another translation rule for each physical pathname that doesn't fit the logical-pathname portability restrictions.
I haven't used those systems in quite a while, so yes, they may or may not work. (I think I did some light testing with those systems, but they are not a priority for me at the moment.)
NB: why don't you just use the following?
(:source-registry (:tree #-mcl "/Users/costanza/lisp/" #+mcl "Macintosh HD:Users:costanza:lisp:"))
Because I have to be able to switch between different versions of the same system, for example: "/Users/costanza/lisp/develop/cl-foo-version-a/cl-foo.asd" vs. "/Users/costanza/lisp/develop/cl-foo-version-b/cl-foo.asd" Feeding the whole tree doesn't do the trick for me. Thanks for the feedback! Pascal
Good luck!
Thanks for taking care of this.
Best, Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Would it be the classic "missing a directory separator at the end of the namestring"?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] ... Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.)
-- Pascal Costanza
Looks like a SBCL bug in how you setup logical pathnames, that SBCL is catching: Not sure how to parse that sentence. Is this my bug, or an SBCL bug? Thought at first your translations were fishy (what with more wildcards on one side than the other), I changed my mind after investigating, failed to rephrase it properly. Oops. Now I believe it's a bug in SBCL, either in TRANSLATE-PATHNAME where the error occurs, or in PATHNAME-INTERSECTIONS where the fishy path is constructed, or maybe in DIRECTORY for not catching errors.
My previous message includes enough of a test case for SBCL implementors to reproduce the error: (setf (logical-pathname-translations "foo") `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl") ("**;*.*.*" "/home/foo/**/*.*"))) (directory #p"foo:cl;*.asd.newest") ;==> Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME did not match: NIL "FASL" ;; reported in TRANSLATE-PATHNAME If we balance the wildcards, we still get an error, though a different one: (setf (logical-pathname-translations "foo") `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl") ("**;*.*.*" "/home/foo/**/*.*"))) (directory #p"foo:cl;*.asd.newest") ;;==> can't substitute this into the middle of a word: :WILD ;; also reported in TRANSLATE-PATHNAME
So logical-pathnames do not commute with directory in SBCL.
I don't understand what you're talking about. I thought ASDF doesn't do anything with logical pathnames?
ASDF doesn't introduce logical pathnames, and when you provide them, it makes sure to pass them through to the implementation. Then SBCL tries to do clever things with DIRECTORY, and fails.
NB: why don't you just use the following?
(:source-registry (:tree #-mcl "/Users/costanza/lisp/" #+mcl "Macintosh HD:Users:costanza:lisp:"))
Because I have to be able to switch between different versions of the same system, for example:
"/Users/costanza/lisp/develop/cl-foo-version-a/cl-foo.asd" vs. "/Users/costanza/lisp/develop/cl-foo-version-b/cl-foo.asd"
Feeding the whole tree doesn't do the trick for me.
You can feed the whole tree, except for the few files that you need: #.(progn #+mcl (defun asdf::probe-posix (posix-namestring) "If a file exists for the posix namestring, return the pathname" #-mcl posix-namestring #+mcl #.(read-from-string " (with-cstrs ((cpath posix-namestring)) (rlet ((is-dir :boolean) (fsref :fsref)) (when (eq #$noerr (#_fspathmakeref cpath fsref is-dir)) (ccl::%path-from-fsref fsref is-dir))))")) `(:source-registry ,(loop for i in '("/Users/costanza/lisp/override-a/" "/Users/costanza/lisp/override-x/" "/Users/costanza/lisp/") collect `(:tree ,(probe-posix i))) :inherit-configuration)) Or you can use a symlink farm (assuming MCL can find the truename of an HFS alias). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I hold that America, Champion of the World is a betrayal of its humble beginnings as One Nation Underdog.
On 11 June 2011 03:50, Faré <fahree@gmail.com> wrote:
ASDF doesn't introduce logical pathnames, and when you provide them, it makes sure to pass them through to the implementation.
Behaviour of logical pathnames with DIRECTORY is somewhat underspecified. Given (setf (logical-pathname-translations "foo") `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl") ("**;*.*.*" "/home/foo/**/*.*"))) and existence both /home/foo/faslcache/bar/quux.fasl /home/foo/bar/quux.fasl should (directory "foo:bar;x.fasl") return both, or just the one in faslcache? SBCL opts for both (modulo the aforementioned bug), other implementations may do things differently. Calling TRANSLATE-LOGICAL-PATHNAME first makes the answer unambiguous -- just the faslcache one, thanks -- which is why I believe ASDF should do that prior to calling DIRECTORY. Cheers, -- nikodemus
ASDF doesn't introduce logical pathnames, and when you provide them, it makes sure to pass them through to the implementation.
Behaviour of logical pathnames with DIRECTORY is somewhat underspecified.
Given
(setf (logical-pathname-translations "foo") `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl") ("**;*.*.*" "/home/foo/**/*.*")))
and existence both
/home/foo/faslcache/bar/quux.fasl /home/foo/bar/quux.fasl
should
(directory "foo:bar;x.fasl")
return both, or just the one in faslcache?
SBCL opts for both (modulo the aforementioned bug), other implementations may do things differently.
I think if it's trying that hard, it should show only the first: only the fasl one is available through the LPN. And then, with :resolve-symlinks nil (or some other implementation-specific hack), it should give the logical pathname of that file instead of its truename. But yes, I realize that the most recent way I cache the results of the search for all .asd files now (per DIRECTORY returning TRUENAMEs in the standard) breaks the previous ASDF promise of not transforming logical-pathname's into physical pathnames. ASDF BUG - or at least degradation in behavior to LPN users.
Calling TRANSLATE-LOGICAL-PATHNAME first makes the answer unambiguous -- just the faslcache one, thanks -- which is why I believe ASDF should do that prior to calling DIRECTORY.
It's also the wrong thing wrt what ASDF would like to do to support logical pathname users in the same way as before. I see an ASDF 2.016.2 patch release coming. PS: I'm impressed with how quick you came with a fix. Thank you! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org For pretty much every writer, the big problem isn't piracy, it's obscurity. — Tim O'Reilly, as cited by Cory Doctorow
On 11 Jun 2011, at 15:56, Nikodemus Siivola wrote:
On 11 June 2011 03:50, Faré <fahree@gmail.com> wrote:
ASDF doesn't introduce logical pathnames, and when you provide them, it makes sure to pass them through to the implementation.
Behaviour of logical pathnames with DIRECTORY is somewhat underspecified.
Given
(setf (logical-pathname-translations "foo") `(("**;*.fasl.*" "/home/foo/faslcache/**/*.fasl") ("**;*.*.*" "/home/foo/**/*.*")))
and existence both
/home/foo/faslcache/bar/quux.fasl /home/foo/bar/quux.fasl
should
(directory "foo:bar;x.fasl")
return both, or just the one in faslcache?
Just the one in faslcache. If I ask for that particular file directly (foo:bar;quux.fasl), it will only find the first one and cannot find the second one, so directory returning the second one is misleading. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 11 June 2011 19:41, Pascal Costanza <pc@p-cos.net> wrote:
Just the one in faslcache. If I ask for that particular file directly (foo:bar;quux.fasl), it will only find the first one and cannot find the second one, so directory returning the second one is misleading.
I have to say that I don't particularly disagree -- but that would be have been a more radical change than just fixing the bug in pathname-intersection: something to think about a bit more first. Cheers, -- Nikodemus
On 11 Jun 2011, at 18:47, Nikodemus Siivola wrote:
On 11 June 2011 19:41, Pascal Costanza <pc@p-cos.net> wrote:
Just the one in faslcache. If I ask for that particular file directly (foo:bar;quux.fasl), it will only find the first one and cannot find the second one, so directory returning the second one is misleading.
I have to say that I don't particularly disagree -- but that would be have been a more radical change than just fixing the bug in pathname-intersection: something to think about a bit more first.
Just to stress this again: I think directory returning the second name is not only misleading, but also incorrect with regard to what the HyperSpec says. The HyperSpec says that directory "[d]etermines which, if any, files that are present in the file system have names matching pathspec". The second file doesn't have a name that matches the given path. Directory should do something that is equivalent to translate-logical-pathname, it seems to me, because that is what determines the semantics of logical pathname translations and makes such pathnames unambiguous. (cf. also the non-commutativity of pathname-match-p) Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 11 June 2011 01:41, Pascal Costanza <pc@p-cos.net> wrote:
Looks like a SBCL bug in how you setup logical pathnames, that SBCL is catching:
Not sure how to parse that sentence. Is this my bug, or an SBCL bug?
Anyway, the setup above worked in SBCL 1.0.48, and works in every other Common Lisp implementation that I'm dealing with.
It's an SBCL bug, triggered by ASDF no longer calling TRANSLATE-LOGICAL-PATHNAME before calling DIRECTORY. SBCL fix coming up. Cheers, -- nikodemus
On 11 June 2011 15:37, Nikodemus Siivola <nikodemus@random-state.net> wrote:
SBCL fix coming up.
Pascal, does this fix things for you? Cheers, -- nikodemus (in-package :sb-impl) (defun pathname-intersections (one two) (aver (logical-pathname-p one)) (aver (logical-pathname-p two)) (labels ((intersect-version (one two) (aver (typep one '(or null (member :newest :wild :unspecific) integer))) (aver (typep two '(or null (member :newest :wild :unspecific) integer))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) ((eql one two) one) (t nil))) (intersect-name/type (one two) (aver (typep one '(or null (member :wild :unspecific) string))) (aver (typep two '(or null (member :wild :unspecific) string))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) ((string= one two) one) (t (return-from pathname-intersections nil)))) (intersect-directory (one two) (aver (typep one '(or null (member :wild :unspecific) list))) (aver (typep two '(or null (member :wild :unspecific) list))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) (t (aver (eq (car one) (car two))) (mapcar (lambda (x) (cons (car one) x)) (intersect-directory-helper (cdr one) (cdr two))))))) (let ((version (intersect-version (pathname-version one) (pathname-version two))) (name (intersect-name/type (pathname-name one) (pathname-name two))) (type (intersect-name/type (pathname-type one) (pathname-type two))) (host (pathname-host one))) (mapcar (lambda (d) (make-pathname :host host :name name :type type :version version :directory d)) (intersect-directory (pathname-directory one) (pathname-directory two))))))
On 11 Jun 2011, at 15:41, Nikodemus Siivola wrote:
On 11 June 2011 15:37, Nikodemus Siivola <nikodemus@random-state.net> wrote:
SBCL fix coming up.
Pascal, does this fix things for you?
Yes, this works! Thanks a lot! Pascal
Cheers,
-- nikodemus
(in-package :sb-impl)
(defun pathname-intersections (one two) (aver (logical-pathname-p one)) (aver (logical-pathname-p two)) (labels ((intersect-version (one two) (aver (typep one '(or null (member :newest :wild :unspecific) integer))) (aver (typep two '(or null (member :newest :wild :unspecific) integer))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) ((eql one two) one) (t nil))) (intersect-name/type (one two) (aver (typep one '(or null (member :wild :unspecific) string))) (aver (typep two '(or null (member :wild :unspecific) string))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) ((string= one two) one) (t (return-from pathname-intersections nil)))) (intersect-directory (one two) (aver (typep one '(or null (member :wild :unspecific) list))) (aver (typep two '(or null (member :wild :unspecific) list))) (cond ((eq one :wild) two) ((eq two :wild) one) ((or (null one) (eq one :unspecific)) two) ((or (null two) (eq two :unspecific)) one) (t (aver (eq (car one) (car two))) (mapcar (lambda (x) (cons (car one) x)) (intersect-directory-helper (cdr one) (cdr two))))))) (let ((version (intersect-version (pathname-version one) (pathname-version two))) (name (intersect-name/type (pathname-name one) (pathname-name two))) (type (intersect-name/type (pathname-type one) (pathname-type two))) (host (pathname-host one))) (mapcar (lambda (d) (make-pathname :host host :name name :type type :version version :directory d)) (intersect-directory (pathname-directory one) (pathname-directory two))))))
-- Pascal Costanza
participants (3)
-
Faré -
Nikodemus Siivola -
Pascal Costanza