Address PR comments + PEP8 fixes

Author: Vasileios Karakasis

docs/conf.py

@@ -232,12 +232,15 @@
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-    ('manpage', 'reframe', 'The CLI frontend for managing and executing ReFrame tests',
+    ('manpage', 'reframe',
+     'The CLI frontend for managing and executing ReFrame tests',
      [author], 1),
     ('config_reference', 'reframe.settings', 'ReFrame Configuration Manual',
      [author], 8)
 ]
-manpages_url = 'http://man7.org/linux/man-pages/man{section}/{page}.{section}.html'
+manpages_url = (
+    'http://man7.org/linux/man-pages/man{section}/{page}.{section}.html'
+)
 
 
 # -- Options for Texinfo output -------------------------------------------

docs/config_reference.rst

@@ -690,7 +690,7 @@ All logging handlers share the following set of common attributes:
      See the :attr:`reframe.core.pipeline.RegressionTest.reference` attribute of regression tests for more details.
    - ``%(check_perf_ref)s``: The reference performance value of a certain performance variable.
    - ``%(check_perf_unit)s``: The unit of measurement for the measured performance variable.
-   - ``%(check_perf_upper_thres)s``: The lower threshold of the performance difference from the reference value expressed as a fractional value.
+   - ``%(check_perf_upper_thres)s``: The upper threshold of the performance difference from the reference value expressed as a fractional value.
      See the :attr:`reframe.core.pipeline.RegressionTest.reference` attribute of regression tests for more details.
    - ``%(check_perf_value)s``: The performance value obtained for a certain performance variable.
    - ``%(check_perf_var)s``: The name of the `performance variable <tutorial_basic.html#writing-a-performance-test>`__ being logged.

docs/index.rst

@@ -2,8 +2,8 @@
 Welcome to ReFrame
 ==================
 
-ReFrame is a framework for writing tests for HPC systems that can check for functionality and performance regressions.
-The goal of this framework is to abstract away the complexity of the interactions with the system, separating the logic of a regression test from the low-level details, which pertain to the system configuration and setup.
+ReFrame is a high-level framework for writing regression tests for HPC systems.
+The goal of the framework is to abstract away the complexity of the interactions with the system, separating the logic of a regression test from the low-level details, which pertain to the system configuration and setup.
 This allows users to write easily portable regression tests, focusing only on the functionality.
 
 Regression tests in ReFrame are simple Python classes that specify the basic parameters of the test.

docs/manpage.rst

@@ -109,7 +109,7 @@ Tests can be filtered by different attributes and there are specific command lin
 
    Select tests that do not target GPUs.
    These are all tests with :attr:`num_gpus_per_node` equals to zero
-   This option and :option:`--cpu-only` are mutually exclusive.
+   This option and :option:`--gpu-only` are mutually exclusive.
 
    The :option:`--gpu-only` and :option:`--cpu-only` check only the value of the :attr:`num_gpus_per_node` attribute of tests.
    The value of this attribute is not required to be non-zero for GPU tests.
@@ -177,7 +177,7 @@ Options controlling ReFrame output
 
    - The ReFrame-generated build script, if not a run-only test.
    - The standard output and standard error of the build phase, if not a run-only test.
-   - The ReFrame-generated job script, if not a compile-onlyl test.
+   - The ReFrame-generated job script, if not a compile-only test.
    - The standard output and standard error of the run phase, if not a compile-only test.
    - Any additional files specified by the :attr:`keep_files` regression test attribute.
 
@@ -328,7 +328,7 @@ Flexible node allocation
 
 ReFrame can automatically set the number of tasks of a test, if its :attr:`num_tasks <reframe.core.pipeline.RegressionTest.num_tasks>` attribute is set to a value less than or equal to zero.
 This scheme is conveniently called *flexible node allocation* and is valid only for the Slurm backend.
