Custom Query (1030 matches)

As per discussion on #ccl:

Finalizer ordering is currently arbitrary or backwards where it seems it should not be. (Note the definition of FINALIZE is essentially lifted from TRIVIAL-GARBAGE.)

;; This is a demonstration of finalization order in CCL.  When I run this,
;; I get the following output:
;;
;;     Finalize FOO 1
;;     Finalize FOO 2
;;     I would like #S(FOO) 2
;;     Finalize BAR 2
;;
;; This unfortunately means that if the FOO finalizer does something destructive
;; and permanent (like freeing a foreign value), BAR's finalizer can cause a
;; crash.

(defstruct (foo (:constructor %make-foo)))
(defstruct (bar (:constructor %make-bar)))

(defun finalize (object function)
  (ccl:terminate-when-unreachable object
                                  (lambda (obj)
                                    (declare (ignore obj))
                                    (funcall function)))
  object)

(defun make-foo (id)
  (let* ((foo (%make-foo)))
    (finalize foo (lambda () (format t "~&Finalize FOO ~A~%" id)))))

(defun make-bar (id)
  (let* ((foo (make-foo id))
         (bar (%make-bar)))
    (finalize bar
              (lambda ()
                (format t "~&I would like ~A ~A~%" foo id)
                (format t "~&Finalize BAR ~A~%" id)))))

(make-foo 1)
(make-bar 2)
(gc)

One would expect that FOO 2 would not be finalized until after BAR 2, because FOO 2 is referenced by BAR 2's finalizer lambda. I surmise that this is because the only reference to a finalizer is via its object, and therefore, anything the finalizer references becomes eligible for collection as soon as the object itself does.

A simple workaround is to simply strongly reference the lambda, and then make it dereference itself:

(defvar *strong-finalizers* (make-hash-table))

(defstruct (foo (:constructor %make-foo)))
(defstruct (bar (:constructor %make-bar)))

(defun finalize (object function)
  (setf (gethash function *strong-finalizers*) t)
  (ccl:terminate-when-unreachable object
                                  (lambda (obj)
                                    (declare (ignore obj))
                                    (funcall function)
                                    (remhash function *strong-finalizers*)))
  object)

(defun make-foo (id)
  (let* ((foo (%make-foo)))
    (finalize foo (lambda () (format t "~&Finalize FOO ~A~%" id)))))

(defun make-bar (id)
  (let* ((foo (make-foo id))
         (bar (%make-bar)))
    (finalize bar
              (lambda ()
                (format t "~&I would like ~A ~A~%" foo id)
                (format t "~&Finalize BAR ~A~%" id)))))

(make-bar 2)
(gc)

(make-foo 1)
(gc)
(gc)
(gc)

In this case, the finalizer for FOO 2 is not called until the next cycle (though it appears to take some allocation and a cycle or two to make it notice).

On Lion, it appears that overlay-style scroll bars can't be clicked in Hemlock editor windows. The clicks appear to go to the underlying text view, and they make a selection rather than scrolling the window content.

To reproduce:

• open a file large enough to need scrolling
• scroll by gesture so that the scroll bars appear
• try to drag the scrollbar

Observe that the scrollbar cannot be grabbed.

Using "legacy" scrollbars works fine.

1.8-dev-r15098, Mac OS X 10.7.2. I see the behavior in both 32-bit and 64-bit lisps.

I've noticed the problem that some perfectly valid numbers like #x40000000 weren't recognized as (SIGNED-BYTE 64) / (UNSIGNED-BYTE 64) when working with cl-sqlite. I've distilled the problem down to ccl::%%set-signed-longlong / ccl::%%set-unsigned-longlong (see attached test) and further down to .SPgetu64 / .SPgets64 implementations in ARM lisp kernel. The problem was that 'one-digit' bignums weren't taken into account by these subprims. My patch seems to fix this, but I don't often write ARM assembly, so please take a look at it before applying.