0.7.5.22:
[sbcl.git] / doc / sbcl.1
index e16b6ee..e28d861 100644 (file)
@@ -70,8 +70,8 @@ after the MacLisp compiler, people will tell you that Lisp is an
 interpreted language. Ignore them.)
 
 SBCL aims for but has not yet reached compliance with the ANSI
-standard for Common Lisp. More information on this is available in the
-BUGS section below.
+standard for Common Lisp. More information about this is available in
+the BUGS section below.
 
 SBCL also includes various non-ANSI extensions.
 
@@ -270,8 +270,9 @@ options.
 .TP 3
 .B --noinform
 Suppress the printing of any banner or other informational message at
-startup. (This makes it easier to write Lisp programs which work in
-Unix pipelines. See also the "--noprogrammer" and "--noprint" options.)
+startup. (This makes it easier to write Lisp programs which work
+cleanly in Unix pipelines. See also the "--noprint" and
+"--disable-debugger" options.)
 .PP
 
 In the future, runtime options may be added to control behavior such
@@ -301,21 +302,32 @@ read-eval-print loop on standard input, evaluate the command given.
 More than one --eval option can be used, and all will be executed, in
 the order they appear on the command line.
 .TP 3
+.B --load <filename>
+This is equivalent to --eval '(load "<filename>")'. The special
+syntax is intended to reduce quoting headaches when invoking SBCL
+from shell scripts.
+.TP 3
 .B --noprint
 When ordinarily the toplevel "read-eval-print loop" would be executed,
 execute a "read-eval loop" instead, i.e. don't print a prompt and
 don't echo results. Combined with the --noinform runtime option, this
-makes it easier to write Lisp "scripts" which work in Unix pipelines.
+makes it easier to write Lisp "scripts" which work cleanly in Unix
+pipelines.
 .TP 3
-.B --noprogrammer
+.B --disable-debugger
+This is equivalent to --eval '(sb-ext:disable-debugger)'.
 By default, a Common Lisp system tries to ask the programmer for help
 when it gets in trouble (by printing a debug prompt on *DEBUG-IO*).
 However, this is not useful behavior for a system running with no
 programmer available, and this option tries to set up more appropriate
-behavior for that situation. Thus we set *DEBUG-IO* to send its
-output to *ERROR-OUTPUT*, and to raise an error if any input is
-requested from it; and we set *DEBUGGER-HOOK* to output a backtrace,
-then exit the process with a failure code.
+behavior for that situation. This is implemented by modifying special
+variables: we set *DEBUG-IO* to send its output to *ERROR-OUTPUT*, and
+to raise an error if any input is requested from it, and we set
+*DEBUGGER-HOOK* to output a backtrace, then exit the process with a
+failure code. Because it is implemented by modifying special variables,
+its effects persist in .core files created by SB-EXT:SAVE-LISP-AND-DIE.
+(If you want to undo its effects, see the SB-EXT:ENABLE-DEBUGGER
+command.)
 .PP
 
 Regardless of the order in which --sysinit, --userinit, and --eval
@@ -340,10 +352,10 @@ chance to see it.
 
 .SH SYSTEM REQUIREMENTS
 
-Unlike its distinguished ancestor CMU CL, SBCL currently runs only on X86
-(Linux, FreeBSD, and OpenBSD) and Alpha (Linux). For information on 
-other ongoing ports, see the sbcl-devel mailing list, and/or the
-web site.
+Unlike its distinguished ancestor CMU CL, SBCL currently runs only on
+X86 (Linux, FreeBSD, and OpenBSD), Alpha (Linux), and SPARC (Linux).
+For information on other ongoing and possible ports, see the
+sbcl-devel mailing list, and/or the web site.
 
 SBCL requires on the order of 16Mb RAM to run on X86 systems. 
 
@@ -380,17 +392,13 @@ This section attempts to list the most serious and long-standing bugs.
 For more detailed and current information on bugs, see the BUGS file
 in the distribution.
 
