Merge pull request #119 from epics-containers/typo-fix

Fix some typos (adds Grammarly extension)

.devcontainer/devcontainer.json

@@ -24,7 +24,8 @@
                 "redhat.vscode-yaml",
                 "ryanluker.vscode-coverage-gutters",
                 "charliermarsh.ruff",
-                "ms-azuretools.vscode-docker"
+                "ms-azuretools.vscode-docker",
+                "znck.grammarly"
             ]
         }
     },

.vscode/settings.json

@@ -8,4 +8,10 @@
     "[python]": {
         "editor.defaultFormatter": "charliermarsh.ruff",
     },
+    "grammarly.selectors": [
+        {
+            "language": "markdown",
+            "scheme": "file"
+        }
+    ],
 }

docs/explanations/changes.md

@@ -65,7 +65,7 @@ It is easy to determine which template version and thus which `ec` SemVer versio
 Types of Changes
 ----------------
 
-Changes to the framework are likely to be initiated in one the places described under the following headings. As far as possible such changes will be backwards compatible going forward, and if they are not then a major version release will be made.
+Changes to the framework are likely to be initiated in one of the places described under the following headings. As far as possible such changes will be backwards compatible going forward, and if they are not then a major version release will be made.
 
 ### ibek
 

docs/explanations/introduction.md

@@ -7,7 +7,7 @@
 ```{include} ../overview.md
 ```
 
-See below for more detail on each of these.
+See below for more details on each of these.
 
 ## Concepts
 
@@ -231,7 +231,7 @@ There are these types of CI:
 This project initially targets x86_64 Linux Soft IOCs and RTEMS IOC running
 on MVME5500 hardware. Soft IOCs that require access to hardware on the
 server (e.g. USB or PCIe) will be supported by mounting the hardware into
-the container (theses IOCS will not support Kubernetes failover).
+the container (these IOCS will not support Kubernetes failover).
 
 Other linux architectures could be added to the Kubernetes cluster. We have
 tested arm64 native builds and will add this as a supported architecture

docs/explanations/kubernetes_cluster.md

@@ -47,7 +47,7 @@ The separate clusters allow us to have separate:
 - administrative domain
 - performance domain
 
-The down side is that we have to manage multiple clusters. There is a lot of
+The downside is that we have to manage multiple clusters. There is a lot of
 tooling available to help with this, as multi-cluster using cloud providers is
 quite a common pattern. We are currently investigating approaches to multi-cluster
 management.

docs/explanations/net_protocols.md

@@ -29,7 +29,7 @@ between an external client and a kubernetes Pod:
 
 - use of broadcast packets
 - negotiating an ephemeral port in the application layer (NAT cannot route to
-  a such a port since it looks like a new connection)
+  such a port since it looks like a new connection)
 
 When prototyping IOCs in Kubernetes we found that the following protocols
 had issues for the above reasons:
@@ -57,7 +57,7 @@ is a solution for all protocols we will need.
 
 ## Solution - hostNetwork
 
-To get round these issues and all possible future network issues we:
+To get around these issues and all possible future network issues we:
 
 - Use remote worker nodes that sit in the beamline subnet
 - We use hostNetwork=true which bypasses the CNI and gives Pods direct access

docs/explanations/repositories.md

@@ -28,7 +28,7 @@ that can be used by multiple IOC instances in multiple domains. Because
 Generic IOCs are containerized and not facility specific, they should work
 anywhere. Therefore these make sense as public repositories.
 
-There may be cases where the this is not possible, for example if the
+There may be cases where this is not possible, for example if the
 Generic IOC relies on proprietary support modules with restricted licensing.
 
 The existing Continuous

docs/how-to/ibek-support.md

@@ -6,7 +6,7 @@ This is draft only and out of date. It will be updated soon.
 
 The ibek-defs repository contains ibek support yaml. Here is an example
 procedure for local testing of changes to support yaml in ibek-defs
-along side IOC yaml that uses it.
+alongside IOC yaml that uses it.
 
 (Suggest you do this inside a dev-e7 workspace devcontainer)
 

docs/reference/environment.md

@@ -67,7 +67,7 @@ be adjusted to suit your domain. The variables are as follows:
   (at least for common functions).
 
 - **EC_DEBUG**: causes the `ec` command to output debug information for all
-  commands. For more targetted debugging you can use `ec -d ...`.
+  commands. For more targeted debugging you can use `ec -d ...`.
 
 ## Installation of `ec`
 

docs/tutorials/create_beamline.md

@@ -37,13 +37,13 @@ which to place the new repo. If you do not have one then follow GitHub's
 
 Log in to your account by going here <https://github.com/login>.
 
-You will also need to setup ssh keys to authenticate to github from git. See
+You will also need to set up ssh keys to authenticate to Github from git. See
 [about ssh].
 
 (create-new-beamline-local)=
 ## Create a New Beamline Repo for local deployments
 
-Here we will use the copy the ec services template repository to make a new beamline.
+Here we will use the ec services template repository to make a new beamline.
 
 NOTE: for these tutorials we will use your personal GitHub Account to
 store everything we do, all source repositories and container images. For

docs/tutorials/create_ioc.md

@@ -300,7 +300,7 @@ the c2dv viewer showing an image from the example IOC
 
 Above we looked at some ibek *Support yaml* and created an *IOC yaml* file.
 The details of where *Support yaml* files come from and how to create your
-own are covered a later tutorial {any}`generic_ioc`.
+own are covered in a later tutorial {any}`generic_ioc`.
 
 However, without looking into the set of *Support yaml* files that are
 inside a given Generic IOC we can still make a meaningful *IOC yaml* file.
