;;; -*- Mode:Lisp; Readtable:CL; Package:USER; Base:10; Patch-File:T -*- ;;; Patch file for System version 126.100 ;;; Reason: ;;; Make LISP:WARN work with *BREAK-ON-WARNINGS*. Was blowing out with problem within ;;; SIGNAL-CONDITION. ;;; ;;; This is a quick and dirty fix -- probably not ultimate. Problems: ;;; ;;; 1. Works by mixing FERROR into COMMON-LISP-WARNING flavor. This seems ;;; like some kind of breach of categories, but using the WARNING flavor ;;; alone doesn't provide any error handler at all. (That is what you would ;;; want for a warning that could never break!) ;;; ;;; 2. WARN does not really work like the existing doc string, which makes a distinction ;;; between *BREAK-ON-WARNINGS* and EH:*SIGNAL-ON-WARNINGS*. The code does not make ;;; a distinction, maybe the error handler does in SIGNAL-CONDITION, but this is not ;;; obvious. Let's leave this for further research. ;;; ;;; --Keith & SMH ;;; Written 3-Oct-88 14:59:17 by keith (Keith Corbett) at site Gigamos Cambridge ;;; while running on Breaking Glass from band 3 ;;; with Experimental System 126.99, Experimental ZWEI 126.14, Experimental ZMail 74.6, Experimental Local-File 76.0, Experimental File-Server 25.0, Experimental Lambda-Diag 18.0, Experimental Unix-Interface 15.0, Experimental Tape 26.4, microcode 1762, SDU Boot Tape 3.14, SDU ROM 103. ; From modified file DJ: L.DEBUGGER; CONDITION-FLAVORS.LISP#13 at 3-Oct-88 14:59:17 #10R EH#: (COMPILER-LET ((*PACKAGE* (PKG-FIND-PACKAGE "EH"))) (COMPILER::PATCH-SOURCE-FILE "SYS: DEBUGGER; CONDITION-FLAVORS  " (defflavor common-lisp-warning () (format-condition-mixin warning ferror)) (defmethod (common-lisp-warning :case :proceed-asking-user :no-action) (continuation ignore) "Simply proceed from warning." (funcall continuation :no-action)) (compile-flavor-methods common-lisp-warning) (defun warn (format-string &rest format-args) "This is the Common Lisp WARN function. FORMAT-STRING and FORMAT-ARGS are used to construct a warning message which is output to *ERROR-OUTPUT*. WARN always returns NIL. Normally, WARN simply produces this output and returns NIL, without using the condition-handling system. However, there are two variables which can be used to modify its behavior. *BREAK-ON-WARNINGS*, if not NIL, makes WARN behave like enter a debugger breakpoint. A message will be printed, and the debugger is entered. This can give one a chance to inspect the state of a computation at the point when a warning is generated. EH:*SIGNAL-ON-WARNINGS*, if not NIL (as it is by default), causes WARN to signal an EH:COMMON-LISP-WARNING condition. This is to permit a sophisticated system to produce its own warnings, or simply to log them. If this condition is not handled, then WARN behaves normally (it prints the error message itself); otherwise, it simply returns NIL. If *BREAK-ON-WARNINGS* is not NIL, then the condition IS signaled -- it is the default interactive handler (which is what decides when to call the Lisp debugger) which decides whether to break, by looking at both the type of the condition and *BREAK-ON-WARNINGS*." (check-type format-string string) (unless (and (or *signal-on-warnings* *break-on-warnings*) (signal-condition (make-condition 'common-lisp-warning :format-string format-string :format-args format-args :proceed-types '(:no-action)) '(:no-action))) (format *error-output* "~&>>WARNING: ~?~&" format-string format-args)) nil) ))