-It is possible to get in deep trouble by exhausting
+It is possible to get in deep trouble by exhausting 
 memory. To plagiarize a sadly apt description of a language not
 renowned for the production of bulletproof software, "[The current
 SBCL implementation of] Common Lisp makes it harder for you to shoot
 yourself in the foot, but when you do, the entire universe explodes."
 .TP 3
 \--
-The system doesn't deal well with stack overflow. (It tends to cause
-a segmentation fault instead of being caught cleanly.)
-.TP 3
-\--
 Like CMU CL, the SBCL system overcommits memory at startup. On typical
 Unix-alikes like Linux and FreeBSD, this means that if the SBCL system
 turns out to use more virtual memory than the system has available for
@@ -412,7 +420,7 @@ Some things are implemented very inefficiently.
 .TP 3
 \--
 Multidimensional arrays are inefficient, especially
-multidimensional arrays of floating point numbers
+multidimensional arrays of floating point numbers.
 .TP 3
 \--
 The DYNAMIC-EXTENT declaration isn't implemented at all, not even
@@ -426,18 +434,21 @@ SBCL implementation of CLOS doesn't do some important known
 optimizations.)
 .TP 3
 \--
-SBCL, like most implementations of Common Lisp, has trouble
-passing floating point numbers around efficiently, because
-they're larger than a machine word. (Thus, they get "boxed" in
+SBCL, like most (maybe all?) implementations of Common Lisp on 
+stock hardware, has trouble
+passing floating point numbers around efficiently, because a floating
+point number, plus a few extra bits to identify its type,
+is larger than a machine word. (Thus, they get "boxed" in
 heap-allocated storage, causing GC overhead.) Within
 a single compilation unit,
 or when doing built-in operations like SQRT and AREF,
 or some special operations like structure slot accesses,
 this is avoidable: see the user manual for some
 efficiency hints. But for general function calls across
-the boundaries of compilation units, passing a floating point
-number as a function argument (or returning a floating point
-number as a function value) is a fundamentally slow operation.
+the boundaries of compilation units, passing the result of 
+a floating point calculation
+as a function argument (or returning a floating point
+result as a function value) is a fundamentally slow operation.
 .PP
 
 There are still some nagging pre-ANSIisms, notably
@@ -474,15 +485,19 @@ handled specially by certain type expanders.)
 
 .SH REPORTING BUGS
 
-To report a bug, please send mail to sbcl-help@lists.sourceforge.net
-or sbcl-devel@lists.sourceforge.net.
+To report a bug, please send mail to the mailing lists sbcl-help or
+sbcl-devel. You can find the complete mailing list addresses on the
+web pages, <http://sbcl.sourceforge.net/>. (You may also find fancy
+SourceForge bug-tracking machinery there, but don't be fooled. As of
+2002-07-25 anyway, we don't actively monitor that machinery and just
+haven't been able to figure out how to turn it off.)
 
 As with any software bug report, it's most helpful if you can provide
 enough information to reproduce the symptoms reliably, and if you say
 clearly what the symptoms are. E.g. "There seems to be something wrong
 with TAN of very small negative arguments. When I execute
-(TAN LEAST-NEGATIVE-SINGLE-FLOAT) interactively on sbcl-1.2.3 on my Linux
-4.5 X86 box, I get an UNBOUND-VARIABLE error."
+(TAN LEAST-NEGATIVE-SINGLE-FLOAT) interactively on sbcl-1.2.3 on my
+Linux 4.5 X86 box, I get an UNBOUND-VARIABLE error."
 
 .SH SUPPORT
 
@@ -490,6 +505,24 @@ Various information about SBCL is available at
 <http://sbcl.sourceforge.net/>. The mailing lists there are the
 recommended place to look for support.
 
+.SH FILES
+
+.TP
+.I sbcl
+executable program containing some low-level runtime support and
+a loader, used to read sbcl.core
+.TP
+.I sbcl.core
+dumped memory image containing most of SBCL, to be loaded by the
+'sbcl' executable
+.TP
+.I sbclrc
+optional system-wide startup script (in an etc-ish system
+configuration file directory)
+.TP
+.I .sbclrc
+optional per-user customizable startup script (in user's home directory)
+
 .SH AUTHORS
 
 Dozens of people have made substantial contributions to SBCL and its