Custom Query (1030 matches)

I haven't been able to reduce that to a small runnable example yet, but when we compile our application with (ccl::snap-reader-methods :known-sealed-world t)

If we subsequently re-define a class, even identically, some existing methods using that class will fail with an "Invalid memory operation". That's with 1.8-r15359 LinuxX8664. Before the patch from http://trac.clozure.com/ccl/changeset/14968 was used, it was a plain crash.

Can CCL be patched so that any class-redefinition after snap-reader-methods would invalidate the snapped reader methods, and possibly issue a warning or continuable error (since a promise was broken)?

Xref: ITA bug 105557

When using a trunk darwinx8664 lisp at r15433 on Mountain Lion, slime often takes tens of seconds to start up.

At a quick first glance, I observe that allocate_tcr() often ends up looping hundreds of thousands, or even millions, of times before it gets a TCR that has a suitable address to use as a Mach port name.

Slime creates several threads at a startup, and usually a few of them end up taking a while to get going. Crudely instrumenting allocate_tcr() shows that the time to find a suitable port name can take anywhere from under a second to 20 seconds or more.

I was loading a matrix math package, via (ql:quickload "clem"), and got an error that the %unbox-s8 vinsin is missing. It's missing in both x8664-vinsins.lisp and x8632-vinsins.lisp. I have a fix that I'll commit to trunk soon.

To test, evaluate the following two forms. The first one errors before the fix.

(defun foo (m x)
  (declare (optimize (speed 3) (safety 0)))
  (declare (type (simple-array (signed-byte 8) *) m))
  (setf (aref m 0) x))

(let ((a (make-array 2 :element-type '(signed-byte 8))))
  (foo a -128)
  (assert (eql -128 (aref a 0)))
  (foo a 127)
  (assert (eql 127 (aref a 0)))
  (foo a 128)
  (assert (eql -128 (aref a 0))))