From: Nikodemus S. <nik...@ra...> - 2008-02-08 18:19:54
|
On 2/6/08, Christophe Rhodes <cs...@ca...> wrote: > I think I agree with this, but I strongly disagree with the way that > you're proposing to implement it: there is nothing more annoying to me > than to find that the system has "intelligently" hidden some > information which would have been useful to me, which it could have > told me about, but which I have no way of reconstructing. > > I would be entirely happy with some clever slime feature which > selectively cleaned the printing of backtraces, preferably togglable > on a single keystroke, but I want to register my opposition to removal > of potentially significant information. This isn't really addressed > just to you, Atilla; I've just read > clean-xep/clean-&more-processor/frame-call, and I don't really like it > as it currently is in SBCL -- I think that the > *show-entry-point-details* default is wrong. (I don't mind > reformatting of information, but outright removal to the point that it > cannot be deduced is annoying). I'm not entirely sure what you mean by this. I certainly won't defend the not-very-pretty-implementation, but I don't see how information is being "removed to the point that it cannot be deduced", since the unexpurgated version is there for the asking. > My preferred way of addressing this would be to work on slime's > DEFIMPLEMENTATION PRINT-FRAME for sbcl; I think it would be very > reasonable for that to bind *show-entry-point-details* to nil by > default, or to do some other frame printing entirely. While sbcl-swank.lisp is not very shy when it comes to internals, I would prefer to provide this from within SBCL itself. (Calling SB-DEBUG:DWIM-PRINT-FRAME-CALL instead of PRINT-FRAME-CALL in Swank is fine -- but implementing the frame cleaning inside Swank seems just wrong.) While I don't feel terribly strongly about the default value of *SHOW-ENTRY-POINT-DETAILS*, I do have to say that as long as *DEBUGGER-BEGINNER-HELP-P* is T by default I don't see the point of _not_ cleaning things like this: ((SB-C::HAIRY-ARG-PROCESSOR READ-CHAR) #<SB-SYS:FD-STREAM for "standard input" {117488E9}> NIL #:EOF-OBJECT #<unused argument>) into this: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {117488E9}> NIL #:EOF-OBJECT #<unused argument>) I wrote: > Verbosity: > > 0: #<FRAME> > 1: default -- maximally cleaned frames > 2: don't clean actual function names (right now just PCL stuff) > 3: don't clean entry point details but on reflection I think TRT is to add keyword arguments to PRINT-FRAME-CALL -- akin to WRITE. If we in the future come up with new things to toggle in frame printing, cramming them into a single verbosity scale will just be painful. Cheers, -- Nikodemus |