Merge pull request #60 from marcelldls/grammar-patch

Grammar patch

Author: gilesknap

docs/user/explanations/introduction.rst

@@ -102,7 +102,7 @@ implementing these features:
 - View the current log
 - View historical logs (via graylog or other centralized logging system)
 - Connect to an IOC and interact with its shell
-- debug an ioc by starting a bash shell inside it's container
+- debug an IOC by starting a bash shell inside it's container
 
 
 Kubernetes Alternative
@@ -243,7 +243,7 @@ There are these types of CI:
       or other OCI registry
 
 :beamline definition source:
-    - prepares a helm chart from each ioc instance definition
+    - prepares a helm chart from each IOC instance definition
     - tests that the helm chart is deployable (but does not deploy it)
     - locally launches each IOC instance and loads its configuration to
       verify that the configuration is valid (no system tests because this

docs/user/reference/environment.rst

@@ -58,7 +58,7 @@ Optional Variables
 - **EC_LOG_URL**: if you have a centralized logging service with a web UI then
   you can set this variable to the URL of the web UI. This will then be
   displayed when the command ``ec ioc log-history <ioc-name>`` is run. The
-  ioc name is added to the URL using ``{ioc-name}`` as a placeholder e.g.
+  IOC name is added to the URL using ``{ioc-name}`` as a placeholder e.g.
 
   - ``EC_LOG_URL='https://graylog2.diamond.ac.uk/search?rangetype=relative&fields``
     ``=message%2Csource&width=1489&highlightMessage=&relative=172800&q=pod_name%3A``

docs/user/reference/faq.rst

@@ -12,7 +12,7 @@ engineering screens. TODO: more details will be added to a new section.
 Why have ioc-XXX repositories?
 ------------------------------
 Why not put the Dockerfile and image generating in the support module itself
-instead of creating a separate Generic ioc module for each image we
+instead of creating a separate Generic IOC module for each image we
 generate?
 
 Answers:

docs/user/tutorials/create_beamline.rst

@@ -60,7 +60,7 @@ You will also need to setup ssh keys to authenticate to github from git. See
 Create a New Repository
 -----------------------
 
-Here we will copy the beamline template repository and change it's name to bl01t.
+Here we will copy the beamline template repository and change its name to bl01t.
 We will then step through the changes that are required to make it your own.
 
 NOTE: for these tutorials we will use your personal GitHub Account to
@@ -104,7 +104,7 @@ Steps
 
     #. edit ``environment.sh``
 
-    #. change the name of the example ioc from ``iocs/blxxi-ea-ioc-01`` to
+    #. change the name of the example IOC from ``iocs/blxxi-ea-ioc-01`` to
        ``iocs/bl01t-ea-ioc-01``
 
     #. change the beamline name in the two bash scripts in the ``services``
@@ -118,7 +118,7 @@ Environment.sh
 ~~~~~~~~~~~~~~
 
 Environment.sh is a bash script that is sourced by a beamline user or developer
-in order to setup their environment to work with the beamline.
+in order to set up their environment to work with the beamline.
 
 The command line tool ``ec`` uses the environment configured by this script
 to determine where to deploy IOCS and where to find container images etc.

docs/user/tutorials/create_ioc.rst

@@ -277,7 +277,7 @@ Viewing IOC output
 ~~~~~~~~~~~~~~~~~~
 
 Our detector output is available over PVAccess since we added the PVA plugin.
-We can view it using the ``c2dv`` tool. Theses commands will install ``c2dv``
+We can view it using the ``c2dv`` tool. These commands will install ``c2dv``
 and launch it to view the IOC output:
 
 .. code-block:: bash
@@ -392,7 +392,7 @@ docker if that is what you are using):
 
 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.
+changes in the startup script and substitution file and re-deploy the IOC.
 
 .. note::
 

docs/user/tutorials/debug_generic_ioc.rst

@@ -6,7 +6,7 @@ Debugging Generic IOC Builds
     This tutorial is out of date and will be updated soon.
 
 This tutorial is a continuation of `generic_ioc`. Here we will look into
-debugging failed builds and fix the issue we saw in the  previous tutorial.
+debugging failed builds and fix the issue we saw in the previous tutorial.
 
 This also comes under the category of type 2. change from the list
 at `ioc_change_types`.

docs/user/tutorials/deploy_example.rst

@@ -69,7 +69,7 @@ where indicated):
     source bl01t
 
 Once you have done this and logged out and back in again to pick up your new
-profile you should be able enable the ``bl01t`` environment as follows:
+profile you should be able to enable the ``bl01t`` environment as follows:
 
 .. code-block:: bash
 
@@ -97,7 +97,7 @@ IOC Instance.
 
 The following command will deploy the example IOC instance to your local
 machine (unless you have skipped ahead and set up your Kubernetes config
-in which case the same command  will deploy to your Kubernetes cluster).
+in which case the same command will deploy to your Kubernetes cluster).
 
 .. code-block:: bash
 
@@ -158,7 +158,7 @@ Managing the Example IOC Instance
 Starting and Stopping IOCs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To stop / start  the example IOC try the following commands. Note that
+To stop / start the example IOC try the following commands. Note that
 ``ec ps -a`` shows you all IOCs including stopped ones.
 
 .. code-block:: bash
