With cvs Slime on 2005-02-01, invoking C-c RET on piece of my code generates the following output (with lots of code snipped):
(let () (flet ((#:handler-show-message-11502 (c) (popup-message ...))) (handler-case (let ((#:data-11500 (let ((data (apply ... (append (list x-var y-var) (when ...))))) (if log-p (apply #'%ensure-log-cases data (list x-var y-var)) ...))) (#:original-vars-11501 (when ...)) ...) (if trellis-display-spec (do-trellis-plot :scatterplot icon (:ftn ...) plot (:ftn ...) trellis-display-spec nil log-p #:data-11500 (x-var y-var) #:original-vars-11501) ...)) ...)))
With the latest cvs Slime on 2005-03-14, invoking C-c RET on the same piece of code generates the following output:
(let () (flet ((#1=#:handler-show-message-11502 (c) (popup-message ...))) (handler-case (let ((#2=#:data-11500 (let ((data (apply ... (append (list . #3=(x-var y-var)) (when ...))))) (if log-p (apply #'%ensure-log-cases data (list . #3#)) ...))) (#4=#:original-vars-11501 (when ...)) ...) (if trellis-display-spec (do-trellis-plot :scatterplot icon #5=(:ftn ...) plot #6=(:ftn ...) trellis-display-spec nil log-p #2# #3# #4#) ...)) ...)))
I much prefer the way the 2005-02-01 Slime displays the macroexpanded code. Is there any way to tell Slime NOT to use a bunch of sharpsigns and numbers when displaying the output from C-c RET? Using sharpsigns and numbers make the expanded code hard to read. My memory sucks and I have to search back and forth for a particular definition of a sharpsign reference when there are more than one. There are 7 such sharpsign references in the C-c RET output of this particular piece of code. To make the matters worse, doing a C-c RET on (DO-TRELLIS-PLOT ...) in the C-c RET output from the latest cvs Slime will throw me into the debugger:
Reader error at 556 on #<String-Input Stream>: Object is not labelled #2# [Condition of type READER-ERROR]
Doing the same thing with the 2005-02-01 Slime is no problem.
Best,
-cph
The #<number>=<object> ... #<number># syntax is a result of setting a printer variable, such as *PRINT-CIRCLE* to some non-NIL value.
On Mon, 14 Mar 2005 16:26:28 -0800, Chisheng Huang cph@chi-square-works.com wrote:
With cvs Slime on 2005-02-01, invoking C-c RET on piece of my code generates the following output (with lots of code snipped):
<snip>
With the latest cvs Slime on 2005-03-14, invoking C-c RET on the same piece of code generates the following output:
(let () (flet ((#1=#:handler-show-message-11502 (c)
<snip>
The #<number>=<object> ... #<number># syntax is a result of setting a printer variable, such as *PRINT-CIRCLE* to some non-NIL value. It gives the Lisp printer the ability to print (possibly readably) objects which have circular structure (e.g. a linked-list node with a pointer to itself) without looping indefinitely (which, you will agree, should probably be avoided).
However, unless you're working with self-referencing data structures, having *PRINT-CIRCLE* set to something non-NIL can be more of an annoyance than anything else.
So, (1) are you sure you haven't set *PRINT-CIRCLE* to some non-NIL value? (2) Try setting it to NIL and re-running C-c RET. Does that help?
The #<number>=<object> ... #<number># syntax is a result of setting a printer variable, such as *PRINT-CIRCLE* to some non-NIL value. It gives the Lisp printer the ability to print (possibly readably) objects which have circular structure (e.g. a linked-list node with a pointer to itself) without looping indefinitely (which, you will agree, should probably be avoided).
However, unless you're working with self-referencing data structures, having *PRINT-CIRCLE* set to something non-NIL can be more of an annoyance than anything else.
So, (1) are you sure you haven't set *PRINT-CIRCLE* to some non-NIL value? (2) Try setting it to NIL and re-running C-c RET. Does that help?
I only mess with *PRINT-CIRCLE* when I'm printing circular data structures.
Another Slime user kindly sent me the following message posted to the mailing list a few days ago:
... and I wonder if the macroexpand could bind *print-circle* to nil so that the macroexpansion command does not show a sexp full of #n= and #n# that I find harder to understand. OTOH, it allows us to see structure sharing in the code but that doesn't seem to be terribly useful...
You can do something like this:
(setf (cdr (assoc '*print-circle* swank:*swank-pprint-bindings*)) nil)
I haven't noticed #n# problems with CMUCL but I don't macroexpand all that often.
It never occurs to me that Slime might rebind *PRINT-CIRCLE* dynamically behind my back when doing macro expansion. By the way, I'm using CMUCL.
Thanks.
-cph
-
Chisheng Huang -
Denis Bueno