Opened 13 years ago
Closed 13 years ago
#181 closed defect (fixed)
Failure to load ASDF definitions from JAR files.
Reported by: | Mark Evenson | Owned by: | Mark Evenson |
---|---|---|---|
Priority: | major | Milestone: | 1.0.1 |
Component: | other | Version: | 1.0 |
Keywords: | url-pathname asdf | Cc: | |
Parent Tickets: |
Description
Unfortunately, I think we shipped abcl-1.0.0 with a non-working contrib loading mechanism stemming from an inability to load ASDF definitions from jar archives. This is probably due to the late inclusion of asdf-2.017.22.
The following error occurs from issuing a "(require 'abcl-asdf)":
Error while trying to load definition for system abcl-asdf from pathname jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd: File not found: jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {47B620A2}> #<ASDF:LOAD-SYSTEM-DEFINITION-ERROR {73949D1}> #<FUNCTION {47B620A2}>) 1: (APPLY #<FUNCTION {47B620A2}> (#<ASDF:LOAD-SYSTEM-DEFINITION-ERROR {73949D1}> #<FUNCTION {47B620A2}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF:LOAD-SYSTEM-DEFINITION-ERROR {73949D1}> #<FUNCTION {47B620A2}>) 3: (INVOKE-DEBUGGER #<ASDF:LOAD-SYSTEM-DEFINITION-ERROR {73949D1}>) 4: (ERROR ASDF:LOAD-SYSTEM-DEFINITION-ERROR :NAME "abcl-asdf" :PATHNAME #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd" :CONDITION #<FILE-ERROR {421D3C0B}>) 5: (#<FUNCTION {6189076}> #<FILE-ERROR {421D3C0B}>) 6: (SIGNAL #<FILE-ERROR {421D3C0B}>) 7: org.armedbear.lisp.Lisp.error(Lisp.java:374) 8: org.armedbear.lisp.Load.load(Load.java:147) 9: org.armedbear.lisp.Load.load(Load.java:683) 10: org.armedbear.lisp.Load$_load.execute(Load.java:633) 11: org.armedbear.lisp.Symbol.execute(Symbol.java:820) 12: org.armedbear.lisp.LispThread.execute(LispThread.java:701) 13: org.armedbear.lisp.load_1.execute(load.lisp:33) 14: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 17: org.armedbear.lisp.asdf_248.execute(asdf.lisp:1697) 18: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 19: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1308) 20: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 22: org.armedbear.lisp.asdf_246.execute(asdf.lisp:1697) 23: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 24: org.armedbear.lisp.asdf_243.execute(asdf.lisp:1688) 25: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 26: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 27: org.armedbear.lisp.asdf_245.execute(asdf.lisp:1697) 28: org.armedbear.lisp.Symbol.execute(Symbol.java:796) 29: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 30: org.armedbear.lisp.asdf_251.execute(asdf.lisp:1715) 31: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 32: org.armedbear.lisp.asdf_243.execute(asdf.lisp:1688) 33: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 34: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 35: org.armedbear.lisp.asdf_250.execute(asdf.lisp:1715) 36: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 37: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 38: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794) 39: (SYSTEM::%LOAD #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd" T NIL T) 40: (LOAD #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd")
Change History (5)
comment:1 Changed 13 years ago by
Status: | new → assigned |
---|
comment:2 Changed 13 years ago by
Status: | assigned → accepted |
---|
comment:3 Changed 13 years ago by
The root of the problem seems to be that we have a bug somewhere in the primitives, probably in the truename, for Pathname that surfaces if *DEFAULT-PATHNAME-DEFAULTS* is set to a JAR-PATHNAME.
Assume that we have a jar with an ASDF defintion at #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/jss.asd".
Then the following shows the bug:
CL-USER> (setf *default-pathname-defaults* "/Users/evenson/") "/Users/evenson/" CL-USER> (probe-file (merge-pathnames #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/jss.asd")) #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/jss.asd" CL-USER> (setf *default-pathname-defaults* #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/") #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/" CL-USER> (probe-file (merge-pathnames #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/jss.asd")) NIL
comment:4 Changed 13 years ago by
Milestone: | unscheduled → 1.0.1 |
---|
Need tests to ensure that this stays fixed.
comment:5 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
In r13692 we patch our ASDF to deal with the problems exposed here, but there are more issues to consider with the MERGE-PATHNAME routine in the presence of a JAR-PATHNAME.