[asdf-devel] asdf loading error error
While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error: Error while trying to load definition for system abcl-cdk from pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)). [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] Restarts: 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system abcl-cdk after reinitializing the source-registry. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {55860583}> #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>) 1: (APPLY #<FUNCTION {55860583}> (#<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}> #<FUNCTION {55860583}>) 3: (INVOKE-DEBUGGER #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {7A5599D4}>) 4: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "abcl-cdk" :PATHNAME #P"/Users/sly/projects/abcl-cdk/abcl-cdk.asd" ...) 5: (#<FUNCTION {76BF4B40}> #<SIMPLE-ERROR {9E66C0B}>) 6: (SIGNAL #<SIMPLE-ERROR {9E66C0B}>) 7: (ERROR "There is no applicable method for the generic function ~S ~ when called with arguments ~S." #<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> ((NIL))) 8: (#<FUNCTION {372CC276}> #<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> (NIL)) 9: (APPLY #<FUNCTION {372CC276}> (#<STANDARD-GENERIC-FUNCTION {4DE3AFA9}> (NIL))) 10: (ASDF/SYSTEM:BUILTIN-SYSTEM-P NIL) 11: (#<FUNCTION {8E593A8}> "~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT") 12: (APPLY #<FUNCTION {8E593A8}> ("~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT")) 13: (UIOP/UTILITY:CALL-FUNCTION #<FUNCTION {8E593A8}> "~S: ~S doesn't follow asdf version numbering convention" UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT") 14: (UIOP/UTILITY:PARSE-VERSION "1.5.6-SNAPSHOT" #<FUNCTION {8E593A8}>) 15: (ASDF/PARSE-DEFSYSTEM::NORMALIZE-VERSION "1.5.6-SNAPSHOT" :COMPONENT "org.openscience.cdk/cdk" :PARENT #<ASDF/SYSTEM:SYSTEM {43A2DC5E}> ...) 16: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM #<ASDF/SYSTEM:SYSTEM {43A2DC5E}> (:MVN "org.openscience.cdk/cdk" :VERSION "1.5.6-SNAPSHOT") :PREVIOUS-SERIAL-COMPONENT "org.freehep/freehep-graphicsio-svg") 17: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "abcl-cdk" :PATHNAME NIL :NAME "abcl-cdk" ...)) I can understand the first error, but the second error that gets generated along the way seems like a mistake. Let me know if I can offer more information to help track this down. thanks, Cyrus
On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error:
Error while trying to load definition for system abcl-cdk from pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)). [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
There's an error while reporting a warning (warning about your system having a bad version string). I suggest you add this method in system.lisp after defclass system: (defmethod builtin-system-p ((x null)) nil) Does it help? Robert, do you want me to commit that? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you're a quiet, law-abiding citizen most of the time but occasionally cut someone up and bury them in your backyard, you're a bad guy. — Paul Graham, "The Power of the Marginal"
Faré wrote:
On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error:
Error while trying to load definition for system abcl-cdk from pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)). [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
There's an error while reporting a warning (warning about your system having a bad version string). I suggest you add this method in system.lisp after defclass system: (defmethod builtin-system-p ((x null)) nil) Does it help?
Robert, do you want me to commit that?
I'd like to understand this patch better before we push it. Why is it that having a method on NIL is right? Doesn't this just mask a bug where we are incorrectly treating NIL as if it's a system designator? What's the cause for trying to ask if NIL is a built in system? Presumably some system lookup returned NIL, right? If so, why wasn't that trapped as an error? thanks, r
On 2/23/14, 17:27, Robert Goldman wrote:
Faré wrote:
On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error:
Error while trying to load definition for system abcl-cdk from pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)). [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
There's an error while reporting a warning (warning about your system having a bad version string). I suggest you add this method in system.lisp after defclass system: (defmethod builtin-system-p ((x null)) nil) Does it help?
Robert, do you want me to commit that?
I'd like to understand this patch better before we push it.
Why is it that having a method on NIL is right? Doesn't this just mask a bug where we are incorrectly treating NIL as if it's a system designator?
What's the cause for trying to ask if NIL is a built in system? Presumably some system lookup returned NIL, right? If so, why wasn't that trapped as an error?
The error is coming from the [ABCL-ASDF contrib which defines an MVN-COMPONENT class descending from ASDF:COMPONENT][1]. This class is used to represent a Maven dependency which is resolved to a binary JVM artifact on the distributed Maven POM graph specified by three coordinates: GROUP-ID, ARTIFACT-ID, and VERSION. In my implementation, I have (probably mistakenly) tried to overload the ASDF:COMPONENT VERSION slot to contain a version inteligble to both Maven and ASDF. Unfortunately, the Maven version can basically contain any string, not having a meaningfully defined ordering (i.e. you can only determine if versions are different, not if one preceded another) which conflicts with ASDF requirements for strict "semantic versioning" (if I am using that term correctly). In my defense, I think this was working this way with ASDF 1, before ASDF 2's requirements came into being. Currently, ABCL-ASDF "cheats" by stuffing a possibly non-conforming ASDF version in the COMPONENT VERSION slot via the ASDF:ENSURE-MVN-VERSION "cleanup" function, so that the form (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6-SNAPSHOT") produces this error while (:mvn "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT") will correctly reference the correct Maven artifact, sneaking by ASDF's checking for a valid version. The right way forward would be to re-write the MVN-COMPONENT class not to use the inherited VERSION slot, but another for its purposes. But in the meantime, users get a baffling error when they use a non-ASDF compliant slot value. [1]: http://abcl.org/trac/browser/trunk/abcl/contrib/abcl-asdf/abcl-asdf.lisp -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
OK, so that's why there's a bad version error. I get that. Would it be a big problem to fix the system instead of trying to fix ASDF? That still doesn't answer my original question: what's this about the built-system-p check? Why does that need fixing?
Could this be the BUILT-IN-SYSTEM-P check? Faré recently added this block to the code for wrangling system versions: (let ((sysfile (system-source-file (component-system component)))) (when (and (typep component 'system) (not bspp)) (setf (builtin-system-p component) (lisp-implementation-pathname-p sysfile))) (setf version (normalize-version version :component name :parent parent :pathname sysfile))) Question: what version of ASDF are you testing on? The version of the code above dates from Feb 7. Any chance you are testing an earlier version? Faré: it looks like BSPP here is built-in-system-p-supplied-p, yes? If so, it looks like this block is trying to guess whether a system is built in. If this is the source of the error, though, I don't see how (TYPEP NIL 'SYSTEM) could be passing. Thanks, r
On Sun, Feb 23, 2014 at 11:27 AM, Robert Goldman <rpgoldman@sift.net> wrote:
There's an error while reporting a warning (warning about your system having a bad version string). I suggest you add this method in system.lisp after defclass system: (defmethod builtin-system-p ((x null)) nil) Does it help?
Robert, do you want me to commit that?
I'd like to understand this patch better before we push it.
Why is it that having a method on NIL is right? Doesn't this just mask a bug where we are incorrectly treating NIL as if it's a system designator?
What's the cause for trying to ask if NIL is a built in system? Presumably some system lookup returned NIL, right? If so, why wasn't that trapped as an error?
In this case it's not so much a system designator than something returned by (find-system name nil) in a case where it's acceptable. The test that matters is in parse-defsystem.lisp function normalize-version: (unless (builtin-system-p (find-component parent component)) which for backward compatibility (probably with old SBCL), declines to warn about builtin systems that have badly formed version strings. But in this case, the system doesn't exist, so find-system returns nil, and builtin-system-p errors out instead of returning nil. The warning message should NOT error out when the system doesn't exist, and either you should put that unless under an (if-let (dep (find-component parent component)) ...) or you should make builtin-system-p accept nil as input (nil does not designate a builtin-system). Now, from Mark Evenson's explanation of how abcl-asdf is abusing the version string, it seems that indeed, abcl should not be doing that — at least, not unless and until we adopt some extensible version-compatibility protocol, as has been discussed before, though without a fully worked out proposal. Note that the strict "semantic versioning" requirement of ASDF versions already existed in ASDF1, but wasn't enforced, except backhandedly by hand/or ASDF3 saving version-satisfies (and thus :version dependency-def) silently give non-meaningful answers. ASDF2 started issuing warnings instead, which is the right thing to do. Eventually, these warnings could be turned into errors, after cleaning up quicklisp. Mark: yes, abcl-asdf better avoid that route for now, unless you want to first propose a patch to asdf. Please use a different slot maven-version or some such. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Q. Why does "philosophy of consciousness/nature of reality" seem to interest you so much? A. Take away consciousness and reality and there's not much left. — Greg Egan, interview in Eidolon 15
participants (4)
-
Cyrus Harmon -
Faré -
Mark Evenson -
Robert Goldman