From 515282abfe57932429ff80673aecf1d41feea8ee Mon Sep 17 00:00:00 2001 From: dhickin Date: Sat, 4 Oct 2014 01:33:59 +0100 Subject: [PATCH] Spelling and typos. --- documentation/copyandmonitor.html | 40 ++++++++++++++--------------- documentation/pvArray.html | 26 +++++++++---------- documentation/pvDataDiscussion.html | 10 ++++---- 3 files changed, 38 insertions(+), 38 deletions(-) diff --git a/documentation/copyandmonitor.html b/documentation/copyandmonitor.html index bf3afd2..3b25eb1 100644 --- a/documentation/copyandmonitor.html +++ b/documentation/copyandmonitor.html @@ -52,7 +52,7 @@ provides a language independent overview of copy and monitor.

NOTE:pvRequest.html must be updated since it is based on an earlier version of pvCopy that -had knowlege of PVRecord. The C++ version was implemented in pvDatabaseCPP +had knowledge of PVRecord. The C++ version was implemented in pvDatabaseCPP and the Java version on pvIOCJava. At present only the C++ version of the new API for pvCopy is implemented.

@@ -65,13 +65,13 @@ At present only the C++ version of the new API for pvCopy is implemented. Given an ascii string createRequest creates a PVStructure that provides a pvData representation of the information from the ascii string. It is this structure that can be passed to the channel create methods.
- The information in a pvRequest selects an arbitrarary subset of the + The information in a pvRequest selects an arbitrary subset of the fields in a top level structure that resides in the server. In addition options can be specified. Both global and field specific options can be specified.
pvCopy
-
This is a faculity used by channel providers. +
This is a facility used by channel providers. It provides client specific code that manages a copy of an arbitrary subset of the fields in a top level structure that resides in the provider. It also allows provider access to options specified @@ -185,7 +185,7 @@ where This is the method for creating a PVCopy instance.
pvMaster
-
the top level sructure managed by the server.
+
the top level structure managed by the server.
pvRequest
selects the set of subfields desired and options for each field.
@@ -241,12 +241,12 @@ where
updateCopyFromBitSet
For each set bit in bitSet set the field in copyPVStructure to the value - of the corrseponding field in pvMaster. + of the corresponding field in pvMaster.
updateMaster
For each set bit in bitSet set the field in pvMaster to the value - of the corrseponding field in copyPVStructure. + of the corresponding field in copyPVStructure.
getOptions
@@ -266,7 +266,7 @@ where

This consists of two components:

monitor
-
Used by code that implements pvAccess montors.
+
Used by code that implements pvAccess monitors.
monitorPlugin
Code that provides special semantics for monitors.
@@ -346,7 +346,7 @@ Note that each client has it's own queue that is not shared with other client.
start
Start monitoring. - This will result in a an inital monitor that has the current value + This will result in a an initial monitor that has the current value of all fields.
stop
@@ -356,11 +356,11 @@ Note that each client has it's own queue that is not shared with other client.
poll
Called to get a monitor element. - If no new elemants are available then a null pointer is returned. + If no new elements are available then a null pointer is returned.
release
- Release the monotor element. + Release the monitor element. The caller owns the monitor element between the calls to poll and release.
@@ -488,7 +488,7 @@ It has methods:

MonitorPluginManager is a singleton. The first call to get will create the single instance. - Further calls will rerurn the single instance. + Further calls will return the single instance.
addPlugin
@@ -496,18 +496,18 @@ It has methods:

findPlugin
- Find a plugin. A NULL shared pointer is reurned if it has not been added. + Find a plugin. A NULL shared pointer is returned if it has not been added.
showNames
- Show the names of all puugins that have been added. + Show the names of all plugins that have been added.

NOTE: Should the method causeMonitor have arguments pvField and pvTop -be defined so that they can not be modfied. -This would be posssible if the following was defined: +be defined so that they can not be modified. +This would be possible if the following was defined: 

 typedef std::tr1::shared_ptr<const PVField> PVFieldConstPtr;
 typedef std::tr1::shared_ptr<const PVStructure> PVStructureConstPtr;
@@ -519,7 +519,7 @@ virtual bool causeMonitor(
         PVStructureConstPtr const &pvTop,
         MonitorElementPtr const &monitorElement) = 0;
-But just adding these definitions is not sufficent. +But just adding these definitions is not sufficient. In addition all methods defined in pvDataCPP must be checked. In particular many of the methods in Convert must have their arguments modified. @@ -545,15 +545,15 @@ structure powerSupply structure power double value structure alarm - struvture display + structure display structure voltage double value structure alarm - struvture display + structure display structure current double value structure alarm - struvture display + structure display

A pvAccess client wants to create a monitor on the powerSupply as follows: The client wants a top level structure that looks like: @@ -578,7 +578,7 @@ client wants. It can be attached to any field via the following options: [plugin=onChange,raiseMonitor=value] This plugin will trigger a monitor for the field only if the field changes -value. In addition value equals false means do not raise a monotor +value. In addition value equals false means do not raise a monitor for changes to this field. But if a change to another field does cause a monitor the change to this field will be passed to the client. diff --git a/documentation/pvArray.html b/documentation/pvArray.html index 9f7c031..9de1fb7 100644 --- a/documentation/pvArray.html +++ b/documentation/pvArray.html @@ -68,7 +68,7 @@ license.

Changes

Since the last version of this document the following changes have -been made to the proposed interface definitionsi for PVValueArray:

+been made to the proposed interface definitions for PVValueArray:

put(const svector &from)
This has been removed. shareData can be used instead.
@@ -93,7 +93,7 @@ purpose for pvData:
pvData (Process Variable Data) defines and implements an efficent way to store, access, and communicate memory resident data structures.
This statement appears as the first sentence of pvDataJava.html. -A few sentances later the document makes clear that communication +A few sentences later the document makes clear that communication includes network communication. Thus pvData provides an interface for network accessible structured data. If the interfaces for C++ and Java are similar then @@ -160,7 +160,7 @@ PVScalar and extensions, PVArray and extensions. PVStructureArray is not discussed.

PVField

-

This is the base for all the PVXXX iterfaces. +

This is the base for all the PVXXX interfaces. It provides basic methods for allowing network transfer and for traversing structured data. The pvDataJava and pvDataCPP definitions are similar. @@ -306,7 +306,7 @@ methods:

The proposed version is like the pvDataCPP version except for dumpValue -and the stream interators.

+and the stream iterators.

pvDataJava

 interface PVScalar extends PVField {
@@ -1161,7 +1161,7 @@ typedef std::tr1::shared_ptr<PVStringArray> PVStringArrayPtr;
    
put

      
This is the recommended method for modifying the array elements.
        It may change the capacity if len asks for more elements
-       than the cureent capacity allows.
+       than the current capacity allows.
        It does not change the current length.
       

    
shareData

@@ -1169,7 +1169,7 @@ typedef std::tr1::shared_ptr<PVStringArray> PVStringArrayPtr;
         Note that if capacity is ever changed then data will no
         longer be shared.
         This method can also be called to force the PVValueArray to have a new
-        raw array. This is usefull for implementing Copy On Write.
+        raw array. This is useful for implementing Copy On Write.
@@ -1218,12 +1218,12 @@ and start with a brief summary modeled after Section 31.3(STL Containers) in:
The subsection names are the same names that Stroustrup uses. Each subsection starts with a brief summary that is similar to -the summary Stroustrup has at the beginnining of each subsection.

+the summary Stroustrup has at the beginning of each subsection.

The comparison is always with std::vector. In addition it shows what is defined by by std::vector but not by shared_vector.

Someone who already understand the C++ STL can understand shared_vector -by just looking at the brief summarys. +by just looking at the brief summaries. For others the brief summary is followed by tutorial information.

shared_vector example

@@ -1322,7 +1322,7 @@ These are not used by any of the client methods.

Brief Summary 

 C c();         Default constructor; c is empty.
-C c(n);        c is initialized with n elementis with the value value_type{};
+C c(n);        c is initialized with n elements with the value value_type{};
                offset is 0; size is n;
 C c(n,e);      Initialize c with n copies of e.
                offset is 0; size is n;
@@ -1373,7 +1373,7 @@ shared_vector(size_t n, value_type e);
 
The first three constructors all create a new shared_vector
 by also creating a new raw array,
 The difference is the size of the array, i.e. how many elements it contains,
-and how the elements are initalized.
+and how the elements are initialized.
 

 

 
shared_vector()

@@ -1405,7 +1405,7 @@ emptyArray 1
 zeroArray {16}[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...]
 oneArray {8}[1, 1, 1, 1, 1, 1, 1, 1]
-

NOTE EXISTING: Why did emptyArray disply the above. +

NOTE EXISTING: Why did emptyArray display the above. Should it be "emptyArray {0} []"?

Construct by sharing raw array from a shared_vector

@@ -1593,7 +1593,7 @@ crend() Constant last element of reverse sequence

shared_vector supports both iterators and reverse iterators as defined by the STL. For both constant iterators are also defined. -A constant iterator does not allow an array elemnent to be modified.

+A constant iterator does not allow an array element to be modified.

The following is an example of a constant iterator.

 int32 sum = 0;
@@ -1705,7 +1705,7 @@ produces:
 
 void make_unique()         Make caller the only user of std::tr1::shared_ptr
 bool unique()              Is the caller the only user of std::tr1::shared_ptr
-void slice(offset,length)  Change window offset andsize
+void slice(offset,length)  Change window offset and size
 
 // following should only be used for debugging
 const std::tr1::shared_ptr<E>&
diff --git a/documentation/pvDataDiscussion.html b/documentation/pvDataDiscussion.html
index 5f9b13b..d059dd7 100644
--- a/documentation/pvDataDiscussion.html
+++ b/documentation/pvDataDiscussion.html
@@ -70,11 +70,11 @@ license.

 more and more member functions.
 These member functions have nothing to do with the primary primary
 purpose for pvData:
-
pvData (Process Variable Data) defines and implements an efficent
+
pvData (Process Variable Data) defines and implements an efficient
 way to store, access, and communicate memory resident data structures.

 This statement appears as the first sentence of pvDataJava.html.
-A few sentances later the document makes it clear that communication
-includes efficent network communication.
+A few sentences later the document makes it clear that communication
+includes efficient network communication.
 Thus pvData provides an interface for network accessible structured data.
 The problem of adding member functions that have nothing to do with the primary purpose
 started with the Java API.
@@ -82,7 +82,7 @@ It already had extra methods that solved problems that should have had a differe
 This document removes the extra methods so that when new problems arise in the future
 the solution will not involve adding new member functions to the introspection and data API.
 

-
The introspection and data API for pvData should only encapuslate methods that support the primary purpose
+
The introspection and data API for pvData should only encapsulate methods that support the primary purpose
 stated above.
 The interfaces for C++ and Java should be similar so that
 someone who understands the interface in one of the languages
@@ -308,7 +308,7 @@ public interface PVDataCreate {
 The existing Java implementation of toString displayed all elements.
 For large arrays this is not desirable.
 The new methods provide a way for the client to limit the number of elements.
-The default might be set to something like display up to 10 elements with 5 fron the beginning and 5 from the end.

+The default might be set to something like display up to 10 elements with 5 from the beginning and 5 from the end.

 
For C++ this can be a replacement for dumpValue.

 
PVBooleanArray, ..., PVStructureArray

 
The old get and put are replaced by two new and simpler methods: