Changes between Version 5 and Version 6 of ReleaseNotes

Timestamp:

11/08/07 20:12:51 (6 years ago)

Author:

gb

Comment:

--

ReleaseNotes

@@ -107 +107 @@
 
 - The break-loop colon commands for showing the contents of
-  stack frames try to present the frame's contents in a way that's
-  (hopefully) more meaningful and useful.  For each stack frame
-  shown in detail, the corresponding function's argument list
-  is printed, followed by the current values of the function's
-  arguments (indented slightly), a blank line, and the current
-  values of the function's local variables (outdented slightly.)
-  The old method of showing a stack frame's "raw" contents is
-  still available as the :RAW break loop command.
-
-  The new style of presenting a stack-frame's contents is also
-  used in the Cocoa IDE.
+stack frames try to present the frame's contents in a way that's
+(hopefully) more meaningful and useful.  For each stack frame
+shown in detail, the corresponding function's argument list
+is printed, followed by the current values of the function's
+arguments (indented slightly), a blank line, and the current
+values of the function's local variables (outdented slightly.)
+The old method of showing a stack frame's "raw" contents is
+still available as the :RAW break loop command.
+
+The new style of presenting a stack-frame's contents is also
+used in the Cocoa IDE.
 
 - It's historically been possible to create stacks (for threads
-  other than the original one) whose size exceeds the nominal
-  OS resource limits for a stack's size.  (OpenMCL's threads
-  use multiple stacks; the stack in question is the one that
-  OpenMCL generally refers to as the "control" or "C" stack.)
-  It's not entirely clear what (if anything) the consequences
-  of exceeding these limits have been, but OpenMCL's GC can
-  use all of the available (C) stack space that it thinks it
-  has under some conditions, and, under OSX/Mach/Darwin, there
-  have been reports of excessive page file creation and paging
-  activity that don't seem related to heap behavior in environments
-  where the GC is running on (and possibly using much of) a stack
-  whose size greatly exceeds the hard resource limit on stack
-  size.
-
-  Trying to determine exactly what was causing the excessive
-  pages got me trapped in a twisty maze of Mach kernel sources,
-  all alike.  I tried to pin C stack size to the hard resource
-  limit on stack size and have not been able to provoke the
-  excessive paging problems since, but am not confident in
-  concluding (yet) that the problems had to do with resource
-  limits being exceeded.
-
-  The hard resource limits on stack size for the OS versions
-  that I have readily available (in bash, do "ulimit -s -H";
-  in tcsh, it's "limit -h s", don't know offhand about other
-  shells) are:
-
-  unlimited on Linux
-  ~512M on FreeBSD
-  ~64M on Darwin
-
-  The effect of observing (rather than exceeding) this limit
-  on the maximum depth of lisp recursion in OpenMCL is:
-
-  * nothing, on x86-64 (the C stack is not used by lisp code
-    on x86-64)
-
-  * visible on ppc32, which uses 4 32-bit words on the control
-    stack for each lisp function invocation
-
-  * more visible on ppc64, which uses 4 64-bit words of control
-    stack for each lisp function invocation.
-
-  That seems to suggest that (given that the actual stack resource
-  limit is a bit under 64M and that OpenMCL signals stack overflow
-  when the stack pointer gets within a few hundred KB of the actual
-  limit) that ppc64 threads are now limited to a maximum of about
-  2000000 function calls.
-
-  (All of this only matters if attempts are made to create threads
-  with large stacks; the default stack sizes in OpenMCL are usually
-  1-2 MB.)
+other than the original one) whose size exceeds the nominal
+OS resource limits for a stack's size.  (OpenMCL's threads
+use multiple stacks; the stack in question is the one that
+OpenMCL generally refers to as the "control" or "C" stack.)
+It's not entirely clear what (if anything) the consequences
+of exceeding these limits have been, but OpenMCL's GC can
+use all of the available (C) stack space that it thinks it
+has under some conditions, and, under OSX/Mach/Darwin, there
+have been reports of excessive page file creation and paging
+activity that don't seem related to heap behavior in environments
+where the GC is running on (and possibly using much of) a stack
+whose size greatly exceeds the hard resource limit on stack
+size.
+
+Trying to determine exactly what was causing the excessive
+pages got me trapped in a twisty maze of Mach kernel sources,
+all alike.  I tried to pin C stack size to the hard resource
+limit on stack size and have not been able to provoke the
+excessive paging problems since, but am not confident in
+concluding (yet) that the problems had to do with resource
+limits being exceeded.
+
+The hard resource limits on stack size for the OS versions
+that I have readily available (in bash, do "ulimit -s -H";
+in tcsh, it's "limit -h s", don't know offhand about other
+shells) are:
+
+  * unlimited on Linux
+  * ~512M on FreeBSD
+  * ~64M on Darwin
+
+The effect of observing (rather than exceeding) this limit
+on the maximum depth of lisp recursion in OpenMCL is:
+
+  * nothing, on x86-64 (the C stack is not used by lisp code on x86-64)
+
+  * visible on ppc32, which uses 4 32-bit words on the control stack for each lisp function invocation
+
+  * more visible on ppc64, which uses 4 64-bit words of control  stack for each lisp function invocation.
+
+That seems to suggest that (given that the actual stack resource
+limit is a bit under 64M and that OpenMCL signals stack overflow
+when the stack pointer gets within a few hundred KB of the actual
+limit) that ppc64 threads are now limited to a maximum of about
+2000000 function calls.
+
+(All of this only matters if attempts are made to create threads
+with large stacks; the default stack sizes in OpenMCL are usually
+1-2 MB.)
 
 - On a cheerier (and certainly less confusing) note: for the last few
