Merge pull request #1684 from jasonrandrews/spelling

Spelling and link fixes

Author: jasonrandrews

.wordlist.txt

@@ -3688,4 +3688,84 @@ ver
 vit
 wav
 za
-zh
+zh
+ACM
+APs
+ASG
+AutoModelForSpeechSeq
+AutoProcessor
+Avin
+Bioinformatics
+CDK
+Dropbear
+DxeCore
+EFI
+FFTW
+HMMER
+ILP
+IoC
+Jython
+Khrustalev
+LCP
+Maranget
+Minimap
+NFS
+NVPL
+OMP
+OSR
+OneAPI
+OpenRNG
+OpenSSH
+Phttps
+RNG
+Runbook
+SSM
+Shrinkwrap
+Shrinkwrap's
+TSO
+TSan
+TSan's
+ThreadSanitizer
+Toolkits
+ULP
+ULPs
+VSL
+Yury
+Zarlez
+ada
+armtest
+atomicity
+autoscaling
+cmath
+cuBLAS
+cuDNN
+distro's
+dtype
+dxecore
+foir
+fourier
+getter
+libm
+miniconda
+msg
+nInferencing
+oneAPI
+oneapi
+openai
+pseudorandom
+quasirandom
+reorderings
+rootfs
+runbook
+safetensors
+superset
+sysroot
+testroot
+threadsanitizercppmanual
+toolchain's
+transpiles
+vectorstore
+vlen
+vv
+webhook
+xE

content/learning-paths/cross-platform/_example-learning-path/appendix-3-test.md

