Custom Query (1030 matches)
Results (190 - 192 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1092 | invalid | Method on t causes error when it should not | ||
| Description |
The following code signals an error about the :sign keyword argument. The culprit seems to be the method on T, which prevents the method on list to run. If I omit the method on T, or I define it e.g. on built-in-class, the error is gone. (defgeneric render (obj &rest args))
(defmethod render ((obj t) &key)
(print obj))
(defmethod render ((obj list) &rest args)
(mapc (lambda (item)
(apply #'render item args))
obj))
(defmethod render ((obj number) &key sign)
(print (* sign obj)))
(render (list 1 2 3 4) :sign -1)
According to my reading of CLHS (7.6.4 & 7.6.5), no error should be signaled. Indeed, I have tested this with SBCL and it runs just fine. |
|||
| #1087 | fixed | Can't compile Maxima on a Raspberry Pi with CCL (arm architecture) | ||
| Description |
While trying to compile the lisp-only build of Maxima, I encountered a bug which seems to be related to the ARM compiler in CCL. Here are the last lines of the compilation: ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zlog.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zlog.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zunik.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zunik.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zunhj.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zunhj.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zuoik.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zuoik.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zuni1.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zuni1.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zkscl.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zkscl.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zshch.lisp"... ;Loading #P"binary-openmcl/numerical/slatec/zshch.lafsl"... ;Compiling "/home/pi/maxima-5.29.1/src/numerical/slatec/zbknu.lisp"... > Error: PC-relative displacement can't be encoded. > While executing: (:INTERNAL #:G5915 ARM::ARM-FINALIZE), in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > ? |
|||
| #1084 | fixed | deficient error reporting in flet on bad lambda-list | ||
| Description |
cl-user> (compile-file #P"~/test-flet.lisp")
#P"/home/pjb/test-flet.lx64fsl"
nil
nil
cl-user> (cat #P"~/test-flet.lisp")
(defun f (z)
(flet ((g (x) (list x x))
(u z))
(g z)))
; No value
cl-user>
The fact that the "lambda-list" for u is an atom should signal a program-error. CLHS flet says: lambda-list---a lambda list; for flet and labels, it is an ordinary lambda list; and CLHS 3.4.1 says: The syntax for ordinary lambda lists is as follows:
lambda-list::= (var*
[&optional {var | (var [init-form [supplied-p-parameter]])}*]
[&rest var]
[&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]]
[&aux {var | (var [init-form])}*])
so lambda-list for flet and labels cannot be an atom. And in the case where I found this, u was also a global function, so perhaps this could be tested by the compiler to add a hint in the error message that perhaps the form was intented to be in the body of the flet. |
|||
