[pypy-svn] pypy default: Big patch by victorg5: fix typos in pypy/doc/, found by aspell.

arigo commits-noreply at bitbucket.org
Wed Feb 9 15:51:57 CET 2011 

Author: Armin Rigo <arigo at tunes.org>
Branch: 
Changeset: r41731:d0dd8792776a
Date: 2011-02-09 15:51 +0100
http://bitbucket.org/pypy/pypy/changeset/d0dd8792776a/

Log:	Big patch by victorg5: fix typos in pypy/doc/, found by aspell.

diff --git a/pypy/doc/config/translation.backendopt.clever_malloc_removal.txt b/pypy/doc/config/translation.backendopt.clever_malloc_removal.txt
--- a/pypy/doc/config/translation.backendopt.clever_malloc_removal.txt
+++ b/pypy/doc/config/translation.backendopt.clever_malloc_removal.txt
@@ -1,6 +1,6 @@
 Try to inline flowgraphs based on whether doing so would enable malloc
 removal (:config:`translation.backendopt.mallocs`.) by eliminating
-calls that result in escaping. This is an experimental optimisation,
+calls that result in escaping. This is an experimental optimization,
 also right now some eager inlining is necessary for helpers doing
 malloc itself to be inlined first for this to be effective.
 This option enable also an extra subsequent malloc removal phase.

diff --git a/pypy/doc/coding-guide.txt b/pypy/doc/coding-guide.txt
--- a/pypy/doc/coding-guide.txt
+++ b/pypy/doc/coding-guide.txt
@@ -219,7 +219,7 @@
 
   ``range`` and ``xrange`` are identical. ``range`` does not necessarily create an array,
   only if the result is modified. It is allowed everywhere and completely
-  implemented. The only visible difference to CPython is the inaccessability
+  implemented. The only visible difference to CPython is the inaccessibility
   of the ``xrange`` fields start, stop and step.
 
 **definitions**
@@ -306,7 +306,7 @@
   concerns mainly method calls, when the method is overridden or in any
   way given different definitions in different classes.  It also concerns
   the less common case of explicitly manipulated function objects.
