Ran pre-commit run --all on changes in PR

Author: oleksandr-pavlyk

CONTRIBUTING.md

@@ -66,14 +66,14 @@ We use the following Python code style tools:
 >  * `pyproject.toml` and `.flake8` config files for current configurations
 > * `.pre-commit-config.yaml` file for the versions of the tools
 
-Run these three tools before each commit. 
+Run these three tools before each commit.
 
 > **TIP:** Refer your IDE docs to automate these checks or set up `pre-commit` to add git hooks.
 
 ### Setting Up a Pre-commit
-                                     
+
 A `.pre-commit-config.yaml` is included to run various checks before you
-commit your code. 
+commit your code.
 
 To setup `pre-commit` in your workflow, install:
 
@@ -176,7 +176,7 @@ bandit -r dpctl -lll
 Code coverage, for both C and Python sources in dpctl, is generated for each
 pull request (PR). A PR cannot be merged if it leads to a drop in the code
 coverage by more than five percentage points. Therefore, write
-unit tests for your changes. 
+unit tests for your changes.
 
 To check the code coverage for your code, follow these steps:
 
@@ -242,7 +242,7 @@ Messages of a given severity are shown not only in the console for that severity
 
 ### Optional use of the Google logging library (glog)
 
-The dpctl error handler for libsyclinterface can be optionally configured to use [glog](https://github.com/google/glog). 
+The dpctl error handler for libsyclinterface can be optionally configured to use [glog](https://github.com/google/glog).
 
 To use glog, complete the following steps:
 

README.md

@@ -16,15 +16,15 @@ kernel](https://en.wikipedia.org/wiki/Compute_kernel) on an
 
 The compute kernel can be a code:
 * written by the user, e.g., using [`numba-dpex`](https://github.com/IntelPython/numba-dpex)
-* that is part of a library, such as oneMKL  
+* that is part of a library, such as oneMKL
 
 The `dpctl` library is built upon the [SYCL
 standard](https://www.khronos.org/sycl/). It also implements Python
 bindings for a subset of the standard [runtime
 classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_runtime_classes) that allow users to:
 * query platforms
 * discover and represent devices and sub-devices
-* construct contexts and queues 
+* construct contexts and queues
 
 `dpctl` features classes for [SYCL Unified Shared Memory
 (USM)](https://link.springer.com/chapter/10.1007/978-1-4842-5574-2_6)
@@ -37,7 +37,7 @@ devices, queues, memory, and tensors.
 
 `Dpctl` is the core part of a larger family of [data-parallel Python
 libraries and tools](https://www.intel.com/content/www/us/en/developer/tools/oneapi/distribution-for-python.html)
-to program on XPUs. 
+to program on XPUs.
 
 
 
@@ -51,7 +51,7 @@ Python](https://software.intel.com/content/www/us/en/develop/tools/oneapi/compon
 
 ## Inte(R) oneAPI
 
-You can find the most recent release of `dpctl` every quarter as part of the Intel(R) oneAPI releases. 
+You can find the most recent release of `dpctl` every quarter as part of the Intel(R) oneAPI releases.
 
 To get the library from the latest oneAPI release, follow the
 instructions from Intel(R) [oneAPI installation
@@ -95,14 +95,14 @@ setting up a development environment and building `dpctl` from the source.
 
 # Running Examples
 
-Find our examples [here](examples). 
+Find our examples [here](examples).
 
 To run these examples, use:
 
 ```bash
-for script in `ls examples/python/`; 
-    do echo "executing ${script}"; 
-    python examples/python/${script}; 
+for script in `ls examples/python/`;
+    do echo "executing ${script}";
+    python examples/python/${script};
 done
 ```
 

docs/README.md

@@ -29,7 +29,7 @@ instructions to install `liblua`. For example, on Ubuntu 20.04:
 sudo apt-get install liblua5.2-dev
 ```
 
-Generating The Documentation 
+Generating The Documentation
 ============================
 
 The helper script ``scripts/gen_docs.py`` is the preferred way to generate the

docs/docfiles/intro.rst

@@ -5,7 +5,7 @@ The data-parallel control (dpctl) library provides C and Python bindings for
 :sycl_spec_2020:`SYCL 2020 <>`. The SYCL 2020 features supported by dpctl are
 limited to those included by Intel(R) DPCPP compiler and specifically cover the
 SYCL runtime classes described in :sycl_runtime_classes:`Section 4.6 <>`
-of the SYCL 2020 specification. 
+of the SYCL 2020 specification.
 
 Apart from the bindings for these runtime
 classes, dpctl includes bindings for SYCL USM memory allocators and

docs/docfiles/user_guides/QuickStart.rst

@@ -8,8 +8,8 @@ Installation from oneAPI
 ========================
 
 Dpctl is available as part of the oneAPI Intel(R) Distribution for Python (IDP).
-Refer to `Intel(R) oneAPI Toolkits Installation Guide <https://www.intel.com/content/www/us/en/developer/articles/guide/installation-guide-for-oneapi-toolkits.html>`_ 
-to install it. 
+Refer to `Intel(R) oneAPI Toolkits Installation Guide <https://www.intel.com/content/www/us/en/developer/articles/guide/installation-guide-for-oneapi-toolkits.html>`_
+to install it.
 
 In this topic, it is assumed that oneAPI is installed in the standard location and the
 environment variable ``ONEAPI_ROOT`` points to the following installation root
@@ -88,7 +88,7 @@ Building using oneAPI dpcpp
 Install oneAPI and graphics drivers to the system prior
 to proceeding further.
 
-Activate oneAPI 
+Activate oneAPI
 ~~~~~~~~~~~~~~~
 
 On Linux OS
@@ -177,7 +177,7 @@ Building Using Custom dpcpp
 ---------------------------
 
 You can build dpctl from the source using the `DPC++ toolchain <https://github.com/intel/llvm/blob/sycl/sycl/doc/GetStartedGuide.md>`_
-instead of the DPC++ compiler that comes with oneAPI. 
+instead of the DPC++ compiler that comes with oneAPI.
 
 Do this, to enable support for CUDA devices.
 
@@ -224,11 +224,11 @@ After setting up dpctl, you can test the Python examples as follows:
     python examples/python/${script}
     done
 
-The dpctl repository also provides a set of `examples <https://github.com/IntelPython/dpctl/tree/master/examples/cython>`_ 
+The dpctl repository also provides a set of `examples <https://github.com/IntelPython/dpctl/tree/master/examples/cython>`_
 of building the Cython extensions with the DPC++ compiler, that interoperates with dpctl.
 
 To build each example, use
-``CC=icx CXX=dpcpp python setup.py build_ext --inplace``. 
+``CC=icx CXX=dpcpp python setup.py build_ext --inplace``.
 Refer to the ``run.py`` script in respective folders to execute the Cython extension
 examples.
 
@@ -246,7 +246,7 @@ Building the libsyclinterface Library
 =======================================
 
 The libsyclinterface is a shared library used by the Python package.
-To build the library, you need: 
+To build the library, you need:
 
 *  ``DPC++`` toolchain
 * ``cmake``
@@ -280,4 +280,3 @@ library.
         ..
 
     make V=1 -n -j 4 && make check && make install
-

docs/docfiles/user_guides/manual/dpctl/basic_concepts.rst

@@ -68,7 +68,7 @@ This section introduces the basic concepts for XPU management used by `dpctl`.
    "Host allocation", "Yes", "Accessible by both the host and device."
 
 
-Runtime manages synchronization of the host's and device's view into shared allocations. 
+Runtime manages synchronization of the host's and device's view into shared allocations.
 The initial placement of the shared allocations is not defined.
 
 * **Backend**

docs/docfiles/user_guides/manual/dpctl/device_selection.rst

@@ -55,7 +55,7 @@ device selection involves the usage of *filter strings*. Refer to
 
 The :ref:`fig-gpu-device-selection` example also demonstrates the usage of a filter string
 to create a GPU device directly. Using a filter string allows much more
-fine-grained control for selecting a device. 
+fine-grained control for selecting a device.
 
 The following :ref:`fig-filter-selection`
 example demonstrates the usage of the device selection using filter
@@ -93,7 +93,7 @@ A possible output for the :ref:`fig-adv-device-selection` example:
 
 
 A **filter string** is a three-tuple that may specify the *backend*,
-*device type*, and *device number* as a colon (:) separated string. 
+*device type*, and *device number* as a colon (:) separated string.
 
 .. csv-table::
    :header: "String", "Usage", "Values"
@@ -103,19 +103,19 @@ A **filter string** is a three-tuple that may specify the *backend*,
    "*device type*", "Specifies the type of device.", "``host``, ``gpu``, ``cpu``, ``accelerator``"
    "*device number*", "Specifies the ordinality of the device in the listing of devices as determined by the SYCL* runtime.", "Numeric value"
 
-The backend, device type, and device number value are optional but provide at least one of them. 
+The backend, device type, and device number value are optional but provide at least one of them.
 That is, ``opencl:gpu:0``, ``gpu:0``, ``gpu``, ``0``, and ``opencl:0`` are all valid filter strings.
 
 The device listing including the ``device number value`` remains stable for
 a given system unless the driver configuration is changed or the SYCL
-runtime setting is changed using the ``SYCL_DEVICE_FILTER`` environment variable. 
+runtime setting is changed using the ``SYCL_DEVICE_FILTER`` environment variable.
 Refer to :oneapi_filter_selection:`oneAPI filter selection extension <>` for more
 information.
 
 Advanced Device Selection
 -------------------------
 
-Real-world applications may require more precise control over device selection. 
+Real-world applications may require more precise control over device selection.
 Dpctl helps you to accomplish more advanced device selection.
 
 .. _fig-custom-device-selection:
@@ -129,12 +129,12 @@ Dpctl helps you to accomplish more advanced device selection.
 The :ref:`fig-custom-device-selection` example shows a way of selecting a device
 based on a specific hardware property. The process is the following:
 
-1. The :func:`dpctl.get_devices()` returns a list of all *root* devices on the system. 
+1. The :func:`dpctl.get_devices()` returns a list of all *root* devices on the system.
 2. Out of that list the devices that
-support half-precision floating-point arithmetic are selected. 
+support half-precision floating-point arithmetic are selected.
 3. A "score" computed using the SYCL8 runtime's default device scoring logic that is
 stored in :attr:`dpctl.SyclDevice.default_selector_score` is used to select a
-single device. 
+single device.
 
 Refer to the :class:`dpctl.SyclDevice` documentation for a list
 of hardware properties that may be used for device selection.

docs/docfiles/user_guides/manual/dpctl/devices.rst

@@ -16,7 +16,7 @@ The :class:`dpctl.SyclDevice` class includes the default constructor to create a
 explicit :ref:`filter selector strings <sec-filter-selection>` to create a
 device.
 
-.. note:: Refer to :ref:`device_selection` for more information. 
+.. note:: Refer to :ref:`device_selection` for more information.
 
 Listing Devices
 ---------------
@@ -40,10 +40,10 @@ A possible output for the :ref:`fig-listing-devices` example:
 .. program-output:: python ../examples/python/device_selection.py -r list_devices
 
 The :ref:`fig-listing-devices` example demonstrates the usage of
-:func:`dpctl.get_devices`. 
+:func:`dpctl.get_devices`.
 
 You can filter the list based on the
-:class:`dpctl.backend` and :class:`dpctl.device_type`. 
+:class:`dpctl.backend` and :class:`dpctl.device_type`.
 
 The 0-based ordinal position of a device in the output of :func:`dpctl.get_devices` corresponds to
 the ``device id`` value in the filter selector string corresponding to the
@@ -69,7 +69,7 @@ its hardware characteristics:
 * :sycl_device_info:`information descriptors <>` are non-boolean characteristics
   that provide more verbose information about the device
 * :class:`dpctl.SyclDevice` exposes various Python properties that describe a
-  device's aspects and information descriptors. 
+  device's aspects and information descriptors.
 
 For example, the property ``has_aspect_fp16`` returns a boolean expression indicating if:
 
@@ -105,18 +105,18 @@ list all the aspects and information descriptor properties in
 Sub-devices
 -----------
 
-You can partition a device into sub-devices. 
+You can partition a device into sub-devices.
 
-A sub-device represents a subset of the computational units within a device 
-that are grouped based on some hardware criteria. For example, you can partition a two-socket 
+A sub-device represents a subset of the computational units within a device
+that are grouped based on some hardware criteria. For example, you can partition a two-socket
 CPU into two sub-devices, where each sub-device represents a separate
 :numa_domain:`NUMA domain <>`. Depending on the hardware characteristics and
 the capabilities of the SYCL runtime, a sub-device may be partitioned further.
 
 For devices that support partitioning, you can use
 :func:`dpctl.SyclDevice.create_sub_devices` to create a list of
 sub-devices. The requested partitioning scheme is indicated with the usage of the
-required ``partition`` keyword. 
+required ``partition`` keyword.
 
 Several types of partitioning schemes are available:
 

docs/docfiles/user_guides/manual/dpctl/platforms.rst

@@ -12,7 +12,7 @@ Listing Available Platforms
 ---------------------------
 
 To require the platforms available on a system, use
-:func:`dpctl.lsplatform` function. 
+:func:`dpctl.lsplatform` function.
 
 It is possible to print out metadata about a platform:
 

docs/docfiles/user_guides/manual/dpctl/queues.rst

@@ -5,7 +5,7 @@ Queue
 #####
 
 You need a queue to schedule the execution of any computation or data copying on a
-device. 
+device.
 
 The queue construction requires specifying:
 
@@ -23,12 +23,12 @@ Types of Queues
 
 SYCL has a task-based execution model. The order, in which a SYCL runtime
 executes a task on a target device, is specified by a sequence of events that
-must be completed before the execution of the task is allowed. 
+must be completed before the execution of the task is allowed.
 
 Submission of a task returns an event that you can use to further grow the graph of computational
 tasks. A SYCL queue stores the needed data to manage the scheduling operations.
 
-There are two types of queues: 
+There are two types of queues:
 
 * **Out-of-order.** Unless specified otherwise during the constriction of a queue, a SYCL runtime
   executes tasks, which dependencies are met in an unspecified order, with the
@@ -42,7 +42,7 @@ Creating a New Queue
 --------------------
 
 :class:`dpctl.SyclQueue(ctx, dev, property=None)` creates a new queue instance
-for the given compatible context and device. 
+for the given compatible context and device.
 
 To create the **in-order** queue, set a keyword ``parametr`` to ``in_order``
 
@@ -86,7 +86,7 @@ Profiling a Task Submitted to a Queue
 -------------------------------------
 
 The result of scheduling the execution of a task on a queue is an event. You can use
-an event for several purposes: 
+an event for several purposes:
 
 * Query for the status of the task execution
 * Order execution of future tasks after it is completed
@@ -97,7 +97,7 @@ The profiling information is only populated if the queue
 used is created with the ``enable_profiling`` property and only becomes available
 after the task execution is complete.
 
-The :class:`dpctl.SyclTimer` class implements a Python context manager. 
+The :class:`dpctl.SyclTimer` class implements a Python context manager.
 You can use this context manager to collect cumulative profiling information for all the tasks submitted
 to the queue of interest by functions executed within the context: