Re: [Sbcl-devel] [asdf-devel] SBCL 1.0.49 / ASDF 2.015.3 doesn't load my asdf systems anymore
Nikodemus Siivola
> * (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
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Pascal Costanza
On 10 Jun 2011, at 23:00, Nikodemus Siivola wrote:
> On 10 June 2011 23:48, Pascal Costanza <p...@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.
Pascal Costanza
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?
Faré
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.)
Pascal Costanza
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
Faré
>> that SBCL is catching:
> Not sure how to parse that sentence. Is this my bug, or an SBCL bug?
(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.
Nikodemus Siivola
>> 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
Nikodemus Siivola
> 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))))))
Nikodemus Siivola
> 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
Nikodemus Siivola
> SBCL opts for both (modulo the aforementioned bug), other
Fixed in Git,
Faré
>> 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.
>
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
Pascal Costanza
On 11 Jun 2011, at 15:41, Nikodemus Siivola wrote:
> On 11 June 2011 15:37, Nikodemus Siivola <niko...@random-state.net> wrote:
>
>> SBCL fix coming up.
>
> Pascal, does this fix things for you?
Yes, this works!
Thanks a lot!
Pascal
--
Pascal Costanza
Pascal Costanza
On 11 Jun 2011, at 15:56, Nikodemus Siivola wrote:
> On 11 June 2011 03:50, Faré <fah...@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.
Nikodemus Siivola
> 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
Pascal Costanza
On 11 Jun 2011, at 18:47, Nikodemus Siivola wrote:
> On 11 June 2011 19:41, Pascal Costanza <p...@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.