Custom Query (1030 matches)
Results (709 - 711 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1275 | fixed | create-jvm broken in ccl's jni.lisp | ||
| Description |
library/jni.lisp defines create-jvm, which calls ccl::call-with-string-vector with two arguments; ccl::call-with-string-vector requires three. Supplying an encoding, e.g. :us-ascii, appears to fix the problem. |
|||
| #1278 | fixed | (code-char #xFFFE) returns NIL at least on x86 and x86-64 | ||
| Description |
And (code-char #xFFFF) returns NIL too. Unicode Corrigendum 9 http://www.unicode.org/versions/corrigendum9.html explains that "noncharacters" should not be rejected. They are the codepoints U+FFFE U+FFFF U+1FFFE U+1FFFF ... up to U+10FFFE and U+10FFFF, plus the codepoints U+FDD0..U+FDEF. It states "the definition of noncharacter in the standard has led some implementers to interpret any presence of a noncharacter code point in a Unicode string as causing that string to be ill-formed, and thereby has led to inappropriate over-rejection" And later: noncharacters "are not illegal in interchange nor do they cause ill-formed Unicode text". Being able to represent codepoint U+FFFE is also important, because when found in a file or stream it is a strong diagnostic indication that the Unicode text was parsed incorrectly - typically the wrong UTF-16 endianity has been used. Replacing it with NIL is both non-standard (see Corrigendum 9 above) and makes troubleshooting more difficult. For these reasons, I am asking to change CODE-CHAR such that (code-char #xFFFE) returns #\U+FFFE and (code-char #\U+FFFF) returns #\U+FFFF |
|||
| #1280 | fixed | Cannot INLINE functions created by MACROLET | ||
| Description |
A function defined with MACROLET that is declaimed as INLINE doesn't seem to actually inline at the call site. If you manually write the definition out without the MACROLET, inlining works as expected. I have tried locally declaring the function as INLINE at the call site, and I have also tried doing a DECLAIM INLINE outside of the MACROLET, all to no avail. See the interactions below to reproduce. File def.lisp (defpackage :foo
(:use :cl)
(:export fun))
(in-package :foo)
(macrolet ((def (name op)
`(progn
(declaim (inline ,name))
(defun ,name (a b)
(,op a b)))))
(def fun +))
File use.lisp (in-package :cl-user) (defun bar (a b) (declare (optimize speed (safety 0) (debug 0) (space 0))) (foo:fun a (* a b))) REPL interaction (note the line marked with !!!!...!!) CL-USER> (lisp-implementation-type) "Clozure Common Lisp" CL-USER> (lisp-implementation-version) "Version 1.11-dev-r16361M-trunk (LinuxARM32)" CL-USER> (load (compile-file "def.lisp")) #P"def.lafsl" CL-USER> (load (compile-file "use.lisp")) #P"use.lafsl" CL-USER> (disassemble #'bar) ;; Source: "use.lisp.newest":23-122 (mov imm0 (:$ 19)) (stmdb (:! sp) (imm0 vsp fn lr)) (mov fn temp2) (stmdb (:! vsp) (arg_z arg_y)) ;[12] ;;; (* a b) (sploadlr .SPbuiltin-times) ;[16] (blx lr) ;;; (foo:fun a (* a b)) (ldr arg_y (:@ vsp (:$ 4))) ;[24] (mov nargs (:$ 8)) (ldr temp1 (:@ fn 'FOO:FUN)) ; *** !!!!!!!!!!!!!! (ldmia (:! sp) (imm0 vsp fn lr)) (ldr temp2 (:@ temp1 (:$ 6))) ;[40] (ldr pc (:@ temp2 (:$ -2))) ;;; #<no source text> NIL |
|||
