tutorials: proofreading of rst files using llm

tutorials/configurator/doc/conclusion.rst

@@ -1,9 +1,9 @@
 Conclusion
 ==========
 
-Congratulations, you’ve made it! You should now be able to set up IPv4
+Congratulations, you've made it! You should now be able to set up IPv4
 static autoconfiguration for networks in the INET Framework. Use the
-link below if you have questions or you'd like to help us improve this
+link below if you have any questions or if you'd like to help us improve this
 tutorial.
 
 Discussion

tutorials/configurator/doc/step1.rst

@@ -7,7 +7,7 @@ Goals
 In the first step, we want to automatically assign addresses in a wired
 network. To make the task a little bit more complicated, the network
 won't be a single LAN, but several LANs connected via routers. We want to
-place nodes on each subnet into a different subnet, but otherwise, we
+place nodes on each subnet into different subnets, but otherwise, we
 don't care how addresses are assigned. We also ignore the question of
 filling routing tables for now -- it will be covered in later steps.
 
@@ -83,7 +83,7 @@ but tell the visualizer to ignore switches and access points, as they
 don't have IP addresses.
 
 Other settings in the ``General`` section, such as the WiFi bit rate,
-are not relevant for the topic of the tutorial.
+are not relevant to the topic of the tutorial.
 
 .. literalinclude:: ../omnetpp.ini
    :language: ini
@@ -107,7 +107,7 @@ parameter.
 Note that the configurator assigned a 29-bit netmask to the hosts and
 the router interfaces connecting to the switches, and a 30-bit netmask
 to the other router interfaces. Three hosts and the router's interface
-towards a switch as a group has four interfaces, thus, a 30-bit netmask
+towards a switch as a group have four interfaces, thus, a 30-bit netmask
 with a 2-bit host identifier would have sufficed. However, the
 configurator doesn't assign addresses where the host identifier is
 all-zeros or all-ones (as they commonly refer to the subnet itself

tutorials/configurator/doc/step10.rst

@@ -9,7 +9,7 @@ static routes. It also demonstrates leaving the routing tables
 unconfigured, so that a dynamic routing protocol can configure them. The step
 consists of three parts:
 
--  **Part A**: Static routing based on error rate metric
+-  **Part A**: Static routing based on the error rate metric
 -  **Part B**: Unconfigured routing tables, prepared for MANET routing
 -  **Part C**: Routing tables configured using AODV protocol
 

tutorials/configurator/doc/step11.rst

@@ -5,7 +5,7 @@ Goals
 -----
 
 Sometimes the configurator's configuration is just almost right. In such
-a case it's possible to dump the configuration into a file, edit it and
+a case, it's possible to dump the configuration into a file, edit it and
 use the file in place of the original configuration. This step consists
 of two parts:
 
@@ -16,8 +16,8 @@ Part A - Dumping the full configuration
 ---------------------------------------
 
 The configurator can be instructed to dump its configuration into a
-config file, in the XML configuration format. This file contains all the
-assigned addresses, routing table entries and members of wireless links,
+config file in the XML configuration format. This file contains all the
+assigned addresses, routing table entries, and members of wireless links,
 so they can be easily modified. The modified config file can be used as
 the XML configuration for subsequent simulation runs.
 
@@ -44,7 +44,7 @@ config file.
 Results
 ~~~~~~~
 
-Routes to all nodes are visualized on the following image.
+Routes to all nodes are visualized in the following image.
 
 .. figure:: media/step11a_routes.png
    :width: 100%
@@ -58,7 +58,7 @@ Part B - Using the modified configuration
 
 In this part, we edit the config file and use it as the XML
 configuration. The goal is that packets should travel counter-clockwise
-in the triangle of the three routers, i.e. each router should forward
+in the triangle of the three routers, i.e., each router should forward
 packets in the triangle through its interface on the right.
 
 Configuration
@@ -78,14 +78,14 @@ host in each LAN pings another host in the adjacent LAN in the
 counter-clockwise direction.
 
 The routes in all three routers' routing tables are modified. Routes
-that would send packets the wrong way (i.e. not counter-clockwise in the
+that would send packets the wrong way (i.e., not counter-clockwise in the
 triangle) are redirected to the other interface. In essence, all routers
 send out packets through their interface to the right (except for
-packets destined to the connecting LAN.)
+packets destined for the connecting LAN.)
 
 The modified XML configuration is in
 :download:`step11b.xml <../step11b.xml>` (see
-:download:`step11a\_dump.xml <../step11a_dump.xml>` for the original.)
+:download:`step11a\_dump.xml <../step11a_dump.xml>` for the original).
 The differences between the original and the modified config files are
 displayed below (the original is shown in red).
 
