From: Eric M. <eri...@fr...> - 2013-05-26 09:35:04
|
Hi, A recent development. CL-USER> (lisp-implementation-version) "1.1.7.114-be974ed-dirty" CL-USER> *features* (:SWANK :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ASDF-UNICODE :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :LARGEFILE :LINKAGE-TABLE :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64) CL-USER> (char-equal #\É #\é) NIL CL-USER> -- Eric Marsden |
From: Christophe R. <cs...@ca...> - 2013-05-26 19:59:46
|
Eric Marsden <eri...@fr...> writes: > A recent development. OK, thanks! > CL-USER> (char-equal #\É #\é) > NIL > CL-USER> So, I can fix this, but in the process of doing that I ran what I thought would be a suitable test... (with-test (:name :case-insensitive-char-comparisons) (dotimes (i char-code-limit) (let* ((char (code-char i)) (down (char-downcase char)) (up (char-upcase char))) (assert (char-equal char char)) (when (char/= char down) (assert (char-equal char down))) (when (char/= char up) (assert (char-equal char up)))))) ... and discovered that this fails: U+1F80 upcases to U+1F88, but U+1F88 apparently doesn't downcase to U+1F80. Not sure why yet, but that latter part isn't actually a regression (so it might not get fixed, if indeed it needs fixing, before the release). Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2013-05-26 21:04:05
|
Christophe Rhodes <cs...@ca...> writes: > ... and discovered that this fails: U+1F80 upcases to U+1F88, but U+1F88 > apparently doesn't downcase to U+1F80. Not sure why yet, but that > latter part isn't actually a regression (so it might not get fixed, if > indeed it needs fixing, before the release). I now know more than I wanted to know about Greek typography. Read <http://www.tlg.uci.edu/~opoudjis/unicode/unicode_adscript.html> and be enlightened, or confused. I'll commit the minimal fix (for the regression) tomorrow, to get #\é / #\É and most other cases right. The joys of iota subscripts and capitalization will wait until after the release. Cheers, Christophe |
From: Zach B. <xa...@xa...> - 2013-05-27 01:59:24
|
Christophe Rhodes <cs...@ca...> writes: > Christophe Rhodes <cs...@ca...> writes: > >> ... and discovered that this fails: U+1F80 upcases to U+1F88, but U+1F88 >> apparently doesn't downcase to U+1F80. Not sure why yet, but that >> latter part isn't actually a regression (so it might not get fixed, if >> indeed it needs fixing, before the release). > > I now know more than I wanted to know about Greek typography. Read > <http://www.tlg.uci.edu/~opoudjis/unicode/unicode_adscript.html> and be > enlightened, or confused. > > I'll commit the minimal fix (for the regression) tomorrow, to get #\é / > #\É and most other cases right. The joys of iota subscripts and > capitalization will wait until after the release. I've been testing Quicklisp libraries with 1.1.7.113-0b3f5cc and got this failure in cl-l10n: unhandled TYPE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {100322BF13}>: The value NIL is not of type CHARACTER. Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {100322BF13}> 0: (SB-VM::LOAD-CHARACTER #<SB-C::VOP :INFO SB-VM::CHARACTER-MOVE :ARGS #<SB-C:TN-REF :TN #<SB-C:TN 'NIL!1> :WRITE-P NIL :VOP SB-VM::CHARACTER-MOVE> :RESULTS #<SB-C:TN-REF :TN #<SB-C:TN t2[RAX]> :WRITE-P T :VOP SB-VM::CHARACTER-MOVE>> #<SB-C:TN 'NIL!1> #<SB-C:TN t3[RAX]>) 1: ((LAMBDA (SB-C::.VOP.) :IN "/home/xach/src/sbcl/src/cold/compile-cold-sbcl.lisp") #<SB-C::VOP :INFO SB-VM::CHARACTER-MOVE :ARGS #<SB-C:TN-REF :TN #<SB-C:TN 'NIL!1> :WRITE-P NIL :VOP SB-VM::CHARACTER-MOVE> :RESULTS #<SB-C:TN-REF :TN #<SB-C:TN t2[RAX]> :WRITE-P T :VOP SB-VM::CHARACTER-MOVE>>) 2: (SB-C::GENERATE-CODE #<SB-C:COMPONENT :NAME (LABELS FINISH :IN FIND-REPLACEMENT-MARKER-IN-PATTERN) {10069E9803}>) 3: (SB-C::%COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LABELS FINISH :IN FIND-REPLACEMENT-MARKER-IN-PATTERN) {10069E9803}>) 4: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LABELS FINISH :IN FIND-REPLACEMENT-MARKER-IN-PATTERN) {10069E9803}>) ...lots more... Full log is at http://report.quicklisp.org/cl-l10n/2013-05-26/failtail.txt Backtrace looks really fishy to me. Is it related to this issue? Zach |
From: Attila L. <att...@gm...> - 2013-05-27 03:40:27
|
> I've been testing Quicklisp libraries with 1.1.7.113-0b3f5cc and got > this failure in cl-l10n: for the record i also get this with SBCL head. ; compiling (DEFUN FIND-REPLACEMENT-MARKER-IN-PATTERN (PATTERN MARKER-CHARACTER &KEY ...) ...);;; warning: wnused declarations found in form: (IGNORABLE DATE), (IGNORABLE DAY-OF-WEEK), (TYPE NON-NEGATIVE-FIXNUM DAY-OF-WEEK). debugger invoked on a TYPE-ERROR in thread #<THREAD "main thread" RUNNING {1002B5FC33}>: The value NIL is not of type CHARACTER. note the corruption in the text: "wnused declarations found"! it's printed several times before the error with the same "wunused" word. CL-USER> (lisp-implementation-version) "1.1.7.114.hu.dwim.4-410587d" -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The worst thing that can happen to a good cause is, not to be skillfully attacked, but to be ineptly defended.” — Frédéric Bastiat (1801–1850): 'Economic Sophisms' (1845) |
From: Christophe R. <cs...@ca...> - 2013-05-27 06:41:39
|
Zach Beane <xa...@xa...> writes: > Backtrace looks really fishy to me. Is it related to this issue? My guess is not: more likely to be a newly-introduced compiler invariant breakage somewhere. (The char-equal bug simply means that some non-ascii characters are not treated as case-insensitively equal when they should be). But I'll commit that fix and then we'll see. Good to know that there are more regressions to find in this freeze period. Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2013-05-27 08:24:33
|
Christophe Rhodes <cs...@ca...> writes: > Zach Beane <xa...@xa...> writes: > >> Backtrace looks really fishy to me. Is it related to this issue? > > My guess is not: more likely to be a newly-introduced compiler invariant > breakage somewhere. (The char-equal bug simply means that some > non-ascii characters are not treated as case-insensitively equal when > they should be). But I'll commit that fix and then we'll see. OK, so it's now committed. On the assumption that it doesn't fix this compiler problem in cl-l10n, could I have a recipe to reproduce it locally? Thanks, Christophe |
From: Attila L. <att...@gm...> - 2013-05-27 10:39:16
Attachments:
x.lisp
|
please find a file attached that contains a standalone function that reproduces the error when compiled. it involves inlining. hth, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Programs must be written for people to read, and only incidentally for machines to execute.” — Abelson & Sussman, SICP, preface to the first edition |
From: Christophe R. <cs...@ca...> - 2013-05-27 10:57:05
|
Attila Lendvai <att...@gm...> writes: > please find a file attached that contains a standalone function that > reproduces the error when compiled. it involves inlining. Thanks! It does involve inlining, and some other oddities. Replacing the call to (values) in the peek local function with #\Null removes the compiler error, perhaps unsurprisingly; replacing it with nil also removes the error, which is more surprising. I'll be enjoying the sunshine on a public holiday a bit today, but thank you for the test case. Cheers, Christophe |
From: Paul K. <pk...@gm...> - 2013-05-27 22:55:12
|
Christophe Rhodes wrote: > Attila Lendvai<att...@gm...> writes: > >> please find a file attached that contains a standalone function that >> reproduces the error when compiled. it involves inlining. > > Thanks! It does involve inlining, and some other oddities. Replacing > the call to (values) in the peek local function with #\Null removes the > compiler error, perhaps unsurprisingly; replacing it with nil also > removes the error, which is more surprising. I'll be enjoying the > sunshine on a public holiday a bit today, but thank you for the test > case. Thank you! Fixed in 17dd0a1 (Compute single-value-type correctly in the absence of required values). We've managed to cope with computing the type of multiple-value expressions incorrectly in single-value contexts for at least a decade… and only noticed now. It's certainly proving to be an interesting month. Paul Khuong |