I hunted down a few of the places in the source where these excessively
verbose messages were being produced. I can provide a patch file, if desired.
These worked for me.
;;;-----------------------------------
REGARDING: DEBUG (type H for help) -- (spread out over too many lines).
;;; /usr/local/lisp/cmucl/src/code/debug.lisp:
(defun internal-debug ()
(let ((*in-the-debugger* t)
(*read-suppress* nil))
(unless (typep *debug-condition* 'step-condition)
(clear-input *debug-io*)
(format *debug-io* "~2&Debug (type H for help)~2%")) <--------
#-mp (debug-loop)
#+mp (mp:without-scheduling (debug-loop))))
SUGGESTION: Remove the line entirely, use fewer newlines, or create a variable
in ext: to allow the user to stop it from printing.
-----------------------------------
REGARDING: RESTARTS: -- (extra lines above it)
;;; /usr/local/lisp/cmucl/src/code/debug.lisp:
(defun show-restarts (restarts &optional (s *error-output*))
(when restarts
(format s "~&Restarts:~%") <----------------------
(let ((count 0)
(names-used '(nil))
(max-name-len 0))
(dolist (restart restarts)
(let ((name (restart-name restart)))
(when name
(let ((len (length (princ-to-string name))))
(when (> len max-name-len)
(setf max-name-len len))))))
(unless (zerop max-name-len)
(incf max-name-len 3))
(dolist (restart restarts)
(let ((name (restart-name restart)))
(cond ((member name names-used)
(format s "~& ~2D: [EMAIL PROTECTED]" count max-name-len restart))
(t
(format s "~& ~2D: [~VA] ~A~%"
count (- max-name-len 3) name restart)
(push name names-used))))
(incf count)))))
SUGGESTION: Remove ~& from the format directive.
-----------------------------------
REGARDING: Python version 1.1, VM Version etc..... during compilation
;;; /usr/local/lisp/cmucl/src/compiler/main.lisp
;;; Print some junk at the beginning and end of compilation.
;;;
(defun start-error-output (source-info)
(declare (type source-info source-info))
(compiler-mumble "~2&; Python version ~A, VM version ~A on ~A.~%" <----
compiler-version (backend-version *backend*)
(ext:format-universal-time nil (get-universal-time)
:style :government
:print-weekday nil
:print-timezone nil))
(dolist (x (source-info-files source-info))
(compiler-mumble "; Compiling: ~A ~A~%" <---------------
(namestring (file-info-name x))
(ext:format-universal-time nil (file-info-write-date x)
:style :government
:print-weekday nil
:print-timezone nil)))
(compiler-mumble "~%") <-------------------------
(undefined-value))
(defun finish-error-output (source-info won) <--------------
(declare (type source-info source-info))
(compiler-mumble "~&; Compilation ~:[aborted after~;finished in~] ~A.~&"
won
(elapsed-time-to-string
(- (get-universal-time)
(source-info-start-time source-info))))
(undefined-value))
SUGGESTION: I suppose it is because of some bootstrapping issue that setting
*compile-verbose* has no effect. I suggest: Remove the first compiler-mumble
("Python version...") entirely. In the second, don't bother with the time.
Remove (compiler-mumble "~%"). Remove finish-error-output entirely.
-----------------------------------
REGARDING: Excessive newlines before errors.
/usr/local/lisp/cmucl/src/code/:
(defun print-simple-error (condition stream)
(format stream "~&~@<Error in function ~S: ~3i~:_~?~:>" <----------------
(condition-function-name condition)
(simple-condition-format-control condition)
(simple-condition-format-arguments condition)))
SUGGESTION: Remove ~& Also, warnings are introduced with "Warning:". Perhaps
this should use "Error:"
-----------------------------------
REGARDING: Inconsistency in error messages.
Most error messages begin with "Error" but the messages in PCL do not. (but
see above)
SUGGESTION: Add "Error:" in PCL error messages.
-----------------------------------
REGARDING: Default values of global variables related to verbosity.
The current settings might be nice for cmucl developers, but the rest of us
(who are also less likely to know about these) probably don't want all that
stuff. I suggest:
(defvar *gc-verbose* nil) ; In ./code/gc.lisp or ./code/gengc.lisp
(defvar ext::*top-level-auto-declare* t) ; In ./code/eval.lisp
(defvar debug::*debug-print-current-frame* nil) ; In ./code/debug/lisp (and
make it external in ext:).
-- Peter
On Monday 13 October 2003 09:51, Raymond Toy wrote:
> >>>>> "Peter" == Peter Denno <[EMAIL PROTECTED]> writes:
>
> Peter> ;;;============== EXAMPLE 1 - break on error ===============
> Peter> Particularly I was referring to the stuff beginning below with
> "starting here ---> ": (1) Printing the top of the stack seems redundant
> with the error Peter> printed before the "Restarts:". And I can get that
> information easy. (2) Peter> "Debug (type H for Help)" - isn't it enough
> that I have the debugger prompt?
>
> I think it that line is useful for someone unfamiliar with CMUCL's
> debugger.
>
> Peter> No matching method for the generic function
> Peter> #<STANDARD-GENERIC-FUNCTION XML-QUERY-DATA-MODEL:CHILDREN (5)
> {28649939}>, Peter> when
> Peter> called with arguments (NIL).
> Peter> [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
>
> Peter> Restarts:
> Peter> 0: [CONTINUE] Retry call to :FUNCTION.
> Peter> 1: [ABORT ] Return to Top-Level.
>
> Peter> starting here ---------->
>
> Peter> Debug (type H for help)
>
> Peter> ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg>
> #<unused-arg> Peter> #<STANDARD-GENERIC-FUNCTION
> XML-QUERY-DATA-MODEL:CHILDREN (5) {28649939}> Peter> (NIL))
> Peter> Source:
> Peter> ; File: target:pcl/braid.lisp
>
> Peter> ; File has been modified since compilation:
> Peter> ; target:pcl/braid.lisp
> Peter> ; Using form offset instead of character position.
> Peter> (CERROR "Retry call to ~S."
> Peter> 'NO-APPLICABLE-METHOD-ERROR
> Peter> :FUNCTION
> Peter> GENERIC-FUNCTION
> Peter> ...)
> Peter> <-------- ending here
>
> Yes, this is a bit verbose and I do find it somewhat annoying.
>
> Peter> ;;;============== EXAMPLE 2 -- compilation
> ====================== Peter> Since you brought up compiler output...
>
> Peter> ; Python version 1.1, VM version Intel x86 on 10 OCT 03 08:41:03
> pm. Peter> ... That's not really useful. Maybe it could be said once at
> start-up.
>
> Peter> ; Compiling:
> Peter>
> /home/pdenno/sis/repo/source/modelAnalysis/readers/xsd-reader.lisp 10 OCT
> 03 Peter> 08:34:05 pm
> Peter> ... Putting the date and time here seems overkill.
>
> Peter> ; Compilation finished in 0:00:01.
> Peter> ... as does this. If I cared about time, I'd time it myself.
>
> A bit verbose. Easy to change, but you have to hack the sources.
>
> Peter> ;;;============== EXAMPLE 3 -- compilation
> ========================= Peter> (1) Here I can (declaim (optimize
> (ext:inhibit-warnings 3))), but that isn't Peter> sticky (I can't just put
> it in my init.lisp and be done with it). (2) We get
>
> I think it would be a bad idea to turn off these warnings globally.
>
> Peter> a similar warnings when evaluating an undeclared global at top
> level. I know Peter> I can get rid of it, with (setf
> ext:*top-level-auto-declare* t), but I Peter> wouldn't mind the message if
> it took up 1 line. However as it is, useful Peter> stuff is scrolling off
> the screen.
>
> That could probably be cleaned up to take one or 2 lines.
>
> Peter> ; Loading
> #p"/opt/cl-binary/model-analysis/cmufasl/readers/xsd-reader.x86f".
>
> Peter> ;
> Peter> ;
> Peter> ; File:
> /home/pdenno/sis/repo/source/modelAnalysis/readers/xsd-reader.lisp
>
> Peter> ; In: DEFMETHOD |Element-Constructor| (XSD-CONSTRUCTION-CONTEXT
> T T T)
>
> Peter> ; (SETF *EEE* ELEM)
> Peter> ; ==>
> Peter> ; (SETQ *EEE* ELEM)
> Peter> ; Warning: Undefined variable *EEE*
> Peter> ; ;
>
> Peter> ; Warning: This variable is undefined:
> Peter> ; *EEE*
> Peter> ;
>
> Peter> ; Compilation unit finished.
> Peter> ; 2 warnings
>
> Peter> ... Why is that 2 warnings? It says the same thing twice for one
> line of code.
>
> The heuristics on when and how to print warnings needs work here I
> guess.
>
> Peter> Then tells me there were two of them.
>
> Well, if you compile cmucl, you'll see that compiling pathname.lisp
> produces:
>
> ; Warning: 37973 more uses of undefined type STREAM:FILE-SIMPLE-STREAM.
>
> Fortunately, only 2 cases are actually printed out. :-)
>
> Peter> The above sounds like lots of whining. I don't mean to complain
> -- you guys Peter> are doing a great job -- its just hard to find the
> relevant stuff in all this Peter> output. I'd try to help, but just
> compiling cmucl is a pretty tough job. I Peter> was successful at one time,
> but not lately
>
> Consider using Pierre Mai's build scripts using a snapshot build. You
> should be able to build it fairly easily.
>
> Overall, since I run cmulisp inside of emacs via ilisp, things
> scrolling off don't bother me much.
>
> Ray
--
Best Regards,
- Peter
Peter Denno
National Institute of Standards and Technology,
Manufacturing System Integration Division,
100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595
Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694
