On 2/23/14, 17:27, Robert Goldman wrote:
Faré wrote:
On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon ch-l...@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.
