By default SBCL implements @code{eval} by calling the native code
compiler. SBCL also includes an interpreter for use in special cases
-where using the compiler is undesireable, for example due to compilation
+where using the compiler is undesirable, for example due to compilation
overhead. Unlike in some other Lisp implementations, in SBCL interpreted
code is not safer or more debuggable than compiled code.
SBCL, like CMUCL before it, relies primarily on the automatic
conversion and direct manipulation approaches. The @code{SB-ALIEN}
-package provices a facility wherein foreign values of simple scalar
+package provides a facility wherein foreign values of simple scalar
types are automatically converted and complex types are directly
manipulated in their foreign representation. Additionally the
lower-level System Area Pointers (or @acronym{SAP}s) can be used where
The @code{sb-alien:sap-alien} function converts @var{sap} (a system
area pointer) to a foreign value with the specified
-@var{type}. @var{type} is not evaluated. </para>
+@var{type}. @var{type} is not evaluated.
The @var{type} must be some foreign pointer, array, or record type.
@end defun
facilities.
@item Extensible Streams
-@code{sb-gray} is an implentation of @emph{Gray Streams}. @xref{Gray
+@code{sb-gray} is an implementation of @emph{Gray Streams}. @xref{Gray
Streams}.
@code{sb-simple-streams} is an implementation of the @emph{simple
@item Executable Fasl Packaging
@code{sb-executable} can be used to concatenate multiple fasls into a
-single executable (though the presense of an SBCL runtime and core image
+single executable (though the presence of an SBCL runtime and core image
is still required to run it).
The @code{:executable} argument to @ref{Function
@item Bitwise Rotation
@code{sb-rotate-byte} provides an efficient primitive for bitwise
rotation of integers, an operation required by eg. numerous
-cryptographic algorightms, but not available as a primitive in ANSI
+cryptographic algorithms, but not available as a primitive in ANSI
Common Lisp. @xref{sb-rotate-byte}.
@item Test Harness
@subsection Internals Documentation
If you're interested in the development of the SBCL system itself,
-then subcribing to @cite{sbcl-devel} is a good idea.
+then subscribing to @cite{sbcl-devel} is a good idea.
SBCL internals documentation -- besides comments in the source -- is
-currenly maitained as a @emph{wiki-like} website:
+currently maintained as a @emph{wiki-like} website:
@uref{http://sbcl-internals.cliki.net/}.
Some low-level information describing the programming details of the
spurious package-lock-violations at runtime even if the packages are
unlocked.
-In practice all this means that package-locks have a neglible
+In practice all this means that package-locks have a negligible
performance penalty in compiled code as long as they are not violated.
@node Operations Violating Package Locks
Re-enables package locks affecting the named symbols during compilation
in the lexical scope of the declaration. Enabling locks that were not
-first disabled with @code{sb-ext:disable-package-locks} declararion, or
+first disabled with @code{sb-ext:disable-package-locks} declaration, or
enabling locks that are already enabled has no effect.
@end deftp
@comment node-name, next, previous, up
@section Semaphores
-escribed here should be considered
+described here should be considered
experimental, subject to API changes without notice.
@include struct-sb-thread-semaphore.texinfo
SBCL supports a system-wide scheduler implemented on top of
@code{setitimer} that also works with threads but does not require a
-separate schduler thread.
+separate scheduler thread.
@menu
@end menu
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.11.15"
+"1.0.11.16"