X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fsbcl.1;h=29b55594e89a6871c0f7f686c25d24c611f179ed;hb=3c5609fe910bae51ff885c8cfd4be879151e7489;hp=2d05d291ed3e66d616a34b8d5ae9088f0a1a692d;hpb=9e958331e64dad70e512dde6b553b590b4985a18;p=sbcl.git diff --git a/doc/sbcl.1 b/doc/sbcl.1 index 2d05d29..29b5559 100644 --- a/doc/sbcl.1 +++ b/doc/sbcl.1 @@ -10,13 +10,13 @@ .\" If you want to use this code or any part of CMU Common Lisp, please .\" contact Scott Fahlman or slisp-group@cs.cmu.edu. .\" ********************************************************************** +.\" Most of SBCL, including this man page, is in the public domain. See +.\" COPYING in the distribution for more information. .\" -.\" $Header$ -.\" FIXME: The date below should be $Date$. .TH SBCL 1 "$Date$" .AT 3 .SH NAME -SBCL -- "Steel Bank Common Lisp" +SBCL -- Steel Bank Common Lisp .SH DESCRIPTION @@ -25,6 +25,203 @@ the free CMU CL programming environment. (The name is intended to acknowledge the connection: steel and banking are the industries where Carnegie and Mellon made the big bucks.) +.SH LICENSING + +It is free software, mostly in the public domain, but with some +subsystems under BSD-style licenses which allow modification and +reuse as long as credit is given. It is provided "as is", with no +warranty of any kind. + +For more information about license issues, see the COPYING file in +the distribution. For more information about history, see the +CREDITS file in the distribution. + +.SH RUNNING SBCL + +To run SBCL, type "sbcl" at the command line with no arguments. (SBCL +understands command line arguments, but you probably won't need to use +them unless you're a fairly advanced user. If you are, you should +read the COMMAND LINE SYNTAX section, below.) You should see some +startup messages, then a prompt ("*"). Type a Lisp expression at the +prompt, and SBCL will read it, execute it, print any values returned, +give you another prompt, and wait for your next input. E.g. + + * (+ 1 2 3) + + 6 + * (funcall (lambda (x y) (list x y y)) :toy :choo) + + (:TOY :CHOO :CHOO) + * "Hello World" + + "Hello World" + * + +Many people like to run SBCL, like other Lisp systems, as a subprocess +under Emacs. The Emacs "Slime" and "ilisp" modes provide many +convenient features, like command line editing, tab completion, and +various kinds of coupling between Common Lisp source files and the +interactive SBCL subprocess, but they can be somewhat fragile wrt. +packages and readtables, in which case SBCL in the Emacs "shell" mode +can a useful substitute. + +.SH OVERVIEW + +SBCL compiles Common Lisp to native code. (Even today, some 30 years +after the MacLisp compiler, people will tell you that Lisp is an +interpreted language. Ignore them.) + +SBCL aims for but has not completely achieved compliance with the ANSI +standard for Common Lisp. More information about this is available in +the BUGS section below. + +SBCL also includes various non-ANSI extensions, described more fully +in the User Manual. Some of these are in the base system and others +are "contrib" modules loaded on request using REQUIRE. For example, +to load the SB-BSD-SOCKETS module that providces TCP/IP connectivity, + + * (require 'asdf) + * (require 'sb-bsd-sockets) + +Many Lispy extensions have been retained from CMU CL: +.TP 3 +\-- +CMU-CL-style safe implementation of type declarations: +"Declarations are assertions." +.TP 3 +\-- +the source level debugger (very similar to CMU CL's) +.TP 3 +\-- +the profiler (now somewhat different from CMU CL's) +.TP 3 +\-- +saving the state of the running SBCL process, producing a +"core" file which can be restarted later +.TP 3 +\-- +Gray streams (a de-facto standard system of overloadable CLOS classes +whose instances can be used wherever ordinary ANSI streams can be used) +.TP 3 +\-- +weak pointers and finalization (which have unfortunately +suffered from at least some code rot, so that e.g. weak hash +tables don't work) +.PP + +Fundamental system interface extensions are also provided: +.TP 3 +\-- +calling out to C code (a.k.a. FFI, foreign function interface, +with very nearly the same interface as CMU CL) +.TP 3 +\-- +some simple support for operations with a "scripting language" +flavor, e.g. reading POSIX argc and argv, or executing a +subprogram +.PP + +.SH DIFFERENCES FROM CMU CL + +SBCL can be built from scratch using a plain vanilla ANSI Common Lisp +system and a C compiler, and all of its properties are specified by +the version of the source code that it was created from. This clean +bootstrappability was the immediate motivation for forking off of the +CMU CL development tree. A variety of implementation differences are +motivated by this design goal. + +Maintenance work in SBCL since the fork has diverged somewhat from the +maintenance work in CMU CL. Many but not all bug fixes and +improvements have been shared between the two projects, and sometimes +the two projects disagree about what would be an improvement. + +Most extensions supported by CMU CL have been unbundled from SBCL, +including Motif support, the Hemlock editor, search paths, the +low-level Unix interface, the WIRE protocol, various user-level macros +and functions (e.g. LETF, ITERATE, MEMQ, REQUIRED-ARGUMENT), and many +others. + +SBCL inplements multithreading, but in a completely different fashion +from CMU CL: see the User Manual for details. As of 0.8.5 this is +considered beta-quality and must be explicitly enabled at build time. + +SBCL has retained some extensions from its parent CMU CL. Many of the +retained extensions are in these categories: +.TP 3 +\-- +things which might be in the new ANSI spec, e.g. safe type +declarations, weak pointers, finalization, foreign function +interface to C, and Gray streams +.TP 3 +\-- +things which are universally available in Unix scripting languages, +e.g. RUN-PROGRAM and POSIX argv and getenv +.TP 3 +\-- +hooks into the low level workings of the system which can be useful +for debugging, e.g. requesting that a particular function be executed +whenever GC occurs, or tuning compiler diagnostic output +.TP 3 +\-- +unportable performance hacks, e.g. FREEZE-TYPE and PURIFY. For more +information about these, look at the online documentation for symbols +in the SB-EXT package, and look at the user manual. +.PP + +There are also a few retained extensions which don't fall into any +particular category, e.g. the ability to save running Lisp images as +executable files. + +Some of the retained extensions have new names and/or different +options than their CMU CL counterparts. For example, the SBCL function +which saves a Lisp image to disk and kills the running process is +called SAVE-LISP-AND-DIE instead of SAVE-LISP, and SBCL's +SAVE-LISP-AND-DIE supports fewer keyword options than CMU CL's +SAVE-LISP does. + +(Why doesn't SBCL support more extensions natively? Why drop all +those nice extensions from CMU CL when the code already exists? This +is a frequently asked question on the mailing list. There are two +principal reasons. First, 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. Some of these are distributed with +SBCL as "contrib" modules, others are distributed as separate software +packages by separate maintainers. Second, it's a practical decision - +focusing on a smaller number of things will, we hope, let us do a +better job on them.) + +.SH THE COMPILER + +SBCL inherits from CMU CL the "Python" native code compiler. (Though +we often avoid that name in order to avoid confusion with the +scripting language also called Python.) This compiler is very clever +about understanding the type system of Common Lisp and using it to +optimize code, and about producing notes to let the user know when the +compiler doesn't have enough type information to produce efficient +code. It also tries (almost always successfully) to follow the unusual +but very useful principle that "declarations are assertions", i.e. +type declarations should be checked at runtime unless the user +explicitly tells the system that speed is more important than safety. + +The compiler reportedly produces pretty good code for modern CPU +architectures which have lots of registers, but its code for the X86 +is marred by many extra loads and stores to stack-based temporary +variables. Because of this, and because of the extra levels of +indirection in Common Lisp relative to C, the performance of SBCL +isn't going to impress people who are impressed by small constant +factors. However, even on the X86 it tends to be faster than byte +interpreted languages (and can be a lot faster). + +The compiled code uses garbage collection to automatically +manage memory. The garbage collector implementation varies considerably +from CPU to CPU. In particular, on some CPUs the GC is nearly exact, +while on others it's more conservative, and on some CPUs the GC +is generational, while on others simpler stop and copy strategies +are used. + +For more information about the compiler, see the user manual. + .SH COMMAND LINE SYNTAX Command line syntax can be considered an advanced topic; for ordinary @@ -39,7 +236,7 @@ runtime environment, some command line arguments are processed during the initialization of the Common Lisp system, and any remaining command line arguments are passed on to user code. -The full, unambiguous syntax for SBCL is +The full, unambiguous syntax for invoking SBCL at the command line is .TP 3 .B sbcl [runtime options] --end-runtime-options [toplevel options] --end-toplevel-options [user options] .PP @@ -58,13 +255,23 @@ Supported runtime options are .TP 3 .B --core 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 accept 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 -startup. (Combined with the --noprint toplevel option, this makes it -straightforward to write Lisp "scripts" which work as Unix pipes.) +startup. (This makes it easier to write Lisp programs which work +cleanly in Unix pipelines. See also the "--noprint" and +"--disable-debugger" options.) +.TP 3 +.B --help +Print some basic information about SBCL, then exit. +.TP 3 +.B --version +Print SBCL's version information, then exit. .PP In the future, runtime options may be added to control behavior such @@ -74,237 +281,97 @@ Runtime options, including any --end-runtime-options option, 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 -Load filename instead of the default system-wide -initialization file. (See the FILES section.) -There is no special option to cause -no system-wide initialization file to be read, but on a Unix -system "--sysinit /dev/null" can be used to achieve the same effect. +Load filename instead of the default system-wide initialization file. +(See the FILES section.) There is no special option to cause no +system-wide initialization file to be read, but on a Unix system +"--sysinit /dev/null" can be used to achieve the same effect. .TP 3 .B --userinit -Load filename instead of the default user -initialization file. (See the FILES section.) -There is no special option to cause -no user initialization file to be read, but on a Unix -system "--userinit /dev/null" can be used to achieve the same effect. +Load filename instead of the default user initialization file. (See +the FILES section.) There is no special option to cause no user +initialization file to be read, but on a Unix system "--userinit +/dev/null" can be used to achieve the same effect. .TP 3 .B --eval After executing any initialization file, but before starting the -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. +read-eval-print loop on standard input, read and evaluate the command +given. More than one --eval option can be used, and all will be read +and executed, in the order they appear on the command line. +.TP 3 +.B --load +This is equivalent to --eval '(load "")'. 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 straightforward to write Lisp -"scripts" which work as Unix pipe utilities.) +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 cleanly in Unix +pipelines. .TP 3 -.B --noprogrammer -Ordinarily the system initializes *DEBUG-IO* to *TERMINAL-IO*. -When the --notty option is set, however, *DEBUG-IO* is instead -set to a stream which sends its output to *ERROR-OUTPUT* and -which raises an error on input. As a result, any attempt by the -program to get programmer feedback through the debugger -causes an error which abnormally terminates the entire -Lisp environment. (This can be useful behavior for programs -which are to run without programmer supervision.) +.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, then listening, 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. This is implemented by +redefining INVOKE-DEBUGGER so that any call exits the process with a +failure code after printing a backtrace, and by redefining *DEBUG-IO* +to send its output to *ERROR-OUTPUT* and to raise an error if any +input is requested from it. (Note that because it is implemented by +modifying special variables and FDEFINITIONs, its effects persist in +.core files created by SB-EXT:SAVE-LISP-AND-DIE. If you want to undo +its effects, e.g. if you build a system unattended and then want to +operate a derived system interactively, see the SB-EXT:ENABLE-DEBUGGER +command.) .PP Regardless of the order in which --sysinit, --userinit, and --eval options appear on the command line, the sysinit file, if it exists, is loaded first; then the userinit file, if it exists, is loaded; then -any --eval commands are executed in sequence; then the read-eval-print -loop is started on standard input. At any step, error conditions or -commands such as SB-EXT:QUIT can cause execution to be terminated -before proceeding to subsequent steps. - -Note that when running SBCL from a core file created by a user call to -the SB-EXT:SAVE-LISP-AND-DIE, the toplevel options may be under the -control of user code passed as arguments to SB-EXT:SAVE-LISP-AND-DIE. -For this purpose, the --end-toplevel-options option itself can be -considered a toplevel option, i.e. the user core, at its option, may -not support it. +any --eval commands are read and executed in sequence; then the +read-eval-print loop is started on standard input. At any step, error +conditions or commands such as SB-EXT:QUIT can cause execution to be +terminated before proceeding to subsequent steps. + +Note that when running SBCL with the --core option, using a core file +created by a user call to the SB-EXT:SAVE-LISP-AND-DIE, the toplevel +options may be under the control of user code passed as arguments to +SB-EXT:SAVE-LISP-AND-DIE. For this purpose, the --end-toplevel-options +option itself can be considered a toplevel option, i.e. the user core, +at its option, may not support it. In the standard SBCL startup sequence (i.e. with no user core involved) toplevel options and any --end-toplevel-options option are stripped out of the command line argument list before user code gets a chance to see it. -.SH OVERVIEW - -SBCL aims for but has not reached ANSI compliance. - -SBCL compiles Lisp to native code, or optionally to more-compact but -much slower byte code. - -SBCL's garbage collector is generational and conservative. - -SBCL includes a source level debugger, as well as the ANSI TRACE -facility and a rudimentary profiler. - -.SH DIFFERENCES FROM CMU CL - -SBCL can be built from scratch using a plain vanilla ANSI Common Lisp -system and a C compiler, and all of its properties are specified by -the version of the source code that it was created from. (This clean -bootstrappability was the immediate motivation for forking off of the -CMU CL development tree.) - -Many extensions supported by CMU CL, like Motif support, -the Hemlock editor, search paths, the WIRE protocol, various -user-level macros and functions (e.g. LETF, ITERATE, MEMQ, -REQUIRED-ARGUMENT), and many others. - -SBCL has retained some extensions of its parent CMU CL. Many -of them are in three categories: -.TP 3 -\-- -hooks into the low level workings of the system which can be useful -for debugging (e.g. a list of functions to be run whenever GC occurs, -or an operator to cause a particular string to be compiled into a fasl -file) -.TP 3 -\-- -non-portable performance hacks (e.g. PURIFY, which causes -everything currently in existence to become immune to GC) -.TP 3 -\-- -things which might be in the new ANSI spec (e.g. weak pointers, -finalization, foreign function interface to C, and Gray streams) -.PP - -There are also various retained extensions which don't fall into -any particular category, e.g. -.TP 3 -\-- -the ability to save running Lisp images as executable files -.PP - -Some of the retained extensions have new names and/or different -options than their CMU CL counterparts. For example, the SBCL function -which saves a Lisp image to disk and kills it is called -SAVE-LISP-AND-DIE instead of SAVE-LISP, and it supports fewer keyword -options than CMU CL's SAVE-LISP. - -.SH THE COMPILER - -SBCL inherits from CMU CL the "Python" native code compiler. This -compiler is very clever about understanding the type system of Common -Lisp and using it to produce efficient code, and about producing notes -to let the user know when the compiler doesn't have enough type -information to produce efficient code. It also tries (almost always -successfully) to follow the unusual but very useful principle that -type declarations should be checked at runtime unless the user -explicitly tells the system that speed is more important than safety. - -The CMU CL version of this compiler reportedly produces pretty good -code for modern machines which have lots of registers, but its code -for the X86 is marred by a lot of extra loads and stores to -stack-based temporary variables. Because of this, and because of the -extra levels of indirection in Common Lisp relative to C, we find a -typical performance decrease by a factor of perhaps 2 to 5 for small -programs coded in SBCL instead of GCC. - -For more information about the compiler, see the user manual. - -.SH DOCUMENTATION - -Currently, the documentation for the system is -.TP 3 -\-- -the user manual -.TP 3 -\-- -this man page -.TP 3 -\-- -doc strings and online help built into the SBCL executable -.PP - .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 -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 -routinely; the only reason SBCL doesn't currently do this is a -combination of bootstrapping technicalities and inertia.) - -.SH ENVIRONMENT - -.TP 10n -.BR SBCL_HOME -If this variable is set, it overrides the default directories for -files like "sbclrc" and "sbcl.core", so that instead of being searched -for in e.g. /etc/, /usr/local/etc/, /usr/lib/, and /usr/local/lib/, they -are searched for only in the directory named by SBCL_HOME. This is -intended to support users who wish to use their own version of SBCL -instead of the version which is currently installed as the system -default. -.PP - -.SH FILES - -/usr/lib/sbcl.core and /usr/local/lib/sbcl.core are the standard -locations for the standard SBCL core, unless overridden by the SBCL_HOME -variable. +SBCL currently runs on X86 (Linux, FreeBSD, OpenBSD, and NetBSD), Alpha +(Linux, Tru64), PPC (Linux, Darwin/MacOS X), SPARC (Linux and Solaris +2.x), and MIPS (Linux). For information on other ongoing and possible +ports, see the sbcl-devel mailing list, and/or the web site. -/etc/sbclrc and /usr/local/etc/sbclrc are the standard locations for -system-wide SBCL initialization files, unless overridden by the -SBCL_HOME variable. +SBCL requires on the order of 16Mb RAM to run on X86 systems, though +all but the smallest programs would be happier with 32Mb or more. -$HOME/.sbclrc is the standard location for a user's SBCL -initialization file. +.SH KNOWN BUGS -.SH BUGS - -Too numerous to list, alas. This section attempts to list the most -serious known bugs, and a reasonably representative sampling of -others. For more information on bugs, see the BUGS file in the -distribution. - -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. -.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. -.PP +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. -The facility for dumping a running Lisp image to disk gets confused -when run without the PURIFY option, and creates an unnecessarily large -core file (apparently representing memory usage up to the previous -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 -(DEFUN FOO (X) NIL) -(DEFUN BAR (X) (IF (FOO X) 1 2)) -(DEFUN FOO (X) (PLUSP X)) -then running (FOO 1) gives 2 (because the compiler "knew" -that FOO's return type is NULL). +It is possible to get in deep trouble by exhausting heap memory. The +SBCL system overcommits memory at startup, so, 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 it, other +processes tend to be killed randomly (!). The compiler's handling of function return values unnecessarily violates the "declarations are assertions" principle that it otherwise @@ -314,27 +381,45 @@ compiling a file containing (DECLAIM (FTYPE (FUNCTION (T) NULL) SOMETIMES)) (DEFUN SOMETIMES (X) (ODDP X)) (DEFUN FOO (X) (IF (SOMETIMES X) 'THIS-TIME 'NOT-THIS-TIME)) -then running (FOO 1) gives NOT-THIS-TIME, because the -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. +then running (FOO 1) gives NOT-THIS-TIME, because the compiler +relied on the truth of the DECLAIM without checking it. -CLOS (based on the PCL reference implementation) is quite slow. - -There are many nagging pre-ANSIisms, e.g. +Some things are implemented very inefficiently. +.TP 3 +\-- +Multidimensional arrays are inefficient, especially +multidimensional arrays of floating point numbers. +.TP 3 +\-- +The DYNAMIC-EXTENT declaration isn't implemented at all, not even +for &REST lists or upward closures, so such constructs always allocate +their temporary storage from the heap, causing GC overhead. .TP 3 \-- -CLOS (based on the PCL reference implementation) is incompletely -integrated into the system, so that e.g. SB-PCL::FIND-CLASS is a -different function than CL::FIND-CLASS. (This is less of a problem in -practice than the speed, but it's still distasteful.) +CLOS isn't particularly efficient. (In part, CLOS is so dynamic +that it's slow for fundamental reasons, but beyond that, the +SBCL implementation of CLOS doesn't do some important known +optimizations.) +.TP 3 +\-- +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 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 .TP 3 -- The ANSI-recommended idiom for creating a function which is only @@ -346,30 +431,92 @@ doesn't do what you'd expect. (Instead, you have to declare the function as SB-EXT:MAYBE-INLINE to get the desired effect.) .TP 3 \-- -The DYNAMIC-EXTENT declaration is not implemented, and is simply -ignored. (This is allowed by the ANSI spec, but can have a large -efficiency cost in some kinds of code.) -.TP 3 --- -Compiling DEFSTRUCT in strange places (e.g. inside a DEFUN) doesn't -do anything like what it should. -.TP 3 -\-- -The symbol * is the name of a type similar to T. (It's used as part -of the implementation of compound types like (ARRAY * 1).) +There are several nonconforming bits of type syntax. E.g. (1) The type +FOO is strictly equivalent to (FOO), so e.g. the type OR is treated as +the type (OR), i.e. the empty type. This is the way that the ancestral +code worked, and even though ANSI specifically forbids it, it hasn't +been fixed yet. (2) The symbol * is the name of a type similar to T. +(It's used as part of the implementation of compound types like (ARRAY +* 1) and (CONS * *). In a strict ANSI implementation, * would not be +the name of a type, but instead just a symbol which is recognized and +handled specially by certain type expanders.) .PP +.SH REPORTING BUGS + +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 at . (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 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 +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." + .SH SUPPORT -Please send bug reports or other information to -. +Various information about SBCL is available at +. The mailing lists there are the recommended +place to look for support. -.SH DISTRIBUTION +.SH ENVIRONMENT -SBCL is a free implementation of Common Lisp derived from CMU CL. Both -sources and executables are freely available; this software is "as -is", and has no warranty of any kind. CMU and the authors assume no -responsibility for the consequences of any use of this software. See -the CREDITS file in the distribution for more information about -history, contributors and permissions. +.TP 10n +.BR SBCL_HOME +This variable controls where files like "sbclrc", "sbcl.core", and the +add-on "contrib" systems are searched for. If it is not set, then +sbcl sets it from a compile-time default location which is usually +/usr/local/lib/sbcl/ but may have been changed e.g. by a third-party +packager. +.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. Looked for in $SBCL_HOME, +unless overridden by the --core option. +.TP +.I sbclrc +optional system-wide startup script, looked for in $SBCL_HOME/sbclrc +then /etc/sbclrc, unless overridden by the --sysinit command line +option. +.TP +.I .sbclrc +optional per-user customizable startup script (in user's home +directory, or as specified by --userinit) + +.SH AUTHORS + +Dozens of people have made substantial contributions to SBCL and its +subsystems, and to the CMU CL system on which it was based, over the +years. See the CREDITS file in the distribution for more information. + +.SH SEE ALSO + +Full SBCL documentation is maintained as a Texinfo manual. If is has +been installed, the command +.IP +.B info sbcl +.PP +should give you access to the complete manual. Depending on your +installation it may also be available in HTML and PDF formats in eg. +.IP +.B /usr/local/share/doc/sbcl/ +.PP +See the SBCL homepage +.IP +.B http://www.sbcl.org/ +.PP +for more information, including directions on how to subscribe to the +sbcl-devel and sbcl-help mailing-lists.