Opened 12 years ago

Closed 12 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 12 years ago by Mark Evenson

Status: newassigned

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.

comment:2 Changed 12 years ago by Mark Evenson

Status: assignedaccepted

comment:3 Changed 12 years ago by Mark Evenson

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 12 years ago by Mark Evenson

Milestone: unscheduled1.0.1

Need tests to ensure that this stays fixed.

comment:5 Changed 12 years ago by Mark Evenson

Resolution: fixed
Status: acceptedclosed

(In [13704]) Fix #181: TRUENAME doesn't always canonicalize the outer DEVICE component of JAR-PATHNAME.

If *DEFAULT-PATHNAME-DEFAULTS* is a JAR-PATHNAME, then TRUENAME will
not attempt to canonicalize the outer DEVICE component of a JAR-PATHNAME.

Remove corresponding kludge from ASDF.

Note: See TracTickets for help on using tickets.