references #180: fix a couple of typos

evb/README.md

@@ -18,7 +18,7 @@ a given event (trigger) from all FEDs received by a RU are combined
 into a super-fragment.
 
 - Builder Unit (BU) combines the superfragments from all RUs into a
-complete event and writes multiple events into a file.
+complete event and writes multiple events into one file.
 
 
 In addition to the main applications, further code is available:
@@ -106,13 +106,13 @@ by e.g. using local structs for monitoring data which can be locked
 independently from the main monitoring task which retrieves the
 information every second.
 
-The main interprocess communication uses the custom
-evb::OneToOneQueue. It allows to concurrently enqueue and dequeue
-elements without locking from one producer and one consumer. In case
-that multiple threads need to enqueue or dequeue elements of the same
-queue, external locking is required. The OneToOneQueue template
-provides methods to display the queue contents on the XDAQ hyperdaq
-pages, too.
+The main inter-thread communication uses the custom
+evb::OneToOneQueue template. It allows to concurrently enqueue and
+dequeue elements without locking from one producer and one
+consumer. In case that multiple threads need to enqueue or dequeue
+elements of the same queue, external locking is required. The
+OneToOneQueue template provides methods to display the queue contents
+on the XDAQ hyperdaq pages, too.
 
 
 ### Configuration and monitoring
@@ -123,9 +123,9 @@ accessible in the xdaq::Infospace of the application. There's a helper
 class InfoSpaceItems which encapsulates often used patterns.
 
 A special case is the handling of the FEROL sources: the FEROL sources
-is a xdata::Vector of xdata::Bag containing the connection parameters
+is a xdata::Vector of xdata::Bag's containing the connection parameters
 for the FEROL (c.f. readoutunit/Configuration.h). These values are
-filled by the configurator, or like the IP address resolved at
+filled by the DAQ configurator, or are like the IP address resolved at
 configure time. The FEROL sources contain all FEROLs which are defined
 in the FED builder connected to this RU and only change when a new DAQ
 configuration is made. The xdata::Vector fedSourceIds contain the
@@ -137,7 +137,7 @@ The runNumber is defined in EvBStateMachine.h and is set by the SOAP
 message received from the DAQ FM at Enable.
 
 Each application has a monitoring xdaq::Infospace, which is mapped to
-a corresponding flash list. Note that a copy of the flash lists are
+a corresponding flash list. Note that copies of the flash lists are
 kept in the EvB repository. However, the actually used ones are part
 of the XaaS configurations. A few monitoring parameters are available
 in the application infospace, too. They are updated on request. These
@@ -169,7 +169,7 @@ RDMA-specific methods to transfer the data.
 
 The structs used for the I2O messages are defined in
 I2OMessages.h. There are three types of messages: to request events,
-to send the data, and to request the lumisection information.
+to send the data, and to request lumisection information.
 
 #### Event requests
 
@@ -191,7 +191,7 @@ triggers are available to fulfill the request. The EVM adds a list of
 RU TIDs participating in the event building, too. This list is used
 later by the BU to decide if it got the superfragments from all
 RUs. This list can in principle be different for each request, which
-would to allow to (temporarily) mask certain RUs. However, this
+would allow to (temporarily) mask certain RUs. However, this
 functionality has never been used.
 
 The EVM sends the EventRequests to all RUs, which use this information