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