-  years, OpenMCL has shipped with an extended example which provides an
-  integrated development environment (IDE) based on Cocoa; that's often
-  been described as "the demo IDE" and could also be fairly described as
-  "slow", "buggy", "incomplete", and "little more than a proof of
-  concept."
-
-  I think that it's fair to describe the current state of the IDE as
-  being "less slow", "less buggy", "less incomplete", and "much more
-  than a proof of concept" than it has been (e.g., there's been some
-  actual progress over the last few months and there are plans to
-  try to continue working on the IDE and related tools.)  It'd probably
-  be optimistic to call it "usable" in its current state (that may
-  depend on how low one's threshold of usability is), but I hope that
-  people who've been discouraged by the lack of IDE progress over the
-  last few years will see reason to be encouraged (and that anyone
-  interested will submit bug reports, patches, feature requests, code ...)
+years, OpenMCL has shipped with an extended example which provides an
+integrated development environment (IDE) based on Cocoa; that's often
+been described as "the demo IDE" and could also be fairly described as
+"slow", "buggy", "incomplete", and "little more than a proof of
+concept."
+
+I think that it's fair to describe the current state of the IDE as
+being "less slow", "less buggy", "less incomplete", and "much more
+than a proof of concept" than it has been (e.g., there's been some
+actual progress over the last few months and there are plans to
+try to continue working on the IDE and related tools.)  It'd probably
+be optimistic to call it "usable" in its current state (that may
+depend on how low one's threshold of usability is), but I hope that
+people who've been discouraged by the lack of IDE progress over the
+last few years will see reason to be encouraged (and that anyone
+interested will submit bug reports, patches, feature requests, code ...)
 
 - There are now "objc-bridge" and "cocoa-ide" subdirectories; by default,
-  REQUIRE will look in these directories for files whose name matches
-  a module name.  Several files were moved from the "examples" directory
-  to "objc-bridge"; other example files, the "OpenMCL.app" skeleton
-  bundle, and the "hemlock" directory were moved to "cocoa-ide".
+REQUIRE will look in these directories for files whose name matches
+a module name.  Several files were moved from the "examples" directory
+to "objc-bridge"; other example files, the "OpenMCL.app" skeleton
+bundle, and the "hemlock" directory were moved to "cocoa-ide".
 
 
 = OpenMCL 1.1-pre-070512 =
 - The FASL version changed (old FASL files won't work with this
-  lisp version), as did the version information which tries to
-  keep the kernel in sync with heap images.  Note that it's generally
-  a lot easier to recompile recent sources with recent images, e.g.,
-  trying to compile 070512 sources with an 070407 image is unlikely
-  to work without tricky bootstrapping.
+lisp version), as did the version information which tries to
+keep the kernel in sync with heap images.  Note that it's generally
+a lot easier to recompile recent sources with recent images, e.g.,
+trying to compile 070512 sources with an 070407 image is unlikely
+to work without tricky bootstrapping.
+
 - Most of the changes in this release involve the calling sequence
-  used on x86-64.  In very general terms, some kinds of function-call
-  intensive code may see a significant performance boost, most code
-  should see a slight improvement, some code might see a (hopefully
-  very slight) degradation, and anything significantly slower than
-  previous releases should be reported as a bug.
-  It is -possible- that some of these changes may cause errors to
-  be reported differently (the function reported as the function
-  executing when the error ocurred might be different/wrong).  I
-  have not seen as many cases of this as I expected to when making
-  the change, but am also not sure that I fixed all possible cases.
+used on x86-64.  In very general terms, some kinds of function-call
+intensive code may see a significant performance boost, most code
+should see a slight improvement, some code might see a (hopefully
+very slight) degradation, and anything significantly slower than
+previous releases should be reported as a bug.
+
+It is -possible- that some of these changes may cause errors to
+be reported differently (the function reported as the function
+executing when the error ocurred might be different/wrong).  I
+have not seen as many cases of this as I expected to when making
+the change, but am also not sure that I fixed all possible cases.
+
 - The FFI-related reader macros #_, #$, and #& all read a case-sensitive
