Custom Query (1030 matches)
Results (295 - 297 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1186 | fixed | FORMAT prints one digit too many after decimal point for ~e directive | ||
| Description |
FORMAT prints one digit too many after decimal point for ~e directive (CLHS 22.3.3.2). E.g.: $ ./lx86cl Welcome to Clozure Common Lisp Version 1.9-r16078 (LinuxX8632)! ? (loop for d in '(1 2 3 4 5 6) do (format t "~,ve ~,ve~%" d 1.2345678e-10 d 1.2345678e+10)) 1.23E-10 1.23E+10 1.235E-10 1.235E+10 1.2346E-10 1.2346E+10 1.23457E-10 1.23457E+10 1.234568E-10 1.234568E+10 1.2345679E-10 1.2345678E+10 NIL On the other hand SBCL 1.0.55.0 is correct from what I can tell: * (loop for d in '(1 2 3 4 5 6) do (format t "~,ve ~,ve~%" d 1.2345678e-10 d 1.2345678e+10)) 1.2e-10 1.2e+10 1.23e-10 1.23e+10 1.235e-10 1.235e+10 1.2346e-10 1.2346e+10 1.23457e-10 1.23457e+10 1.234568e-10 1.234568e+10 NIL |
|||
| #763 | invalid | FP exception handling and "random" FP exceptions | ||
| Description |
On at least some fairly recent versions of OSX, using drag-and-drop to drag text around in the Cocoa IDE generates an FP exception (invalid operation IIRC). This happens deep in some CG text-drawing code that's invoked by CCL calling the superclass's #/mouseDown: method, and we report it as an arithmetic error. The error's likely to just be confusing and disruptive to the user. We can work around this particular bug by disabling FP exceptions around the next-method call. We generally try to report FP exceptions that occur in foreign code; this certainly makes sense if (for instance) #_sin is called as part of the implementation of CL:SIN. It's less clear that it's desirable or useful to try to detect and report FP exceptions that have nothing to do with CL math functions, though we've traditionally done so. |
|||
| #1030 | fixed | Failure with conditional-store | ||
| Description |
(This is assuming ccl::conditional-store should work as a typical compare-and-swap, even though it's not exported.) The RUN function below causes an assertion failure within 2000 iterations on my Linux-x86 machine. An svref place has the same issue. I did not see a problem on Darwin. Removing the assertion (but keeping the conditional-store) results in a hang. Replacing that conditional-store (the second one) with setf also produces a hang. (defstruct stack
(head nil)
(lock nil))
(defun call-with-spin-lock (stack fn)
(loop :until (ccl::conditional-store
(stack-lock stack) nil t))
(unwind-protect
(funcall fn)
(assert (ccl::conditional-store
(stack-lock stack) t nil))))
(defmacro with-spin-lock ((stack) &body body)
`(call-with-spin-lock ,stack (lambda () ,@body)))
(defun push-stack (value stack)
(with-spin-lock (stack)
(push value (stack-head stack))))
(defun pop-stack (stack)
(with-spin-lock (stack)
(pop (stack-head stack))))
(defun test (thread-count)
(let ((stack (make-stack)))
(loop :repeat thread-count
:do (ccl:process-run-function "test" #'push-stack t stack))
(loop :repeat thread-count
:do (loop :until (pop-stack stack)))))
(defun run ()
(loop
(test 1)
(format t ".")))
|
|||
