Custom Query (1030 matches)

If the CCL IDE bundle is moved out of the CCL directory and executed, certain functions will fail (e.g. just do #&NSApp in the listener and see what happens). This is because the ccl: logical translation no longer points to the CCL directory, but rather to whatever directory the bundle is in. This is set by the init-ccl-directory-for-ide function. This could also be a problem for any saved applications depending on what they do. There are various ways this could be addressed: 1) add a new value into the Info.plist identifying the CCL directory and use it to initialize the ccl: translation 2) Modify init-ccl-directory-for-ide to search for the right directory 3) create a physical link to the CCL directory in the bundle somewhere and use that as the translation for the ccl: logical directory, 4) add a user preference that identifies where the CCL directory is and use that to initialize the translation. I prefer #4 because it is easier to change if the bundle is moved to a different machine or if the CCL directory is moved at some point. #2 is intriguing but depending on how the search is done, could take a significant amount of time. So I am requesting an enhancement to the IDE that adds a preference item identifying the CCL directory. It should default to the value currently used. In the meantime I will assure that applications that my tools generate will reset the logical translation in some way.

Compilation of the following function fails on ARM:

(defun fixnum-double (x)
  (declare (fixnum x))
  (* x 10d0))

That's because it uses FIXNUM->DOUBLE vinsn that has :single-float temp which is not supported by CCL::ALLOCATE-TEMPORARY-VREG.

Test case from Zach Beane.

Ideally, both the (logand #xf... ...) and (ldb (byte 32 0) ...) would open-code nicely in this case (on a 64-bit lisp, anyway).

(defun ldb-logand-diff (a b)
  (declare (type (unsigned-byte 32) a b))
  (let (x y)
    (setf x (logand #xFFFFFFFF (+ a b)))
    (setf y (ldb (byte 32 0) (+ b a)))
    (values x y)))

I could imagine hairing up the compiler macro on LDB, but maybe there's a better idea.