under Emacs. The Emacs "ilisp" mode provides many convenient features,
like command line editing, tab completion, and various kinds of
coupling between Common Lisp source files and the interactive SBCL
-subprocess.
+subprocess, but can be somewhat fragile because it tries to be so
+clever and intimate in its interactions with the Lisp subprocess. In
+case of ilisp problems, running SBCL in the Emacs "shell" mode can a
+useful substitute.
.SH OVERVIEW
(Why doesn't SBCL support more extensions? Why drop all those nice
extensions from CMU CL when the code already exists? This is a
-frequently asked question on the mailing list. In other cases, it's a
+frequently asked question on the mailing list. In some cases, it's a
design philosophy issue: arguably SBCL has done its job by supplying a
stable FFI, and the right design decision is to move functionality
derived from that, like socket support, into separate libraries,
.TP 3
.B --core <corefilename>
Run the specified Lisp core file instead of the default. (See the FILES
-section.) Note that if the Lisp core file is a user-created core file, it may
-run a nonstandard toplevel which does not recognize the standard toplevel
-options.
+section for the standard core, or the system documentation for
+SB-INT:SAVE-LISP-AND-DIE for information about how to create a
+custom core.) Note that if the Lisp core file is a user-created core
+file, it may run a nonstandard toplevel which does not recognize the
+standard toplevel options.
.TP 3
.B --noinform
Suppress the printing of any banner or other informational message at
are stripped out of the command line before the
Lisp toplevel logic gets a chance to see it.
-Supported toplevel options for the standard SBCL core are
+The toplevel options supported by the standard SBCL core are
.TP 3
.B --sysinit <filename>
Load filename instead of the default system-wide initialization file.
.SH SYSTEM REQUIREMENTS
-Unlike its distinguished ancestor CMU CL, SBCL currently runs only on
-X86 (Linux, FreeBSD, and OpenBSD), Alpha (Linux), and SPARC (Linux).
+SBCL currently runs on
+X86 (Linux, FreeBSD, and OpenBSD), Alpha (Linux, Tru64), PPC
+(Linux) and SPARC (Linux and Solaris 2.x).
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.
+SBCL requires on the order of 16Mb RAM to run on X86 systems,
+though for all but the smallest programs would be happier with 32Mb
+or more.
.SH ENVIRONMENT
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.)
+2002-07-25 anyway, we don't actively monitor that machinery, and it
+exists only because we 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
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
+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
projects / sbcl.git / blobdiff