-  Describing the exact compability rules is rather involved (but if you
+  Describing the exact compatibility rules is rather involved (but if you
   break them, you should get explicit errors from the rtyper and not
   obscure crashes.)
 
@@ -466,9 +466,9 @@
 (>=0.13.0) can be run with the ``--rpython-mode`` command line option. This option
 enables the RPython checker which will checks for some of the
 restrictions RPython adds on standard Python code (and uses a 
-more agressive type inference than the one used by default by
+more aggressive type inference than the one used by default by
 pylint). The full list of checks is available in the documentation of
-Pylin. 
+Pylint. 
 
 RPylint can be a nice tool to get some information about how much work
 will be needed to convert a piece of Python code to RPython, or to get
@@ -636,7 +636,7 @@
 
 When we need access to interpreter-level objects we put the module into
 `pypy/module`_.  Such modules use a `mixed module mechanism`_
-which makes it convenient to use both interpreter- and applicationlevel parts
+which makes it convenient to use both interpreter- and application-level parts
 for the implementation.  Note that there is no extra facility for
 pure-interpreter level modules, you just write a mixed module and leave the
 application-level part empty.

diff --git a/pypy/doc/config/translation.type_system.txt b/pypy/doc/config/translation.type_system.txt
--- a/pypy/doc/config/translation.type_system.txt
+++ b/pypy/doc/config/translation.type_system.txt
@@ -1,4 +1,4 @@
 Which type system to use when rtyping_. This option should not be set
-explicitely.
+explicitly.
 
 .. _rtyping: ../rtyper.html

diff --git a/pypy/doc/discussion/distribution-newattempt.txt b/pypy/doc/discussion/distribution-newattempt.txt
--- a/pypy/doc/discussion/distribution-newattempt.txt
+++ b/pypy/doc/discussion/distribution-newattempt.txt
@@ -54,7 +54,7 @@
 
 We need:
 
-* app-level primitives for having 'remote proxy' accessable
+* app-level primitives for having 'remote proxy' accessible
 
 * some "serialiser" which is not truly serialising stuff, but making
   sure communication will go.

diff --git a/pypy/doc/glossary.txt b/pypy/doc/glossary.txt
--- a/pypy/doc/glossary.txt
+++ b/pypy/doc/glossary.txt
@@ -195,7 +195,7 @@
 
 **translation-time**
    In the context of the JIT_, translation time is when the PyPy
-   source is being analysed and the JIT itself is being created.
+   source is being analyzed and the JIT itself is being created.
 
 .. _`translator`:
 

diff --git a/pypy/doc/discussion/somepbc-refactoring-plan.txt b/pypy/doc/discussion/somepbc-refactoring-plan.txt
--- a/pypy/doc/discussion/somepbc-refactoring-plan.txt
+++ b/pypy/doc/discussion/somepbc-refactoring-plan.txt
@@ -27,7 +27,7 @@
 
 To be declared in module pypy.annotator.desc, with a mapping
 annotator.bookkeeper.descs = {<python object>: <XxxDesc instance>}
-accessed with bookkeepeer.getdesc(<python object>).
+accessed with bookkeeper.getdesc(<python object>).
 
 Maybe later the module should be moved out of pypy.annotation but for now I
 suppose that it's the best place.

diff --git a/pypy/doc/discussion/security-ideas.txt b/pypy/doc/discussion/security-ideas.txt
--- a/pypy/doc/discussion/security-ideas.txt
+++ b/pypy/doc/discussion/security-ideas.txt
@@ -191,7 +191,7 @@
     def serve_admin(token):
         print "Highest big is:", declassify(highest_bid, token=token)
 
-The declassify() function reads the value if the "token" is priviledged
+The declassify() function reads the value if the "token" is privileged
 enough, and raises an exception otherwise.
 
 What are we protecting here?  The fact that we need the administrator

diff --git a/pypy/doc/config/translation.gcrootfinder.txt b/pypy/doc/config/translation.gcrootfinder.txt
--- a/pypy/doc/config/translation.gcrootfinder.txt
+++ b/pypy/doc/config/translation.gcrootfinder.txt
@@ -2,7 +2,7 @@
 methods, this is mostly only interesting for framework GCs. For those you have
 a choice of various alternatives:
 
- - use a shadow stack (XXX link to paper), e.g. explicitely maintaining a stack
+ - use a shadow stack (XXX link to paper), e.g. explicitly maintaining a stack
    of roots
 
  - use stackless to find roots by unwinding the stack.  Requires

diff --git a/pypy/doc/dev_method.txt b/pypy/doc/dev_method.txt
--- a/pypy/doc/dev_method.txt
+++ b/pypy/doc/dev_method.txt
@@ -77,11 +77,11 @@
     pairs.
 
 It is a method that fits distributed teams well because it gets the team
-focused around clear (and challenging) goals while working collarobative
+focused around clear (and challenging) goals while working collaborative
 (pairprogramming, status meeting, discussions etc) as well as accelerated
 (short increments and tasks, "doing" and testing instead of long start ups of
 planning and requirement gathering). This means that most of the time a sprint
-is a great way of getting results, but also to get new people aquinted with
+is a great way of getting results, but also to get new people acquainted with
 the codebase. It is also a great method for dissemination and learning within
 the team because of the pairprogramming.
 
@@ -112,7 +112,7 @@
    month before the event. Beforehand we have some rough plans called "between
    sprints" and the sprintplan is based on the status of those issues but also
    with a focus on upcoming releases and deliverables. Usually its the core
-   developers who does this but the transparancy and participation have
+   developers who does this but the transparency and participation have
    increased since we started with our weekly "pypy-sync meetings" on IRC. The
    sync meetings in combination with a rough in between planning makes it
    easier for other developer to follow the progress and thus participating in
@@ -121,7 +121,7 @@
    The goal needs to be challenging or it won't rally the full effort of the
    team, but it must not be unrealistic as that tends to be very frustrating
    and dissatisfying. It is also very important to take into account the
-   particpants when you set the goal for the sprint. If the sprint takes place
+   participants when you set the goal for the sprint. If the sprint takes place
    connected to a conference (or similar open events) the goals for the actual
    coding progress should be set lower (or handled in another way) and focus
    should shift to dissemination and getting new/interested people to a
@@ -140,8 +140,8 @@
    evacuated by 23:00? These are important questions that can gravely affect
    the "feel and atmosphere" of the sprint as well as the desired results!
 
-   Also, somewhat close to low cost places to eat and accomodate
-   participants. Facilities for making tea/coffe as well as some kind of
+   Also, somewhat close to low cost places to eat and accommodate
+   participants. Facilities for making tea/coffee as well as some kind of
    refrigerator for storing food. A permanent Internet connection is a must -
    has the venue were the sprint is planned to be weird rules for access to
    their network etc etc?
@@ -151,7 +151,7 @@
    project also owns one beamer - specifically for sprint purposes.
 
    The person making sure that the requirements for a good sprint venue is
-   being met should therefore have very good local connections or, preferrably
+   being met should therefore have very good local connections or, preferably
    live there.
 
 3. Information - discussions about content and goals (pre announcements) are
@@ -164,7 +164,7 @@
    the sprint announcements points to information about local transportation
    (to the country and to the city and to the venue), currency issues, food
    and restaurants etc. There are also webpages in which people announce when
-   they will arrive and where they are accomodated.
+   they will arrive and where they are accommodated.
 
    The planning text for the sprint is updated up till the sprint and is then
    used during the status meetings and between to track work. After the sprint
@@ -174,11 +174,11 @@
    people involved. 
 
    One very important strategy when planning the venue is cost
-   efficiency. Keeping accomodation and food/travel costs as low as possible
+   efficiency. Keeping accommodation and food/travel costs as low as possible
    makes sure that more people can afford to visit or join the sprint
    fully. The partially EU funded parts of the project do have a so called sprint budget
    which we use to try to help developers to participate in our sprints
-   (travel expenses and accomodation) and because most of the funding is so
+   (travel expenses and accommodation) and because most of the funding is so
    called matched funding we pay for most of our expenses in our own
    organizations and companies anyway.
  
@@ -205,8 +205,8 @@
    formally responsible for the sprints.
 
    Suggestions for off hours activities and social events for the break day is
-   a good way of emphazising how important it is to take breaks - some
-   pointers in that direction from the local organiziser is good.
+   a good way of emphasizing how important it is to take breaks - some
+   pointers in that direction from the local organizer is good.
 
    At the end of the sprint we do a technical summary (did we achieve the
    goals/content), what should be a rough focus for the work until the next
@@ -231,7 +231,7 @@
 
 Of course. Just follow the work on pypy-dev and if you specifically are
 interested in information about our sprints - subscribe to
-pypy-sprint at codespeak.net and read the news on codespeak for anouncements etc.
+pypy-sprint at codespeak.net and read the news on codespeak for announcements etc.
 
 If you think we should sprint in your town - send us an email - we are very
 interested in using sprints as away of making contact with active developers

diff --git a/pypy/doc/config/objspace.usemodules.zipimport.txt b/pypy/doc/config/objspace.usemodules.zipimport.txt
--- a/pypy/doc/config/objspace.usemodules.zipimport.txt
+++ b/pypy/doc/config/objspace.usemodules.zipimport.txt
@@ -1,3 +1,3 @@
-This module implements zipimport mechanise described
+This module implements zipimport mechanism described
 in PEP 302. It's supposed to work and translate, so it's included
 by default
\ No newline at end of file

diff --git a/pypy/doc/architecture.txt b/pypy/doc/architecture.txt
--- a/pypy/doc/architecture.txt
+++ b/pypy/doc/architecture.txt
@@ -14,7 +14,7 @@
 We aim to provide:
 
  * a common translation and support framework for producing
-   implementations of dynamic languages, emphasising a clean
+   implementations of dynamic languages, emphasizing a clean
    separation between language specification and implementation
    aspects.
 

diff --git a/pypy/doc/discussion/distribution-implementation.txt b/pypy/doc/discussion/distribution-implementation.txt
--- a/pypy/doc/discussion/distribution-implementation.txt
+++ b/pypy/doc/discussion/distribution-implementation.txt
@@ -14,7 +14,7 @@
 
 First we do split objects into value-only primitives (like int) and other.
 Basically immutable builtin types which cannot contain user-level objects
-(int, float, long, str, None, etc.) will be always transfered as value-only
+(int, float, long, str, None, etc.) will be always transferred as value-only
 objects (having no states etc.). The every other object (user created classes,
 instances, modules, lists, tuples, etc. etc.) are always executed by reference.
 (Of course if somebody wants to ie. copy the instance, he can marshal/pickle
@@ -65,7 +65,7 @@
   but not needed yet.
 
 * From the remote point of view, every exported object which needs such
-  has got a local apropriate storage W_LocalXXX where XXX is a type 
+  has got a local appropriate storage W_LocalXXX where XXX is a type 
   by which it could be accessed from a wire.
 
 The real pain:
@@ -76,7 +76,7 @@
 in annotator, which sucks a lot). The (some) idea is to wrap all the methods
 with additional checks, but that's both unclear and probably not necessary.
 
-XXX If we can easily change underlaying implementation of an object, than
+XXX If we can easily change underlying implementation of an object, than
 this might become way easier. Right now I'll try to have it working and
 thing about RPython later.
 

diff --git a/pypy/doc/discussion/VM-integration.txt b/pypy/doc/discussion/VM-integration.txt
--- a/pypy/doc/discussion/VM-integration.txt
+++ b/pypy/doc/discussion/VM-integration.txt
@@ -24,7 +24,7 @@
   - handle native .NET objects as transparently as possible
 
   - automatically apply obvious Python <--> .NET conversions when
-    crossing the borders (e.g. intgers, string, etc.)
+    crossing the borders (e.g. integers, string, etc.)
 
 One possible solution is the "proxy" approach, in which we manually
 (un)wrap/(un)box all the objects when they cross the border.
@@ -64,13 +64,13 @@
 stateful part and a behavioral part.
 
 We need to introduce the new ootypesystem type ``Pair``: it acts like
-a Record but it hasn't its own identiy: the id of the Pair is the id
+a Record but it hasn't its own identity: the id of the Pair is the id
 of its first member.
 
   XXX about ``Pair``: I'm not sure this is totally right. It means
   that an object can change identity simply by changing the value of a
   field???  Maybe we could add the constraint that the "id" field
-  can't be modifiend after initialization (but it's not easy to
+  can't be modified after initialization (but it's not easy to
   enforce).
 
   XXX-2 about ``Pair``: how to implement it in the backends? One

diff --git a/pypy/doc/eventhistory.txt b/pypy/doc/eventhistory.txt
--- a/pypy/doc/eventhistory.txt
+++ b/pypy/doc/eventhistory.txt
@@ -1,7 +1,7 @@
 
 
     The PyPy project is a worldwide collaborative effort and its
-    members are organising sprints and presenting results at conferences
+    members are organizing sprints and presenting results at conferences
     all year round.  **This page is no longer maintained!**  See `our blog`_
     for upcoming events. 
 
@@ -120,7 +120,7 @@
 
 The Mallorca sprint that took place in Palma de Mallorca is over.
 Topics included progressing with the JIT work started in G&#246;teborg
-and Paris, GC and optimisation work, stackless, and
+and Paris, GC and optimization work, stackless, and
 improving our way to write glue code for C libraries.
 
 Read more in `the announcement`_, there is a `sprint report`_

diff --git a/pypy/doc/index-report.txt b/pypy/doc/index-report.txt
--- a/pypy/doc/index-report.txt
+++ b/pypy/doc/index-report.txt
@@ -30,7 +30,7 @@
 `D08.2 JIT Compiler Architecture`_ is a report about the Architecture and
 working of our JIT compiler generator. *(2007-05-01)*
 
-`D08.1 JIT Compiler Release`_ reports on our sucessfully including a
+`D08.1 JIT Compiler Release`_ reports on our successfully including a
 JIT compiler for Python and the novel framework we used to
 automatically generate it in PyPy 1.0. *(2007-04-30)*
 
@@ -76,7 +76,7 @@
 
 
 `D02.1 Development Tools and Website`_ is a report
-about the codespeak_ development environment and aditional tool support for the
+about the codespeak_ development environment and additional tool support for the
 PyPy development process. *(2007-03-21)*
 
 `D03.1 Extension Compiler`_ is a report about

diff --git a/pypy/doc/interpreter.txt b/pypy/doc/interpreter.txt
--- a/pypy/doc/interpreter.txt
+++ b/pypy/doc/interpreter.txt
@@ -35,7 +35,7 @@
 module body source codes.  Interpreting such code objects means
 instantiating and initializing a `Frame class`_ and then
 calling its ``frame.eval()`` method.  This main entry point 
-initialise appropriate namespaces and then interprets each 
+initialize appropriate namespaces and then interprets each 
 bytecode instruction.  Python's standard library contains
 the `lib-python/2.5.2/dis.py`_ module which allows to view
 the Virtual's machine bytecode instructions:: 
@@ -278,11 +278,11 @@
 ---------------------- 
 
 A unique PyPy property is the ability to easily cross the barrier
-between interpreted and machine-level code (often refered to as
+between interpreted and machine-level code (often referred to as
 the difference between `interpreter-level and application-level`_). 
 Be aware that the according code (in `pypy/interpreter/gateway.py`_) 
 for crossing the barrier in both directions is somewhat
-involved, mostly due to the fact that the type-infering
+involved, mostly due to the fact that the type-inferring
 annotator needs to keep track of the types of objects flowing
 across those barriers. 
 
@@ -323,7 +323,7 @@
 Summarizing, the ``interp2app`` mechanism takes care to route 
 an application level access or call to an internal interpreter-level 
 object appropriately to the descriptor, providing enough precision
-and hints to keep the type-infering annotator happy. 
+and hints to keep the type-inferring annotator happy. 
 
 
 Calling into application level code from interpreter-level 

diff --git a/pypy/doc/config/translation.list_comprehension_operations.txt b/pypy/doc/config/translation.list_comprehension_operations.txt
--- a/pypy/doc/config/translation.list_comprehension_operations.txt
+++ b/pypy/doc/config/translation.list_comprehension_operations.txt
@@ -1,2 +1,2 @@
-Experimental optimisation for list comprehensions in RPython.
+Experimental optimization for list comprehensions in RPython.
 

diff --git a/pypy/doc/cleanup-todo.txt b/pypy/doc/cleanup-todo.txt
--- a/pypy/doc/cleanup-todo.txt
+++ b/pypy/doc/cleanup-todo.txt
@@ -15,7 +15,7 @@
    simplify translator/c/gc.py
  - clean up the tangle of including headers in the C backend
  - make approach for loading modules more sane, mixedmodule capture
-   too many platform dependecies especially for pypy-cli
+   too many platform dependencies especially for pypy-cli
  - review pdbplus, especially the graph commands, also in the light of
    https://codespeak.net/issue/pypy-dev/issue303 and the fact that
    we can have more than one translator/annotator around (with the

diff --git a/pypy/doc/discussion/use_case_of_logic.txt b/pypy/doc/discussion/use_case_of_logic.txt
--- a/pypy/doc/discussion/use_case_of_logic.txt
+++ b/pypy/doc/discussion/use_case_of_logic.txt
@@ -13,10 +13,10 @@
 We define Business Logic as expressing consistency (as an example) on
 a set of objects in a business application.
 
-For exeample checking the consistency of a calculation before
+For example checking the consistency of a calculation before
 committing the changes.
 
-The domain is quite rich in example of uses of Busines Logic.
+The domain is quite rich in example of uses of Business Logic.
 
 Datamining
 ===========
@@ -26,7 +26,7 @@
 Databases
 =========
 
-Validity contraints for the data can be expressed as constraints.
+Validity constraints for the data can be expressed as constraints.
 
 Constraints can be used to perform type inference when querying the
 database.
@@ -34,7 +34,7 @@
 Semantic web
 =============
 
-The use case is like the database case, except the ontology langauge
+The use case is like the database case, except the ontology language
 it self is born out of Descriptive Logic
 
 
@@ -50,8 +50,8 @@
 Configuration
 ==============
 
-User configuration can use information infered from : the current
-user, current plantform , version requirements, ...
+User configuration can use information inferred from : the current
+user, current platforms , version requirements, ...
 
 The validity of the configuration can be checked with the constraints.
 
@@ -61,15 +61,15 @@
 
 Timetables, process scheduling, task scheduling.
 
-Use rules to determin when to execute tasks (only start batch, if load
+Use rules to determine when to execute tasks (only start batch, if load
 is low, and previous batch is finished.
 
 Load sharing.
 
-Route optimisation. Planning the routes of a technitian based on tools
+Route optimization. Planning the routes of a technician based on tools
 needed and such
 
-An example is scheduling a confenre like Europython see:
+An example is scheduling a conference like Europython see:
 
 http://lists.logilab.org/pipermail/python-logic/2005-May/000107.html
 

diff --git a/pypy/doc/config/translation.backendopt.print_statistics.txt b/pypy/doc/config/translation.backendopt.print_statistics.txt
--- a/pypy/doc/config/translation.backendopt.print_statistics.txt
+++ b/pypy/doc/config/translation.backendopt.print_statistics.txt
@@ -1,2 +1,2 @@
 Debugging option. Print statics about the forest of flowgraphs as they
-go through the various backend optimisations.
\ No newline at end of file
+go through the various backend optimizations.
\ No newline at end of file

diff --git a/pypy/doc/config/translation.vanilla.txt b/pypy/doc/config/translation.vanilla.txt
--- a/pypy/doc/config/translation.vanilla.txt
+++ b/pypy/doc/config/translation.vanilla.txt
@@ -1,2 +1,2 @@
-Try to make the resulting compiled program as portable (=moveable to another
+Try to make the resulting compiled program as portable (=movable to another
 machine) as possible. Which is not much.

diff --git a/pypy/doc/discussion/outline-external-ootype.txt b/pypy/doc/discussion/outline-external-ootype.txt
--- a/pypy/doc/discussion/outline-external-ootype.txt
+++ b/pypy/doc/discussion/outline-external-ootype.txt
@@ -108,7 +108,7 @@
 
     Foo = ootype.ExternalInstance({'bar': ([Signed, Signed], Float)})
 
-Then, the annotation for Foo's intances is SomeExternalInstance(Foo).
+Then, the annotation for Foo's instances is SomeExternalInstance(Foo).
 This way, the transformation from high-level types to platform-level
 types is straightforward and correct.
 
@@ -156,7 +156,7 @@
 Exceptions
 ~~~~~~~~~~
 
-.NET and JVM users want to catch external exceptions in a natuarl way;
+.NET and JVM users want to catch external exceptions in a natural way;
 e.g.::
 
     try:
@@ -164,7 +164,7 @@
     except System.OverflowException:
         ...
 
-This is not straighforward because to make the flow objspace happy the
+This is not straightforward because to make the flow objspace happy the
 object which represent System.OverflowException must be a real Python
 class that inherits from Exception.
 
@@ -200,7 +200,7 @@
 necessary to rewrite a part of it.
 
 To represent low-level types, it uses NativeInstance, a subclass of
-ootype.Instance that contains all the informations needed by the
+ootype.Instance that contains all the information needed by the
 backend to reference the class (e.g., the namespace). It also supports
 overloading.
 
@@ -209,5 +209,5 @@
 helpers. It might be saner to use another annotation not to mix apples
 and oranges, maybe factoring out common code.
 
-I don't know whether and how much code can be reused from the exising
+I don't know whether and how much code can be reused from the existing
 bltregistry.

diff --git a/pypy/doc/configuration.txt b/pypy/doc/configuration.txt
--- a/pypy/doc/configuration.txt
+++ b/pypy/doc/configuration.txt
@@ -89,7 +89,7 @@
         ``default`` specifies the default value of the option. ``requires`` is
         a list of two-element tuples describing the requirements when the
         option is set to true, ``suggests`` is a list of the same structure but
-        the options in there are only suggested, not absolutely neccessary. The
+        the options in there are only suggested, not absolutely necessary. The
         difference is small: if the current option is set to True, both the
         required and the suggested options are set. The required options cannot
         be changed later, though. ``negation`` specifies whether the negative
@@ -127,7 +127,7 @@
 Configuration Objects
 ---------------------
 
-``Config`` objects hold the choosen values for the options (of the default,
+``Config`` objects hold the chosen values for the options (of the default,
 if no choice was made). A ``Config`` object is described by an
 ``OptionDescription`` instance. The attributes of the ``Config`` objects are the
 names of the children of the ``OptionDescription``. Example::

diff --git a/pypy/doc/config/translation.backendopt.inline.txt b/pypy/doc/config/translation.backendopt.inline.txt
--- a/pypy/doc/config/translation.backendopt.inline.txt
+++ b/pypy/doc/config/translation.backendopt.inline.txt
@@ -7,4 +7,4 @@
 inlined is needed for malloc removal
 (:config:`translation.backendopt.mallocs`) to be effective.
 
-This optimisation is used by default.
+This optimization is used by default.

diff --git a/pypy/doc/faq.txt b/pypy/doc/faq.txt
--- a/pypy/doc/faq.txt
+++ b/pypy/doc/faq.txt
@@ -147,7 +147,7 @@
 .. _`prolog and javascript`:
 
 ---------------------------------------------------------------
-Can PyPy support intepreters for other languages beyond Python?
+Can PyPy support interpreters for other languages beyond Python?
 ---------------------------------------------------------------
 
 The toolsuite that translates the PyPy interpreter is quite

diff --git a/pypy/doc/discussion/gc.txt b/pypy/doc/discussion/gc.txt
--- a/pypy/doc/discussion/gc.txt
+++ b/pypy/doc/discussion/gc.txt
@@ -9,7 +9,7 @@
 =============
 
 This document tries to gather gc-related issues which are very recent
-or in-developement. Also, it tries to document needed gc refactorings
+or in-development. Also, it tries to document needed gc refactorings
 and expected performance of certain gc-related operations.
 
 Problem area

diff --git a/pypy/doc/carbonpython.txt b/pypy/doc/carbonpython.txt
--- a/pypy/doc/carbonpython.txt
+++ b/pypy/doc/carbonpython.txt
@@ -167,7 +167,7 @@
             return self.x
 
 
-Note that the type of ``self`` must not be speficied: it will
+Note that the type of ``self`` must not be specified: it will
 automatically assumed to be ``MyClass``.
 
 The ``__init__`` method is not automatically mapped to the .NET
@@ -182,7 +182,7 @@
 outside; the RPython compiler automatically calls ``__init__``
 whenever an RPython class is instantiated.
 
-In the future this discrepacy will be fixed and the ``__init__``
+In the future this discrepancy will be fixed and the ``__init__``
 method will be automatically mapped to the constructor.
 
 
@@ -208,7 +208,7 @@
 
 At the moment there is no special syntax support for indexers and
 properties: for example, you can't access ArrayList's elements using
-the square bracked notation, but you have to call the call the
+the square bracket notation, but you have to call the call the
 ``get_Item`` and ``set_Item`` methods; similarly, to access a property
 ``XXX`` you need to call ``get_XXX`` and ``set_XXX``::
 

diff --git a/pypy/doc/config/objspace.usemodules._rawffi.txt b/pypy/doc/config/objspace.usemodules._rawffi.txt
--- a/pypy/doc/config/objspace.usemodules._rawffi.txt
+++ b/pypy/doc/config/objspace.usemodules._rawffi.txt
@@ -1,3 +1,3 @@
 An experimental module providing very low-level interface to
 C-level libraries, for use when implementing ctypes, not
-indended for a direct use at all.
\ No newline at end of file
+intended for a direct use at all.
\ No newline at end of file

diff --git a/pypy/doc/discussion/ctypes_todo.txt b/pypy/doc/discussion/ctypes_todo.txt
--- a/pypy/doc/discussion/ctypes_todo.txt
+++ b/pypy/doc/discussion/ctypes_todo.txt
@@ -3,7 +3,7 @@
 * Write down missing parts and port all tests, eventually adding
   additional tests.
 
-  - for unions and structs, late assignement of _fields_ is somewhat buggy.
+  - for unions and structs, late assignment of _fields_ is somewhat buggy.
     Tests about behavior of getattr working properly on instances
     are missing or not comprehensive. Some tests are skipped because I didn't
     understand the details.
@@ -15,7 +15,7 @@
   - there are features, which we don't support like buffer() and
     array() protocols.
 
-  - are the _CData_value return lifetime/gc sematics correct?
+  - are the _CData_value return lifetime/gc semantics correct?
 
   - for some ABIs we will need completely filled ffitypes to do the
     right thing for passing structures by value, we are now passing enough

diff --git a/pypy/doc/getting-started.txt b/pypy/doc/getting-started.txt
--- a/pypy/doc/getting-started.txt
+++ b/pypy/doc/getting-started.txt
@@ -71,7 +71,7 @@
 Where to go from here
 ----------------------
 
-After you succesfully manage to get PyPy's source you can read more about:
+After you successfully manage to get PyPy's source you can read more about:
 
  - `Building and using PyPy's Python interpreter`_
  - `Learning more about the translation toolchain and how to develop (with) PyPy`_

diff --git a/pypy/doc/config/index.txt b/pypy/doc/config/index.txt
--- a/pypy/doc/config/index.txt
+++ b/pypy/doc/config/index.txt
@@ -33,7 +33,7 @@
 There is an `overview`_ of all command line arguments that can be
 passed in either position.
 
-Many of the more interesting object space options enable optimzations,
+Many of the more interesting object space options enable optimizations,
 which are described in `Standard Interpreter Optimizations`_, or allow
 the creation of objects that can barely be imagined in CPython, which
 are documented in `What PyPy can do for your objects`_.

diff --git a/pypy/doc/clr-module.txt b/pypy/doc/clr-module.txt
--- a/pypy/doc/clr-module.txt
+++ b/pypy/doc/clr-module.txt
@@ -139,5 +139,5 @@
     >>>> Application.Run(frm)
 
 Unfortunately at the moment you can't do much more than this with Windows
-Forms, because we still miss support for delegates and so it's not possibile
+Forms, because we still miss support for delegates and so it's not possible
 to handle events.

diff --git a/pypy/doc/cli-backend.txt b/pypy/doc/cli-backend.txt
--- a/pypy/doc/cli-backend.txt
+++ b/pypy/doc/cli-backend.txt
@@ -14,7 +14,7 @@
 
 While in an ideal world we might suppose GenCLI to run fine with
 every implementation conforming to that standard, we know the world we
-live in is far from ideal, so extra efforts can be needed to mantain
+live in is far from ideal, so extra efforts can be needed to maintain
 compatibility with more than one implementation.
 
 At the moment of writing the two most popular implementations of the
@@ -84,7 +84,7 @@
 returning the name of the helpers and one subclass for each of the two
 supported platforms.
 
-Since Microfost ``ilasm`` is not capable of compiling the PyPy
+Since Microsoft ``ilasm`` is not capable of compiling the PyPy
 standard interpreter due to its size, on Windows machines we also look
 for an existing Mono installation: if present, we use CLR for
 everything except the assembling phase, for which we use Mono's
@@ -132,7 +132,7 @@
 while .NET only supports Unicode with the char type. There are at
 least two ways to map plain Char to CTS:
 
-  - map UniChar to char, thus mantaining the original distinction
+  - map UniChar to char, thus maintaining the original distinction
     between the two types: this has the advantage of being a
     one-to-one translation, but has the disadvantage that RPython
     strings will not be recognized as .NET strings, since they only
@@ -234,7 +234,7 @@
 subtle bugs in more complex ones, because the two exception
 hierarchies don't completely overlap.
 
-At the moment we've choosen to build an RPython exception hierarchy
+At the moment we've chosen to build an RPython exception hierarchy
 completely independent from the CLI one, but this means that we can't
 rely on exceptions raised by built-in operations.  The currently
 implemented solution is to do an exception translation on-the-fly.
@@ -242,7 +242,7 @@
 As an example consider the RPython int_add_ovf operation, that sums
 two integers and raises an OverflowError exception in case of
 overflow. For implementing it we can use the built-in add.ovf CLI
-instruction that raises System.OverflowExcepion when the result
+instruction that raises System.OverflowException when the result
 overflows, catch that exception and throw a new one::
 
     .try 
@@ -267,7 +267,7 @@
 represented by flow graphs that we need to translate CLI IL code. Flow
 graphs are expressed in a format that is very suitable for being
 translated to low level code, so that phase is quite straightforward,
-though the code is a bit involed because we need to take care of three
+though the code is a bit involved because we need to take care of three
 different types of blocks.
 
 The code doing this work is located in the Function.render
@@ -278,7 +278,7 @@
 statement used for indicating the virtual machine the number and type
 of local variables used.
 
-Then it sequentally renders all blocks in the graph, starting from the
+Then it sequentially renders all blocks in the graph, starting from the
 start block; special care is taken for the return block which is
 always rendered at last to meet CLI requirements.
 

diff --git a/pypy/doc/index.txt b/pypy/doc/index.txt
--- a/pypy/doc/index.txt
+++ b/pypy/doc/index.txt
@@ -27,7 +27,7 @@
 
 * `Development bug/feature tracker`_: filing bugs and feature requests. 
 
-* `Sprint mailing list`_: mailing list for organising upcoming sprints. 
+* `Sprint mailing list`_: mailing list for organizing upcoming sprints. 
 
 * **IRC channel #pypy on freenode**: Many of the core developers are hanging out 
   at #pypy on irc.freenode.net.  You are welcome to join and ask questions
@@ -39,7 +39,7 @@
 Meeting PyPy developers
 =======================
 
-The PyPy developers are organising sprints and presenting results at
+The PyPy developers are organizing sprints and presenting results at
 conferences all year round. They will be happy to meet in person with
 anyone interested in the project.  Watch out for sprint announcements
 on the `development mailing list`_.

diff --git a/pypy/doc/discussion/chained_getattr.txt b/pypy/doc/discussion/chained_getattr.txt
--- a/pypy/doc/discussion/chained_getattr.txt
+++ b/pypy/doc/discussion/chained_getattr.txt
@@ -25,7 +25,7 @@
        
     now for the LOAD_CHAINED_GLOBAL bytecode implementation:
 
-        Module dicts have a special implemnetation, providing: 
+        Module dicts have a special implementation, providing: 
 
         - an extra "fastlookup" rpython-dict serving as a cache for
           LOAD_CHAINED_GLOBAL places within the modules: 

diff --git a/pypy/doc/jit/overview.txt b/pypy/doc/jit/overview.txt
--- a/pypy/doc/jit/overview.txt
+++ b/pypy/doc/jit/overview.txt
@@ -136,7 +136,7 @@
 to the complete language.  This would be a major effort and be platform- and
 language-specific.  Moreover maintenance would be a headache: we believe that
 many changes that are trivial to implement in CPython, are likely to invalidate
-previous carefully-tuned optimisations.
+previous carefully-tuned optimizations.
 
 For major improvements in speed, JIT techniques are necessary.  For Python,
 Psyco gives typical speedups of 2 to 4 times - up to 100 times in algorithmic

diff --git a/pypy/doc/extradoc.txt b/pypy/doc/extradoc.txt
--- a/pypy/doc/extradoc.txt
+++ b/pypy/doc/extradoc.txt
@@ -323,7 +323,7 @@
 * Jython_ is a Python implementation in Java.
 
 * IronPython_ a new Python implementation compiling Python into 
-  Microsofts Common Language Runtime (CLR) Intermediate Language (IL).
+  Microsoft's Common Language Runtime (CLR) Intermediate Language (IL).
 
 * Tunes_ is not entirely unrelated.  The web site changed a lot, but a
   snapshot of the `old Tunes Wiki`_ is available on codespeak; browsing

diff --git a/pypy/doc/discussion/cli-optimizations.txt b/pypy/doc/discussion/cli-optimizations.txt
--- a/pypy/doc/discussion/cli-optimizations.txt
+++ b/pypy/doc/discussion/cli-optimizations.txt
@@ -1,7 +1,7 @@
 Possible optimizations for the CLI backend
 ==========================================
 
-Stack push/pop optimitazion
+Stack push/pop optimization
 ---------------------------
 
 The CLI's VM is a stack based machine: this fact doesn't play nicely
@@ -61,7 +61,7 @@
 generated by Microsoft CLR, yet.
 
 Thus, we might consider to optimize it manually; it should not be so
-difficult, but it is not trivial becasue we have to make sure that the
+difficult, but it is not trivial because we have to make sure that the
 dropped locals are used only once.
 
 
@@ -79,8 +79,8 @@
 subtle bugs in more complex ones, because the two exception
 hierarchies don't completely overlap.
 
-For now I've choosen to build an RPython exception hierarchy
-completely indipendent from the CLI one, but this means that we can't
+For now I've chosen to build an RPython exception hierarchy
+completely independent from the CLI one, but this means that we can't
 rely on exceptions raised by standard operations. The currently
 implemented solution is to do an exception translation on-the-fly; for
 example, the 'ind_add_ovf' is translated into the following IL code::
@@ -105,7 +105,7 @@
 I.e., it catches the builtin OverflowException and raises a RPython
 OverflowError.
 
-I haven't misured timings yet, but I guess that this machinery brings
+I haven't measured timings yet, but I guess that this machinery brings
 to some performance penalties even in the non-overflow case; a
 possible optimization is to do the on-the-fly translation only when it
 is strictly necessary, i.e. only when the except clause catches an
@@ -188,7 +188,7 @@
 The current implementations of ll_dict_getitem and ll_dict_get in
 ootypesystem.rdict do two consecutive lookups (calling ll_contains and
 ll_get) on the same key. We might cache the result of
-pypylib.Dict.ll_contains so that the succesive ll_get don't need a
+pypylib.Dict.ll_contains so that the successive ll_get don't need a
 lookup. Btw, we need some profiling before choosing the best way. Or
 we could directly refactor ootypesystem.rdict for doing a single
 lookup.

diff --git a/pypy/doc/discussion/howtoimplementpickling.txt b/pypy/doc/discussion/howtoimplementpickling.txt
--- a/pypy/doc/discussion/howtoimplementpickling.txt
+++ b/pypy/doc/discussion/howtoimplementpickling.txt
@@ -39,7 +39,7 @@
 of the program and its state (example: a Forth backend),
 I would see it as a valid solution, since it is
 relocatable. It is of course a possible fall-back to write
-sucn a backend of we fail otherwise.
+such a backend of we fail otherwise.
 
 There are some simple steps and some more difficult ones.
 Let's start with the simple.
@@ -94,7 +94,7 @@
 the prickelpit.c file in the Stackless distribution.
 
 As a conclusion, pickling of tasklets is an addition to Stackless,
-but not meand to be an extension to Python. The need to support
+but not meant to be an extension to Python. The need to support
 pickling of certain objects should not change the interface.
 It is better to decouple this and to use surrogate types for
 pickling which cannot collide with future additions to Python.
@@ -145,7 +145,7 @@
 SLP switching strategies
 ........................
 
-SLP has undergone several rewrites. The first implemenation was aiming
+SLP has undergone several rewrites. The first implementation was aiming
 at complete collaboration. A new frame's execution was deferred until
 all the preparational C function calls had left the C stack. There
 was no extra state to be saved.
@@ -195,13 +195,13 @@
 
 Right now, PyPy saves C state of functions in tiny activation records:
 the alive variables of a block, together with the entry point of
-the function tnat was left.
+the function that was left.
 This is an improvement over storing raw stack slices, but the pattern
 is similar: The C stack state gets restored when we switch.
 
 In this sense, it was the astonishing resume when Richard and I discussed
 this last week: PyPy essentially does a variant of Hard switching! At least it
-does a compromize that does not really help with pickling.
+does a compromise that does not really help with pickling.
 
 On the other hand, this approach is half the way. It turns out to
 be an improvement over SLP not to have to avoid recursions in the
@@ -240,7 +240,7 @@
 we really need to restore before we can do the function call?
 
 - the argument decoding is done, already, and the fact that we could have done
-  the function call shows, that no exception occured. We can ignore the rest
+  the function call shows, that no exception occurred. We can ignore the rest
   of this activation record and do the housekeeping.
   
 - the frame is prepared, and arguments are stored in it. The operation
@@ -268,7 +268,7 @@
 A rough sketch of the necessary analysis:
 
 for every block in an RPython function that can reach unwind:
-Analyse control flow. It should be immediately leading to
+Analyze control flow. It should be immediately leading to
 the return block with only one output variable. All other alive variables
 should have ended their liveness in this block.
 

diff --git a/pypy/doc/extending.txt b/pypy/doc/extending.txt
--- a/pypy/doc/extending.txt
+++ b/pypy/doc/extending.txt
@@ -12,8 +12,8 @@
 Possibilities
 =============
 
-Right now, there are three posibilities of providing third-party modules
-for the PyPy python interpreter (in order of usefulnes):
+Right now, there are three possibilities of providing third-party modules
+for the PyPy python interpreter (in order of usefulness):
 
 * Write them in pure python and use ctypes, see ctypes_
   section
@@ -39,7 +39,7 @@
 
 We also provide a `ctypes-configure`_ for overcoming the platform dependencies,
 not relying on the ctypes codegen. This tool works by querying gcc about
-platform-depenent details (compiling small snippets of C code and running
+platform-dependent details (compiling small snippets of C code and running
 them), so it'll benefit not pypy-related ctypes-based modules as well.
 
 .. _`ctypes-configure`: http://codespeak.net/~fijal/configure.html
@@ -91,9 +91,9 @@
   compilation-check requires to recompile whole PyPy python interpreter,
   which takes 0.5-1h. We plan to solve this at some point in near future.
 
-* although rpython is a garabage-collected language, the border between
+* although rpython is a garbage-collected language, the border between
   C and RPython needs to be managed by hand (each object that goes into the
-  C level must be explicitely freed) XXX we try to solve this
+  C level must be explicitly freed) XXX we try to solve this
 
 Some document is available `here`_
 

diff --git a/pypy/doc/distribution.txt b/pypy/doc/distribution.txt
--- a/pypy/doc/distribution.txt
+++ b/pypy/doc/distribution.txt
@@ -10,7 +10,7 @@
 
 The implementation uses an RPC-like protocol, which accesses
 only members of objects, rather than whole objects. This means it
-does not rely on objects being picklable, nor on having the same
+does not rely on objects being pickleable, nor on having the same
 source code available on both sides. On each call, only the members
 that are used on the client side are retrieved, objects which
 are not used are merely references to their remote counterparts.
@@ -27,7 +27,7 @@
 remote side replies by providing a bound method. On the client this bound
 method appears as a remote reference: this reference is called with a remote
 reference to x as self, the integer 1 which is copied as a primitive type, a
-reference to a list and a refence to y. The remote side receives this call,
+reference to a list and a reference to y. The remote side receives this call,
 processes it as a call to the bound method x.foo, where 'x' is resolved as a
 local object, 1 as an immutable primitive, [1,2,3] as a reference to a mutable
 primitive and y as a reference to a remote object. If the type of y is not
@@ -74,7 +74,7 @@
 
   - No attribute access
 
-  - Arguments of calls must be picklable on one side and unpicklable on
+  - Arguments of calls must be pickleable on one side and unpickleable on
     remote side, which means they must share source code, they do not
     become remote references
 
@@ -105,7 +105,7 @@
 
   - two way RPC (unlike Pyro)
 
-  - also heavy restrictions on objects - they must sublcass certain class
+  - also heavy restrictions on objects - they must subclass certain class
 
 .. _`Pyro`: http://pyro.sourceforge.net/
 .. _`transparent proxies`: objspace-proxies.html#tproxy

diff --git a/pypy/doc/cpython_differences.txt b/pypy/doc/cpython_differences.txt
--- a/pypy/doc/cpython_differences.txt
+++ b/pypy/doc/cpython_differences.txt
@@ -160,7 +160,7 @@
 ----------------------------
 
 Officially, CPython has no rule at all for when exactly
-overriden method of subclasses of built-in types get
+overridden method of subclasses of built-in types get
 implicitly called or not.  As an approximation, these methods
 are never called by other built-in methods of the same object.
 For example, an overridden ``__getitem__()`` in a subclass of
@@ -211,7 +211,7 @@
   PyPy.  On CPython it would set the maximum number of nested
   calls that can occur before a RuntimeError is raised; on PyPy
   overflowing the stack also causes RuntimeErrors, but the limit
-  is checked at a lower level.  (The limit is currenty hard-coded
+  is checked at a lower level.  (The limit is currently hard-coded
   at 768 KB, corresponding to roughly 1480 Python calls on
   Linux.)
 

diff --git a/pypy/doc/config/objspace.usemodules.posix.txt b/pypy/doc/config/objspace.usemodules.posix.txt
--- a/pypy/doc/config/objspace.usemodules.posix.txt
+++ b/pypy/doc/config/objspace.usemodules.posix.txt
@@ -1,3 +1,3 @@
 Use the essential 'posix' module.
 This module is essential, included by default and cannot be removed (even when
-specified explicitly, the option gets overriden later).
+specified explicitly, the option gets overridden later).

diff --git a/pypy/doc/buildtool.txt b/pypy/doc/buildtool.txt
--- a/pypy/doc/buildtool.txt
+++ b/pypy/doc/buildtool.txt
@@ -165,7 +165,7 @@
 Note that there is a test project in 'tool/build/testproject' that can serve
 as an example.
 
-Prerequisities
+Prerequisites
 --------------
 
 Your project can use the build tool if:

diff --git a/pypy/doc/config/translation.backendopt.profile_based_inline.txt b/pypy/doc/config/translation.backendopt.profile_based_inline.txt
--- a/pypy/doc/config/translation.backendopt.profile_based_inline.txt
+++ b/pypy/doc/config/translation.backendopt.profile_based_inline.txt
@@ -7,4 +7,4 @@
 The option takes as value a string which is the arguments to pass to
 the program for the instrumented run.
 
-This optimisation is not used by default.
\ No newline at end of file
+This optimization is not used by default.
\ No newline at end of file

diff --git a/pypy/doc/discussion/thoughts_string_interning.txt b/pypy/doc/discussion/thoughts_string_interning.txt
--- a/pypy/doc/discussion/thoughts_string_interning.txt
+++ b/pypy/doc/discussion/thoughts_string_interning.txt
@@ -8,7 +8,7 @@
 the dict lookup method will find the string always by identity,
 saving the need to do a string comparison.
 
-Interned Srings in CPython
+Interned Strings in CPython
 --------------------------
 
 CPython keeps an internal dictionary named ``interned`` for all of these
@@ -137,7 +137,7 @@
   D:\pypy\dist\pypy\translator\goal>
 
 
-This was just an exercize to get an idea. For sure this is not to be checked in.
+This was just an exercise to get an idea. For sure this is not to be checked in.
 Instead, I'm attaching the simple patch here for reference.
 ::
 

diff --git a/pypy/doc/discussion/summer-of-pypy-pytest.txt b/pypy/doc/discussion/summer-of-pypy-pytest.txt
--- a/pypy/doc/discussion/summer-of-pypy-pytest.txt
+++ b/pypy/doc/discussion/summer-of-pypy-pytest.txt
@@ -16,7 +16,7 @@
 Remote imports:
 ---------------
 
-On the beggining of communication, master server sends to client
+On the beginning of communication, master server sends to client
 import hook code, which then can import all needed libraries.
 
 Libraries are uploaded server -> client if they're needed (when
@@ -47,7 +47,7 @@
 Then we transfer output data to server as string, possibly tweaking
 file names (which is quite easy).
 
-Delivarables:
+Deliverables:
 =============
 
 - better use of testing machines

diff --git a/pypy/doc/discussion/improve-rpython.txt b/pypy/doc/discussion/improve-rpython.txt
--- a/pypy/doc/discussion/improve-rpython.txt
+++ b/pypy/doc/discussion/improve-rpython.txt
@@ -4,7 +4,7 @@
 Improve the interpreter API
 ---------------------------
 
-- Rationalize the modules, and the names, of the differents functions needed to
+- Rationalize the modules, and the names, of the different functions needed to
   implement a pypy module. A typical rpython file is likely to contain many
   `import` statements::
 
@@ -34,7 +34,7 @@
 ----------------
 
 - Arithmetic with unsigned integer, and between integer of different signedness,
-  when this is not ambiguous.  At least, comparison and assignement with
+  when this is not ambiguous.  At least, comparison and assignment with
   constants should be allowed.
 
 - Allocate variables on the stack, and pass their address ("by reference") to

diff --git a/pypy/doc/discussion/compiled-swamp.txt b/pypy/doc/discussion/compiled-swamp.txt
--- a/pypy/doc/discussion/compiled-swamp.txt
+++ b/pypy/doc/discussion/compiled-swamp.txt
@@ -3,7 +3,7 @@
 
 * benchmarks
 * tests
-* compliancy tests
+* compliance tests
 * play1
 * downloads
 * ...

diff --git a/pypy/doc/discussion/distribution-roadmap.txt b/pypy/doc/discussion/distribution-roadmap.txt
--- a/pypy/doc/discussion/distribution-roadmap.txt
+++ b/pypy/doc/discussion/distribution-roadmap.txt
@@ -13,7 +13,7 @@
 some kind of remote control over program execution. For start I would
 suggest using RMI (Remote Method Invocation) and remote object access
 (in case of low level it would be struct access). For the simplicity
-it will make some sense to target high-level platform at the beggining
+it will make some sense to target high-level platform at the beginning
 (CLI platform seems like obvious choice), which provides more primitives
 for performing such operations. To make attempt easier, I'll provide
 some subset of type system to be serializable which can go as parameters
@@ -52,7 +52,7 @@
 ---------------------------------------
 
 The biggest step here is to provide JIT integration into distribution
-system. This should allow to make it really usefull (probably compile-time
+system. This should allow to make it really useful (probably compile-time
 distribution will not work for example for whole Python interpreter, because
 of too huge granularity). This is quite unclear for me how to do that
 (JIT is not complete and I don't know too much about it). Probably we

More information about the Pypy-commit mailing list