[Doc] Fix typos (#5283)

* Fix typos

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

CMakeLists.txt

@@ -72,7 +72,7 @@ endif()
 
 if (WIN32)
   # For `Debug` configs MSVC links to a debuggable runtime by default which has
-  # symbol conflicts with the prebuilt LLVM in `Release`. We shoule be providing
+  # symbol conflicts with the prebuilt LLVM in `Release`. We should be providing
   # prebuilt LLVMs for both `Debug` and `Release` but LLVM 10 cannot be built by
   # MSVC in `Debug` config because MSVC would try to fill uninitialize memory
   # with `0xCC` but it too breaks `LLVMTableGen` which is depended on by almost

ci/Dockerfile.ubuntu.18.04

@@ -51,7 +51,7 @@ RUN tar xf cmake-3.20.5-linux-x86_64.tar.gz && \
     rm cmake-3.20.5-linux-x86_64.tar.gz
 ENV PATH="/cmake-3.20.5-linux-x86_64/bin:$PATH"
 
-# Intall LLVM 10
+# Install LLVM 10
 WORKDIR /
 # Make sure this URL gets updated each time there is a new prebuilt bin release
 RUN wget https://github.com/taichi-dev/taichi_assets/releases/download/llvm10_linux_patch2/taichi-llvm-10.0.0-linux.zip

ci/Dockerfile.ubuntu.18.04.cpu

@@ -27,7 +27,7 @@ RUN wget https://github.com/Kitware/CMake/releases/download/v3.20.5/cmake-3.20.5
     rm cmake-3.20.5-linux-x86_64.tar.gz
 ENV PATH="/cmake-3.20.5-linux-x86_64/bin:$PATH"
 
-# Intall LLVM 10
+# Install LLVM 10
 WORKDIR /
 # Make sure this URL gets updated each time there is a new prebuilt bin release
 RUN wget https://github.com/taichi-dev/taichi_assets/releases/download/llvm10_linux_patch2/taichi-llvm-10.0.0-linux.zip && \

ci/Dockerfile.ubuntu.20.04

@@ -52,7 +52,7 @@ RUN tar xf cmake-3.20.5-linux-x86_64.tar.gz && \
     rm cmake-3.20.5-linux-x86_64.tar.gz
 ENV PATH="/cmake-3.20.5-linux-x86_64/bin:$PATH"
 
-# Intall LLVM 10
+# Install LLVM 10
 WORKDIR /
 # Make sure this URL gets updated each time there is a new prebuilt bin release
 RUN wget https://github.com/taichi-dev/taichi_assets/releases/download/llvm10_linux_patch2/taichi-llvm-10.0.0-linux.zip

ci/Dockerfile.ubuntu.20.04.cpu

@@ -23,7 +23,7 @@ RUN tar xf cmake-3.20.5-linux-x86_64.tar.gz && \
     rm cmake-3.20.5-linux-x86_64.tar.gz
 ENV PATH="/cmake-3.20.5-linux-x86_64/bin:$PATH"
 
-# Intall LLVM 10
+# Install LLVM 10
 WORKDIR /
 # Make sure this URL gets updated each time there is a new prebuilt bin release
 RUN wget https://github.com/taichi-dev/taichi_assets/releases/download/llvm10_linux_patch2/taichi-llvm-10.0.0-linux.zip

ci/Dockerfile_generator.py

@@ -113,7 +113,7 @@
 """
 
 LLVM_BLOCK = """
-# Intall LLVM 10
+# Install LLVM 10
 WORKDIR /
 # Make sure this URL gets updated each time there is a new prebuilt bin release
 RUN wget https://github.com/taichi-dev/taichi_assets/releases/download/llvm10_linux_patch2/taichi-llvm-10.0.0-linux.zip

cmake/TaichiCXXFlags.cmake

@@ -72,7 +72,7 @@ endif()
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-private-field ")
 
     # [Global] By evaluating "constexpr", compiler throws a warning for functions known to be dead at compile time.
-    # However, some of these "constexpr" are debug flags and will be manually enabled upon debuging.
+    # However, some of these "constexpr" are debug flags and will be manually enabled upon debugging.
     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unneeded-internal-declaration ")
 endif ()
 

cmake/TaichiCore.cmake

@@ -471,7 +471,7 @@ if(TI_WITH_PYTHON AND NOT TI_EMSCRIPTENED)
     # https://cmake.org/cmake/help/v3.13/command/target_link_libraries.html?highlight=target_link_libraries#linking-object-libraries
     target_link_libraries(${CORE_WITH_PYBIND_LIBRARY_NAME} PRIVATE ${CORE_LIBRARY_NAME})
 
-    # TODO 4832: move some header dependencis to other targets, e.g., gui
+    # TODO 4832: move some header dependencies to other targets, e.g., gui
     target_include_directories(${CORE_WITH_PYBIND_LIBRARY_NAME}
       PRIVATE
         ${PROJECT_SOURCE_DIR}

cmake/TaichiExamples.cmake

@@ -28,7 +28,7 @@ target_link_libraries(${EXAMPLES_NAME} PRIVATE
 	metal_codegen
 	)
 
-# TODO 4832: be specific on the header dependencis here, e.g., ir
+# TODO 4832: be specific on the header dependencies here, e.g., ir
 target_include_directories(${EXAMPLES_NAME}
   PRIVATE
     ${PROJECT_SOURCE_DIR}

docs/design/llvm_sparse_runtime.md

@@ -199,7 +199,7 @@ i32 Dynamic_append(Ptr meta_, Ptr node_, i32 data) {
 2. `chunk_strat` tracks the starting index of a given chunk, and always starts at `0` . `p_chunk_ptr` is initialized to the pointer to the first chunk.
 3. Inside the `while` loop, checks if the given chunk slot is empty first, and allocates a new chunk if so.
 4. Compares if the determined index `i` falls within the current chunk.
-   1. If so, stores `data` into the corresponding slot in this chunk. Note that the first `sizeof(Ptr)` bytes are skiped: they are reserved to store the address of the next chunk.
+   1. If so, stores `data` into the corresponding slot in this chunk. Note that the first `sizeof(Ptr)` bytes are skipped: they are reserved to store the address of the next chunk.
    2. Otherwise, jumps to the next chunk.
 
 # Runtime
@@ -290,7 +290,7 @@ i32 reserve_new_element() {
 }
 ```
 
-It increments `num_elements` to get the index of this new elment, and calculates the belonging chunk ID. Then it ensures that the chunk is actually allocated using [`touch_chunk()`](https://github.com/taichi-dev/taichi/blob/172cab8a57fcfc2d766fe2b7cd40af669dadf326/taichi/runtime/llvm/runtime.cpp#L1570-L1584):
+It increments `num_elements` to get the index of this new element, and calculates the belonging chunk ID. Then it ensures that the chunk is actually allocated using [`touch_chunk()`](https://github.com/taichi-dev/taichi/blob/172cab8a57fcfc2d766fe2b7cd40af669dadf326/taichi/runtime/llvm/runtime.cpp#L1570-L1584):
 
 ```cpp
 void ListManager::touch_chunk(int chunk_id) {

docs/lang/articles/advanced/layout.md

@@ -164,7 +164,7 @@ y = ti.field(ti.f32)
 ti.root.dense(ti.i, M).place(x, y)
 ```
 
-The memroy layout then becomes
+The memory layout then becomes
 
 ```
 #  address: low .............................. high
@@ -175,7 +175,7 @@ Here, `place` interleaves the elements of Taichi fields `x` and `y`.
 
 As previously introduced, the access methods to `x` and `y` remain the same for both  AoS and SoA. Therefore, the data layout can be changed flexibly without revising the application logic.
 
-<!-- haidong: I hope this part is 1) revised to a runnable and complete example 2) provides performane constrast-->
+<!-- haidong: I hope this part is 1) revised to a runnable and complete example 2) provides performance constrast-->
 For better illustration, let's see an example of an 1D wave equation solver:
 
 ```python
@@ -336,7 +336,7 @@ Actually, the above demonstrated `ti.root` statements are implemented with `Fiel
 
 By default, Taichi implicitly fits a field in a larger buffer with power-of-two dimensions. We take the power-of-two padding convention because it is widely adopted in computer graphics. The design enables fast indexing with bitwise arithmetic and better memory address alignment, while trading off memory occupations.
 
-For example, a `(18, 65)` field is materialized with a `(32, 128)` buffer, which is acceptable. As field size grows, the padding strategy can be exaggeratedly unbearable: `(129, 6553600)` will be expanded to `(256, 6335600)`, which allocates considerable unsed blank memory. Therefore, Taichi provides the optional packed mode to allocate buffer that tightly fits the requested field shape. It is especially useful when memory usage is a major concern.
+For example, a `(18, 65)` field is materialized with a `(32, 128)` buffer, which is acceptable. As field size grows, the padding strategy can be exaggeratedly unbearable: `(129, 6553600)` will be expanded to `(256, 6335600)`, which allocates considerable unused blank memory. Therefore, Taichi provides the optional packed mode to allocate buffer that tightly fits the requested field shape. It is especially useful when memory usage is a major concern.
 
 To leverage the packed mode, spcifify `packed` in `ti.init()` argument:
 
@@ -350,4 +350,4 @@ ti.init(packed=True)
 a = ti.field(ti.i32, shape=(18, 65))  # no padding
 ```
 
-You might observe mild performance regression with the packed mode due to more complex adressing and memory alignment. Therefore, the packed mode should be specified only when memory capacity is a major concern.
+You might observe mild performance regression with the packed mode due to more complex addressing and memory alignment. Therefore, the packed mode should be specified only when memory capacity is a major concern.

docs/lang/articles/advanced/performance.md

@@ -109,7 +109,7 @@ see the [Fields (advanced)](layout.md) section.
 
 Taichi comes with a few optimizations that leverage the *fast memory* (e.g. CUDA
 shared memory, L1 cache) for performance optimization. The idea is straightforward:
-Wherever possible, Taichi substitutes the access to the global memroy (slow) with
+Wherever possible, Taichi substitutes the access to the global memory (slow) with
 that to the local one (fast), and writes the data in the local memory (e.g., CUDA
 shared memory) back to the global memory in the end. Such transformations preserve
 the semantics of the original program (will be explained later).

docs/lang/articles/advanced/sparse.md

@@ -32,7 +32,7 @@ we will significantly save storage and computing power.
 The key to leveraging spatial sparsity is replacing *dense* grids with *sparse* grids.
 :::
 
-The traditional sparse spatial data stuctures are [Quadtrees](https://en.wikipedia.org/wiki/Quadtree) (2D) and
+The traditional sparse spatial data structures are [Quadtrees](https://en.wikipedia.org/wiki/Quadtree) (2D) and
 [Octrees](https://en.wikipedia.org/wiki/Octree) (3D). Since dereferencing pointers is relatively costly on modern computer architectures, compared to quadtrees and octrees, it is more performance-friendly to use shallower trees with larger branching factors.
 [VDB](https://www.openvdb.org/) and [SPGrid](http://pages.cs.wisc.edu/~sifakis/papers/SPGrid.pdf) are such examples.
 In Taichi, programmers can compose data structures similar to VDB and SPGrid with SNodes. The advantages of Taichi sparse spatial data structures include

docs/lang/articles/contribution/contributor_guide.md

@@ -327,7 +327,7 @@ The following examples can be found in [cmake/TaichiCXXFlags.cmake](https://gith
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nullability-completeness ")
 
 # [Global] By evaluating "constexpr", compiler throws a warning for functions known to be dead at compile time.
-# However, some of these "constexpr" specifiers are debug flags and will be manually enabled upon debuging.
+# However, some of these "constexpr" specifiers are debug flags and will be manually enabled upon debugging.
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unneeded-internal-declaration ")
 ```
 

docs/lang/articles/contribution/dev_install.md

@@ -211,7 +211,7 @@ We provide pre-built, customized LLVM binaries. For now, Taichi supports LLVM 10
 
 <TabItem value="windows">
 
-Add an environment variable `LLVM_DIR` with value `<Path to the extrated LLVM binary>`
+Add an environment variable `LLVM_DIR` with value `<Path to the extracted LLVM binary>`
 
 </TabItem>
 
@@ -275,7 +275,7 @@ cmake --build . --target=INSTALL --config=Release
 ```
 
 1. Use Visual Studio 2017+ to build **LLVM.sln**.
-2. Ensure that you use the **Release** configuration. After building the `INSTALL` project (under folde **CMakePredefinedTargets** in the Solution Explorer window).
+2. Ensure that you use the **Release** configuration. After building the `INSTALL` project (under folder **CMakePredefinedTargets** in the Solution Explorer window).
 3. If you use MSVC 2019+, ensure that you use **C++17** for the `INSTALL` project.
 4. When the build completes, add an environment variable `LLVM_DIR` with value `<PATH_TO_BUILD>/build/installed/lib/cmake/llvm`.
 

docs/lang/articles/contribution/write_test.md

@@ -279,7 +279,7 @@ Now, Taichi supports the following extensions:
 | async_mode    | Asynchronous execution mode                                   |
 | quant_basic   | Basic operations in quantization                              |
 | quant         | Full quantization functionalities                             |
-| data64        | 64-bit data and arithmetics                                   |
+| data64        | 64-bit data and arithmetic                                   |
 | adstack       | For keeping the history of mutable local variables in autodiff|
 | bls           | Block-local storage                                           |
 | assertion     | Run-time asserts in Taichi kernels                            |

docs/lang/articles/faq.md

@@ -60,7 +60,7 @@ The `dynamic` SNode supports variable-length fields. It acts similarly to `std::
 An alternative solution is to allocate a large enough `dense` field, with a corresponding 0-D field
 `field_len[None]` tracking its length. In practice, programs allocating memory using `dynamic`
 SNodes may be less efficient than using `dense` SNodes, due to dynamic data structure
-maintainance overheads.
+maintenance overheads.
 :::
 
 ### How do I program on less structured data structures (such as graphs and tetrahedral meshes) in Taichi?

docs/lang/articles/misc/cli_utilities.md

@@ -5,7 +5,7 @@ sidebar_position: 6
 # Command line utilities
 
 A successful installation of Taichi should add a CLI (Command-Line
-Interface) to your system, which is helpful to perform several rountine
+Interface) to your system, which is helpful to perform several routine
 tasks quickly. To invoke the CLI, please run `ti` or
 `python3 -m taichi`.
 

docs/lang/articles/misc/debugging.md

@@ -302,7 +302,7 @@ AssertionError:
 ```
 The error message can be verbose and scary. However, many stack frames reveal
 Taichi compiler implementation details, which are too noisy for debugging.
-In current verison, you could choose to supress the level of traceback messages by setting `sys.tracebacklimit`,
+In current version, you could choose to suppress the level of traceback messages by setting `sys.tracebacklimit`,
 which makes the stack traceback from Taichi-scope more intuitive:
 
 ```python {2}

docs/lang/articles/misc/export_results.md

@@ -308,11 +308,11 @@ writer.add_faces(indices)
 - Add optional channels
 
 ```python
-# Add custome vertex channel, the input should include a key, a supported datatype and, the data np.array
+# Add custom vertex channel, the input should include a key, a supported datatype and, the data np.array
 vdata = np.random.rand(20)
 writer.add_vertex_channel("vdata1", "double", vdata)
 
-# Add custome face channel
+# Add custom face channel
 foo_data = np.zeros(12)
 writer.add_face_channel("foo_key", "foo_data_type", foo_data)
 # error! because "foo_data_type" is not a supported datatype. Supported ones are

docs/lang/articles/misc/global_settings.md

@@ -66,7 +66,7 @@ are specified, then the one in the environment variable will
 
 :::note
 
-If `ti.init` is called twice, then the configuation in first invocation
+If `ti.init` is called twice, then the configuration in first invocation
 will be completely discarded, e.g.:
 
 ```python {1,3}

