docs: Fix a few typos

doc/rest/reference/coordinator.rst

@@ -343,7 +343,7 @@ Here are some typical monitor usages::
 Security
 --------
 
-Internal communication between Processors, Coordinators and ResourceController is performed using XMLRPC and thus is not secure. However, since no authentication information or actual commands are transmitted by XMLRPC, and the coordinator module does not enable the processes that use it to do anything that they are not ALREADY capable of doing on their own (i.e. spawn ssh processes), the main security vulnerabilty is Denial Of Service (i.e. an attacker listening to the XMLRPC traffic could send messages causing Processors to shutdown, or Coordinators to be blocked from running any Processors).  In other words the security philosophy of this module is to avoid compromising your security, by leaving the security of process invocation entirely to your existing security mechanisms (i.e. ssh and ssh-agent).  Commands are only sent using SSH, not XMLRPC, and the XMLRPC components are designed to prevent known ways that an XMLRPC caller might be able to run a command on an XMLRPC server or client. (I blocked known security vulnerabilities in Python's SimpleXMLRPCServer module).
+Internal communication between Processors, Coordinators and ResourceController is performed using XMLRPC and thus is not secure. However, since no authentication information or actual commands are transmitted by XMLRPC, and the coordinator module does not enable the processes that use it to do anything that they are not ALREADY capable of doing on their own (i.e. spawn ssh processes), the main security vulnerability is Denial Of Service (i.e. an attacker listening to the XMLRPC traffic could send messages causing Processors to shutdown, or Coordinators to be blocked from running any Processors).  In other words the security philosophy of this module is to avoid compromising your security, by leaving the security of process invocation entirely to your existing security mechanisms (i.e. ssh and ssh-agent).  Commands are only sent using SSH, not XMLRPC, and the XMLRPC components are designed to prevent known ways that an XMLRPC caller might be able to run a command on an XMLRPC server or client. (I blocked known security vulnerabilities in Python's SimpleXMLRPCServer module).
 
 In the same spirit, the current implementation does not seek to block users from issuing commands that could let them "hog" resources, for the simple reason that in an SSH-enabled environment, they would be able to do so regardless of this module's policy.  I.e. the user can simply not use this module, and spawn lots of processes directly using SSH.  In the current implementation, every user can send directives to the ResourceController that affect resource allocation to other users' jobs.  This means everybody has to "play nice", only giving their Coordinator(s) higher priority if it is really appropriate and agreed by other users.  Unless a different process invocation mechanism (other than SSH by each user) were adopted, it doesn't really make sense to me to try to enforce a policy that is stricter than the policy of the underlying process invocation mechanism (i.e. SSH).  Since every user can use SSH to spawn as many jobs as they want, without regard for sharing with others, making this module's policy "strict" doesn't really secure anything.
 

doc/rest/reference/mapping.rst

@@ -71,7 +71,7 @@ Let's examine these examples one by one:
 Directionality and Reverse Traversal
 ------------------------------------
 
-Note that dictGraph stores directed edges, that is, a->b does not imply b->a; those are two distinct edges that would have to be added separately if you want an edge going both directions.  Moreover, the current implementation of dictGraph does not provide a mechanism for traveling an edge backwards.  To do so with algorithmic efficiency requires storing each edge twice: once in a forward index and once in a reverse index.  Since that doubles the memory requirements for storing a graph, the default dictGraph class does not do this.  If you want such a "forward-backwards" graph, use the dictGraphFB subclass that stores both forwad and reverse indexes, and supports the inverse operator ($\sim$).  $\sim$ graph gets the reverse mapping, e.g. ($\sim$ graph)[node2] corresponds to the set of nodes that have edges to node2.  This area of the code hasn't been tested much yet.
+Note that dictGraph stores directed edges, that is, a->b does not imply b->a; those are two distinct edges that would have to be added separately if you want an edge going both directions.  Moreover, the current implementation of dictGraph does not provide a mechanism for traveling an edge backwards.  To do so with algorithmic efficiency requires storing each edge twice: once in a forward index and once in a reverse index.  Since that doubles the memory requirements for storing a graph, the default dictGraph class does not do this.  If you want such a "forward-backwards" graph, use the dictGraphFB subclass that stores both forward and reverse indexes, and supports the inverse operator ($\sim$).  $\sim$ graph gets the reverse mapping, e.g. ($\sim$ graph)[node2] corresponds to the set of nodes that have edges to node2.  This area of the code hasn't been tested much yet.
 
 Graph
 -----

doc/rest/reference/seqdb.rst

@@ -438,7 +438,7 @@ Let's go through this line by line:
 
 * we create a subclass of ProteinSQLSequence to show how Python makes it easy to create customized behaviors that can make database access more efficient.  Here we've simply added a __len__ method that uses the protein_length attribute obtained directly from the database, courtesy of SQLRow.__getattr__, which knows what columns exist in the database, and provides them transparently as object attributes.  (The ordinary SequenceBase __len__ method calculates it by obtaining the whole sequence string and calculating its length.  Clearly it's more efficient for the database to retrieve this number (stored as a column called protein_length) and return it, rather than making it send us the whole sequence).
 
-* next we call the protein.objclass() method to inform the table object that it should use our new class for instantiating any row objects for this table.  It will call this class with the usual SQLRow contructor arguments (table, id).
+* next we call the protein.objclass() method to inform the table object that it should use our new class for instantiating any row objects for this table.  It will call this class with the usual SQLRow constructor arguments (table, id).
 
 
 BlastDBXMLRPC

doc/rest/reference/sqlgraph.rst

@@ -19,7 +19,7 @@ database table classes to :mod:`worldbase`, and when retrieved
 they will automatically reconnect to the database server.  Indeed,
 you can save the :class:`DBServerInfo` object itself to :mod:`worldbase`
 as a standard name (e.g. referring to UCSC's MySQL server).
-Then any database table refering to this standard name could
+Then any database table referring to this standard name could
 automatically re-connect to a *local* copy of that server
 when retrieved from :mod:`worldbase`.
 

doc/rest/tutorials/compgenomics.rst

@@ -6,7 +6,7 @@ Many groups (e.g. David Haussler's group at UC Santa Cruz) have constructed alig
 (``ss1`` and ``ss2``) bracketing a single exon (``exon``).
 We use the alignment database to map each of these splice sites onto all the aligned
 genomes, and to print the percent-identity and percent-aligned for each genome,
-as well as the two nucleotides consituting the splice site itself.
+as well as the two nucleotides constituting the splice site itself.
 It also prints the conservation of the two exonic region (between ``ss1``
 and ``ss2``::
 

doc/rest/whatsnew.rst

@@ -24,7 +24,7 @@ extensively on Windows.  This involved a variety of changes:
   during the object's lifetime.
   Previously, Pygr relied on these files to be closed automatically
   by Python garbage collection (i.e. when the object's refcount goes to zero).
-  However, an open file can cause wierd problems on Windows, e.g. if one
+  However, an open file can cause weird problems on Windows, e.g. if one
   process tries to delete a file while another file still has the file
   open.  Our tests suggested that relying on Python garbage collection
   to close the file automatically was not adequate on Windows.

pygr/nlmsa_utils.py

@@ -160,7 +160,7 @@ def saveSeq(self, seq, nsID= -1, offset=0, nlmsaID=None):
             return # the union added it for us, no need to do anything
         if isinstance(seq, types.StringType):
             id = seq # treat this as fully qualified identifier
-        else: # get the identfier from the seq / database
+        else: # get the identifier from the seq / database
             id = self.getSeqID(seq)
         if nlmsaID is None: # allocate a new unique id
             nlmsaID = self.nlmsa.nextID()

tests/runtest.py

@@ -104,7 +104,7 @@ def run(targets, options):
 
     # disables debug messages at < 2 verbosity, debug+info at < 1
     if options.verbosity < 1:
-        disable_threshold = 'INFO' # Should implicity disable DEBUG as well
+        disable_threshold = 'INFO' # Should implicitly disable DEBUG as well
     elif options.verbosity < 2:
         disable_threshold = 'DEBUG'
 

tests/testlib/unittest_extensions.py

@@ -53,7 +53,7 @@ class PygrTestProgram(unittest.TestProgram):
     def __init__(self, **kwargs):
         verbosity = kwargs.pop('verbosity', 1)
         if verbosity < 1:
-            logger.disable('INFO')  # Should implicity disable DEBUG as well
+            logger.disable('INFO')  # Should implicitly disable DEBUG as well
         elif verbosity < 2:
             logger.disable('DEBUG')
         if kwargs.get('testRunner') is None: