Update of /cvsroot/sbcl/sbcl/doc/manual
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17458/doc/manual
Modified Files:
beyond-ansi.texinfo debugger.texinfo ffi.texinfo
Log Message:
0.9.0.13:
Miscellaneous small fixes
... manual patches, from Adam Warner and Peter Barabas
... %reader-error from Raymond Toy
... external-format tests from Teemu Kalvas
Index: beyond-ansi.texinfo
===================================================================
RCS file: /cvsroot/sbcl/sbcl/doc/manual/beyond-ansi.texinfo,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- beyond-ansi.texinfo 10 Apr 2005 12:55:56 -0000 1.18
+++ beyond-ansi.texinfo 1 May 2005 09:12:53 -0000 1.19
@@ -146,15 +146,15 @@
@section Efficiency Hacks
The @code{sb-ext:purify} function causes SBCL first to collect all
-garbage, then to mark all uncollected objects as permanent, never
-again attempting to collect them as garbage. This can cause a large
-increase in efficiency when using a primitive garbage collector, or a
-more moderate increase in efficiency when using a more sophisticated
-garbage collector which is well suited to the program's memory usage
-pattern. It also allows permanent code to be frozen at fixed
-addresses, a precondition for using copy-on-write to share code
-between multiple Lisp processes. it is less important with modern
-generational garbage collectors.
+garbage, then to mark all uncollected objects as permanent, never again
+attempting to collect them as garbage. This can cause a large increase
+in efficiency when using a primitive garbage collector, or a more
+moderate increase in efficiency when using a more sophisticated garbage
+collector which is well suited to the program's memory usage pattern. It
+also allows permanent code to be frozen at fixed addresses, a
+precondition for using copy-on-write to share code between multiple Lisp
+processes. This is less important with modern generational garbage
+collectors, but not all SBCL platforms use such a garbage collector.
@include fun-sb-ext-purify.texinfo
Index: debugger.texinfo
===================================================================
RCS file: /cvsroot/sbcl/sbcl/doc/manual/debugger.texinfo,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- debugger.texinfo 1 Mar 2005 10:21:30 -0000 1.11
+++ debugger.texinfo 1 May 2005 09:12:53 -0000 1.12
@@ -370,8 +370,8 @@
@end lisp
Usually the elimination of tail-recursive frames makes debugging more
-pleasant, since theses frames are mostly uninformative. If there is
-any doubt about how one function called another, it can usually be
+pleasant, since these frames are mostly uninformative. If there is any
+doubt about how one function called another, it can usually be
eliminated by finding the source location in the calling frame.
@xref{Source Location Printing}.
Index: ffi.texinfo
===================================================================
RCS file: /cvsroot/sbcl/sbcl/doc/manual/ffi.texinfo,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- ffi.texinfo 9 Dec 2004 16:15:59 -0000 1.9
+++ ffi.texinfo 1 May 2005 09:12:53 -0000 1.10
@@ -282,12 +282,14 @@
@item
The foreign type specifier @code{sb-alien:c-string} is similar to
-@...{(* char)}, but is interpreted as a null-terminated string, and
-is automatically converted into a Lisp string when accessed; or if the
+@code{(* char)}, but is interpreted as a null-terminated string, and is
+automatically converted into a Lisp string when accessed; or if the
pointer is C @code{NULL} or @code{0}, then accessing it gives Lisp
-@...{nil}. Lisp strings are stored with a trailing NUL
-termination, so no copying (either by the user or the implementation)
-is necessary when passing them to foreign code.
+@code{nil}. Lisp strings of type @code{base-string} are stored with a
+trailing NUL termination, so no copying (either by the user or the
+implementation) is necessary when passing them to foreign code; strings
+of type @code{(simple-array character (*))} are copied by the
+implementation as required.
Assigning a Lisp string to a @code{c-string} structure field or
variable stores the contents of the string to the memory already
@@ -1182,8 +1184,8 @@
order to enable incremental loading with some linkers, you may need to
say @samp{cc -G 0 -c test.c})
-Once the C code has been compiled, you can start up Lisp and load it
-in: @samp{sbcl} Lisp should start up with its normal prompt.
+Once the C code has been compiled, you can start up Lisp and load it in:
+@samp{sbcl}. Lisp should start up with its normal prompt.
Within Lisp, compile the Lisp file. (This step can be done
separately. You don't have to recompile every time.)

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details