Custom Query (1030 matches)

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

Hi,

It looks like there's a mismatched #ifndef/#endif pair in ccl/lisp-kernel/lisp-debug.c for Windows here:

    void
    redirect_debugger_io()
    {
    #ifndef WINDOWS
      if (1 || !isatty(fileno(dbgin))) {
        int fd = open("/dev/tty", O_RDWR);
        if (fd >=0) {
          dbgin=fdopen(fd,"r");
          open_debug_output(fd);
        }
    #endif   <--- too soon?
      }
    }

This causes the build to fail with:

x86_64-w64-mingw32-gcc -include ../platform-win64.h -c ../lisp-debug.c -DWIN_64 -DWINDOWS -D_REENTRANT -DX86 -DX8664 -D_GNU_SOURCE -DHAVE_TLS -DEMUTLS -DTCR_IN_GPR -DSVN_REVISION="16387" -g -O2 -Wno-format  -m64 -o lisp-debug.o
../lisp-debug.c:234:1: error: expected identifier or '(' before '}' token
 }
 ^
Makefile:74: recipe for target 'lisp-debug.o' failed
make: *** [lisp-debug.o] Error 1

I think the #endif just needs to come after the subsequent }. After moving it the build seems to succeed for me.

Thanks,

Jared

After doing (rebuild-ccl :full t) on an OS X 10.11 system, (require 'cocoa) will fail by crashing into the lisp kernel debugger. A slightly simpler test case is (require 'objc-support), but that doesn't fully exercise things.

As I mentioned earlier today, I believe that this is (at least in part) because Objective-C isa pointers are not necessarily pointers any more.

Starting the lisp with the environment variable OBJC_DISABLE_NONPOINTER_ISA set to YES will enable the (require 'cocoa) to succeed.

$ env OBJC_DISABLE_NONPOINTER_ISA=YES ccl

(I found this out on ​http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html)