-  foreign function, constant, or variable name from the input stream
-  and try to find the corresponding definition in the interface files.
-  If the name is prefixed with a #\? - as in #_?foo - the macros
-  return true if the definition could be found and false otherwise.
-  (The general idea is that this might be useful for conditionalizing
-  code in some cases, and there should be -some- way of quietly testing 
-  that something's defined.)
+foreign function, constant, or variable name from the input stream
+and try to find the corresponding definition in the interface files.
+If the name is prefixed with a #\? - as in #_?foo - the macros
+return true if the definition could be found and false otherwise.
+(The general idea is that this might be useful for conditionalizing
+code in some cases, and there should be -some- way of quietly testing 
+that something's defined.)
+
 - There is now support for making the contents of (possibly very large)
-  files accessible as lisp vectors.  (This may be many times faster
-  than something like 
+files accessible as lisp vectors.  (This may be many times faster
+than something like 
 
 {{{
@@ -235 +236 @@
 }}}
 
-  but has the similar effect of making the contents of VECTOR match the
-  contents of the file.)
+but has the similar effect of making the contents of VECTOR match the
+contents of the file.)
 
 {{{CCL:MAP-FILE-TO-IVECTOR pathname element-type [Function]}}}
 
-  "element-type" should be a type specifier such that
-  (UPGRADED-ARRAY-ELEMENT-TYPE element-type) is a subtype
-  of either SIGNED-BYTE or UNSIGNED-BYTE.
-
-  Tries to open the file named by "pathname" for reading and to
-  map its contents into the process's address space via #_mmap;
-  if successful, returns a lisp vector of element-type
-  (UPGRADED-ARRAY-ELEMENT-TYPE element-type) which is displaced
-  to an underlying (SIMPLE-ARRAY element-type (*)) whose contents
-  match the mapped file's.
-
-  Because of alignment issues, the mapped file's contents will
-  start a few bytes (4 bytes on 32-bit platforms, 8 bytes on 64-bit
-  platforms) "into" the vector; the displaced array returned by
-  CCL:MAP-FILE-TO-IVECTOR hides this overhead, but its usually
-  more efficient to operate on the underlying simple 1-dimensional
-  array.  Given a displaced array (like the value returned by
-  CCL:MAP-FILE-TO-IVECTOR), the CL function ARRAY-DISPLACEMENT
-  returns the underlying array and the displacement index in elements.
-
-  Currently, only read-only file mapping is supported; the underlying
-  vector will be allocated in read-only memory, and attempts to use
-  (e.g.) (SETF (AREF ...) ...) to modify the mapped vector's contents
-  will result in memory faults.
+"element-type" should be a type specifier such that
+(UPGRADED-ARRAY-ELEMENT-TYPE element-type) is a subtype
+of either SIGNED-BYTE or UNSIGNED-BYTE.
+
+Tries to open the file named by "pathname" for reading and to
+map its contents into the process's address space via #_mmap;
+if successful, returns a lisp vector of element-type
+(UPGRADED-ARRAY-ELEMENT-TYPE element-type) which is displaced
+to an underlying (SIMPLE-ARRAY element-type (*)) whose contents
+match the mapped file's.
+
+Because of alignment issues, the mapped file's contents will
+start a few bytes (4 bytes on 32-bit platforms, 8 bytes on 64-bit
+platforms) "into" the vector; the displaced array returned by
+CCL:MAP-FILE-TO-IVECTOR hides this overhead, but its usually
+more efficient to operate on the underlying simple 1-dimensional
+array.  Given a displaced array (like the value returned by
+CCL:MAP-FILE-TO-IVECTOR), the CL function ARRAY-DISPLACEMENT
+returns the underlying array and the displacement index in elements.
+
+Currently, only read-only file mapping is supported; the underlying
+vector will be allocated in read-only memory, and attempts to use
+(e.g.) (SETF (AREF ...) ...) to modify the mapped vector's contents
+will result in memory faults.
   
-  {{{CCL:MAP-FILE-TO-OCTET-VECTOR pathname [Function]}}}
-
-  Equivalent to (CCL:MAP-FILE-TO-IVECTOR pathname '(UNSIGNED-BYTE 8)).
-
-  {{{CCL:UNMAP-IVECTOR displaced-vector}}}
-
-  If the argument is a mapped vector (as returned by
-  MAP-FILE-TO-IVECTOR) that has not yet been "unmapped" by this
-  function, undoes the memory mapping, closes the mapped file, and
-  adjusts its argument so that it's displaced to a 0-length vector.
-
-  CCL:UNMAP-OCTET-VECTOR is an alias for CCL:UNMAP-IVECTOR
-
-  Note that whether a vector's created by MAKE-ARRAY or by mapping
-  a file's contents, it can't have ARRAY-TOTAL-SIZE-LIMIT or more
-  elements.  (ARRAY-TOTAL-SIZE-LIMIT is (EXPT 2 24) in 32-bit OpenMCL
-  and (EXPT 2 56) in 64-bit versions.
+{{{CCL:MAP-FILE-TO-OCTET-VECTOR pathname [Function]}}}
+
+Equivalent to (CCL:MAP-FILE-TO-IVECTOR pathname '(UNSIGNED-BYTE 8)).
+
+{{{CCL:UNMAP-IVECTOR displaced-vector}}}
+
+If the argument is a mapped vector (as returned by
+MAP-FILE-TO-IVECTOR) that has not yet been "unmapped" by this
+function, undoes the memory mapping, closes the mapped file, and
+adjusts its argument so that it's displaced to a 0-length vector.
+
+CCL:UNMAP-OCTET-VECTOR is an alias for CCL:UNMAP-IVECTOR
+
+Note that whether a vector's created by MAKE-ARRAY or by mapping
+a file's contents, it can't have ARRAY-TOTAL-SIZE-LIMIT or more
+elements.  (ARRAY-TOTAL-SIZE-LIMIT is (EXPT 2 24) in 32-bit OpenMCL
+and (EXPT 2 56) in 64-bit versions.
 
 - The lisp kernel now tries to signal memory faults that occur when
-  running lisp code as lisp errors.  As a silly example:
+running lisp code as lisp errors.  As a silly example:
 
 {{{
@@ -297 +298 @@
 }}}
 
-  The fact that things are handled this way (rather than going
-  into the kernel debugger with no easy way of recovering) makes
-  it possible to continue a session without losing work in many
-  cases.  In a trivial example like the one above, it's relatively
-  easy to see that no harm has been done and the error should
-  not be hard to recover from.  In some other cases, it may be
-  true that a buggy function has been scribbling ofer memory for
-  a while before that scribbling resulted in a machine exception.
-
-  Moral: if you get an unexpected "memory fault" error (the
-  condition type is actually CCL::INVALID-MEMORY-ACCESS) and
-  don't understand why the fault occurred and the consequences
-  of continuing in the lisp session where the fault occurred,
-  you should view the state of that session with some suspicion.
-
-  Faults in foreign code (should) still trap into the kernel
-  debugger.  (It'd be nice to be able to treat these as lisp
-  errors with the same caveats as described above, but that
-  is more complicated in some cases and isn't yet implemented.)
+The fact that things are handled this way (rather than going
+into the kernel debugger with no easy way of recovering) makes
+it possible to continue a session without losing work in many
+cases.  In a trivial example like the one above, it's relatively
+easy to see that no harm has been done and the error should
+not be hard to recover from.  In some other cases, it may be
+true that a buggy function has been scribbling ofer memory for
+a while before that scribbling resulted in a machine exception.
+
+Moral: if you get an unexpected "memory fault" error (the
+condition type is actually CCL::INVALID-MEMORY-ACCESS) and
+don't understand why the fault occurred and the consequences
+of continuing in the lisp session where the fault occurred,
+you should view the state of that session with some suspicion.
+
+Faults in foreign code (should) still trap into the kernel
+debugger.  (It'd be nice to be able to treat these as lisp
+errors with the same caveats as described above, but that
+is more complicated in some cases and isn't yet implemented.)
 
 - An obscure kernel debugger command - (A), which tries to advance
-  the program counter by one instruction - is now disabled on x86-64.
-  (On the PPC, "one instruction" always meant "4 bytes"; implementing
-  this correctly on x86-64 would require the ability to at least
-  partially disassemble arbitrary x86-64 instructions.)
-
-  On the other hand, the kernel debugger should be able to show
-  FPU registers on x86-64.
+the program counter by one instruction - is now disabled on x86-64.
+(On the PPC, "one instruction" always meant "4 bytes"; implementing
+this correctly on x86-64 would require the ability to at least
+partially disassemble arbitrary x86-64 instructions.)
+
+On the other hand, the kernel debugger should be able to show
+FPU registers on x86-64.
 
 
 = OpenMCL 1.1-pre-070408 =
 - The FASL version changed (old FASL files won't work with this
-  lisp version), as did the version information which tries to
-  keep the kernel in sync with heap images.  Note that it's generally
-  a lot easier to recompile recent sources with recent images, e.g.,
-  trying to compile 070408 sources with an 070214 image is unlikely
-  to work without tricky bootstrapping.
+lisp version), as did the version information which tries to
+keep the kernel in sync with heap images.  Note that it's generally
+a lot easier to recompile recent sources with recent images, e.g.,
+trying to compile 070408 sources with an 070214 image is unlikely
+to work without tricky bootstrapping.
+
 - There's now a Trac bug-tracking/wiki site for OpenMCL at 
-  <http://trac.clozure.com/openmcl>.  It needs bug reports; please
-  visit that site and use the features there to report any bugs
-  that you find.
+<http://trac.clozure.com/openmcl>.  It needs bug reports; please
+visit that site and use the features there to report any bugs
+that you find.
+
 - DEFSTATIC (aka DEFGLOBAL)
-  (CCL:DEFSTATIC var value &optional doc-string)
-  is like DEFPARAMETER in that it proclaims the variable "var" to
-  be special, sets its value to "value", and sets the symbol's
-  VARIABLE documentation to the optional doc-string.  It differs
-  from DEFPARAMETER in that it further asserts that the variable
-  should never be bound dynamically in any thread (via LET/LAMBDA/etc.);
-  the compiler treats any attempts to bind a "static" variable as an
-  error.
-  It is legal to change the value of a "static" variable, but since
-  all threads see the same (static) binding of that variable it may
-  be necessary to synchronize assignments made from multiple threads.
-  (A "static" variable binding is effectively a shared, global resource;
-  a dynamic binding is thread-private.)
-  Access to the value of a static variable is typically faster than
-  is access to the value a special variable that's not proclaimed to
-  be "static".
-  This functionality has been in MCL/OpenMCL for a long time under
-  the name CCL:DEFGLOBAL; CCL:DEFGLOBAL is an alias for CCL:DEFSTATIC,
-  but the latter seemed to be a better name.
+{{{(CCL:DEFSTATIC var value &optional doc-string)}}}
+is like DEFPARAMETER in that it proclaims the variable "var" to
+be special, sets its value to "value", and sets the symbol's
+VARIABLE documentation to the optional doc-string.  It differs
+from DEFPARAMETER in that it further asserts that the variable
+should never be bound dynamically in any thread (via LET/LAMBDA/etc.);
+the compiler treats any attempts to bind a "static" variable as an
+error.
+
+It is legal to change the value of a "static" variable, but since
+all threads see the same (static) binding of that variable it may
+be necessary to synchronize assignments made from multiple threads.
+(A "static" variable binding is effectively a shared, global resource;
+a dynamic binding is thread-private.)
+
+Access to the value of a static variable is typically faster than
+is access to the value a special variable that's not proclaimed to
+be "static".
+
+This functionality has been in MCL/OpenMCL for a long time under
+the name CCL:DEFGLOBAL; CCL:DEFGLOBAL is an alias for CCL:DEFSTATIC,
+but the latter seemed to be a better name.
+
 - The type of foreign object that a MACPTR points to can now be
-  asserted (this means that a MACPTR object can contain a small
-  integer which identifies the alleged FOREIGN-TYPE of the object that
-  the points to.  RLET, MAKE-RECORD, and MAKE-GCABLE-RECORD (see below)
-  assert the foreign type of the object that the MACPTR object they
-  create (as do some new features of the ObjC bridge, described further
-  below.)
-  PRINT-OBJECT on a MACPTR will try to print information about the
-  asserted type of that pointer, as well as information about where
-  the pointer was allocated (heap, stack) and whether it's scheduled
-  for automatic reclamation by the GC.
-  A few constructs that conceivable should assert the type of the
-  pointers they create (e.g., some flavor of PREF, SLOT-VALUE in
-  the ObjC bridge) don't yet do so.
-  A rather obvious way of exploiting typed pointers - namely, extending
-  DESCRIBE and INSPECT to show the contents of foreign records - is
-  not yet implemented.
+asserted (this means that a MACPTR object can contain a small
+integer which identifies the alleged FOREIGN-TYPE of the object that
+the points to.  RLET, MAKE-RECORD, and MAKE-GCABLE-RECORD (see below)
+assert the foreign type of the object that the MACPTR object they
+create (as do some new features of the ObjC bridge, described further
+below.)
+
+PRINT-OBJECT on a MACPTR will try to print information about the
+asserted type of that pointer, as well as information about where
+the pointer was allocated (heap, stack) and whether it's scheduled
+for automatic reclamation by the GC.
+
+A few constructs that conceivable should assert the type of the
+pointers they create (e.g., some flavor of PREF, SLOT-VALUE in
+the ObjC bridge) don't yet do so.
+
+A rather obvious way of exploiting typed pointers - namely, extending
+DESCRIBE and INSPECT to show the contents of foreign records - is
+not yet implemented.
+
 - MAKE-GCABLE-RECORD is like MAKE-RECORD, in that it "makes an instance
-  of a foreign record type".  (Or, to be more banal about it, uses
-  #_malloc to allocate a block of foreign memory of the size of the
-  foreign record type named by its argument.)  MAKE-GCABLE-RECORD
-  additionally tells the lisp garbage collector that it should free
-  the foreign memory when the MACPTR object that describes it becomes
-  garbage.
-  When using "gcable pointers", it's important to remember the
-  distinction between a MACPTR object (which is a lisp object, more-
-  or-less like any other) and the block of foreign memory that the
-  MACPTR object points to.  If a gcable MACPTR is the only thing
-  in the world ("lisp world" or "foreign world") that references
-  the underlying block of foreign memory, then freeing the foreign
-  memory when it becomes impossible to reference it is convenient
-  and sane.  If other lisp MACPTRs reference the underlying block
-  of foreign memory or if the address of that foreign memory is
-  passed to and retained by foreign code, having the GC free the
-  memory may have unpleasant consequences if those other references
-  are used.
+of a foreign record type".  (Or, to be more banal about it, uses
+#_malloc to allocate a block of foreign memory of the size of the
+foreign record type named by its argument.)  MAKE-GCABLE-RECORD
+additionally tells the lisp garbage collector that it should free
+the foreign memory when the MACPTR object that describes it becomes
+garbage.
+
+When using "gcable pointers", it's important to remember the
+distinction between a MACPTR object (which is a lisp object, more-
+or-less like any other) and the block of foreign memory that the
+MACPTR object points to.  If a gcable MACPTR is the only thing
+in the world ("lisp world" or "foreign world") that references
+the underlying block of foreign memory, then freeing the foreign
+memory when it becomes impossible to reference it is convenient
+and sane.  If other lisp MACPTRs reference the underlying block
+of foreign memory or if the address of that foreign memory is
+passed to and retained by foreign code, having the GC free the
+memory may have unpleasant consequences if those other references
+are used.
+
 - CCL:FREE (which is mostly just a wrapper around #_free that allows
-  #_free to be called early in the bootstrapping process) is now 
-  exported; if its argument is a gcable pointer (e.g., created via
-  MAKE-GCABLE-POINTER), it will tell the GC that the pointer's
-  foreign memory has been freed "manually" before calling #_free.
+#_free to be called early in the bootstrapping process) is now 
+exported; if its argument is a gcable pointer (e.g., created via
+MAKE-GCABLE-POINTER), it will tell the GC that the pointer's
+foreign memory has been freed "manually" before calling #_free.
+
 - The mechanisms used to implement locks has changed (for the curious,
-  the changes involve the use of spinlocks rather than a sequence
-  of atomic additions.)  Someone demonstrated a case of deadlock
-  (where a thread was waiting for a lock that was available) under
-  the old implementation.  I'm not sure that I fully understand how
-  that could have happened, but the new implementation at least has
-  the advantage of being a little easier to understand and might be
-  a tiny bit faster.  Please let me know if either of these assumptions
-  was incorrect.
+the changes involve the use of spinlocks rather than a sequence
+of atomic additions.)  Someone demonstrated a case of deadlock
+(where a thread was waiting for a lock that was available) under
+the old implementation.  I'm not sure that I fully understand how
+that could have happened, but the new implementation at least has
+the advantage of being a little easier to understand and might be
+a tiny bit faster.  Please let me know if either of these assumptions
+was incorrect.
+
 - An EOF (control-d) in the REPL (when standard input is a tty or pty
-  device) has traditionally caused an exit to the outer break loop
-  (or had no effect if the REPL was not in a break loop).  If
-  CCL:*QUIT-ON-EOF* is set, an EOF causes the lisp to quit.  (It
-  actually invokes a listener-specific method, so in a multi-listener
-  window system environemt, it might simply cause the listener which
-  receives the EOF to exit.)
-  None of this has any effect when running under environments like
-  SLIME, and (as mentioned above) only matters if the standard input
-  devices is a tty or pseudo-tty (where it's possible to continue
-  reading after an EOF has been read.)  If running under an xterm
-  or OSX Terminal.app, standard input is probably a pty; if running
-  in an Emacs shell buffer or under other means under emacs, different
-  types of IPC mechanisms (pipes, sockets) might be used.
+device) has traditionally caused an exit to the outer break loop
+(or had no effect if the REPL was not in a break loop).  If
+CCL:*QUIT-ON-EOF* is set, an EOF causes the lisp to quit.  (It
+actually invokes a listener-specific method, so in a multi-listener
+window system environemt, it might simply cause the listener which
+receives the EOF to exit.)
+
+None of this has any effect when running under environments like
+SLIME, and (as mentioned above) only matters if the standard input
+devices is a tty or pseudo-tty (where it's possible to continue
+reading after an EOF has been read.)  If running under an xterm
+or OSX Terminal.app, standard input is probably a pty; if running
+in an Emacs shell buffer or under other means under emacs, different
+types of IPC mechanisms (pipes, sockets) might be used.
+
 - SAVE-APPLICATION has historically changed the type of all MACPTR
-  objects (turning them into "dead macptrs", since it's generally
-  meaningless to refer to a foreign pointer from a previous session
-  and generally better to get a type error than some more mysterious
-  or severe failure).  This no longer happens for null pointers (pointers
-  to address 0); COMPILE-FILE also now allows null pointers to be referenced
-  as constants in compiled code.
+objects (turning them into "dead macptrs", since it's generally
+meaningless to refer to a foreign pointer from a previous session
+and generally better to get a type error than some more mysterious
+or severe failure).  This no longer happens for null pointers (pointers
+to address 0); COMPILE-FILE also now allows null pointers to be referenced
+as constants in compiled code.
+
 - Not entirely coincidentally, CCL:+NULL-PTR+ is now defined as a constant
-  (whose value is a null pointer.)  In some cases, it may be more
-  efficient or convenient to pass CCL:+NULL-PTR+ to foreign code than
-  it would be to call (CCL:%NULL-PTR) to "produce" one.
+(whose value is a null pointer.)  In some cases, it may be more
+efficient or convenient to pass CCL:+NULL-PTR+ to foreign code than
+it would be to call (CCL:%NULL-PTR) to "produce" one.
+
 - Historically, OpenMCL (and MCL) have maintained a list of open file
-  streams in the value of CCL:*OPEN-FILE-STREAMS*; maintaining this
-  list helps to ensure that streams get closed in as orderly a manner
-  as possible when the lisp exits.  The code which accessed this list
-  didn't do so in a thread-safe manner.
-  The list is now maintained in a lexical variable; the function
-  CCL:OPEN-FILE-STREAMS returns a copy of that list, 
-  CCL:NOTE-OPEN-FILE-STREAM adds its argument (a file stream) to the
-  list, and CCL:REMOVE-OPEN-FILE-STREAM removes its argument (a file stream)
-  from the list.  (All of these functions use appropriate locking.)
+streams in the value of CCL:*OPEN-FILE-STREAMS*; maintaining this
+list helps to ensure that streams get closed in as orderly a manner
+as possible when the lisp exits.  The code which accessed this list
+didn't do so in a thread-safe manner.
+
+The list is now maintained in a lexical variable; the function
+CCL:OPEN-FILE-STREAMS returns a copy of that list, 
+CCL:NOTE-OPEN-FILE-STREAM adds its argument (a file stream) to the
+list, and CCL:REMOVE-OPEN-FILE-STREAM removes its argument (a file stream)
+from the list.  (All of these functions use appropriate locking.)
+
 - There were a number of timing-related problems related to PROCESS-INTERRUPT
-  (usually involving rapidly and repeatedly interrupting a thread over
-  a long period of time.)  This should be a lot more reliable now
-  (exactly what could go wrong and why and how is all a little hard to
-  describe.) 
+(usually involving rapidly and repeatedly interrupting a thread over
+a long period of time.)  This should be a lot more reliable now
+(exactly what could go wrong and why and how is all a little hard to
+describe.) 
+
 - Some Linux distributions may initialize the user's environment in
-  a way that imposes a soft limit on the amount of virtual memory that
-  a process is allowed to map.  OpenMCL now tries to raise this limit
-  before reserving what may be a very large amount of address space,
-  thanks to a patch from Andi Kleen.
+a way that imposes a soft limit on the amount of virtual memory that
+a process is allowed to map.  OpenMCL now tries to raise this limit
+before reserving what may be a very large amount of address space,
+thanks to a patch from Andi Kleen.
+
 - There were a number of problems with UTF-16 streams, found and
-  fixed by Takehiko Abe.
+fixed by Takehiko Abe.
+
 - Takehiko Abe also provided fixes for some code in "ccl:lib;xref.lisp"
-  and in source-file recording/reporting that (still) didn't understand
-  the concept of EQL-SPECIALIZER metaobjects.
+and in source-file recording/reporting that (still) didn't understand
+the concept of EQL-SPECIALIZER metaobjects.
+
 - ObjC bridge and ObjC examples
-  The ObjC bridge provides a few new mechanisms for defining ObjC
-  methods, for calling ObjC "generic functions" (e.g., message sending),
-  and for dealing with frequently-used record types and with differences
-  between 32-bit and (forthcoming) 64-bit ObjC/Cocoa implementations.
+The ObjC bridge provides a few new mechanisms for defining ObjC
+methods, for calling ObjC "generic functions" (e.g., message sending),
+and for dealing with frequently-used record types and with differences
+between 32-bit and (forthcoming) 64-bit ObjC/Cocoa implementations.
   
-  A lot of macros/functions/other things that really should have been
-  exported from some package for the last few years finally have been
-  exported from the OBJC or NS packages (and a lot of things that have
-  historically been internal to CCL are re-imported into CCL).
-
-  Cocoa (and the underlying Core Graphics libraries) have historically
-  used 32-bit floats and 32-bit integers in data structures that describe
-  geometry, font sizes and metrics, and elsewhere.  64-bit Cocoa will
-  use 64-bit floats and 64-bit integers in many cases.
-
-  The bridge defines the type NS:CGFLOAT as the lisp type of the 
-  preferred float type on the platform, and the constant NS:+CGFLOAT+.
-  On DarwinPPC32, the foreign types :cgfloat, :<NSUI>nteger, and
-  :<NSI>nteger are defined by the bridge (as 32-bit float, 32-bit
-  unsigned integer, and 32-bit signed integer, respectively.); these 
-  types are defined (as 64-bit variants) in the 64-bit interfaces.
-
-  All ObjC classes are properly named, either with a name exported
-  from the NS package (in the case of a predefined class declared in
-  the interface files) or with the name provided in the DEFCLASS
-  form (with :METACLASS NS:+NS-OBJECT) which defines the class from
-  lisp.  The class's lisp name is now proclaimed to be a "static"
-  variable (as if by DEFSTATIC, as described above) and given the
-  class object as its value.  In other words:
+A lot of macros/functions/other things that really should have been
+exported from some package for the last few years finally have been
+exported from the OBJC or NS packages (and a lot of things that have
+historically been internal to CCL are re-imported into CCL).
+
+Cocoa (and the underlying Core Graphics libraries) have historically
+used 32-bit floats and 32-bit integers in data structures that describe
+geometry, font sizes and metrics, and elsewhere.  64-bit Cocoa will
+use 64-bit floats and 64-bit integers in many cases.
+
+The bridge defines the type NS:CGFLOAT as the lisp type of the 
+preferred float type on the platform, and the constant NS:+CGFLOAT+.
+On DarwinPPC32, the foreign types :cgfloat, :<NSUI>nteger, and
+:<NSI>nteger are defined by the bridge (as 32-bit float, 32-bit
+unsigned integer, and 32-bit signed integer, respectively.); these 
+types are defined (as 64-bit variants) in the 64-bit interfaces.
+
+All ObjC classes are properly named, either with a name exported
+from the NS package (in the case of a predefined class declared in
+the interface files) or with the name provided in the DEFCLASS
+form (with :METACLASS NS:+NS-OBJECT) which defines the class from
+lisp.  The class's lisp name is now proclaimed to be a "static"
+variable (as if by DEFSTATIC, as described above) and given the
+class object as its value.  In other words:
 
 {{{
@@ -493 +518 @@
 }}}
 
-  and
+and
 
 {{{
@@ -499 +524 @@
 }}}
 
-  are equivalent.  (Since it's not legal to bind a "static" variable,
-  it may be necessary to rename some things so that unrelated
-  variables whose names coincidentally conflict with ObjC class names
-  don't do so.)
+are equivalent.  (Since it's not legal to bind a "static" variable,
+it may be necessary to rename some things so that unrelated
+variables whose names coincidentally conflict with ObjC class names
+don't do so.)
 
 - A new reader macro - #/ - reads a sequence of "constituent" characters
-  (including colons) from the stream on which it appears and interns
-  that sequence - with case preserved and colons intact - in a new package
-  whose name is NEXTSTEP-FUNCTIONS, exporting the symbol from that package.
-  This means that the act of reading "#/alloc" returns the the symbol
-  NEXTSTEP-FUNCTIONS:|alloc|, and the act of reading "#/initWithFrame:"
-  returns the symbol NEXTSTEP-FUNCTIONS:|initWithFrame:|.  The intent
-  is that the reader macro can be used to construct symbols whose names
-  match ObjC message names; the reader macro tries to do some sanity
-  checks (such as insisting that a name that contains at least one
-  colon ends in a colon), but isn't totally rigourous about enforcing
-  ObjC message name conventions.
-
-  A symbol read using this macro can be used as an operand in
-  most places where an ObjC message name can be used, such as
-  in the (@SELECTOR ...) construct (which is now OBJC:@SELECTOR, 
-  btw.)
-
-  Marco Baringer proposed the idea of using a reader macro to
-  construct lisp symbols which matched ObjC message names.
+(including colons) from the stream on which it appears and interns
+that sequence - with case preserved and colons intact - in a new package
+whose name is NEXTSTEP-FUNCTIONS, exporting the symbol from that package.
+This means that the act of reading "#/alloc" returns the the symbol
+NEXTSTEP-FUNCTIONS:|alloc|, and the act of reading "#/initWithFrame:"
+returns the symbol NEXTSTEP-FUNCTIONS:|initWithFrame:|.  The intent
+is that the reader macro can be used to construct symbols whose names
+match ObjC message names; the reader macro tries to do some sanity
+checks (such as insisting that a name that contains at least one
+colon ends in a colon), but isn't totally rigourous about enforcing
+ObjC message name conventions.
+
+A symbol read using this macro can be used as an operand in
+most places where an ObjC message name can be used, such as
+in the (@SELECTOR ...) construct (which is now OBJC:@SELECTOR, 
+btw.)
+
+Marco Baringer proposed the idea of using a reader macro to
+construct lisp symbols which matched ObjC message names.
 
 - The act of interning a new symbol in the NEXTSTEP-FUNCTIONS
-  package triggers an interface database lookup of Objc methods
-  with the corresponding message name.  If any such information
-  is found, a special type of dispatching function is created
-  and initialized and the weird-looking symbol is given that
-  dispatching function as its function definition.
-
-  The dispatching knows how to call declared ObjC methods defined on
-  the message.  In many cases, all methods have the same foreign type
-  signature, and the dispatching function merely passes any arguments
-  that it receives to a function that does an ObjC message send with
-  the indicated foreign argument and return types.  In other cases,
-  where different ObjC messages have different type signatures, the
-  dispatching function tries to choose a function that handles the
-  right type signature based on the class of the dispatching function's
-  first argument.
-
-  If new information about ObjC methods is introduced (e.g., by
-  using additional interface files or as ObjC methods are defined
-  from lisp), the dispatch function is reinitialized to recognize
-  newly-introduced foreign type signatures.
-
-  The argument and result coercion that the bridge has tradionally
-  supported is supported by the new mechanism (e.g., :<BOOL> arguments
-  can be specified as lisp booleans and :<BOOL> results are returned
-  as lisp boolean values, and an argument value of NIL is coerced to
-  a null pointer if the corresponding argument type is :ID.
-
-  Some ObjC methods accept variable numbers of arguments; the
-  foreign types of non-required arguments are determined by the
-  lisp types of those arguments (e.g., integers are passed as
-  integers, floats as floats, pointers as pointers, record types
-  by reference.)
-
-  Some examples:
+package triggers an interface database lookup of Objc methods
+with the corresponding message name.  If any such information
+is found, a special type of dispatching function is created
+and initialized and the weird-looking symbol is given that
+dispatching function as its function definition.
+
+The dispatching function knows how to call declared ObjC methods defined on
+the message.  In many cases, all methods have the same foreign type
+signature, and the dispatching function merely passes any arguments
+that it receives to a function that does an ObjC message send with
+the indicated foreign argument and return types.  In other cases,
+where different ObjC messages have different type signatures, the
+dispatching function tries to choose a function that handles the
+right type signature based on the class of the dispatching function's
+first argument.
+
+If new information about ObjC methods is introduced (e.g., by
+using additional interface files or as ObjC methods are defined
+from lisp), the dispatch function is reinitialized to recognize
+newly-introduced foreign type signatures.
+
+The argument and result coercion that the bridge has tradionally
+supported is supported by the new mechanism (e.g., :<BOOL> arguments
+can be specified as lisp booleans and :<BOOL> results are returned
+as lisp boolean values, and an argument value of NIL is coerced to
+a null pointer if the corresponding argument type is :ID.
+
+Some ObjC methods accept variable numbers of arguments; the
+foreign types of non-required arguments are determined by the
+lisp types of those arguments (e.g., integers are passed as
+integers, floats as floats, pointers as pointers, record types
+by reference.)
+
+Some examples:
 
 {{{
@@ -579 +604 @@
 }}}
 
-  ObjC methods that "return" structures return them as gcable pointers
-  when called via dispatch functions.  E.g., if "my-window" is an
-  NS:NS-WINDOW instance, then
+ObjC methods that "return" structures return them as gcable pointers
+when called via dispatch functions.  E.g., if "my-window" is an
+NS:NS-WINDOW instance, then
 
 {{{
@@ -587 +612 @@
 }}}
 
-  will return a gcable pointer to a structure that describes that window's
-  frame rectangle.  (The good news is that there's no need to use SLET
-  or special structure-returning message send syntax; the bad news is
-  that #_malloc, #_free, and the GC are all involved in the creation
-  and eventual destruction of structure-typed return values.  Unless
-  and until those factors negatively affect performance, the advantages
-  seem to outweigh the disadvantages.)
+will return a gcable pointer to a structure that describes that window's
+frame rectangle.  (The good news is that there's no need to use SLET
+or special structure-returning message send syntax; the bad news is
+that #_malloc, #_free, and the GC are all involved in the creation
+and eventual destruction of structure-typed return values.  Unless
+and until those factors negatively affect performance, the advantages
+seem to outweigh the disadvantages.)
 
 - Since foreign pointers are now (sometimes, somewhat) typed, it's
-  possible to treat pointers to some foreign types as "instances of
-  built-in classes."  Specifically, a pointer to an :<NSR>ect is
-  recognized as an instance of the built-in class NS:NS-RECT, a
-  pointer to an <NSS>ize is treated as an instance of NS:NS-SIZE,
-  <NSP>oint is recognized as NS:NS-POINT, and <NSR>ange maps to
-  NS:NS-RANGE.  (There are a few other more obscure structure
-  types that get this treatment, and with a little more work the
-  mechanism could be made extensible.)
-
-  For each of these built-in classes:
-
-  - a PRINT-OBJECT method is defined
-
-  - a foreign type name derived from the class name (e.g., :NS-RECT
+possible to treat pointers to some foreign types as "instances of
+built-in classes."  Specifically, a pointer to an :<NSR>ect is
+recognized as an instance of the built-in class NS:NS-RECT, a
+pointer to an <NSS>ize is treated as an instance of NS:NS-SIZE,
+<NSP>oint is recognized as NS:NS-POINT, and <NSR>ange maps to
+NS:NS-RANGE.  (There are a few other more obscure structure
+types that get this treatment, and with a little more work the
+mechanism could be made extensible.)
+
+For each of these built-in classes:
+
+  * a PRINT-OBJECT method is defined
+
+  * a foreign type name derived from the class name (e.g., :NS-RECT
     for NS:NS-RECT) is made an alias for the corresponding type
     (so it's possible to say (RLET ((R :NS-RECT)) ...)).