Menu
▾
▴
[Sbcl-commits] CVS: sbcl/doc/manual beyond-ansi.texinfo,1.18,1.19 debugger.texinfo,1.11,1.12 ffi.texinfo,1.9,1.10
|
From: Christophe R. <cr...@us...> - 2005-05-01 09:13:02
|
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 -@code{(* 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 -@code{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.) |