0.6.9.13:

[sbcl.git] / src / code / debug.lisp

diff --git a/src/code/debug.lisp b/src/code/debug.lisp
index a8cb121..b7709e1 100644 (file)
--- a/src/code/debug.lisp
+++ b/src/code/debug.lisp
@@ -637,13 +637,17 @@ reset to ~S."
            (*print-pretty* t)
            (*package* original-package))
 
+       ;; Before we start our own output, finish any pending output.
+       ;; Otherwise, if the user tried to track the progress of
+       ;; his program using PRINT statements, he'd tend to lose
+       ;; the last line of output or so, and get confused.
+       (flush-standard-output-streams)
+
        ;; The initial output here goes to *ERROR-OUTPUT*, because the
        ;; initial output is not interactive, just an error message,
        ;; and when people redirect *ERROR-OUTPUT*, they could
        ;; reasonably expect to see error messages logged there,
        ;; regardless of what the debugger does afterwards.
-       #!+sb-show (sb!conditions::show-condition *debug-condition*
-                                                *error-output*)
        (format *error-output*
               "~2&debugger invoked on condition of type ~S:~%  "
               (type-of *debug-condition*))
@@ -660,11 +664,11 @@ reset to ~S."
        (let (;; FIXME: The first two bindings here seem wrong,
             ;; violating the principle of least surprise, and making
             ;; it impossible for the user to do reasonable things
-            ;; like using PRINT to send output to the program's
-            ;; ordinary (possibly redirected-to-a-file)
-            ;; *STANDARD-OUTPUT*, or using PEEK-CHAR or some such
-            ;; thing on the program's ordinary (possibly also
-            ;; redirected) *STANDARD-INPUT*.
+            ;; like using PRINT at the debugger prompt to send output
+            ;; to the program's ordinary (possibly
+            ;; redirected-to-a-file) *STANDARD-OUTPUT*, or using
+            ;; PEEK-CHAR or some such thing on the program's ordinary
+            ;; (possibly also redirected) *STANDARD-INPUT*.
             (*standard-input* *debug-io*)
             (*standard-output* *debug-io*)
             ;; This seems reasonable: e.g. if the user has redirected
@@ -674,10 +678,11 @@ reset to ~S."
             (*error-output* *debug-io*))
         (unless (typep condition 'step-condition)
           (format *debug-io*
-                  "~%~@<entering the debugger because of ~S~:@_~:@_~
-                   Within the debugger, you can type HELP for help. At ~
-                   any command prompt (inside the debugger or not) you can ~
-                   type (SB-EXT:QUIT) to terminate the SBCL executable.~:@>~2%"
+                  "~%~@<Within the debugger, you can type HELP for help. At ~
+                   any command prompt (within the debugger or not) you can ~
+                   type (SB-EXT:QUIT) to terminate the SBCL executable. ~
+                   The condition which caused the debugger to be entered ~
+                   is bound to ~S.~:@>~2%"
                   '*debug-condition*)
           (show-restarts *debug-restarts* *debug-io*)
           (terpri *debug-io*))
@@ -709,7 +714,7 @@ reset to ~S."
 
 ;;; This calls DEBUG-LOOP, performing some simple initializations
 ;;; before doing so. INVOKE-DEBUGGER calls this to actually get into
-;;; the debugger. SB!CONDITIONS::ERROR-ERROR calls this in emergencies
+;;; the debugger. SB!KERNEL::ERROR-ERROR calls this in emergencies
 ;;; to get into a debug prompt as quickly as possible with as little
 ;;; risk as possible for stepping on whatever is causing recursive
 ;;; errors.