all: fix some typos

Change-Id: I988e7e437d9957b828e05c0b098d11a4c8bdde7a Reviewed-on: https://go-review.googlesource.com/c/wiki/+/551635 Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Commit-Queue: shuang cui <[email protected]> Commit-Queue: Ian Lance Taylor <[email protected]>
golang · Dec 13, 2024 · f47dd4a · f47dd4a
1 parent a0405ab
commit f47dd4a
Show file tree

Hide file tree

Showing 3 changed files with 5 additions and 5 deletions.
diff --git a/Go2GenericsFeedback.md b/Go2GenericsFeedback.md
@@ -294,7 +294,7 @@ To make it easier to see new feedback. Please _make a Gist_. And also help to ke
   }
   ```
 
-- Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as refering to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interfaces should also be considered.
+- Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as referring to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interfaces should also be considered.
 
 - Patrick Smith: We might consider requiring the type keyword when defining methods on generic types. This makes the code a little more verbose, but clearer and more consistent (now type parameters are always preceded by the type keyword).
 

diff --git a/Projects.md b/Projects.md
@@ -1134,7 +1134,7 @@ See also [SQLDrivers page](SQLDrivers).
   * [sparse](https://github.com/james-bowman/sparse) - Go Sparse matrix formats for linear algebra supporting scientific and machine learning applications, compatible with [gonum](https://github.com/gonum/gonum/mat) matrix libraries.
   * [statistics](https://github.com/grd/stat) - GNU GSL Statistics (GPLv3)
   * [stats](https://github.com/montanaflynn/stats) - A statistics package with common functions missing from the Golang standard library.
-  * [Tideland golib](https://github.com/tideland/golib) - Numerics package for statistcal analysis
+  * [Tideland golib](https://github.com/tideland/golib) - Numerics package for statistical analysis
   * [Units](https://github.com/smyrman/units) - Implements types, units, converter functions and some mathematics for some common physical types. lib
   * [vector](https://github.com/proxypoke/vector) - A small vector lib.
 
@@ -1521,7 +1521,7 @@ See also [SQLDrivers page](SQLDrivers).
 ### Resource Embedding
 
   * [fileb0x](https://github.com/UnnoTed/fileb0x) - Simple tool to embed files in go with focus on "customization" and ease to use.
-  * [go-bindata](https://github.com/jteeuwen/go-bindata) - Package that converts any file into managable Go source code.
+  * [go-bindata](https://github.com/jteeuwen/go-bindata) - Package that converts any file into manageable Go source code.
   * [go-resources](https://github.com/omeid/go-resources) - Unfancy resources embedding with Go.
   * [go.rice](https://github.com/GeertJohan/go.rice) - go.rice is a Go package that makes working with resources such as html,js,css,images and templates very easy.
   * [implant](https://github.com/skx/implant/) - implant allows embedding static resources, from a series of directories (recursively).
@@ -1632,7 +1632,7 @@ See also [SQLDrivers page](SQLDrivers).
   * [logparse](https://github.com/xojoc/logparse) - Parser for most common log formats
   * [NTemplate](https://github.com/yohcop/ntemplate.go) - Nested Templates
   * [parse](https://github.com/rymis/parse) - PEG parser that uses reflection to define grammar
-  * [peg](https://github.com/badgerodon/peg) - Parsing Expression Grammer Parser
+  * [peg](https://github.com/badgerodon/peg) - Parsing Expression Grammar Parser
   * [pigeon](https://github.com/mna/pigeon) - Parsing Expression Grammar (PEG) Parser generator for Go
   * [plural](https://github.com/rickb777/plural) - No-fuss plurals for formatting both countable and continuous ranges of values.
   * [polyglot](https://github.com/lxn/polyglot) - String translation utilities for Go

diff --git a/TestComments.md b/TestComments.md
@@ -92,7 +92,7 @@ print them.
 
 Avoid comparing results that may inherently depend on output stability of some
 external package that you do not control. Instead, the test should compare on
-semantically relevant information that is stable and resistent to changes in
+semantically relevant information that is stable and resistant to changes in
 your dependencies. For functionality that returns a formatted string or
 serialized bytes, it is generally not safe to assume that the output is stable.
-Original file line number
+Diff line change
@@ Expand Up @@
       }
       ```
-    - Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as refering to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interfaces should also be considered.
+    - Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as referring to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interfaces should also be considered.
     - Patrick Smith: We might consider requiring the type keyword when defining methods on generic types. This makes the code a little more verbose, but clearer and more consistent (now type parameters are always preceded by the type keyword).
@@ Expand Down @@