-When allocating nodes automatically, ReFrame will take into account all node limiting factors, such as partition :js:attr:`access`` options, and any job submission control options described above.
+When allocating nodes automatically, ReFrame will take into account all node limiting factors, such as partition :js:attr:`access` options, and any job submission control options described above.
 Nodes from this pool are allocated according to different policies.
 If no node can be selected, the test will be marked as a failure with an appropriate message.
 
@@ -338,7 +338,7 @@ If no node can be selected, the test will be marked as a failure with an appropr
    Available values are the following:
 
    - ``all``: Flexible tests will be assigned as many tasks as needed in order to span over *all* the nodes of the node pool.
-   - ``idle``: Flexible tests will be assigned as many tasks as needed in order to span over the *idle* the nodes of the node pool.
+   - ``idle``: Flexible tests will be assigned as many tasks as needed in order to span over the *idle* nodes of the node pool.
      Querying of the node state and submission of the test job are two separate steps not executed atomically.
      It is therefore possible that the number of tasks assigned does not correspond to the actual idle nodes.
 

docs/sanity_functions_reference.rst

@@ -57,7 +57,7 @@ The page ":doc:`deferrables`" explains in detail how sanity functions work and h
 
     Sanity function decorator.
 
-    The evaluation of the decorated will be deferred and it will be suitable for use in the sanity and performance patterns of a regression test.
+    The evaluation of the decorated function will be deferred and it will become suitable for use in the sanity and performance patterns of a regression test.
 
     .. code:: python
 

docs/tutorial_advanced.rst

@@ -478,7 +478,7 @@ For a complete list of supported container platforms, the user is referred to th
 As soon as the container platform to be used is defined, you need to specify the container image to use and the commands to run inside the container:
 
 .. literalinclude:: ../tutorial/advanced/advanced_example10.py
-  :lines: 18-21
+  :lines: 17-20
 
 These two attributes are mandatory for container-based check.
 The :attr:`image <reframe.core.containers.ContainerPlatform.image>` attribute specifies the name of an image from a registry, whereas the :attr:`commands <reframe.core.containers.ContainerPlatform.commands>` attribute provides the list of commands to be run inside the container.
@@ -488,7 +488,7 @@ In the above example, ReFrame will run the container as follows:
 
 .. code:: shell
 
-    singularity exec -B"/path/to/test/stagedir:/rfm_workdir" docker://ubuntu:18.04 bash -c 'cd rfm_workdir; pwd; ls; cat /etc/os-release'
+    singularity exec -B"/path/to/test/stagedir:/workdir" docker://ubuntu:18.04 bash -c 'cd rfm_workdir; pwd; ls; cat /etc/os-release'
 
 By default ReFrame will mount the stage directory of the test under ``/rfm_workdir`` inside the container and it will always prepend a ``cd`` command to that directory.
 The user commands then are then run from that directory one after the other.

docs/tutorial_basic.rst

@@ -139,11 +139,11 @@ ReFrame provides already a wide range of useful sanity functions ranging from wr
 For a complete listing of the available functions, you may have a look at the :doc:`sanity_functions_reference`.
 
 In our example, the :func:`assert_found <reframe.utility.sanity.assert_found>` function accepts a regular expression pattern to be searched in a file and either returns :class:`True` on success or raises a :class:`SanityError <reframe.core.exceptions.SanityError>` in case of failure with a descriptive message.
-This function accepts any valid `Python Regular Expression <https://docs.python.org/3/library/re.html#regular-expression-syntax>`__ syntax.
+This function accepts any valid `Python Regular Expression <https://docs.python.org/3/library/re.html#regular-expression-syntax>`__.
 As a file argument, :func:`assert_found <reframe.utility.sanity.assert_found>` accepts any filename, which will be resolved against the stage directory of the test.
 You can also use the :attr:`stdout <reframe.core.pipeline.RegressionTest.stdout>` and :attr:`stderr <reframe.core.pipeline.RegressionTest.stderr>` attributes to reference the standard output and standard error, respectively.
 
-.. tip:: You need not to care about handling exceptions, and error handling in general, inside your test.
+.. tip:: You don't need to care about handling exceptions, and error handling in general, inside your test.
   The framework will automatically abort the execution of the test, report the error and continue with the next test case.
 
 The last two lines of the regression test are optional, but serve a good role in a production environment:

docs/tutorial_deps.rst

@@ -68,7 +68,7 @@ The full set of OSU example tests is shown below:
 
 .. literalinclude:: ../tutorial/advanced/osu/osu_benchmarks.py
 
-Notice that the order dependencies are defined in a test file is irrelevant.
+Notice that the order in which dependencies are defined in a test file is irrelevant.
 In this case, we define :class:`OSUBuildTest` at the end.
 ReFrame will make sure to properly sort the tests and execute them.
 

reframe/core/decorators.py

@@ -131,9 +131,9 @@ def required_version(*versions):
       1. ``VERSION``: Specifies a single version.
       2. ``{OP}VERSION``, where ``{OP}`` can be any of ``>``, ``>=``, ``<``,
          ``<=``, ``==`` and ``!=``. For example, the version specification
-         string ``'>=2.15'`` will only allow the following test to be loaded
-         only by ReFrame 2.15 and higher. The ``==VERSION`` specification is
-         the equivalent of ``VERSION``.
+         string ``'>=2.15'`` will allow the following test to be loaded only
+         by ReFrame 2.15 and higher. The ``==VERSION`` specification is the
+         equivalent of ``VERSION``.
       3. ``V1..V2``: Specifies a range of versions.
 
       You can specify multiple versions with this decorator, such as
@@ -193,8 +193,8 @@ def run_before(stage):
     The method will run just before the specified pipeline stage and it should
     not accept any arguments except ``self``.
 
-    This decorator can be stacked, which case the function will be attached to
-    multiple pipeline stages.
+    This decorator can be stacked, in which case the function will be attached
+    to multiple pipeline stages.
 
     The ``stage`` argument can be any of ``'setup'``, ``'compile'``,
     ``'run'``, ``'sanity'``, ``'performance'`` or ``'cleanup'``.

reframe/core/pipeline.py

@@ -1329,7 +1329,7 @@ def check_sanity(self):
 
            .. versionchanged:: 3.0
               You may not override this method directly unless you are in
-              speciaxl test. See `here
+              special test. See `here
               <migration_2_to_3.html#force-override-a-pipeline-method>`__ for
               more details.