Fix some typos (#542)

* updated .gitignore

* fixed typos

.gitignore

@@ -68,6 +68,7 @@ spack*
 # Populated by cmake before build
 /include/podio/podioVersion.h
 /python/podio/__version__.py
+/python/podio_version.py
 
 # CLion artifacts
 .idea/

doc/advanced_topics.md

@@ -63,7 +63,7 @@ nlohmann::json json{
 };
 ```
 
-Each element of the collection will be converted to a JSON object, where the keys are the same as in the datamodel definiton.
+Each element of the collection will be converted to a JSON object, where the keys are the same as in the datamodel definition.
 Components contained in the objects will similarly be similarly converted.
 
 **JSON is not foreseen as a mode for persistency, i.e. there is no plan to add the conversion from JSON to the in memory representation of the datamodel.**
@@ -168,7 +168,7 @@ datamodels and provides access to this information possible. In this context we
 refer to an *EDM* as the shared library (and the corresponding public headers)
 that have been compiled from code that has been generated from a *datamodel
 definition* in the original YAML file. In general whenever we refer to a
-*datamodel* in this context we mean the enitity as a whole, i.e. its definition
+*datamodel* in this context we mean the entity as a whole, i.e. its definition
 in a YAML file, the concrete implementation as an EDM, as well as other related
 information that is related to it.
 

doc/datamodel_syntax.md

@@ -153,7 +153,7 @@ Some customization of the generated code is possible through flags. These flags
 
 ## Extending a datamodel / using types from an upstream datamodel
 It is possible to extend another datamodel with your own types, resp. use some datatypes or components from an upstream datamodel in your own datamodel.
-This can be useful for prototyping new datatypes or for accomodating special requirements without having to reimplement / copy a complete datamodel.
+This can be useful for prototyping new datatypes or for accommodating special requirements without having to reimplement / copy a complete datamodel.
 
 To pass an upstream datamodel to the class generator use the `--upstream-edm` option that takes the package name as well as the yaml definition file of the upstream datamodel separated by a colon (':').
 This will effectively make all components and datatypes of the upstream datamodel available to the current definition for validation and generation of the necessary includes.

doc/examples.md

@@ -2,7 +2,7 @@
 
 The following snippets show the support of PODIO for the different use cases as
 well as some potential pitfalls. These examples are mainly concerned with how
-collections of objects and the objects themselve interact. As such they are
+collections of objects and the objects themselves interact. As such they are
 framework agnostic.
 
 ### Object Ownership
@@ -66,7 +66,7 @@ or via direct accessors
     auto hit  = cluster.Hits(<aNumber>);
 ```
 
-If asking for an entry outside bounds, a std::out_of_range exception is thrown.
+If asking for an entry outside bounds, a `std::out_of_range` exception is thrown.
 
 
 ### Looping through Collections

doc/templates.md

@@ -11,7 +11,7 @@ The entry point for reading yaml files is the [`python/podio_gen/podio_config_re
 When reading the yaml file a basic validation is run and the data members, relations and vector members of components and datatypes are parsed into `MemberVariable` objects (defined in [`python/podio_gen/generator_utils.py`](/python/podio_gen/generator_utils.py)).
 The main entry point to the code generation is the [`python/podio_class_generator.py`](/python/podio_class_generator.py) which takes care of instantiating the language specific code generator (either C++ or a prototype version for Julia at this point).
 The language specific generators inherit from the [`ClassGeneratorBaseMixin`](/python/podio_gen/generator_base.py) which takes care of some common initialization and provides some common functionality for code generation.
- In the end each langauge specific generator will take care of (either by itself or through the common functionality in `ClassGeneratorBaseMixin`):
+ In the end each language specific generator will take care of (either by itself or through the common functionality in `ClassGeneratorBaseMixin`):
 - Configuring the Jinja2 template engine. At the moment this is mainly making the templates known to the engine.
 - The necessary preprocessing of all the datatypes and components. This includes collecting necessary include directories and forward declaration, as well as digesting `ExtraCode` snippets.
 - Putting all the necessary information into a `dict` that can be easily used in the Jinja2 templates. See [below](#available-information-in-the-templates) for what is available in the templates
@@ -30,7 +30,7 @@ They are broadly split along the classes that are generated for each datatype or
 |---------------------------------|---------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|
 | `Component.h.jinja2`            | Definition for each component                                                                           | `[<package>/]<component-name>.h`                                                      |
 | `Data.h.jinja2`                 | POD struct of each datatype (living in the POD layer)                                                   | `[<package>/]<datatype-name>Data.h`                                                   |
-| `Obj.{h,cc}.jinja2`             | `Obj` class for each datatype (linving in the object layer) and managing resources                      | `[<package>/]<datatype-name>Obj.h`,  `src/<datatype-name>Obj.cc`                      |
+| `Obj.{h,cc}.jinja2`             | `Obj` class for each datatype (living in the object layer) and managing resources                      | `[<package>/]<datatype-name>Obj.h`,  `src/<datatype-name>Obj.cc`                      |
 | `[Mutable]Object.{h,cc}.jinja2` | The user facing interfaces for each datatype (living in the user layer)                                 | `[<package>/][Mutable]<datatype-name>.h`, `src/[Mutable]<datatype-name>.cc`           |
 | `Collection.{h,cc}.jinja2`      | The user facing collection interface (living in the user layer)                                         | `[<package>/]<datatype-name>Collection.h`, `src/<datatype-name>Collection.cc`         |
 | `CollectionData.{h,cc}.jinja2`  | The classes managing the collection storage (not user facing!)                                          | `[<package>/]<datatype-name>CollectionData.h`, `src/<datatype-name>CollectionData.cc` |
@@ -102,7 +102,7 @@ The following keys / variables are filled for each datatype
 | `OneToManyRelations`          | The one-to-many relation members of the datatype as a list of `MemberVariable`s                                                                                    |
 | `VectorMembers`               | The vector members of the datatype as a list of `MemberVariable`s                                                                                                  |
 | `includes`                    | The include directives for the the user facing classes header files                                                                                      |
-| `includes_cc`                 | The include directives for the implemenations of the user facing classes                                                                                 |
+| `includes_cc`                 | The include directives for the implementations of the user facing classes                                                                                 |
 | `includes_data`               | The necessary include directives for the `Data` POD types                                                                                                |
 | `includes_obj`                | The include directives for the `Obj` classes headers.                                                                                                    |
 | `includes_cc_obj`             | The include directives for the implementation files of the `Obj` classes.                                                                                |
@@ -139,7 +139,7 @@ In principle all members are accessible in the templates, however, the most impo
 
 ### `DataType`
 Defined in [`python/generator_utils.py`](/python/generator_utils.py).
-This is essenitally a stripped down version of the `MemberVariable` with the major difference being that the string representation returns the fully qualified type instead.
+This is essentially a stripped down version of the `MemberVariable` with the major difference being that the string representation returns the fully qualified type instead.
 The available fields are
 
 | field       | description                                                                    |

include/podio/CollectionBufferFactory.h

@@ -19,7 +19,7 @@ namespace podio {
  *
  * It is implemented as a singleton, which is populated at the time a shared
  * datamodel library is loaded. It is assumed that that happens early on in the
- * startup of an appliation, such that only a single thread will access the
+ * startup of an application, such that only a single thread will access the
  * factory instance for registering datatypes. Since the necessary creation
  * functions are part of the core datamodel library, this should be very easy to
  * achieve by simply linking to that library. Once the factory is populated it
@@ -53,7 +53,7 @@ class CollectionBufferFactory {
    *
    * @param collType The collection type name (e.g. from collection->getTypeName())
    * @param version The schema version the created buffers should have
-   * @param susbsetColl Should the buffers be for a subset collection or not
+   * @param subsetColl Should the buffers be for a subset collection or not
    *
    * @return CollectionReadBuffers if a creation function for this collection
    * type has been registered, otherwise an empty optional

include/podio/FrameCategories.h

@@ -13,7 +13,7 @@ namespace podio {
  * parameters. These are parameters / metadata that are valid for all
  * collections of a given name in a file, e.g. CellID encoding strings. These
  * parameters are usually stored in a dedicated metadata Frame inside a file,
- * see the predefined category names in the Cateogry namespace.
+ * see the predefined category names in the Category namespace.
  *
  * @param collName the name of the collection
  * @param paramName the name of the parameter
@@ -34,7 +34,7 @@ namespace Category {
   constexpr const auto Event = "events";
   /// The run category
   constexpr const auto Run = "runs";
-  /// The metadata cateogry that is used to store a single Frame that holds data
+  /// The metadata category that is used to store a single Frame that holds data
   /// that is valid for a whole file, e.g. collection level parameters
   constexpr const auto Metadata = "metadata";
 } // namespace Category

include/podio/GenericParameters.h

@@ -30,7 +30,7 @@ namespace podio {
 /// The types which are supported in the GenericParameters
 using SupportedGenericDataTypes = std::tuple<int, float, std::string, double>;
 
-/// Static bool for determining if a type T is a supported GenericParamter type
+/// Static bool for determining if a type T is a supported GenericParameters type
 template <typename T>
 static constexpr bool isSupportedGenericDataType = detail::isAnyOrVectorOf<T, SupportedGenericDataTypes>;
 
@@ -41,7 +41,7 @@ using EnableIfValidGenericDataType = typename std::enable_if_t<isSupportedGeneri
 
 namespace detail {
   /// Helper struct to determine how to return different types from the
-  /// GenericParamters to avoid unnecessary copies but also to prohibit carrying
+  /// GenericParameters to avoid unnecessary copies but also to prohibit carrying
   /// around const references to ints or floats
   template <typename T>
   struct GenericDataReturnTypeHelper {
@@ -114,7 +114,7 @@ class GenericParameters {
     setValue<std::string>(key, std::move(value));
   }
 
-  /// Overlaod for catching initializer list setting of string vector values
+  /// Overload for catching initializer list setting of string vector values
   void setValue(const std::string& key, std::vector<std::string> values) {
     setValue<std::vector<std::string>>(key, std::move(values));
   }

include/podio/ROOTFrameReader.h

@@ -96,7 +96,7 @@ class ROOTFrameReader {
     return m_fileVersion;
   }
 
-  /// Get the names of all the availalable Frame categories in the current file(s)
+  /// Get the names of all the available Frame categories in the current file(s)
   std::vector<std::string_view> getAvailableCategories() const;
 
   /// Get the datamodel definition for the given name
@@ -130,7 +130,7 @@ class ROOTFrameReader {
   };
 
   /**
-   * Initialze the passed CategoryInfo by setting up the necessary branches,
+   * Initialize the passed CategoryInfo by setting up the necessary branches,
    * collection infos and all necessary meta data to be able to read entries
    * with this name
    */
@@ -150,7 +150,7 @@ class ROOTFrameReader {
 
   /**
    * Read the data entry specified in the passed CategoryInfo, and increase the
-   * counter aferwards. In case the requested entry is larger than the
+   * counter afterwards. In case the requested entry is larger than the
    * available number of entries, return a nullptr.
    */
   std::unique_ptr<podio::ROOTFrameData> readEntry(ROOTFrameReader::CategoryInfo& catInfo);

include/podio/ROOTLegacyReader.h

@@ -84,7 +84,7 @@ class ROOTLegacyReader {
     return m_fileVersion;
   }
 
-  /// Get the names of all the availalable Frame categories in the current file(s)
+  /// Get the names of all the available Frame categories in the current file(s)
   std::vector<std::string_view> getAvailableCategories() const;
 
 private:

include/podio/SIOFrameReader.h

@@ -51,7 +51,7 @@ class SIOFrameReader {
     return m_fileVersion;
   }
 
-  /// Get the names of all the availalable Frame categories in the current file(s)
+  /// Get the names of all the available Frame categories in the current file(s)
   std::vector<std::string_view> getAvailableCategories() const;
 
   /// Get the datamodel definition for the given name

include/podio/SIOLegacyReader.h

@@ -63,7 +63,7 @@ class SIOLegacyReader {
     return m_fileVersion;
   }
 
-  /// Get the names of all the availalable Frame categories in the current file(s)
+  /// Get the names of all the available Frame categories in the current file(s)
   std::vector<std::string_view> getAvailableCategories() const;
 
 private:

include/podio/SchemaEvolution.h

@@ -96,7 +96,7 @@ class SchemaEvolution {
                                              const std::string& collType) const;
 
   /**
-   * Register an evoution function for a given collection type and given
+   * Register an evolution function for a given collection type and given
    * versions from where to where the evolution applies.
    *
    * Several assumptions are in place here:
@@ -105,7 +105,7 @@ class SchemaEvolution {
    *   datatype.
    * - An evolution function has to be registered for all possible versions from
    *   1 to N - 1, where N is the current version
-   * - An evolution function can only be registerd once for a given datatype and
+   * - An evolution function can only be registered once for a given datatype and
    *   fromVersion
    * - For auto generated code the passed in priority has to be AutoGenerated
    *   otherwise it might override user defined functions
@@ -118,7 +118,7 @@ class SchemaEvolution {
    * apply
    * @param currentVersion The current schema version for the data type
    * @param evolutionFunc The evolution function that evolves passed in buffers
-   * from fromVersion to currrentVersion
+   * from fromVersion to currentVersion
    * @param priority The priority of this evolution function. Defaults to
    * UserDefined which overrides auto generated functionality.
    */

include/podio/UserDataCollection.h

@@ -81,7 +81,7 @@ class UserDataCollection : public CollectionBase {
 
 public:
   UserDataCollection() = default;
-  /// Constructor from an existing vector (wich will be moved from!)
+  /// Constructor from an existing vector (which will be moved from!)
   UserDataCollection(std::vector<BasicType>&& vec) : _vec(std::move(vec)) {
   }
   UserDataCollection(const UserDataCollection&) = delete;
@@ -166,7 +166,7 @@ class UserDataCollection : public CollectionBase {
     return false;
   }
 
-  /// declare this collection to be a subset collectionv - no effect
+  /// declare this collection to be a subset collection - no effect
   void setSubsetCollection(bool) override {
   }
 
@@ -195,7 +195,7 @@ class UserDataCollection : public CollectionBase {
     return DatamodelRegistry::NoDefinitionNecessary;
   }
 
-  // ----- some wrapers for std::vector and access to the complete std::vector (if really needed)
+  // ----- some wrappers for std::vector and access to the complete std::vector (if really needed)
 
   typename std::vector<BasicType>::iterator begin() {
     return _vec.begin();

include/podio/utilities/MaybeSharedPtr.h

@@ -15,7 +15,7 @@ namespace detail {
 constexpr static auto MarkOwned [[maybe_unused]] = detail::MarkOwnedTag{};
 
 /// "Semi-smart" pointer class for pointers that at some point during their
-/// lifetime might hand over management to another entitity. E.g. Objects that
+/// lifetime might hand over management to another entity. E.g. Objects that
 /// are added to a collection will hand over the management of their Obj* to
 /// collection. In such a case two things need to be considered:
 /// - Other Objects with the same Obj* instance should not delete the managed

python/podio/frame.py

@@ -149,7 +149,7 @@ def get(self, name):
   def put(self, collection, name):
     """Put the collection into the frame
 
-    The passed collectoin is "moved" into the Frame, i.e. it cannot be used any
+    The passed collection is "moved" into the Frame, i.e. it cannot be used any
     longer after a call to this function. This also means that only objects that
     were in the collection at the time of calling this function will be
     available afterwards.
@@ -286,7 +286,7 @@ def get_parameters(self):
     Returns:
         podio.GenericParameters: The stored generic parameters
     """
-    # Going via the not entirely inteded way here
+    # Going via the not entirely intended way here
     return self._frame.getParameters()
 
   def get_param_info(self, name):

python/podio/frame_iterator.py

@@ -12,7 +12,7 @@ class FrameCategoryIterator:
   """
 
   def __init__(self, reader, category):
-    """Construct the iterator from the reader and the cateogry.
+    """Construct the iterator from the reader and the category.
 
     Args:
         reader (Reader): Any podio reader offering access to Frames
@@ -22,7 +22,7 @@ def __init__(self, reader, category):
     self._category = category
 
   def __iter__(self):
-    """The trivial implementaion for the iterator protocol."""
+    """The trivial implementation for the iterator protocol."""
     return self
 
   def __next__(self):

python/podio/sio_io.py

@@ -13,7 +13,7 @@
 
 
 class Reader(BaseReaderMixin):
-  """Reader class for readion podio SIO files."""
+  """Reader class for reading podio SIO files."""
 
   def __init__(self, filename):
     """Create a reader that reads from the passed file.
@@ -28,7 +28,7 @@ def __init__(self, filename):
 
 
 class LegacyReader(BaseReaderMixin):
-  """Reader class for reading legcy podio sio files.
+  """Reader class for reading legacy podio sio files.
 
   This reader can be used to read files that have not yet been written using the
   Frame based I/O into Frames for a more seamless transition.

python/podio/test_Frame.py

@@ -33,7 +33,7 @@ class FrameTest(unittest.TestCase):
   """General unittests for for python bindings of the Frame"""
   def test_frame_invalid_access(self):
     """Check that the advertised exceptions are raised on invalid access."""
-    # Creat an empty Frame here
+    # Create an empty Frame here
     frame = Frame()
     with self.assertRaises(KeyError):
       _ = frame.get('NonExistantCollection')

python/podio_gen/generator_base.py

@@ -55,7 +55,7 @@ class ClassGeneratorBaseMixin:
     processing without filling the contents)
   - upstream_edm (an optional upstream datamodel)
   - datamodel (the current datamodel read from the yamlfile)
-  - get_syntax (whether to use get synatx or not)
+  - get_syntax (whether to use get syntax or not)
   - incfolder (whether to create an includeSubfolder or not)
   - expose_pod_members (whether or not to expose the pod members)
   - formatter_func (an optional formatting function that is called after the