CCL 1.8 on Mac OS X fails to compile asdf as pulled just now.
Not-very-helpful transcript snippet:
COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] Toplevel Forms... Toplevel Forms... Toplevel Forms... Toplevel Forms... ions of (:METHOD PERFORM (LOAD-OP CL-SOURCE-FILE)), in this file Testsuite failed: ASDF compiled with ERRORS
Interactively, interestingly, when I try to build from an asdf:*central-registry* with home:lisp;asdf; in it, I get this error:
Error while trying to load definition for system asdf from pathname home:lisp;asdf;asdf.asd.newest: Illegal logical namestring "/Users/rpg/lisp/asdf/asdf.asd" [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
No idea what that's about. When I use /Users/rpg/lisp/asdf/ instead, it works fine.
Interactively, I get:
;Compiler warnings for "home:lisp;asdf;asdf.lisp.newest" : ; In an anonymous lambda form at position 220553: Duplicate definitions of (:METHOD PERFORM (LOAD-OP CL-SOURCE-FILE)), in this file ; Warning: COMPILE-FILE failed while performing #<COMPILE-OP > on #<CL-SOURCE-FILE "asdf" "asdf">. ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)>, in process repl-thread(14). ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP > on #<CL-SOURCE-FILE "asdf" "asdf">. ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)>, in process repl-thread(14).
So are the redefinitions breaking the update?
On Tue, Jan 8, 2013 at 2:36 PM, Robert Goldman rpgoldman@sift.info wrote:
CCL 1.8 on Mac OS X fails to compile asdf as pulled just now.
Not-very-helpful transcript snippet:
COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] Toplevel Forms... Toplevel Forms... Toplevel Forms... Toplevel Forms... ions of (:METHOD PERFORM (LOAD-OP CL-SOURCE-FILE)), in this file Testsuite failed: ASDF compiled with ERRORS
Interactively, interestingly, when I try to build from an asdf:*central-registry* with home:lisp;asdf; in it, I get this error:
Error while trying to load definition for system asdf from pathname home:lisp;asdf;asdf.asd.newest: Illegal logical namestring "/Users/rpg/lisp/asdf/asdf.asd" [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
No idea what that's about. When I use /Users/rpg/lisp/asdf/ instead, it works fine.
Whoa. Something funky is happening. Mind the "logical". Something quite illogical is happening as the result of an attempted merge of pathnames with a logical pathname, presumably the home: thing.
Can you explain me how logical pathnames are used on your machine and in your ASDF configuration?
It's quite possible that I may have gotten some host defaulting mixed up somewhere.
PS: I've exploded asdf into bits. See branch exploded on git.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré]
On 1/8/13 Jan 8 -5:34 PM, Faré wrote:
On Tue, Jan 8, 2013 at 2:36 PM, Robert Goldman rpgoldman@sift.info wrote:
CCL 1.8 on Mac OS X fails to compile asdf as pulled just now.
Not-very-helpful transcript snippet:
COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] COMPONENT-DEPENDS-ON [Defmethod] Toplevel Forms... Toplevel Forms... Toplevel Forms... Toplevel Forms... ions of (:METHOD PERFORM (LOAD-OP CL-SOURCE-FILE)), in this file Testsuite failed: ASDF compiled with ERRORS
Interactively, interestingly, when I try to build from an asdf:*central-registry* with home:lisp;asdf; in it, I get this error:
Error while trying to load definition for system asdf from pathname home:lisp;asdf;asdf.asd.newest: Illegal logical namestring "/Users/rpg/lisp/asdf/asdf.asd" [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
No idea what that's about. When I use /Users/rpg/lisp/asdf/ instead, it works fine.
Whoa. Something funky is happening. Mind the "logical". Something quite illogical is happening as the result of an attempted merge of pathnames with a logical pathname, presumably the home: thing.
Can you explain me how logical pathnames are used on your machine and in your ASDF configuration?
I was using this: (setf (logical-pathname-translations "home") (list (list "**;*.*.*" "/Users/rpg/**/*.*")))
Gives me portability across Mac (/Users) and Linux (/home).
and doing (push "home:lisp;asdf;" asdf:*central-registry*) (asdf:load-system "asdf")
viz:
CL-USER> (logical-pathname-translations "home") ((#P"home:**;*.*.*" #P"/Users/rpg/**/*.*")) CL-USER> (push "home:lisp;asdf;" asdf:*central-registry*) ("home:lisp;asdf;" #P"/Users/rpg/lisp/xophe-clx/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/") CL-USER> (asdf:load-system "asdf")
Unfortunately, on my copy of SLIME, attempts to inspect this "illegal logical pathname" object crashes the inspector.
Something weird seems to be going on inside CCL:
0: ((:INTERNAL ASDF::LOAD-SYSDEF) #<SIMPLE-ERROR #x302000D7344D>) 1: (SIGNAL #<SIMPLE-ERROR #x302000D7344D>) 2: (CCL::%ERROR #<SIMPLE-ERROR #x302000D7344D> ("/Users/rpg/lisp/asdf/asdf.asd") 7841373) Locals: CONDITION = #<SIMPLE-ERROR #x302000D7344D> CCL::ARGS = ("/Users/rpg/lisp/asdf/asdf.asd") CCL::ERROR-POINTER = 7841373 3: (CCL::STRING-TO-PATHNAME "/Users/rpg/lisp/asdf/asdf.asd" 0 29 "home" #P"home:lisp;asdf;") 4: (CCL::FIND-LOAD-FILE #P"home:lisp;asdf;asdf.asd.newest") Locals: CCL::FILE-NAME = #P"home:lisp;asdf;asdf.asd.newest" CCL::FULL-NAME = #P"/Users/rpg/lisp/asdf/asdf.asd" CCL::KIND = NIL CCL::FILE-TYPE = "asd" CCL::MERGED = #P"home:lisp;asdf;asdf.asd.newest" 5: (CCL::%LOAD #P"home:lisp;asdf;asdf.asd.newest" NIL NIL :ERROR :DEFAULT) 6: (LOAD #P"home:lisp;asdf;asdf.asd.newest" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST :ERROR :EXTERNAL-FORMAT :DEFAULT) 7: ((:INTERNAL ASDF::LOAD-SYSDEF))
CL-USER> (describe *fn*) #P"home:lisp;asdf;asdf.asd.newest" Type: LOGICAL-PATHNAME Class: #<BUILT-IN-CLASS LOGICAL-PATHNAME> TYPE: (LOGICAL-PATHNAME . #<CCL::CLASS-WRAPPER LOGICAL-PATHNAME #x300040039A2D>) 1: (:ABSOLUTE "lisp" "asdf") 2: "asdf" 3: "asd" %LOGICAL-PATHNAME-HOST: "home" %LOGICAL-PATHNAME-VERSION: :NEWEST ; No value CL-USER> #P"/Users/rpg/lisp/asdf/asdf.asd" #P"/Users/rpg/lisp/asdf/asdf.asd" CL-USER> (describe *) #P"/Users/rpg/lisp/asdf/asdf.asd" Type: PATHNAME Class: #<BUILT-IN-CLASS PATHNAME> TYPE: (PATHNAME . #<CCL::CLASS-WRAPPER PATHNAME #x3000400399AD>) %PATHNAME-DIRECTORY: (:ABSOLUTE "Users" "rpg" "lisp" "asdf") %PATHNAME-NAME: "asdf" %PATHNAME-TYPE: "asd" %PHYSICAL-PATHNAME-VERSION: :NEWEST %PHYSICAL-PATHNAME-DEVICE: NIL
It does look like FIND-SYSTEM is implicated, as witness the comparison between me checking the logical pathname object created by ASDF, and checking one I make myself:
CL-USER> (asdf:load-system "asdf") #P"home:lisp;asdf;asdf.asd.newest" #P"home:lisp;asdf;asdf.asd.newest" CL-USER> (setf *sys* *) #P"home:lisp;asdf;asdf.asd.newest" CL-USER> (probe-file *sys*) ; Evaluation aborted on #<SIMPLE-ERROR #x302000DFD97D>. ; Evaluation aborted on #<SIMPLE-ERROR #x302000DFD97D>. CL-USER> CL-USER> (probe-file "home:lisp;asdf;asdf.asd") #P"/Users/rpg/lisp/asdf/asdf.asd"
I must go off, sorry -- I'll see if I can dig up any more information. If you can suggest where to look, that would be great.
cheers, r
I was using this: (setf (logical-pathname-translations "home") (list (list "**;*.*.*" "/Users/rpg/**/*.*")))
Gives me portability across Mac (/Users) and Linux (/home).
and doing (push "home:lisp;asdf;" asdf:*central-registry*) (asdf:load-system "asdf")
viz:
CL-USER> (logical-pathname-translations "home") ((#P"home:**;*.*.*" #P"/Users/rpg/**/*.*")) CL-USER> (push "home:lisp;asdf;" asdf:*central-registry*) ("home:lisp;asdf;" #P"/Users/rpg/lisp/xophe-clx/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/") CL-USER> (asdf:load-system "asdf")
Unfortunately, on my copy of SLIME, attempts to inspect this "illegal logical pathname" object crashes the inspector.
I couldn't reproduce, and I don't fully understand this bug yet, but the crux is that we're somehow trying to parse a physical namestring in the context of either an explicit default or the *default-pathname-defaults* being a logical-pathname, and that's something that causes the bug.
Are you perchance using (setf *resolve-symlinks* nil) ?
I have worked around the same bug in the past, and but maybe it resurfaced despite our testing test-logical-pathname.script.
My understanding is that somehow at some unexpected point your *default-pathname-defaults* is a logical-pathname, and this causes confusion — even #p"" will then be a logical pathname. It could also be that ASDF itself was compiled while *default-pathname-defaults* was a logical pathname, and that #p"" and/or other constants in there are then parsed as logical pathnames, and fail. Or it could be anything.
I think we need a function sane-physical-pathname that takes anything in input, tries to turn it to a physical pathname, then tries with *default-pathname-defaults*, then tries with (user-homedir-pathname), maybe with (lisp-implementation-directory), and finally fails with prejudice. Then, we should wrap a lot of defaulting and all our binding of *default-pathname-defaults* with it.
Logical-pathnames are really a big can of worms and of fail.
Alan Perlis quipped that "A programming language is low level when its programs require attention to the irrelevant." But if instead of requiring attention to irrelevant low-level details, a language requires your attention on gratuitous bogosity, what do you call it?
Until we diagnose the exact issue and fix it, a workaround to achieve what you want without logical pathnames is to use :home for your physical home directory in the location DSL, e.g. your ~/.config/common-lisp/source-registry.conf you read:
(:source-registry (:directory (:home "lisp" "asdf")) (:tree (:home "work" "cl")) :inherit-configuration)
Or you could export CL_SOURCE_REGISTRY='(:source-registry ...)'
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Relevant CCL bugs are http://trac.clozure.com/ccl/ticket/953 http://trac.clozure.com/ccl/ticket/978 Ticket 953 is especially relevant if you're older than 15330, which may or may not have been backported to your release branch 1.8.
I've made changes to ASDF to make it more robust, but it's in my exploded branch, which doesn't handle package upgrade yet.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is deplorable that many people think that the best way to improve the world is to forbid something. However, they're morally more advanced than the people who think the best way to improve the world is to kill somebody. — John McCarthy
On Tue, Jan 8, 2013 at 9:43 PM, Faré fare@tunes.org wrote:
I was using this: (setf (logical-pathname-translations "home") (list (list "**;*.*.*" "/Users/rpg/**/*.*")))
Gives me portability across Mac (/Users) and Linux (/home).
and doing (push "home:lisp;asdf;" asdf:*central-registry*) (asdf:load-system "asdf")
viz:
CL-USER> (logical-pathname-translations "home") ((#P"home:**;*.*.*" #P"/Users/rpg/**/*.*")) CL-USER> (push "home:lisp;asdf;" asdf:*central-registry*) ("home:lisp;asdf;" #P"/Users/rpg/lisp/xophe-clx/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/") CL-USER> (asdf:load-system "asdf")
Unfortunately, on my copy of SLIME, attempts to inspect this "illegal logical pathname" object crashes the inspector.
I couldn't reproduce, and I don't fully understand this bug yet, but the crux is that we're somehow trying to parse a physical namestring in the context of either an explicit default or the *default-pathname-defaults* being a logical-pathname, and that's something that causes the bug.
Are you perchance using (setf *resolve-symlinks* nil) ?
I have worked around the same bug in the past, and but maybe it resurfaced despite our testing test-logical-pathname.script.
My understanding is that somehow at some unexpected point your *default-pathname-defaults* is a logical-pathname, and this causes confusion — even #p"" will then be a logical pathname. It could also be that ASDF itself was compiled while *default-pathname-defaults* was a logical pathname, and that #p"" and/or other constants in there are then parsed as logical pathnames, and fail. Or it could be anything.
I think we need a function sane-physical-pathname that takes anything in input, tries to turn it to a physical pathname, then tries with *default-pathname-defaults*, then tries with (user-homedir-pathname), maybe with (lisp-implementation-directory), and finally fails with prejudice. Then, we should wrap a lot of defaulting and all our binding of *default-pathname-defaults* with it.
Logical-pathnames are really a big can of worms and of fail.
Alan Perlis quipped that "A programming language is low level when its programs require attention to the irrelevant." But if instead of requiring attention to irrelevant low-level details, a language requires your attention on gratuitous bogosity, what do you call it?
Until we diagnose the exact issue and fix it, a workaround to achieve what you want without logical pathnames is to use :home for your physical home directory in the location DSL, e.g. your ~/.config/common-lisp/source-registry.conf you read:
(:source-registry (:directory (:home "lisp" "asdf")) (:tree (:home "work" "cl")) :inherit-configuration)Or you could export CL_SOURCE_REGISTRY='(:source-registry ...)'
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
On 1/8/13 Jan 8 -11:39 PM, Faré wrote:
Relevant CCL bugs are http://trac.clozure.com/ccl/ticket/953 http://trac.clozure.com/ccl/ticket/978 Ticket 953 is especially relevant if you're older than 15330, which may or may not have been backported to your release branch 1.8.
I've made changes to ASDF to make it more robust, but it's in my exploded branch, which doesn't handle package upgrade yet.
Sigh.
Unfortunately, SBCL is the only lisp I build from source revision control.
I just grab the CCL binaries when they make a release, since I don't use it in my Real Work\tm, only in testing systems like ASDF and SHOP2.
I'm a bit puzzled by this, though.
Yes, I used a logical pathname when loading ASDF into a Clozure repl to investigate the build failure in the asdf test runner.
But that logical pathname is not in place when I run the tests.
So I guess this is a red herring, and I still need to see why the build failed in the contest of make testall-no-upgrade...
cheers, r
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is deplorable that many people think that the best way to improve the world is to forbid something. However, they're morally more advanced than the people who think the best way to improve the world is to kill somebody. — John McCarthy
On Tue, Jan 8, 2013 at 9:43 PM, Faré fare@tunes.org wrote:
I was using this: (setf (logical-pathname-translations "home") (list (list "**;*.*.*" "/Users/rpg/**/*.*")))
Gives me portability across Mac (/Users) and Linux (/home).
and doing (push "home:lisp;asdf;" asdf:*central-registry*) (asdf:load-system "asdf")
viz:
CL-USER> (logical-pathname-translations "home") ((#P"home:**;*.*.*" #P"/Users/rpg/**/*.*")) CL-USER> (push "home:lisp;asdf;" asdf:*central-registry*) ("home:lisp;asdf;" #P"/Users/rpg/lisp/xophe-clx/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/") CL-USER> (asdf:load-system "asdf")
Unfortunately, on my copy of SLIME, attempts to inspect this "illegal logical pathname" object crashes the inspector.
I couldn't reproduce, and I don't fully understand this bug yet, but the crux is that we're somehow trying to parse a physical namestring in the context of either an explicit default or the *default-pathname-defaults* being a logical-pathname, and that's something that causes the bug.
Are you perchance using (setf *resolve-symlinks* nil) ?
I have worked around the same bug in the past, and but maybe it resurfaced despite our testing test-logical-pathname.script.
My understanding is that somehow at some unexpected point your *default-pathname-defaults* is a logical-pathname, and this causes confusion — even #p"" will then be a logical pathname. It could also be that ASDF itself was compiled while *default-pathname-defaults* was a logical pathname, and that #p"" and/or other constants in there are then parsed as logical pathnames, and fail. Or it could be anything.
I think we need a function sane-physical-pathname that takes anything in input, tries to turn it to a physical pathname, then tries with *default-pathname-defaults*, then tries with (user-homedir-pathname), maybe with (lisp-implementation-directory), and finally fails with prejudice. Then, we should wrap a lot of defaulting and all our binding of *default-pathname-defaults* with it.
Logical-pathnames are really a big can of worms and of fail.
Alan Perlis quipped that "A programming language is low level when its programs require attention to the irrelevant." But if instead of requiring attention to irrelevant low-level details, a language requires your attention on gratuitous bogosity, what do you call it?
Until we diagnose the exact issue and fix it, a workaround to achieve what you want without logical pathnames is to use :home for your physical home directory in the location DSL, e.g. your ~/.config/common-lisp/source-registry.conf you read:
(:source-registry (:directory (:home "lisp" "asdf")) (:tree (:home "work" "cl")) :inherit-configuration)Or you could export CL_SOURCE_REGISTRY='(:source-registry ...)'
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
-
Faré -
Robert Goldman