Is there a particular reason why SWANK:*SLDB-PRINTER-BINDINGS* binds *PRINT-LINES* to 10 instead of NIL?
This truncates error messages in many cases, for example:
The value #S(SB-C::DEBUG-SOURCE :NAMESTRING "/tmp/file7pJ3qL.lisp" :CREATED 3440074405 :SOURCE-ROOT 0 :START-POSITIONS #(0) :FORM NIL :FUNCTION NIL :COMPILED 3440074405 :PLIST (:EMACS-BUFFER "foo.lisp" :EMACS-DIRECTORY "/tmp/" ..)) [Condition of type TYPE-ERROR]
The most interesting piece of that error message (the expected type) is left out which is unfortune. (Using `C' to inspect the condition works for this particular case, but does not necessarily work to retrieve the crucial information in the general case.)
-T.
* Tobias C. Rittweiler [2009-01-04 17:27+0100] writes:
Is there a particular reason why SWANK:*SLDB-PRINTER-BINDINGS* binds *PRINT-LINES* to 10 instead of NIL?
Some limit seems reasonable to stop the debugger from producing megabytes of output just for the error message. Think of printing the contents of a bitvector. 10 is more or less arbitrary. But what is the maximum length of good error message?
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2009-01-04 17:27+0100] writes:
Is there a particular reason why SWANK:*SLDB-PRINTER-BINDINGS* binds *PRINT-LINES* to 10 instead of NIL?
Some limit seems reasonable to stop the debugger from producing megabytes of output just for the error message. Think of printing the contents of a bitvector. 10 is more or less arbitrary. But what is the maximum length of good error message?
It seems to me that neither *PRINT-RIGHT-MARGIN* nor *PRINT-LINES* affect pretty-printing of a bit vector. At least I can't get it to work.
I'd favor reducing *PRINT-LEVEL* and *PRINT-LENGTH* if necessary but binding *PRINT-LINE* to NIL.
(Alternative would be to provide a keybinding that makes the condition be printed in full.)
-T.
PS:
(defvar *bitv* (make-array '(1000) :element-type 'bit :initial-element 0))
(check-type *bitv* integer)
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2009-01-04 17:27+0100] writes:
Is there a particular reason why SWANK:*SLDB-PRINTER-BINDINGS* binds *PRINT-LINES* to 10 instead of NIL?
Some limit seems reasonable to stop the debugger from producing megabytes of output just for the error message. Think of printing the contents of a bitvector. 10 is more or less arbitrary. But what is the maximum length of good error message?
Ok, the problem is that 22.1.3.6 does not specify that printing of bit vectors involves *PRINT-LENGTH*. The same is true for strings (22.1.3.4.) We could, however, use custom pprint dispatch table entries to do the necessary truncating for us.
If you don't mind going that route, I'll happily do the work.
-T.
* Tobias C. Rittweiler [2009-01-04 22:38+0100] writes:
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2009-01-04 17:27+0100] writes:
Is there a particular reason why SWANK:*SLDB-PRINTER-BINDINGS* binds *PRINT-LINES* to 10 instead of NIL?
Some limit seems reasonable to stop the debugger from producing megabytes of output just for the error message. Think of printing the contents of a bitvector. 10 is more or less arbitrary. But what is the maximum length of good error message?
Ok, the problem is that 22.1.3.6 does not specify that printing of bit vectors involves *PRINT-LENGTH*. The same is true for strings (22.1.3.4.) We could, however, use custom pprint dispatch table entries to do the necessary truncating for us.
If you don't mind going that route, I'll happily do the work.
The output is also limited by a custom stream which throws out from write-string after 1000 chars or so. I don't think that there is another general way to limit the output, because print-object methods can always write directly to the stream whithout going through te pretty printer.
You could just increase the limits. But I think the real problem is that the format of original message. If the error message contains variable length part, that part should probably written at the end.
Helmut.
* Helmut Eller [2009-01-05 08:33+0100] writes:
You could just increase the limits.
Paradoxically, it would also work to reduce *PRINT-LINES*. E.g.: (defstruct foo a b c d e f g i j k l m n o p q r s t) (let ((*print-lines* 5)) (format t "object ~a is no of type bar" (make-foo)))
looks quite readable.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Helmut Eller [2009-01-05 08:33+0100] writes:
You could just increase the limits.
Paradoxically, it would also work to reduce *PRINT-LINES*. E.g.: (defstruct foo a b c d e f g i j k l m n o p q r s t) (let ((*print-lines* 5)) (format t "object ~a is no of type bar" (make-foo)))
looks quite readable.
It won't unfortunately work on the error I pasted in my OP.
-T.
Helmut Eller heller@common-lisp.net writes:
The output is also limited by a custom stream which throws out from write-string after 1000 chars or so. I don't think that there is another general way to limit the output, because print-object methods can always write directly to the stream whithout going through te pretty printer.
From what I see looking at the code, the custom stream is only used for
formatting the backtrace--which I have no problem with.
I, however, maintain my belief that it's a faux-past to truncate the error /message/. Just imagine a random error occurs, you're thrown into sldb, and for whatever reason the slime connection is disconnected. _Very_ valuable information could be lost.
-T.
"Tobias C. Rittweiler" writes:
Ok, the problem is that 22.1.3.6 does not specify that printing of bit vectors involves *PRINT-LENGTH*. The same is true for strings (22.1.3.4.) We could, however, use custom pprint dispatch table entries to do the necessary truncating for us.
I committed this.
-T.
-
Helmut Eller -
Tobias C. Rittweiler