Comment latest improvements.

src/CHANGELOG

@@ -883,6 +883,10 @@ ECLS 0.5
 ECL 0.6
 =======
 
+* Supported platforms:
+
+  - ECL now compiles and runs in static mode under MacOSX.
+
 * Errors fixed:
 
   - Code for handling :IMPORT-FROM in DEFPACKAGE was bogus
@@ -921,6 +925,13 @@ ECL 0.6
     routine SI::MANGLE-NAME, output the right name for any symbol
     which is in this array.
 
+  - ECL relies fully on the Boehm-Weiser garbage collector
+    (v. 6.1). The old garbage collector is known to reclaim too much
+    data, resulting in heap corruption. Help is welcome on this field.
+
+  - The headers of the Boehm-Weiser garbage collector are installed
+    together with ECL.
+
 * Visible changes and ANSI compatibility:
 
   - New configuration flag --with-clos-streams, enables the user to

src/doc/goals.in.html

@@ -80,6 +80,7 @@ href="http://ecls.sourceforge.net">ECL</a>, either statically or at runtime.
 <li>Debian Linux on PowerPC</li>
 <li>FreeBSD 4.x</li>
 <li>Cygwin on Intel Windows</li>
+<li>MacOSX</li>
 </ul>
 Most of the code is portable. The parts
 which change from operating system to operating system are about the
@@ -97,13 +98,10 @@ platform, but work is in progress to remove GCC dependencies.
 
 <li><b>Better garbage collection.</b>
 
-<p>As of this release the memory that <a
-href="http://ecls.sourceforge.net">ECL</a> can allocate is restricted to
-16Mb. I have tried replacing the garbage collector with a conservative one
-(Boehm's GC v 4.11) and that did fix the problems, but increases the memory
-requirements of <a href="http://ecls.sourceforge.net">ECL</a>. Since this is
-really undesirable, I have been also thinking about revamping the current
-garbage collector with an interface to mmap(). Time wil tell...
+<p>As of this release the ECL fully relies on the Boehm-Weiser Garbage
+Collector. This increases the memory requirements of <a
+href="http://ecls.sourceforge.net">ECL</a> with respect to the old
+garbage collector, but the whole environment results faster and more robust.
 
 <li><b>Improve the compiler: more agressive inlining, better operations among
 numbers and unboxed arrays of complex numbers.</b>