[armedbear-devel] asdf regression
asdf::oos used to take a :verbose argument. It no longer does. This breaks some of my code (I'm trying to migrate to the latest abcl so I can test/use the jar file feature - thanks Mark!) (I've worked around it for now) -Alan
On 9/9/09 1:57 PM, Alan Ruttenberg wrote:
asdf::oos used to take a :verbose argument. It no longer does. This breaks some of my code (I'm trying to migrate to the latest abcl so I can test/use the jar file feature - thanks Mark!) (I've worked around it for now)
The problem was introduced in changeset is [svn r12067][1]: r12067 | vvoutilainen | 2009-07-27 22:10:46 +0200 (Mon, 27 Jul 2009) | 2 lines Changed paths: M /trunk/abcl/src/org/armedbear/lisp/clos.lisp Better initarg checking. Fixes CHANGE-CLASS.1.11, MAKE-INSTANCE.ERROR.3 and MAKE-INSTANCE.ERROR.4. The problem can be tested by attempting to load an ASDF system defintion as follows: (asdf:operate 'asdf:load-op :abcl :verbose t) which produces the error Invalid initarg :VERBOSE. but probably can be reduced to a simpler test case involving functions with &key arguments after &rest. Filed as [bug #62][2]. Thanks for the report. [1]: http://trac.common-lisp.net/armedbear/changeset/12067 [2]: http://trac.common-lisp.net/armedbear/ticket/62 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2009/9/10 Mark Evenson <evenson@panix.com>:
On 9/9/09 1:57 PM, Alan Ruttenberg wrote:
asdf::oos used to take a :verbose argument. It no longer does. This breaks some of my code (I'm trying to migrate to the latest abcl so I The problem was introduced in changeset is [svn r12067][1]: The problem can be tested by attempting to load an ASDF system defintion as follows:
(asdf:operate 'asdf:load-op :abcl :verbose t)
which produces the error
Invalid initarg :VERBOSE.
but probably can be reduced to a simpler test case involving functions with &key arguments after &rest.
I'm at work and don't have access to abcl stuff. Do &key arguments before &rest work? I do remember trying asdf and thought that it didn't have problems with the args. Apparently I didn't try a sufficient amount of permutations.
On 9/10/09 9:58 AM, Ville Voutilainen wrote:
I'm at work and don't have access to abcl stuff. Do&key arguments before &rest work? I do remember trying asdf and thought that it didn't have problems with the args. Apparently I didn't try a sufficient amount of permutations.
After a bit more analysis on my part, the problem isn't the method declaration, but rather the call to MAKE-INSTANCE (which makes more sense as [r12067][1] modifies CHECK-INITARGS: The bug can be reproduced more easily via: (require 'asdf) (apply #'make-instance 'asdf:load-op :original-initargs '(:verbose t) '(:verbose t))) [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=26ada20278cef4... -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2009/9/10 Mark Evenson <evenson@panix.com>:
After a bit more analysis on my part, the problem isn't the method declaration, but rather the call to MAKE-INSTANCE (which makes more sense as [r12067][1] modifies CHECK-INITARGS:
I'll have to take another look at this. I remember that I specifically tested asdf with a :verbose t parameter. Thanks for the investigation.
On 9/10/09 1:43 PM, Ville Voutilainen wrote:
2009/9/10 Mark Evenson<evenson@panix.com>:
After a bit more analysis on my part, the problem isn't the method declaration, but rather the call to MAKE-INSTANCE (which makes more sense as [r12067][1] modifies CHECK-INITARGS:
I'll have to take another look at this. I remember that I specifically tested asdf with a :verbose t parameter.
It looks like asdf.lisp is a pathological case as it includes at line 508: (defmethod shared-initialize :after ((operation operation) slot-names &key force &allow-other-keys) (declare (ignore slot-names force)) ;; empty method to disable initarg validity checking ) which if I disable this form before evaluation in SBCL, returns the same error as ABCL. So, this has more to do with the way we are invoking and interpreting the various generic functions in MAKE-INSTANCE, then problems with CHECK-INITARGS. Looking through SBCL is somewhat instructive, but confusing as well. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2009/9/10 Mark Evenson <evenson@panix.com>:
It looks like asdf.lisp is a pathological case as it includes at line 508: (defmethod shared-initialize :after ((operation operation) slot-names
There's nothing pathological in defmethoding shared-initialize, IMHO..
which if I disable this form before evaluation in SBCL, returns the same error as ABCL. So, this has more to do with the way we are invoking and interpreting the various generic functions in MAKE-INSTANCE, then problems with CHECK-INITARGS. Looking through SBCL is somewhat instructive, but confusing as well.
Well, we try to compute the effective methods in MAKE-INSTANCE, and also try to see if the lambda list matches any of those. CHECK-INITARGS is a mere helper function.
2009/9/10 Ville Voutilainen <ville.voutilainen@gmail.com>:
It looks like asdf.lisp is a pathological case as it includes at line 508: (defmethod shared-initialize :after ((operation operation) slot-names
Ok, the problem is fixed by r12142 on trunk. Do people want this fix in the 0.16 release branch also? Would people like to have an updated release? Alan, Mark, thanks for testing and reporting the problem.
On 9/10/09 11:00 PM, Ville Voutilainen wrote:
2009/9/10 Ville Voutilainen<ville.voutilainen@gmail.com>:
It looks like asdf.lisp is a pathological case as it includes at line 508: (defmethod shared-initialize :after ((operation operation) slot-names
Ok, the problem is fixed by r12142 on trunk. Do people want this fix in the 0.16 release branch also? Would people like to have an updated release?
I'd say backport to 0.16.x, but hold off on a 0.16.1 until either we get more bugs or we get an explicit request. As far as I understand, Alan is using trunk now for the 'jar:file' loading anyways. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2009/9/11 Mark Evenson <evenson@panix.com>:
Ok, the problem is fixed by r12142 on trunk. Do people want this fix in the 0.16 release branch also? Would people like to have an updated release? I'd say backport to 0.16.x, but hold off on a 0.16.1 until either we get more bugs or we get an explicit request. As far as I understand, Alan is using trunk now for the 'jar:file' loading anyways.
Right, it's already backported, Erik said he'll do a pached release if necessary.
Thanks all! Best, Alan On Fri, Sep 11, 2009 at 2:09 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
2009/9/11 Mark Evenson <evenson@panix.com>:
Ok, the problem is fixed by r12142 on trunk. Do people want this fix in the 0.16 release branch also? Would people like to have an updated release? I'd say backport to 0.16.x, but hold off on a 0.16.1 until either we get more bugs or we get an explicit request. As far as I understand, Alan is using trunk now for the 'jar:file' loading anyways.
Right, it's already backported, Erik said he'll do a pached release if necessary.
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
participants (3)
-
Alan Ruttenberg -
Mark Evenson -
Ville Voutilainen