made debugger handle errors in printing *DEBUG-CONDITION*

[sbcl.git] / doc / sbcl.1

diff --git a/doc/sbcl.1 b/doc/sbcl.1
index 4bf0893..6ec7939 100644 (file)
--- a/doc/sbcl.1
+++ b/doc/sbcl.1
@@ -227,12 +227,14 @@ doc strings and online help built into the SBCL executable
 .SH SYSTEM REQUIREMENTS
 
 Unlike its distinguished ancestor CMU CL, SBCL is currently only
-supported on X86. Linux and FreeBSD are currently available. It would
-probably be straightforward to port the CMU CL support for Alpha or
-SPARC as well, or to OpenBSD or NetBSD, but at the time of this
-writing no such efforts are underway.
-
-As of version 0.6.3, SBCL requires on the order of 16Mb to run. In
+supported on X86. Linux, FreeBSD, and OpenBSD ports are currently
+available. It would probably be straightforward to port the CMU CL
+support for SPARC or Alpha, or to port to NetBSD. Some work on a
+port to the Alpha has been reported on the mailing lists; check
+the archives (available from the home page at
+<http://sbcl.sourceforge.net/>) for information.
+
+As of version 0.6.8, SBCL requires on the order of 16Mb to run. In
 some future version, this number could shrink significantly, since
 large parts of the system are far from execution bottlenecks and could
 reasonably be stored in compact byte compiled form. (CMU CL does this
@@ -283,9 +285,9 @@ The system doesn't deal well with stack overflow.
 .TP 3
 \--
 The SBCL system overcommits memory at startup. On typical Unix-alikes
-like Linux and *BSD, this can cause other processes to be killed
-randomly (!) if the SBCL system turns out to use more virtual memory
-than the system has available for it.
+like Linux and *BSD, this means that if the SBCL system turns out to
+use more virtual memory than the system has available for it, other
+processes to be killed randomly (!)
 .PP
 
 The facility for dumping a running Lisp image to disk gets confused
@@ -295,9 +297,9 @@ high-water mark). Moreover, when the file is loaded, it confuses the
 GC, so that thereafter memory usage can never be reduced below that
 level.
 
-By default, the compiler is overaggressive about static typing,
-assuming that a function's return type never changes. Thus compiling
-and loading a file containing
+The compiler is overaggressive about static typing, assuming that a
+function's return type never changes. Thus compiling and loading a
+file containing
 (DEFUN FOO (X) NIL)
 (DEFUN BAR (X) (IF (FOO X) 1 2))
 (DEFUN FOO (X) (PLUSP X))
@@ -317,9 +319,6 @@ never compiled code to check the declaration.
 
 The TRACE facility can't be used on some kinds of functions.
 
-The profiler is flaky, e.g. sometimes it fails by throwing a
-signal instead of giving you a result.
-
 SYMBOL-FUNCTION is much slower than you'd expect, being implemented
 not as a slot access but as a search through the compiler/kernel
 "globaldb" database.
@@ -359,8 +358,9 @@ of the implementation of compound types like (ARRAY * 1).)
 
 .SH SUPPORT
 
-Please send bug reports or other information to
-<william.newman@airmail.net>.
+Various information about SBCL is available at
+<http://sbcl.sourceforge.net/>. The mailing lists there are the
+recommended place to look for support.
 
 .SH DISTRIBUTION