@@ -380,7 +380,7 @@ Your IOC Instance will now be using the raw startup script and database. But
 should behave exactly the same as before. You are free to experiment with
 changes in the startup script and substitution file and re-deploy the IOC.
 
-To start your new version of the the Instance and replace the previous one use the `deploy-local` command again:
+To start your new version of the Instance and replace the previous one use the `deploy-local` command again:
 
 ```bash
 # re-deploy from local filesystem

docs/tutorials/deploy_example.md

@@ -237,7 +237,7 @@ IOC startup script     /epics/runtime
 
 Being at a terminal prompt inside the IOC container can be useful for debugging
 and testing. You will have access to caget and caput, plus other EPICS tools,
-and you can can inspect files such as the IOC startup script.
+and you can inspect files such as the IOC startup script.
 
 ### Logging
 

docs/tutorials/dev_container.md

@@ -158,7 +158,7 @@ ec stop bl01t-ea-test-02
 
 ### Launching the Developer Container
 
-In the this section we are going to use vscode to launch a developer container.
+In this section we are going to use vscode to launch a developer container.
 This means that all vscode terminals and editors will be running inside a container
 and accessing the container filesystem. This is a very convenient way to work
 because it makes it possible to archive away the development environment
@@ -186,7 +186,7 @@ Once built, open the project in VSCode:
 code .
 ```
 
-When it opens, VSCode may prompt you to open in a devcontainer, if so the choose to do so. If not then use `ctrl-shift-p` and type `Reopen in Container`.
+When it opens, VSCode may prompt you to open in a devcontainer, if so then choose to do so. If not then use `ctrl-shift-p` and type `Reopen in Container`.
 
 You should now be *inside* the container. All terminals started in VSCode will
 be running inside the container. Every file that you open with the VSCode editor
@@ -237,7 +237,7 @@ cd /epics/ioc
 ```
 
 You will just see the default output of a Generic IOC that has no Instance
-configuration. Hit `Ctrl-C` to stop the this default script.
+configuration. Hit `Ctrl-C` to stop the default script.
 
 Next we will add some instance configuration from one of the
 IOC instances in the `bl01t` beamline.

docs/tutorials/generic_ioc.md

@@ -502,7 +502,7 @@ databases:
 
 Finally, also note that the top line refers to a schema file. This is the global
 `ibek` schema for support module definition YAML. A single schema is used
-for all support modules and is published along side the latest release of `ibek`.
+for all support modules and is published alongside the latest release of `ibek`.
 This means that a schema aware editor can provide auto-completion and validation
 for your support module YAML files. The VSCode extension here
 <https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml>
@@ -567,7 +567,7 @@ https://github.com/<YOUR GITHUB ACCOUNT>/ioc-lakeshore340/releases/download/<VER
 This would then be the URL you would put at the top of any IOC instances using
 your released Generic IOC.
 
-To create the instance we create a folder in `bl00t-ea-test-01` and create a IOC Instance definition there as follows:
+To create the instance we create a folder in `bl00t-ea-test-01` and create an IOC Instance definition there as follows:
 
 ```bash
 mkdir -p /workspaces/ioc-lakeshore340/services/bl00t-ea-test-01/config/
@@ -707,7 +707,7 @@ git push
 
 This should trigger a build of the container image in the GitHub Actions CI system. You can watch this by clicking on the `Actions` tab in your new repository.
 
-Assuming the above CI was successful, you now can tag your repository. This will trigger another build and publish the container image to GHCR. The recommended way do this by clicking on the `Releases` tab in your new repository and then clicking on `Create a new release`.
+Assuming the above CI was successful, you now can tag your repository. This will trigger another build and publish the container image to GHCR. The recommended way to do this is by clicking on the `Releases` tab in your new repository and then clicking on `Create a new release`.
 
 :::{figure} ../images/lakeshore_releases.png
 Create a new release on GitHub

docs/tutorials/ioc_changes1.md

@@ -156,7 +156,7 @@ These two definitions allow you to add arbitrary commands to the startup script
 before and after iocInit. This is how we added the `dbLoadRecords` command.
 
 If you want to specify multiple lines in a command you can use the following
-syntax for multi-line stings:
+syntax for multi-line strings:
 
 > ```yaml
 > - type: epics.StartupCommand

docs/tutorials/ioc_changes2.md

@@ -48,7 +48,7 @@ code .
 # Or ctrl+shift+p and choose "Remote-Containers: Reopen in Container"
 ```
 
-Note that if you do not see the prompt to reopen in container, you can open
+Note that if you do not see the prompt to reopen in the container, you can open
 the `Remote` menu with `Ctrl+Alt+O` and select `Reopen in Container`.
 
 The `build` script does two things.

docs/tutorials/rtems_ioc.md

@@ -189,7 +189,7 @@ description: |
     example RTEMS IOC for bl01t
 ```
 
-For configuration we will create a simple database with a few of records and
+For configuration we will create a simple database with a few records and
 a basic startup script. Add the following files to the
 `services/bl01t-ea-test-02/config` directory.
 

docs/tutorials/setup_k8s_new_beamline.md

@@ -130,7 +130,7 @@ Taints:         beamline=bl46p:NoSchedule
                 nodetype=test-rig:NoSchedule
 ```
 
-If you are working with your facility cluster then, you are may not to
+If you are working with your facility cluster then, you may not
 have permission to set up these labels and taints. In this case, your
 administrator will need to do this for you. At DLS, you should expect that
 this is already set up for you.