Custom Query (1030 matches)

From gb:

(declare (type (simple-array double-float) a b))

declares that A and B are SIMPLE-ARRAYs with unspecified dimensionality. We'll generally only try to open-code the AREF/CCL::ASET if the dimensionality of the array is specified in the declaration.

In "reasonably safe" code, if the declared dimensionality of the array was unpecified (or specified as *), we could treat

(aref a i)

as

(%typed-aref (type-of a) a i)

and typecheck that A is in fact a one-dimensional array of the declared type before doing anything with it. If A was in fact of the wrong dimensionality, we'd get a type error (A isn't a simple-one-dimensional-array of the specified type) rather than a wrong-number-of-subscripts error, but I don't think that AREF's error behavior is too rigidly specified. In unsafe code, we crash and burn if the actual dimensionality doesn't match, but win in more cases if it does.

(define-method-combination test-method-combination ()

((around (:around))

(primary () :required t))

`(call-method ,(first around) ( (make-method (call-method ,(first primary))) )))

(defgeneric foo (x)

(:method-combination test-method-combination))

(defmethod foo((o integer))

nil)

(defmethod foo :around ((o integer))

(call-next-method o))

(foo 23)

causes an error: value NIL is not of the expected type SIMPLE-VECTOR.

The bug seems to have been there forever, but the recently released ASDF 1.128 and later actually uses non-standard method combinations and evokes this bug in normal use.

Typing c-/ at the lisp process (in a unix shell) leaves it in a weird state where ps lists it as <defunct>, but it actually keeps running, sometimes apparently working fine, sometimes becoming non-responsive.

Gary knows what causes this, but it might be hard to fix on some platforms.