[pypy-commit] pypy.org extradoc: Regenerate.

[arigo]

Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r341:96983be9602c
Date: 2012-03-08 08:24 -0800
http://bitbucket.org/pypy/pypy.org/changeset/96983be9602c/

Log:	Regenerate.

diff --git a/numpydonate.html b/numpydonate.html
--- a/numpydonate.html
+++ b/numpydonate.html
@@ -65,7 +65,7 @@
 at the latest, we will try our best to make PyPy support NumPy anyway.  We
 however reserve the right to shift any unused funds to other PyPy activities
 when that date is reached.  Of course, since the Conservancy is a
-501(c)(3) charitable organization incorporated in NY, USA, all funds will,
+501&copy;(3) charitable organization incorporated in NY, USA, all funds will,
 regardless of their use, be spent in a way that benefits the general
 public, the advancement of Open Source and Free Software,
 and in particular the PyPy community and the PyPy codebase.</p>
diff --git a/py3donate.html b/py3donate.html
--- a/py3donate.html
+++ b/py3donate.html
@@ -74,7 +74,7 @@
 at the latest, we will try our best to make PyPy support Python 3 anyway.  We
 however reserve the right to shift any unused funds to other PyPy activities
 when that date is reached.  Of course, since the Conservancy is a
-501(c)(3) charitable organization incorporated in NY, USA, all funds will,
+501&copy;(3) charitable organization incorporated in NY, USA, all funds will,
 regardless of their use, be spent in a way that benefits the general
 public, the advancement of Open Source and Free Software,
 and in particular the PyPy community and the PyPy codebase.</p>
diff --git a/tmdonate.html b/tmdonate.html
--- a/tmdonate.html
+++ b/tmdonate.html
@@ -62,7 +62,7 @@
 to use and that have an impact on the structure of the whole program.</p>
 <p>This proposal is about researching and implementing Transactional Memory
 in PyPy.  This is a technique that recently came to the front of the
-multi-core scene.  It promizes to offer multi-core CPU usage without
+multi-core scene.  It promises to offer multi-core CPU usage without
 requiring to fall back to the multi-process solutions described above,
 and also without using the <tt class="docutils literal">threading</tt> module &ndash; just as a small,
 local extension of the programming language that would be used only in
@@ -134,7 +134,7 @@
 <div class="section" id="a-gil-less-python-is-impossible">
 <h2>A GIL-less Python is impossible.</h2>
 <p>This is a classic criticism of research-oriented projects.  We believe
-that the <a class="reference internal" href="#work-plan">work plan</a> plan below can make a serious impact on considering
+that the <a class="reference internal" href="#work-plan">work plan</a> below can make a serious impact on considering
 possible a GIL-less Python.  We believe we can do it, but at the
 very least, even if this work generates a negative result, the negative
 result will document the challenges faced should someone else want to
@@ -234,7 +234,7 @@
 alternatives.  In particular, small quickly-written programs don't need
 the additional baggage of cross-process communication, and large
 programs can sometimes be almost impossible to turn into multi-process
-versions.  By constrast, we believe that TM can fit naturally into most
+versions.  By contrast, we believe that TM can fit naturally into most
 programs, because it only requires local changes to some dispatcher; the
 rest of the program should work without changes.</p>
 </div>