docs/lang/articles/misc/internal.md

@@ -314,7 +314,7 @@ index does the i-th virtual index** correspond to?
 
 Each `SNode` can have a different virtual-to-physical mapping.
 `physical_index_position[i] == -1` means the `i`-th virtual index does
-not corrspond to any physical index in this `SNode`.
+not correspond to any physical index in this `SNode`.
 
 `SNode` s in handy dense fields (i.e.,
 `a = ti.field(ti.i32, shape=(128, 256, 512))`) have **trivial**

docs/rfcs/20220413-aot-for-all-snode.md

@@ -46,7 +46,7 @@ While this is convenient for Python users, it imposes challenges for the deploym
 
 1. Taichi fields are currently implemented as global variables.
 
-    This would result in the Taichi kernels being "not pure" and relying on implicit information. When saving such kernels into the AOT module, it is also necessary to save all the depdendant global states. Ideally, users should be able to create Taichi fields, and pass them into Taichi kernels as parameters.
+    This would result in the Taichi kernels being "not pure" and relying on implicit information. When saving such kernels into the AOT module, it is also necessary to save all the dependent global states. Ideally, users should be able to create Taichi fields, and pass them into Taichi kernels as parameters.
 
 2. SNodes types are missing from the AOT module.
 
@@ -143,7 +143,7 @@ The only change from the existing API is that, you will need to prepend the fiel
 
 There will be two ways to retrieve a field from a tree:
 
-* By name: `add_field()` takes in a `name` parameter. After building a SNode tree, Taichi will generate an attribute for each registered field on that tree. This allows you to directly write `tr.x` to access the field named `'x'`. `name` serves as the unique identifer of the field in the tree. Note that when placing, it is the names being passed in.
+* By name: `add_field()` takes in a `name` parameter. After building a SNode tree, Taichi will generate an attribute for each registered field on that tree. This allows you to directly write `tr.x` to access the field named `'x'`. `name` serves as the unique identifier of the field in the tree. Note that when placing, it is the names being passed in.
 * By field handle: You can also use the field handle returned by `add_field()` to access a field. Here's an example:
    ```py
    builder = ti.SNodeTreeBuilder()