[Openmcl-devel] check-defmethod-congruency error message

[Gary King]

I'm also a fan of the new message and of leaving off the process  
prefix when the error happens via the listener...


On Jan 19, 2006, at 11:01 PM, Gary Byers wrote:

>
>
> On Thu, 19 Jan 2006, John Wiseman wrote:
>
>> Currently ccl::check-defmethod-congruency reports incongruent lambda
>> lists like this:
>>
>>> Error in process listener(1): Incompatible lambda list in
>> #<STANDARD-METHOD ADD-DOCUMENT (DOCUMENT-WRITER T)> for
>> #<STANDARD-GENERIC-FUNCTION ADD-DOCUMENT #x8422EB6>
>>
>> How about changing it to report this instead:
>>
>>> Error in process listener(1): Method #<STANDARD-METHOD ADD-DOCUMENT
>> (DOCUMENT-WRITER T)> has lambda list (SELF DOC &OPTIONAL ANALYZER)
>> which is incompatible with generic function's lambda list, (SELF DOC)
>>
>> It just seems friendlier to show me the current GF lambda list  
>> than to
>> make me hunt down the definition (that I have apparently forgotten or
>> I might not have made the error in the first place).
>>
>>
>> John
>>
>>
>> (defun check-defmethod-congruency (gf method)
>>   (unless (congruent-lambda-lists-p gf method)
>>     (cerror (format nil
>> 		    "Remove ~d method~:p from the generic-function and change its
>> lambda list."
>> 		    (length (%gf-methods gf)))
>> 	    "Method ~S has lambda list ~S which is incompatible with generic
>> function's lambda list, ~S"
>> 	    method (method-lambda-list method) (generic-function-lambda-list
>> gf))
>>     (loop
>>       (let ((methods (%gf-methods gf)))
>>         (if methods
>>           (remove-method gf (car methods))
>>           (return))))
>>     (%set-defgeneric-keys gf nil)
>>     (inner-lfun-bits gf (%ilogior (%ilsl $lfbits-gfn-bit 1)
>>                                   (%ilogand $lfbits-args-mask
>>                                             (lfun-bits (%method-
>> function method))))))
>>   gf)
>>
>>
>
> Agreed.
>
> While playing around with this, I noticed that the code that prints  
> (e.g.)
> "Error in process ..." was originally not supposed to print the extra
> "... in process ..." if the process in question was the initial  
> listener,
> but it wasn't testing for that correctly. I've gotten used enough to
> seeing the longer error message prefix, so at first glance:
>
>> Error: Lambda list of method #<STANDARD-METHOD STREAM-WRITE-STRING  
>> (T T)>,
>>        which is (STREAM STRING &OPTIONAL (START 0)),
>>        is incompatible with that of the generic function STREAM- 
>> WRITE-STRING,
>>        which is (STREAM STRING &OPTIONAL START END).
>> While executing: CHECK-DEFMETHOD-CONGRUENCY
>
> looks kind of wrong, but the shorter prefix makes it more likely  
> that a long/
> multiline error message will be readable.
>
> Another approach would be to always print process context info, but to
> print it along with other context info, e.g.:
>
>> While executing: CHECK-DEFMETHOD-CONGRUENCY in process listener(1).
>
> When dealing with the standard tty environment, the process context is
> almost "dog bites man".  As everyone knows, it's the "man bites dog"
> (error/warning occurred in some process other than the listener) case
> that's generally more newsworthy.
>
> Whether it's always printed or not, I think I'd rather see the process
> info -not- causing long error messages to be even harder to read.   
> Does
> anyone object to this change, or know offhand if it would break  
> existing
> code (SLIME, possibly ?)
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel


-- 
Gary Warren King
metabang.com
http://www.metabang.com/