Merge pull request #25 from sebastic/typos

Fix various typos. Thanks Bas, you're the best. FYI ncdiff is present only for back-compatibility. Operator is symlink to ncbo, which does have a manpage. ncwa should have a manpage, I will investigate.

bm/NCO_rgr.pm

@@ -2680,7 +2680,7 @@ if($RUN_NETCDF4_TESTS_VERSION_GE_431){
 
 #ncks #105
 # Test that -x exclusion of coordinate variables only works with -C
-# fxm: -x is not directly tested because it means testing for non-existance in output. how to do this?
+# fxm: -x is not directly tested because it means testing for non-existence in output. how to do this?
 # ncks -O -x -v time ~/nco/data/in.nc ~/foo.nc
 # ncks -H -C -d time,0 -v time ~/foo.nc
     $dsc_sng="Test that -x exclusion of coordinate variables only works with -C";

doc/nco.texi

@@ -2437,7 +2437,7 @@ Leaks cause peak memory usage to increase monotonically with time
 regardless of script complexity. 
 Slow leaks are very difficult to find.
 Sometimes a @command{malloc()} (or @command{new[]}) failure is the
-only noticeable clue to their existance.
+only noticeable clue to their existence.
 If you have good reasons to believe that a memory allocation failure  
 is ultimately due to an @acronym{NCO} memory leak (rather than
 inadequate @acronym{RAM} on your system), then we would be very
@@ -15550,7 +15550,7 @@ not rank, while, @command{ncwa} changes both variable size and rank.}.
 In this case the input files to @command{ncbo}, @var{file_1} and
 @var{file_2}, will have unequally sized @code{time} dimensions which
 causes @command{ncbo} to fail.
-To prevent this from occuring, use @command{ncwa} to remove the
+To prevent this from occurring, use @command{ncwa} to remove the
 @code{time} dimension from @var{file_2}.
 See the example below.
 

man/ncbo.1

@@ -149,7 +149,7 @@ dimensions which
 causes 
 .B ncbo
 to fail.
-To prevent this from occuring, use 
+To prevent this from occurring, use 
 .B ncwa
 to remove the 
 .B time

src/nco++/ncap2.cc

@@ -96,7 +96,7 @@ int
 main(int argc,char **argv)
 {
   const char fnc_nm[]="main"; 
-  FILE *yyin; /* File handle used to check file existance */
+  FILE *yyin; /* File handle used to check file existence */
   int parse_antlr(std::vector<prs_cls> &prs_vtr ,char*,char*);
 
   /* fxm TODO nco652 */

src/nco++/ncoGrammer.g

@@ -953,7 +953,7 @@ if( nbr_dmn!=lmt_init(lmt,ast_lmt_vtr) )
      int wlk_nbr);
 
      if(tr== ANTLR_USE_NAMESPACE(antlr)nullAST)
-        err_prn("run_dbl"," REPORTS given a null AST Refrence\n");
+        err_prn("run_dbl"," REPORTS given a null AST Reference\n");
             
      //small list dont bother with double parsing     
      // just do a final parse
@@ -1981,7 +1981,7 @@ end0:         if(lmt->getNextSibling() && lmt->getNextSibling()->getType()==NORE
                     }   
 
                    if( var_rhs->sz != var_lhs->sz) 
-                       err_prn(fnc_nm,"regular assign - var size missmatch between \""+var_nm+"\" and RHS of expression");                        
+                       err_prn(fnc_nm,"regular assign - var size mismatch between \""+var_nm+"\" and RHS of expression");                        
 
                    var_lhs->val.vp=var_rhs->val.vp;
 