@@ -183,7 +183,7 @@ To stop / start  the example IOC try the following commands. Note that
 Monitoring and interacting with an IOC shell
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To attach to the ioc shell you can use the following command. HOWEVER, this
+To attach to the IOC shell you can use the following command. HOWEVER, this
 will attach you to nothing in the case of this example IOC as it has no
 shell. In the next tutorial we will use this command to interact with
 iocShell.

docs/user/tutorials/dev_container.rst

@@ -188,7 +188,7 @@ See ``/epics/ioc-adsimdetector/ioc/iocApp/src/Makefile``
 
 You will note that the ``ioc`` folder is greyed out in the VSCode explorer. This
 is because it is in ``.gitignore`` and it is purely generated code. If you
-particularly needed to customize the contents of the ioc source tree then
+particularly needed to customize the contents of the IOC source tree then
 you can remove it from ``.gitignore`` and commit your changes to the repo. These
 changes would then always get loaded for every instance of the Generic IOC.
 
@@ -217,7 +217,7 @@ multiple peer projects.
 
 In VSCode click the ``File`` menu and select ``Add Folder to Workspace``.
 Navigate to ``/repos`` and you will see all the peers of your ``ioc-adsimdetector``
-folder (see `container-layout` below) . Choose the ``bl01t`` folder and add it to the
+folder (see `container-layout` below). Choose the ``bl01t`` folder and add it to the
 workspace - you may see an error but if so clicking "reload window" will
 clear it.
 
@@ -230,8 +230,8 @@ Also take this opportunity to add the folder ``/epics`` to the workspace.
   and git will complain about ownership. You can cancel out of these errors
   as you should not edit project folders inside of ``/epics`` - they were
   built by the container and should be considered immutable. We will learn
-  how to work on support modules in later tuorials. This error should only
-  be seen on first launch. podman users will have no such problem becuase they
+  how to work on support modules in later tutorials. This error should only
+  be seen on first launch. podman users will have no such problem because they
   will be root inside the container and root build the container.
 
 You can now easily browse around the ``/epics`` folder and see all the

docs/user/tutorials/generic_ioc.rst

@@ -11,7 +11,7 @@ test our changes locally before deploying it.
 This is a type 2. change from the list at `ioc_change_types`.
 
 The example IOC used ADSimDetector, we will make a similar IOC that uses
-ADUrl to get images from a web cam.
+ADUrl to get images from a webcam.
 
 Create a New Generic IOC project
 --------------------------------
@@ -49,7 +49,7 @@ using an ``ec`` command.
     From the VSCode menus: File->Add Folder to Workspace
     then select the folder ioc-adurl
 
-#.  Push the repo back to a the new repo on github
+#.  Push the repo back to a new repo on github
 
     .. code-block:: bash
 

docs/user/tutorials/ibek.rst

@@ -42,20 +42,20 @@ ibek-support
   can be found and how to build it.
 - exists to avoid duplication of support module definitions in Generic IOCs
 - and to avoid working on multiple support modules while kicking off epics-containers
-- the ibek-support repo is added as a git-submodule to every Generic ioc
-  (ioc-xxx) repo and in this ensures that a rebuild of a Generic ioc will be
+- the ibek-support repo is added as a git-submodule to every Generic IOC
+  (ioc-xxx) repo and in this ensures that a rebuild of a Generic IOC will be
   with a consistent set of YAML files and install.sh files until a developer
   explicitly updates the submodule.
 
 How to work on ibek-support
 ---------------------------
 
-Building a new Generic ioc and making it compatible with ibek means creating
+Building a new Generic IOC and making it compatible with ibek means creating
 ibek support YAML for all of its dependent support modules
 (where they do not already exist)
 
-These steps assume you have a Generic ioc for ADUrl based on ioc_template as discussed in `generic_ioc`.
-Your Generic ioc has a default ioc instance used for testing.
+These steps assume you have a Generic IOC for ADUrl based on ioc_template as discussed in `generic_ioc`.
+Your Generic IOC has a default IOC instance used for testing.
 In ioc/config/st.cmd we have a default startup script for the example IOC.
 To work on ibek support we will remove this file and replace it with ``ioc.yaml``.
 We already have a git submodule for ibek-defs which we used for accessing patch files
@@ -64,7 +64,7 @@ during build, this will also be used for creating and editing support yaml files
 TODO: this will become a concrete example for walking through as a tutorial with ioc-adurl.
 
 NOTE: these steps are for building and testing the example IOC that comes with
-the Generic ioc template. This will break the system test and that would need
+the Generic IOC template. This will break the system test and that would need
 to be updated accordingly. To just work on ibek support files using an external
 ioc instance YAML file see `../how-to/ibek-support` (I probably need to combine
 these two pages into something coherent).
@@ -78,7 +78,7 @@ STEPS:
 - cd ..
 - add useful yaml definitions to ibek-defs/<a support module>/<a support module>.yaml
 - add some entities that use those definitions to ioc/config/ioc.yaml
-- TODO need to make dev launch mount ioc folder into the container - avoiding build step and giving us a tight inner dev loop
+- TODO need to make dev launch mount IOC folder into the container - avoiding build step and giving us a tight inner dev loop
   - (whereas dev ioc-launch mounts in the config of an IOC instance - MAYBE this is confusing or these commands need better names?)
 - ec dev build
 - ec dev launch