@@ -95,13 +95,13 @@ displayed below (the original is shown in red).
 Results
 ~~~~~~~
 
-Routes to all nodes are visualized on the following image. Note that
+Routes to all nodes are visualized in the following image. Note that
 arrows point only counter-clockwise in the triangle.
 
 .. figure:: media/step11b_routes.png
    :width: 100%
 
-The ping exchanges highlight the modified routes on the following video:
+The ping exchanges highlight the modified routes in the following video:
 
 .. video:: media/Step11B_2_cropped.mp4
    :width: 100%

tutorials/configurator/doc/step12.rst

@@ -34,7 +34,7 @@ which has a wired connection to the router. However, ``area1host3`` is
 not in the communication range of ``area1host1`` (illustrated on the
 image below.) Thus, ``area1host2`` needs to be configured to forward
 ``area1host1``'s packets to ``area1host3``. The error rate metric,
-rather than hop count, is best suited to configure routes in this LAN.
+rather than the hop count, is best suited to configure routes in this LAN.
 Routes in the rest of the network can be configured properly based on
 the hop count metric.
 
@@ -70,13 +70,13 @@ The global ``addStaticRoutes``, ``addDefaultRoutes`` and
 ``addSubnetRoutes`` parameters can also be specified per interface, with
 attributes of the ``<interface>`` element. The attribute names are
 ``add-static-route``, ``add-default-route`` and ``add-subnet-route``,
-and they are all booleans with true as default value. The global and
+and they are all booleans with true as the default value. The global and
 per-interface settings are in a logical AND relationship, so both have
 to be true to take effect.
 
 The default route assumes there is one gateway, and all nodes on the
-link can reach it directly. This is not the case for area 1, because
-``area1host1`` is out of range of the gateway host. The
+link can reach it directly. This is not the case for area 1 because
+``area1host1`` is out of the range of the gateway host. The
 ``add-default-route`` parameter is set to false for the area 1 hosts.
 
 Results

tutorials/configurator/doc/step3.rst

@@ -5,7 +5,7 @@ Goals
 -----
 
 Complex networks often contain several subnetworks, and the user may
-want to assign specific IP address ranges for them. This step
+want to assign specific IP address ranges to them. This step
 demonstrates how to assign a range of IP addresses to subnets.
 
 The model
@@ -15,7 +15,7 @@ This step uses the :ned:`ConfiguratorA` network, as in the previous two
 steps. One switch and the connected hosts as a group will be on the same
 subnet, and there are three such groups in the network.
 
-The configuration is the following:
+The configuration is as follows:
 
 .. literalinclude:: ../omnetpp.ini
    :language: ini
@@ -33,8 +33,8 @@ A brief explanation:
 -  The first three entries assign IP addresses with different network
    prefixes to hosts in the three different subnets.
 
--  The next three entries specify for each router that its interface
-   that connects to a subnet should belong in that subnet. These entries
+-  The next three entries specify, for each router, that its interface
+   connecting to a subnet should belong to that subnet. These entries
    use the ``towards`` selector, which selects the interfaces that are
    connected towards the specified host or hosts.
 
@@ -66,10 +66,10 @@ Another alternative XML configuration is the following:
    :language: xml
 
 This one assigns an address to one host in each of the three subnets. It
-assigns addresses o the interfaces of the routers facing the other
+assigns addresses to the interfaces of the routers facing the other
 routers, and includes a copy of the default configuration. Because
 ``assignDisjunctSubnetAddresses=true``, the configurator puts the
-unspecified hosts, and the subnet facing router interfaces into the same
+unspecified hosts and the subnet-facing router interfaces into the same
 subnet as the specified host.
 
 Results
@@ -82,7 +82,7 @@ The assigned addresses are shown in the following image.
 
 The addresses are assigned as intended. This is useful because it is
 easy to recognize which group a node belongs to just by looking at its
-address (e.g. in the logs.)
+address (e.g., in the logs).
 
 Sources: :download:`omnetpp.ini <../omnetpp.ini>`,
 :download:`ConfiguratorA.ned <../ConfiguratorA.ned>`

tutorials/configurator/doc/step5.rst