@@ -2074,7 +2074,7 @@ end0:         if(lmt->getNextSibling() && lmt->getNextSibling()->getType()==NORE
               {
                 // check size
                if(  var_rhs->sz!=1L &&  var_rhs->sz != cnt)   
-                  err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesnt match RHS size=" + nbr2sng(var_rhs->sz));
+                  err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesn't match RHS size=" + nbr2sng(var_rhs->sz));
 
                    
                 szn=(var_rhs->sz >1 ? 1: 0);     
@@ -2121,7 +2121,7 @@ end0:         if(lmt->getNextSibling() && lmt->getNextSibling()->getType()==NORE
 
                // check size
                if(  var_rhs->sz!=1L &&  var_rhs->sz != cnt)   
-                  err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesnt match RHS size=" + nbr2sng(var_rhs->sz));
+                  err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesn't match RHS size=" + nbr2sng(var_rhs->sz));
 
  
                nco_var_cnf_typ(var_lhs->type,var_rhs);               

src/nco++/ncoTree.cpp

@@ -3234,7 +3234,7 @@ var_sct * ncoTree::assign(ANTLR_USE_NAMESPACE(antlr)RefAST _t,
 					}   
 
 					if( var_rhs->sz != var_lhs->sz) 
-					err_prn(fnc_nm,"regular assign - var size missmatch between \""+var_nm+"\" and RHS of expression");                        
+					err_prn(fnc_nm,"regular assign - var size mismatch between \""+var_nm+"\" and RHS of expression");                        
 
 					var_lhs->val.vp=var_rhs->val.vp;
 
@@ -3368,7 +3368,7 @@ var_sct * ncoTree::assign(ANTLR_USE_NAMESPACE(antlr)RefAST _t,
 						{
 						// check size
 						if(  var_rhs->sz!=1L &&  var_rhs->sz != cnt)   
-						err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesnt match RHS size=" + nbr2sng(var_rhs->sz));
+						err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesn't match RHS size=" + nbr2sng(var_rhs->sz));
 
 
 						szn=(var_rhs->sz >1 ? 1: 0);     
@@ -3415,7 +3415,7 @@ var_sct * ncoTree::assign(ANTLR_USE_NAMESPACE(antlr)RefAST _t,
 
 						// check size
 						if(  var_rhs->sz!=1L &&  var_rhs->sz != cnt)   
-						err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesnt match RHS size=" + nbr2sng(var_rhs->sz));
+						err_prn(fnc_nm,"Hyperslab limits for attribute "+att_nm + " on LHS size="+nbr2sng(cnt)+ " doesn't match RHS size=" + nbr2sng(var_rhs->sz));
 
 
 						nco_var_cnf_typ(var_lhs->type,var_rhs);               

src/nco++/ncoTree.hpp

@@ -351,7 +351,7 @@ if( nbr_dmn!=lmt_init(lmt,ast_lmt_vtr) )
      int wlk_nbr);
 
      if(tr== ANTLR_USE_NAMESPACE(antlr)nullAST)
-        err_prn("run_dbl"," REPORTS given a null AST Refrence\n");
+        err_prn("run_dbl"," REPORTS given a null AST Reference\n");
 
      //small list dont bother with double parsing     
      // just do a final parse

src/nco/nco_aux.c

@@ -286,7 +286,7 @@ nco_aux_evl
         lmt_tpl.max_idx=lmt_tpl.end=cll_idx_min+cll_nbr_cns-1;
         lmt_tpl.cnt=cll_nbr_cns;
         (*lmt_nbr)++;
-        if(*lmt_nbr > MAX_LMT_NBR) nco_err_exit(0,"%s: Number of slabs exceeds allocated mamory");
+        if(*lmt_nbr > MAX_LMT_NBR) nco_err_exit(0,"%s: Number of slabs exceeds allocated memory");
         lmt[(*lmt_nbr)-1]=(lmt_sct *)nco_malloc(sizeof(lmt_sct));
         *lmt[(*lmt_nbr)-1]=lmt_tpl;
         cll_grp_nbr++;
@@ -509,7 +509,7 @@ nco_aux_evl_trv
         lmt_tpl.max_idx=lmt_tpl.end=cll_idx_min+cll_nbr_cns-1;
         lmt_tpl.cnt=cll_nbr_cns;
         (*aux_lmt_nbr)++;
-        if(*aux_lmt_nbr > MAX_LMT_NBR) nco_err_exit(0,"%s: Number of slabs exceeds allocated mamory");
+        if(*aux_lmt_nbr > MAX_LMT_NBR) nco_err_exit(0,"%s: Number of slabs exceeds allocated memory");
         lmt[(*aux_lmt_nbr)-1]=(lmt_sct *)nco_malloc(sizeof(lmt_sct));
         *lmt[(*aux_lmt_nbr)-1]=lmt_tpl;
         cll_grp_nbr++;

src/nco/nco_mmr.c

@@ -199,7 +199,7 @@ nco_malloc_err_hnt_prn /* [fnc] Explain meaning and workarounds for malloc() fai
 (void)
 {
   /* Purpose: Explain meaning and workarounds for malloc() failures */
-  (void)fprintf(stdout,"%s: INFO NCO has reported a malloc() failure. malloc() failures usually indicate that your machine does not have enough free memory (RAM+swap) to perform the requested operation. As such, malloc() failures result from the physical limitations imposed by your hardware. Read http://nco.sf.net/nco.html#mmr for a description of NCO memory usage. The likiest case is that this problem is caused by inadequate RAM on your system, and is not an NCO bug. If so, there are two potential workarounds: First is to process your data in smaller chunks, e.g., smaller or more hyperslabs. The second is to use a machine with more free memory, so that malloc() succeeds.\n\nLarge tasks may uncover memory leaks in NCO. This is likeliest to occur with ncap2. ncap2 scripts are completely dynamic and may be of arbitrary length and complexity. A script that contains many thousands of operations may uncover a slow memory leak even though each single operation consumes little additional memory. Memory leaks are usually identifiable by their memory usage signature. Leaks cause peak memory usage to increase monotonically with time regardless of script complexity. Slow leaks are very difficult to find. Sometimes a malloc() failure is the only noticeable clue to their existance. If you have good reasons to believe that your malloc() failure is ultimately due to an NCO memory leak (rather than inadequate RAM on your system), then we would like to receive a detailed bug report.",nco_prg_nm_get());
+  (void)fprintf(stdout,"%s: INFO NCO has reported a malloc() failure. malloc() failures usually indicate that your machine does not have enough free memory (RAM+swap) to perform the requested operation. As such, malloc() failures result from the physical limitations imposed by your hardware. Read http://nco.sf.net/nco.html#mmr for a description of NCO memory usage. The likiest case is that this problem is caused by inadequate RAM on your system, and is not an NCO bug. If so, there are two potential workarounds: First is to process your data in smaller chunks, e.g., smaller or more hyperslabs. The second is to use a machine with more free memory, so that malloc() succeeds.\n\nLarge tasks may uncover memory leaks in NCO. This is likeliest to occur with ncap2. ncap2 scripts are completely dynamic and may be of arbitrary length and complexity. A script that contains many thousands of operations may uncover a slow memory leak even though each single operation consumes little additional memory. Memory leaks are usually identifiable by their memory usage signature. Leaks cause peak memory usage to increase monotonically with time regardless of script complexity. Slow leaks are very difficult to find. Sometimes a malloc() failure is the only noticeable clue to their existence. If you have good reasons to believe that your malloc() failure is ultimately due to an NCO memory leak (rather than inadequate RAM on your system), then we would like to receive a detailed bug report.",nco_prg_nm_get());
 } /* nco_malloc_err_hnt_prn() */
 
 /* fxm: when are const qualifiers on return values legal? is this a GNUism? */