fix typos in documentation (#2284)

alpaka-group · Jun 4, 2024 · c2a37cc · c2a37cc
1 parent 4bee45e
commit c2a37cc
Show file tree

Hide file tree

Showing 8 changed files with 12 additions and 12 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -7,7 +7,7 @@ Please review our more detailed [Coding Guidelines](https://alpaka.readthedocs.i
 This project is set up for use with [pre-commit](https://pre-commit.com). Using it will make your code conform with most
 of our (easily automatable) code style guidelines automatically.
 In very short (for anything further see [pre-commit](https://pre-commit.com)), after running the following in your
-working clone of Alpaka
+working clone of alpaka
 ```bash
 # if not yet done, install the pre-commit executable following https://pre-commit.com
 cd /path/to/alpaka-working-clone
@@ -28,7 +28,7 @@ the repository root. If you were using `pre-commit` during your changes, this ha
 not, find further instructions below.
 
 ### Visual Studio and CLion
-Suport for clang-format is built-in since Visual Studio 2017 15.7 and CLion 2019.1.
+Support for clang-format is built-in since Visual Studio 2017 15.7 and CLion 2019.1.
 The .clang-format file in the repository will be automatically detected and formatting is done as you type, or triggered when pressing the format hotkey.
 
 ### Bash

diff --git a/README_SYCL.md b/README_SYCL.md
@@ -97,7 +97,7 @@ These can be used interchangeably (some restrictions apply - see below) with the
   See [Intel's FAQ](https://github.com/intel/compute-runtime/blob/master/opencl/doc/FAQ.md#feature-double-precision-emulation-fp64) for more information.
 * The FPGA back-end does not support atomics. alpaka will not check this.
 * Shared memory works but on the GPU it is very slow.
-* The latest Intel OpenCL CPU runtime does not work properly. Some tests (`atomicTest`, `blockSharedTest`, `blockSharedSharingTest` and `warpTest`) fail with a `PI_ERROR_OUT_OF_RESOURCES`. The only runtime version that seems to work is 2022.14.8.0.04 (can be downloaded [here](https://github.com/intel/llvm/releases/download/2022-WW33/oclcpuexp-2022.14.8.0.04_rel.tar.gz) apart from a bug with `all_of_group` / `any_of_group` that requires the warp size being equal to the block size as a workaround.
+* The latest Intel OpenCL CPU runtime does not work properly. Some tests (`atomicTest`, `blockSharedTest`, `blockSharedSharingTest` and `warpTest`) fail with a `PI_ERROR_OUT_OF_RESOURCES`. The only runtime version that seems to work is 2022.14.8.0.04 (can be downloaded [here](https://github.com/intel/llvm/releases/download/2022-WW33/oclcpuexp-2022.14.8.0.04_rel.tar.gz)) apart from a bug with `all_of_group` / `any_of_group` that requires the warp size being equal to the block size as a workaround.
 
 ### Choosing the sub-group size (warp size)
 

diff --git a/docs/source/advanced/cmake.rst b/docs/source/advanced/cmake.rst
@@ -167,7 +167,7 @@ alpaka_FTZ
 alpaka_DEBUG_OFFLOAD_ASSUME_HOST
   .. code-block::
 
-     Allow host-only contructs like assert in offload code in debug mode.
+     Allow host-only constructs like assert in offload code in debug mode.
 
 alpaka_USE_MDSPAN
   .. code-block::

diff --git a/docs/source/basic/abstraction.rst b/docs/source/basic/abstraction.rst
@@ -189,7 +189,7 @@ Control flow statements result in a predicate and only in those threads where it
 Not only *CUDA* GPUs support the execution of multiple threads in a warp.
 Full blown vector processors with good compilers are capable of combining multiple loop iterations containing complex control flow statements in a similar manner as *CUDA*.
 
-Due to the synchronitiy of threads within a warp, memory operations will always occur at the same time in all threads.
+Due to the synchronization of threads within a warp, memory operations will always occur at the same time in all threads.
 This allows to coalesce memory accesses.
 Different *CUDA* devices support different levels of memory coalescing.
 Older ones only supported combining multiple memory accesses if they were aligned and sequential in the order of thread indices.

diff --git a/docs/source/dev/backends.rst b/docs/source/dev/backends.rst
@@ -242,7 +242,7 @@ The following tables list the functions available in the `CUDA Runtime API <http
     +---------------------------------+-----------------------------------------------------------------------+
     | cudaGetDevice                   | n/a (no current device)                                               |
     +---------------------------------+-----------------------------------------------------------------------+
-    | cudaGetDeviceCount              | std::sizet alpaka::getDevCount< TPlatform >()                         |
+    | cudaGetDeviceCount              | std::size_t alpaka::getDevCount< TPlatform >()                         |
     +---------------------------------+-----------------------------------------------------------------------+
     | cudaGetDeviceFlags              | --                                                                    |
     +---------------------------------+-----------------------------------------------------------------------+

diff --git a/docs/source/dev/details.rst b/docs/source/dev/details.rst
@@ -180,7 +180,7 @@ A type can model the queue concept completely by defining specializations for ``
 This functionality can be accessed by the corresponding ``alpaka::enqueue`` and ``alpaka::empty`` template functions.
 
 Currently there is no native language support for describing and checking concepts in C++ at compile time.
-A study group (SG8) is working on the ISO `specification for conecpts <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf>`_ and compiler forks implementing them do exist.
+A study group (SG8) is working on the ISO `specification for concepts <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf>`_ and compiler forks implementing them do exist.
 For usage in current C++ there are libraries like `Boost.ConceptCheck <https://www.boost.org/doc/libs/1_58_0/libs/concept_check/concept_check.htm>`_ which try to emulate requirement checking of concept types.
 Those libraries often exploit the preprocessor and require non-trivial changes to the function declaration syntax.
 Therefore the *alpaka* library does not currently make use of *Boost.ConceptCheck*.
@@ -239,7 +239,7 @@ However, due to SFINAE, this would not result in a compiler error but rather onl
 The ``std::enable_if`` template results in a valid expression, if the condition it contains evaluates to true, and an invalid expression if it is false.
 Therefore it can be used to disable specializations depending on arbitrary boolean conditions.
 It is utilized in the case where the ``TaskId`` member is unequal one or the ``TQueue`` does not inherit from ``UserQueue``.
-In this cirumstances, the condition itself results in valid code but because it evaluates to false, the ``std::enable_if`` specialization results in invalid code and the whole ``Enqueue`` template specialization gets omitted.
+In this circumstances, the condition itself results in valid code but because it evaluates to false, the ``std::enable_if`` specialization results in invalid code and the whole ``Enqueue`` template specialization gets omitted.
 
 Argument dependent lookup for math functions
 --------------------------------------------

diff --git a/docs/source/dev/style.rst b/docs/source/dev/style.rst
@@ -10,7 +10,7 @@ This project is set up for use with `pre-commit <https://pre-commit.com>`_. Usin
 of our (easily automatable) code style guidelines automatically. Pre-commit is a tool that manages
 `git hooks <https://git-scm.com/docs/githooks>`_ conveniently for you.
 In very short (for anything further see `pre-commit <https://pre-commit.com>`_), after running the following in your
-working clone of Alpaka
+working clone of alpaka
 
 .. code-block:: bash
 
@@ -26,7 +26,7 @@ with the necessary changes such that
 
   git add -u
 
-will make the next commit pass. Although disencouraged, in urgent cases it might be needed to be able to commit even if
+will make the next commit pass. Although discouraged, in urgent cases it might be needed to be able to commit even if
 the checks fail. For such cases, you can either use
 
 .. code-block:: bash

diff --git a/docs/source/dev/test.rst b/docs/source/dev/test.rst
@@ -3,7 +3,7 @@
 Writing a unit test
 ===================
 
-After implementing a new functionality in Alpaka, it is recommended to test it. Indeed, having no compile time errors
+After implementing a new functionality in alpaka, it is recommended to test it. Indeed, having no compile time errors
 when building alpaka with any backend doesn't mean that such functionality is well implemented and behaves as expected.
 
 Unit tests are written and integrated with `Catch2 <https://github.com/catchorg/Catch2>`_ and they are standalone executables located in the ``test/unit`` and
@@ -46,7 +46,7 @@ Test cases using an alpaka accelerator are then typically introduced with the ``
 It takes three arguments:
 * a free form test name (must be unique)
 * a tag
-* the accelerator(s) that must run the test case(s) (i.e. ``alpaka::test::TestAccs`` targets all the accelereators selected
+* the accelerator(s) that must run the test case(s) (i.e. ``alpaka::test::TestAccs`` targets all the accelerators selected
 by the ``TestAccs`` header).
 
 Some aliases might be useful: