Custom Query (1030 matches)

Open cocoa-editor.lisp. Type m-x query replace <return> cocoa <return> carbon <return>. Type space. Note that the displayed text doesn't change, but the cursor moves to a location that's one off from the location of next occurrence of "cocoa".

I get this fairly often when editing a file with lot of character constants, like format.lisp. In this case I was typing on a fresh line in the middle of a function: " (format scan-check #" and then I typed a backslash, but it crashed before the backslash got displayed. Below is the entire contents of the AltConsole window that popped up:

*** Error in event process: Array index 35 out of bounds for "  (format-scan-check #\\" .

  0: (:INTERNAL GUI::|-[HemlockTextView drawRect:]|) at pc +149
     Arguments: (#:G25462)
       #:G25462: #<SIMPLE-ERROR Array index 35 out of bounds for "  (format-scan-check #\\" . #x300041E3CEAD>
     Local bindings:
       #:COMPILER-VAR: (NIL)
       #:G25459: #<A Foreign Pointer [stack-allocated] #x7FFF5FBFC8A0>

  1: SIGNAL at pc +981
     Arguments: (CONDITION &REST CCL::ARGS)
       CONDITION: #<SIMPLE-ERROR Array index 35 out of bounds for "  (format-scan-check #\\" . #x300041E3CEAD>
       CCL::ARGS: NIL
     Local bindings:
       CCL::%HANDLERS%: ((ERROR) (ERROR))
       CCL::TAG: #<SIMPLE-ERROR Array index 35 out of bounds for "  (format-scan-check #\\" . #x300041E3CEAD>
       CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS*
       CCL::FN: #<COMPILED-LEXICAL-CLOSURE (:INTERNAL GUI::|-[HemlockTextView drawRect:]|) #x493DBF>

  2: %ERROR at pc +117
     Arguments: (CONDITION CCL::ARGS CCL::ERROR-POINTER)
       CONDITION: #<SIMPLE-ERROR Array index 35 out of bounds for "  (format-scan-check #\\" . #x300041E3CEAD>
       CCL::ARGS: (35 "  (format-scan-check #\\")
       CCL::ERROR-POINTER: 558478

  3: (:INTERNAL CCL::%XERR-DISP) at pc +2485
     Arguments: ()
     Local bindings:
       CCL::FRAME-PTR: 558478
       CCL::FN: #<Compiled-function HEMLOCK-INTERFACE:LINE-CHARACTER #x30004140F18F>
       CCL::OP0: 205
       CCL::OP1: 200
       CCL::OP2: 254
       CCL::SKIP: -1
       CCL::XP: #<A Foreign Pointer #x7FFF5FBFC540>
       CCL::XCF: #<A Foreign Pointer #x442C70>

  4: FUNCALL-WITH-ERROR-REENTRY-DETECTION at pc +181
     Arguments: (CCL::THUNK)
       CCL::THUNK: #<COMPILED-LEXICAL-CLOSURE (:INTERNAL CCL::%XERR-DISP) #x493CCF>
     Local bindings:
       COUNT: 0
       CCL::*ERROR-REENTRY-COUNT*: 0

  5: CCL::%XERR-DISP at pc +501
     Arguments: (#:G128837)
       #:G128837: 17591849973666
     Local bindings:
       #:G128847: #<A Foreign Pointer [stack-allocated] #x7FFF5FBFBD10>
       CCL::XCF: #<A Foreign Pointer #x442C70>
       CCL::XP: #<A Foreign Pointer #x7FFF5FBFC540>
       #:G128848: #<COMPILED-LEXICAL-CLOSURE (:INTERNAL CCL::%XERR-DISP) #x493CCF>

  6: %PASCAL-FUNCTIONS% at pc +397
     Arguments: (CCL::INDEX CCL::ARGS-PTR-FIXNUM)
       CCL::INDEX: 2
       CCL::ARGS-PTR-FIXNUM: 17591849973666
     Local bindings:
       CCL::LISP-FUNCTION: #<Compiled-function CCL::

(it just ends here)

Hi,

I believe there is a new bug on CCL related to reader tables. In particular it appears that doing a copy-readtable no longer produces a deep enough copy. The following small test code illustrates the problem:

(defparameter *my-readtable* (copy-readtable))

(defun my-sharp-dot-read (stream char n)
  (declare (ignore char n stream))
  (format t "My sharp-dot-read invoked!~%"))

(let ((*readtable* *my-readtable*))
  (set-dispatch-macro-character #\# #\. 'my-sharp-dot-read))

(format t "Are they the same?  ~a~%"
        (eq (get-dispatch-macro-character #\# #\. *readtable*)
            (get-dispatch-macro-character #\# #\. *my-readtable*)))

I believe this should print:

    Are they the same?  NIL

And indeed this is what gets printed on a recent copy of SBCL and also on the slightly older version of CCL: CCL 1.11-dev-r16394M-trunk (LinuxX8664).

However, the bleeding-edge CCL, Version 1.11-dev-r16446M-trunk (LinuxX8664), instead prints:

    Are they the same?  T

I can see from the commit log that there has been some recent work on reader macros, so this is perhaps related to those recent changes.

Thanks!

Jared