@@ -18,9 +18,7 @@ The framework allows you to parse Learning Path articles and generate instructio
 2. [Edit Learning Path pages](#edit-learning-path-pages)
 3. [Edit metadata](#edit-metadata)
 4. [Run the framework](#run-the-framework)
-5. [Result summary](#result-summary)
-6. [Visualize results](#visualize-results)
-
+5. [Advanced usage for embedded development](#advanced-usage-for-embedded-development)
 
 ## Install dependencies
 
@@ -279,7 +277,7 @@ In the example above, the summary indicates that for this Learning Path all test
 ## Advanced usage for embedded development
 ### Using the Corstone-300 FVP
 
-By default, the framework runs instructions on the Docker images specified by the [metadata](#edit-metadata). For embedded development, it is possible to build software in a container instance and then check its behaviour on the Corstone-300 FVP.
+By default, the framework runs instructions on the Docker images specified by the [metadata](#edit-metadata). For embedded development, it is possible to build software in a container instance and then check its behavior on the Corstone-300 FVP.
 
 For this, all container instances used by the test framework mount a volume in `/shared`. This is where software for the target FVP can be stored. To check the execution, the FVP commands just need to be identified as a `fvp` section for the framework.
 

content/learning-paths/embedded-and-microcontrollers/introduction-to-tinyml-on-arm/env-setup-5.md

@@ -74,4 +74,4 @@ Your next steps depend on your hardware.
 
 If you have the Grove Vision AI Module, proceed to [Set up the Grove Vision AI Module V2 Learning Path](/learning-paths/embedded-and-microcontrollers/introduction-to-tinyml-on-arm/setup-7-grove/).
 
-If you do not have the Grove Vision AI Module, you can use the Corstone-320 FVP instead. See the Learning Path [Set up the Corstone-320 FVP](/learning-paths/microcontrollers/introduction-to-tinyml-on-arm/env-setup-6-fvp/).
+If you do not have the Grove Vision AI Module, you can use the Corstone-320 FVP instead. See the Learning Path [Set up the Corstone-320 FVP](/learning-paths/embedded-and-microcontrollers/introduction-to-tinyml-on-arm/env-setup-6-fvp/).

content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/2.md

@@ -48,7 +48,7 @@ In the pseudo code snippet above, it's possible for operation B to precede opera
 
 - `memory_order_acquire` and `memory_order_release`
 
-Acquire and release are used to synchronise atomic variables.  In the example below, thread A writes to memory (allocating the string and setting data) and then uses a release-store to publish these updates. Thread B repeatedly performs an acquire-load until it sees the updated pointer. The acquire ensures that once Thread B sees a non-null pointer, all writes made by Thread A (including the update to data) become visible, synchronizing the two threads.
+Acquire and release are used to synchronize atomic variables.  In the example below, thread A writes to memory (allocating the string and setting data) and then uses a release-store to publish these updates. Thread B repeatedly performs an acquire-load until it sees the updated pointer. The acquire ensures that once Thread B sees a non-null pointer, all writes made by Thread A (including the update to data) become visible, synchronizing the two threads.
 
 ```cpp
 // Thread A 

content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/4.md

@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## How can I detect infrequent race conditions?
 
-ThreadSanitizer, commonly referred to as `TSan`, is a concurrency bug detection tool that identifies data races in multi-threaded programs. By instrumenting code at compile time, TSan dynamically tracks memory operations, monitoring lock usage and detecting inconsistencies in thread synchronization. When it finds a potential data race, it reports detailed information to aid debugging. TSan’s overhead can be significant, but it provides valuable insights into concurrency issues often missed by static analysis.
+ThreadSanitizer, commonly referred to as `TSan`, is a concurrency bug detection tool that identifies data races in multi-threaded programs. By instrumenting code at compile time, TSan dynamically tracks memory operations, monitoring lock usage and detecting inconsistencies in thread synchronization. When it finds a potential data race, it reports detailed information to aid debugging. TSan's overhead can be significant, but it provides valuable insights into concurrency issues often missed by static analysis.
 
 TSan is available through both recent `clang` and `gcc` compilers. 
 

content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/_index.md

@@ -27,7 +27,7 @@ armips:
     - Neoverse
 tools_software_languages:
     - C++
-    - ThreadSantizer (TSan)
+    - ThreadSanitizer (TSan)
 operatingsystems:
     - Linux
     - Runbook
@@ -38,7 +38,7 @@ further_reading:
         link: https://en.cppreference.com/w/cpp/atomic/memory_order
         type: documentation
     - resource:
-        title: Thread Santiser Manual 
+        title: Thread Sanitizer Manual 
         link: Phttps://github.com/google/sanitizers/wiki/threadsanitizercppmanual
         type: documentation
 

content/learning-paths/servers-and-cloud-computing/copilot-extension-deployment/2-cdk-services.md

@@ -7,7 +7,7 @@ layout: learningpathall
 ---
 ## Which AWS Services do I need?
 
-In the first GitHub Copilot Extension Learning Path, [Build a GitHub Copilot Extension in Python](learning-paths/servers-and-cloud-computing/gh-copilot-simple), you ran a GitHub Copilot Extension on a single Linux computer, with the public URL provided by an ngrok tunnel to your localhost.
+In the first GitHub Copilot Extension Learning Path, [Build a GitHub Copilot Extension in Python](/learning-paths/servers-and-cloud-computing/gh-copilot-simple), you ran a GitHub Copilot Extension on a single Linux computer, with the public URL provided by an ngrok tunnel to your localhost.
 
 For a production environment, you require:
 

content/learning-paths/servers-and-cloud-computing/cplusplus_compilers_flags/4.md

@@ -128,44 +128,44 @@ Average elapsed time: 0.0420332 seconds
 Average elapsed time: 0.0155661 seconds
 ```
 
-Here we can observe a notable performance speed up from using higher levels of optimisations.
+Here we can observe a notable performance speed up from using higher levels of optimizations.
 
-Please Note: To understand which lower level optimisation are used by `-O1`, `-O2` and `-O3` we can use the `g++ <optimisatiob level> -Q --help=optimizers` command. 
+Please Note: To understand which lower level optimization are used by `-O1`, `-O2` and `-O3` we can use the `g++ <optimization level> -Q --help=optimizers` command. 
 
 
-### Understanding what was optimised 
+### Understanding what was optimized 
 
 Naturally, the next question is to understand which part of your source code was optimized between the outputs above. Full optimization reports generated by compilers like GCC provide a detailed tree of reports through various stages of the optimization process. For beginners, these reports can be overwhelming due to the sheer volume of information they contain, covering every aspect of the code's transformation and optimization. 
 
 For a more manageable overview, you can enable basic optimization information (`opt-info`) reports using specific arguments such as `-fopt-info-vec`, which focuses on vectorization optimizations. The `-fopt-info` flag can be customized by changing the info bit to target different types of optimizations, making it easier to pinpoint specific areas of interest. 
 
-First, to see what part of our source code was optimised between levels 1 and 2 we can run the following commands to see if our vectorisable loop was indeed vectorised. 
+First, to see what part of our source code was optimized between levels 1 and 2 we can run the following commands to see if our vectorizable loop was indeed vectorized. 
 
 ```bash
 g++ -O1 vectorizable_loop.cpp -o level_1 -fopt-info-vec
 ```
 
-Running the `-O1` flag led showed no terminal output indicating no vectorisation was performed. Next, run the command below with the `-O2` flag.
+Running the `-O1` flag led showed no terminal output indicating no vectorization was performed. Next, run the command below with the `-O2` flag.
 
 ```bash
 g++ -O2 vectorizable_loop.cpp -o level_2 -fopt-info-vec
 ```
 
-This time the `-O2` flag enables our loop to be vectorised as can be seen from the output below.
+This time the `-O2` flag enables our loop to be vectorized as can be seen from the output below.
 
 ```output
 vectorizable_loop.cpp:13:30: optimized: loop vectorized using 16 byte vectors
 /usr/include/c++/13/bits/stl_algobase.h:930:22: optimized: loop vectorized using 16 byte vectors
 ```
 
-To see what optimisations were performed and missed between level 2 and level 3, we could direct the terminal output from all optimisations (`-fopt-info`) to a text file with the commands below. 
+To see what optimizations were performed and missed between level 2 and level 3, we could direct the terminal output from all optimizations (`-fopt-info`) to a text file with the commands below. 
 
 ```bash
 g++ -O2 vectorizable_loop.cpp -o level_2 -fopt-info 2>&1 | tee level2.txt
 g++ -O3 vectorizable_loop.cpp -o level_3 -fopt-info 2>&1 | tee level3.txt
 ```
 
-Comparing the outputs between different levels can highlight where in your source code opportunities to optimise code where missed, for example with the `diff` command. This can help you write source code that is more likely to be optimised. However, source code modifications are out of scope for this learning path and we will leave it to the reader to dive into the differences if they wish to learn more. 
+Comparing the outputs between different levels can highlight where in your source code opportunities to optimize code where missed, for example with the `diff` command. This can help you write source code that is more likely to be optimized. However, source code modifications are out of scope for this learning path and we will leave it to the reader to dive into the differences if they wish to learn more. 
 
 
 ## Target balanced performance

content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/conventions.md

@@ -29,8 +29,8 @@ Table 1. Directory layout
 | `/home/user/workspace/linux`         | Folder with the Linux kernel sources       |
 | `/home/user/workspace/linux-headers` | Directory for installing kernel headers    |
 | `/home/user/workspace/linux-build`   | Folder for the Linux kernel build output   |
-| `/home/user/workspace/glibc`         | Foldr for the Glibc sources                |
-| `/home/user/workspace/glibc-build`   | Directory foir the Glibc build output      |
+| `/home/user/workspace/glibc`         | Folder for the Glibc sources               |
+| `/home/user/workspace/glibc-build`   | Directory for the Glibc build output       |
 
 
 

content/learning-paths/servers-and-cloud-computing/using-and-porting-performance-libs/3.md

@@ -88,7 +88,7 @@ Now you observe the `libamath.so` shared object is linked:
 
 ### What about vector operations?
 
-The naming convention of the Arm Performance Library for scalar operations follows that of `libm`. Hence, you are able to simply update the header file and recompile. For vector operations, one option is to rely on the compiler autovectorisation, whereby the compiler generates the vector code. This is used in the Arm Compiler for Linux (ACfL). Alternatively, you can use vector routines, which uses name mangling. Mangling is a technique used in computer programming to modify the names of vector functions to ensure uniqueness and avoid conflicts. This is particularly important in compiled languages like C++ and in environments where multiple libraries or modules may be used together.
+The naming convention of the Arm Performance Library for scalar operations follows that of `libm`. Hence, you are able to simply update the header file and recompile. For vector operations, one option is to rely on the compiler autovectorization, whereby the compiler generates the vector code. This is used in the Arm Compiler for Linux (ACfL). Alternatively, you can use vector routines, which uses name mangling. Mangling is a technique used in computer programming to modify the names of vector functions to ensure uniqueness and avoid conflicts. This is particularly important in compiled languages like C++ and in environments where multiple libraries or modules may be used together.
 
 In the context of Arm's AArch64 architecture, vector name mangling follows the specific convention below to differentiate between scalar and vector versions of functions.