@@ -78,7 +78,7 @@ Second, note that the ``<route>`` element refers to addresses (e.g.
 element. It is valid to do so because the assignment of IP addresses is
 deterministic, that is, given the same input, it will always produce the
 same result. However, if you change the network topology, for example,
-add, remove or reorder hosts, addresses might be assigned in a different
+add, remove, or reorder hosts, addresses might be assigned in a different
 way. The consequence may be that addresses in the ``<route>`` element no
 longer exist in the modified network or they refer to different
 hosts/routers than originally intended, i.e. the configuration will

tutorials/fingerprint/doc/accepting.rst

@@ -3,9 +3,9 @@ Accepting Fingerprint Changes
 
 After successfully validating a set of changes using the methods demonstrated in this tutorial, the baseline fingerprints should be updated. The new baseline will be used in the future to validate new changes by comparing against.
 
-For example, if the fingerprint ingredients have been changed, then it's advisable to revert the changes, because the default ingredients were selected to have the right amount of sensitivity to a broad range of changes, thus may be more suitable for detecting regressions.
+For example, if the fingerprint ingredients have been changed, then it's advisable to revert the changes because the default ingredients were selected to have the right amount of sensitivity to a broad range of changes, thus may be more suitable for detecting regressions.
 
-To do that, replace the ingredients with ``tplx`` (or other chosen set of baseline ingredients):
+To do that, replace the ingredients with ``tplx`` (or another chosen set of baseline ingredients):
 
 .. code-block:: text
 
@@ -24,13 +24,13 @@ Then run the fingerprint tests:
   . -f omnetpp.ini -c WifiShortPacket -r 0  ... : FAILED
   . -f omnetpp.ini -c EthernetShortPacket -r 0  ... : FAILED
 
-The tests fail, because the fingerprint values in the .csv file correspond to the previous set of ingredients or filtering. Since there was no change in the model since validation, it is safe to accept the new values/the new values can be accepted/it is safe to overwrite the .csv file with the new values:
+The tests fail because the fingerprint values in the .csv file correspond to the previous set of ingredients or filtering. Since there was no change in the model since validation, it is safe to accept the new values/the new values can be accepted/it is safe to overwrite the .csv file with the new values:
 
 .. code-block:: fp
 
    $ mv baseline.csv.UPDATED baseline.csv
 
-It is advisable to re-run the tests to check whether the fingerprints are stable; i.e. it might happen that each run gives different values, e.g. when the simulation trajectory depends on memory layout (caused by iteration on std::map of object pointers, for example).
+It is advisable to re-run the tests to check whether the fingerprints are stable; i.e., it might happen that each run gives different values, e.g., when the simulation trajectory depends on memory layout (caused by iteration on std::map of object pointers, for example).
 
 When we re-run the tests, they pass:
 

tutorials/fingerprint/doc/first.rst

@@ -101,15 +101,15 @@ The fingerprint tool
   - can be filtered with -m which is a regex?
   - for more info -h
 
-The fingerprint tool is a conventient way to run fingerprint tests. It is located in the ``inet/bin`` folder, and when the ``inet`` directory is added to the PATH, it can be run from any project directory.
+The fingerprint tool is a convenient way to run fingerprint tests. It is located in the ``inet/bin`` folder, and when the ``inet`` directory is added to the PATH, it can be run from any project directory.
 
 .. (inet subdirectory?).
 
-The fingerprint test tool uses .csv files to run fingerprint tests./uses .csv files to keep track of test runs
+The fingerprint test tool uses .csv files to run fingerprint tests. It uses .csv files to keep track of test runs.
 A line in the .csv file defines a simulation run by specifying the working directory, command line arguments, sim time limit, fingerprint+ingredients, expected result, and tags.
 The result of one fingerprint test can either be PASS, FAILED or ERROR. A test results in FAILED if the calculated fingerprint differs from the one in the .csv file; it results in ERROR when there was an error during the simulation.
 
-.. By default, the fingerprint test tool runs all simulations defined in .csv files in the current folder.TODO later
+.. By default, the fingerprint test tool runs all simulations defined in .csv files in the current folder. TODO later
    The set of simulations can be filtered with the ``-m`` command line option.
 
 When run without arguments, the fingerprint test tool runs all tests in all .csv files in the current directory. Specific .csv files to run can be selected with the first argument.
@@ -221,7 +221,7 @@ The fingerprints can be run from the command line. Make sure to run ``. setenv``
 
 .. TODO: the setenv and the fingerprinttest separately ?
 
-The ``inet_fingerprinttest`` runs all simulations specified in all .csv files in the currect folder:
+The ``inet_fingerprinttest`` runs all simulations specified in all .csv files in the current folder:
 
 .. code-block:: fp
 
@@ -312,4 +312,4 @@ Generally, the workflow involves a change in the model, which we suspect will no
 
 .. note:: Fingerprint testing depends on repeatable deterministic simulations, random number generation, etc. If the tests are not repeatable, i.e. they don’t result in the same fingerprints when run multiple times (e.g. emulation), fingerprint tests are useless.
 
-.. if it's not repeatable, e.g. emulation, than this whole stuff doesn't apply
+.. if it's not repeatable, e.g. emulation, than this whole stuff doesn't apply

tutorials/fingerprint/doc/newevents_filtering.rst

@@ -6,15 +6,15 @@ Adding New Events - Part 1
   3. solution
   4. example
 
-Some changes in the model can add new events to the simulation. These events inevitably change the default fingerprints but they don't necessarily invalidate the model. One option is to filter out the modules in which the new events take place, so they are not included in fingerprint calculation. Taking into account the rest of the modules might show that the simulation trajectory in fact stayed that same.
+Some changes in the model can add new events to the simulation. These events inevitably change the default fingerprints, but they don't necessarily invalidate the model. One option is to filter out the modules in which the new events take place, so they are not included in the fingerprint calculation. Taking into account the rest of the modules might show that the simulation trajectory, in fact, stayed the same.
 
-To filter out modules, run the fingerprint test with the ``--fingerprint-modules`` command line option, e.g.:
+To filter out modules, run the fingerprint test with the ``--fingerprint-modules`` command-line option, e.g.:
 
 .. code-block:: bash
 
    $ inet_fingerprinttest -a --fingerprint-modules='"not fullPath=~**.wlan[*].mac.**"'
 
-As a simplistic example, we will make changes to the Udp module's code; the changes add new events, but doesn't alter the module's behavior. However, the fingerprints will change; we will filter out the Udp module from the fingerprint calculation to verify the model. Here is the workflow:
+As a simplistic example, we will make changes to the Udp module's code; the changes add new events but don't alter the module's behavior. However, the fingerprints will change; we will filter out the Udp module from the fingerprint calculation to verify the model. Here is the workflow:
 
 We run the fingerprint tests without taking the Udp module into account (the order of the quotes is important):
 
@@ -30,8 +30,8 @@ We can accept the fingerprints because there was no change in the model
 
    $ mv baseline.csv.UPDATED baseline.csv
 
-Then we add a line to one of the functions in :cpp:`Udp.cc` which schedules a self message;
-we also add a handleSelfMessage() function which just deletes the message when its received:
+Then we add a line to one of the functions in :cpp:`Udp.cc` which schedules a self-message;
+we also add a ``handleSelfMessage()`` function which just deletes the message when it's received:
 
 .. literalinclude:: ../sources/Udp_mod.cc
    :diff: ../sources/Udp_orig.cc
@@ -46,7 +46,7 @@ We run the fingerprint tests again without the Udp module:
 
 The fingerprint tests PASS; the model is verified.
 
-.. note:: The ``-fingerprint-module=""`` command line argument can be added to the .csv file as well.
+.. note:: The ``-fingerprint-module=""`` command-line argument can be added to the .csv file as well.
 
 We can change the ingredients back to ``tplx`` (or some other default), re-run the tests, and accept the new values. This process is described in more detail in the :doc:`accepting` step.
 
@@ -55,7 +55,7 @@ from the fingerprint calculation. This approach is beneficial because alternate
 with different ingredients are not needed. If only the new event is filtered out, the fingerprints should stay the same.
 
 As a simplistic example, we'll make the same change to the Udp module as before.
-We'll run the tests with the baseline ingredients and filter out the new self message by its id:
+We'll run the tests with the baseline ingredients and filter out the new self-message by its id:
 
 .. code-block:: fp
 
@@ -75,12 +75,12 @@ The tests PASS, and the model is verified.
 
 .. so why is this?
 
-  **because if you filter specifically, then the fingerprints will retain their broad sensitivity, but wont be sensitive
+  **because if you filter specifically, then the fingerprints will retain their broad sensitivity, but won't be sensitive
   to the specific change**
 
-  what i wanna say is
+  what I wanna say is
 
-  - when filtering out something, the best is to filter out very specifically the part of the model which the change affects
+  - when filtering out something, the best is to filter out very specifically the part of the model that the change affects
   - the more specifically one can filter that, the better
   - because then, only that aspect is filtered, and everything else is not
-  - like in the case of the example above...we only filtered out the event which we added. dont need new fingerprints.
+  - like in the case of the example above...we only filtered out the event that we added. Don't need new fingerprints.