From 6032e02b3443eff7869d98ade7cdf6fe536b09aa Mon Sep 17 00:00:00 2001 From: Augustin Degomme Date: Fri, 12 Jun 2020 12:15:58 +0200 Subject: [PATCH] spellings mistakes in doc/ --- doc/Doxyfile.in | 2 +- doc/doxygen/FAQ.doc | 4 ++-- doc/doxygen/inside.doc | 8 ++++---- doc/doxygen/inside_extending.doc | 10 +++++----- doc/doxygen/inside_release.doc | 2 +- doc/doxygen/inside_tests.doc | 10 +++++----- doc/doxygen/module-index.doc | 4 ++-- doc/doxygen/module-sd.doc | 4 ++-- doc/doxygen/module-xbt.doc | 2 +- doc/doxygen/outcomes_logs.doc | 6 +++--- doc/doxygen/platform.doc | 8 ++++---- doc/doxygen/uhood.doc | 12 ++++++------ doc/doxygen/uhood_arch.doc | 4 ++-- 13 files changed, 38 insertions(+), 38 deletions(-) diff --git a/doc/Doxyfile.in b/doc/Doxyfile.in index ecab1a3b49..0efc6f8b4d 100644 --- a/doc/Doxyfile.in +++ b/doc/Doxyfile.in @@ -1595,7 +1595,7 @@ UML_LOOK = NO # the class node. If there are many fields or methods and many nodes the # graph may become too big to be useful. The UML_LIMIT_NUM_FIELDS # threshold limits the number of items for each type to make the size more -# managable. Set this to 0 for no limit. Note that the threshold may be +# manageable. Set this to 0 for no limit. Note that the threshold may be # exceeded by 50% before the limit is enforced. UML_LIMIT_NUM_FIELDS = 10 diff --git a/doc/doxygen/FAQ.doc b/doc/doxygen/FAQ.doc index 2509ee9f1d..36f5c3e95e 100644 --- a/doc/doxygen/FAQ.doc +++ b/doc/doxygen/FAQ.doc @@ -9,7 +9,7 @@ This document is the FAQ of the MSG interface. Some entries are a bit aging and You are at the right place... To understand what you can do or cannot do with SimGrid, you should read the tutorial -slides from the SimGrid's website. You may find more uptodate +slides from the SimGrid's website. You may find more up-to-date material on the blog of Martin Quinson. @@ -91,7 +91,7 @@ condition variables or a SimGrid semaphore, as described in @ref msg_synchro (in Java, only semaphores are available). But actually, many synchronization patterns can be encoded with communication on mailboxes. Typically, if you need one process to notify another one, -you could use a condition variable or a semphore, but sending a +you could use a condition variable or a semaphore, but sending a message to a specific mailbox does the trick in most cases. @subsubsection faq_MIA_communication_time How can I get the *real* communication time? diff --git a/doc/doxygen/inside.doc b/doc/doxygen/inside.doc index 3945ed00c6..d6eb7d0ac0 100644 --- a/doc/doxygen/inside.doc +++ b/doc/doxygen/inside.doc @@ -2,8 +2,8 @@ This page describes the software infrastructure behind the SimGrid project. This is not the components' organisation (described in @ref -uhood_arch) but informations on how to extend the framework, how the -automatic tests are run, and so on. These informations are split on +uhood_arch) but information on how to extend the framework, how the +automatic tests are run, and so on. These information are split on several pages, as follows: - @ref uhood_tech_inside @@ -69,10 +69,10 @@ ln -s $(realpath tools/git-hooks/clang-format.pre-commit) .git/hooks/pre-commit @endverbatim This will add an extra verification before integrating any commit that -you could prepare. If your code does not respects our formating code, +you could prepare. If your code does not respects our formatting code, git will say so, and provide a ready to use patch that you can apply to improve your commit. Just carefully read the error message you get -to find the exact command with git-apply to fix your formating. +to find the exact command with git-apply to fix your formatting. If you find that for a specific commit, the formatter does a very bad job, then add --no-verify to your git commit command line. diff --git a/doc/doxygen/inside_extending.doc b/doc/doxygen/inside_extending.doc index f0f02b6110..1a7f221dbb 100644 --- a/doc/doxygen/inside_extending.doc +++ b/doc/doxygen/inside_extending.doc @@ -34,7 +34,7 @@ the classes of the corresponding interfaces. For instance, if you want to add a new cup model called `Plop`, create two files cpu_plop.hpp and cpu_plop_cpp which contains classes CpuPlopModel, CpuPlop and -CpuPlopAction implementating respectively the interfaces CpuModel, Cpu and +CpuPlopAction implementing respectively the interfaces CpuModel, Cpu and CpuAction. You also need to define a initializing function like this: ~~~~ @@ -101,7 +101,7 @@ void sg_my_network_plugin_init() { } ~~~~ -Then you need to add an entry in surf_interface.cpp refering to your +Then you need to add an entry in surf_interface.cpp referring to your initialization function. ~~~~ @@ -145,13 +145,13 @@ The workflow of a simcall is the following: - If the simcall is not marked as "blocking" in its definition, call `ActorImpl::simcall_answer()` that adds back the issuer process to the list of processes to run in the next scheduling round. - It is thus the responsability of the blocking simcalls to call + It is thus the responsibility of the blocking simcalls to call `ActorImpl::simcall_answer()` themselves in their handler. Note that empty HANDLERs can be omitted. These functions usually do some parameter checking, or retrieve some information about the simcall issuer, but when there no need for such things, the handler -can be omited. In that case, we directly call the function +can be omitted. In that case, we directly call the function `simcall_()`. To simplify the simcall creation, a python script generates most of @@ -204,7 +204,7 @@ in. For simcalls which might block, `kernel_sync()` can be used. It takes a C++ callback and executes it immediately in maestro. This C++ callback is expected to return a `simgrid::kernel::Future` reprensenting the operation -in the kernal. When the operations completes, the user process is waken up +in the kernel. When the operations completes, the user process is waken up with the result: ~~~ diff --git a/doc/doxygen/inside_release.doc b/doc/doxygen/inside_release.doc index f3609b57f9..34614e2bb0 100644 --- a/doc/doxygen/inside_release.doc +++ b/doc/doxygen/inside_release.doc @@ -122,7 +122,7 @@ Release numbering semantic: - 3.X.Y where Y is odd: git current status between two releases - No expectations on such versions - Example - - 3.22.4: unannounced/losely documented stable release + - 3.22.4: unannounced/loosely documented stable release - 3.22.5: git status somewhere between the release of 3.22.4 and the next one - 3.23: Documented and announced stable release diff --git a/doc/doxygen/inside_tests.doc b/doc/doxygen/inside_tests.doc index 10a394a924..e7aba36bbb 100644 --- a/doc/doxygen/inside_tests.doc +++ b/doc/doxygen/inside_tests.doc @@ -61,7 +61,7 @@ It is important to keep your tests fast. We run them very very often, and you should strive to make them as fast as possible, to not bother the other developers. Do not hesitate to stress test your code, but make sure that it runs reasonably fast, or nobody will run "ctest" -before commiting code. +before committing code. @section inside_tests_add_integration Adding integration tests @@ -89,10 +89,10 @@ To add a new integration test, you thus have 3 things to do: details.@n Tesh is sometimes annoying as you have to ensure that the expected output will always be exactly the same. In particular, your should - not output machine dependent informations such as absolute data - path, nor memory adresses as they would change on each run. Several + not output machine dependent information such as absolute data + path, nor memory addresses as they would change on each run. Several steps can be used here, such as the obfucation of the memory - adresses unless the verbose logs are displayed (using the + addresses unless the verbose logs are displayed (using the #XBT_LOG_ISENABLED() macro), or the modification of the log formats to hide the timings when they depend on the host machine.@n The script located in /tools/tesh/generate_tesh can @@ -130,7 +130,7 @@ ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh As usual, you must run "make distcheck" after modifying the cmake files, to ensure that you did not forget any files in the distributed archive. -@section inside_tests_ci Continous Integration +@section inside_tests_ci Continuous Integration We use several systems to automatically test SimGrid with a large set of parameters, across as many platforms as possible. diff --git a/doc/doxygen/module-index.doc b/doc/doxygen/module-index.doc index d1f2962b06..096e81d84d 100644 --- a/doc/doxygen/module-index.doc +++ b/doc/doxygen/module-index.doc @@ -47,7 +47,7 @@ This is not the way it goes in SimGrid: the network routing is defined in a global and compact way instead. This eases the modeling of very large systems, and allows highly optimized datastructures and algorithms in the simulator. The proposed description mechanism is -thus much more convinient and efficient. In addition, it is more +thus much more convenient and efficient. In addition, it is more expressive than the classical solution based on forwarding tables on each host and router. @@ -104,7 +104,7 @@ in other languages). Until then, please head to @ref platform. @defgroup SURF_API SURF @brief Internal kernel of all the simulators used in SimGrid, and associated models. -SURF provides the core functionnalities to simulate a virtual +SURF provides the core functionalities to simulate a virtual platform. It is very low-level and is not intended to be used by end users, but rather to serve as a basis for higher-level simulators. Its interfaces are not frozen (and probably never will be), and the diff --git a/doc/doxygen/module-sd.doc b/doc/doxygen/module-sd.doc index e739dca3d1..90276fac3c 100644 --- a/doc/doxygen/module-sd.doc +++ b/doc/doxygen/module-sd.doc @@ -2,12 +2,12 @@ @defgroup SD_API SimDag: Legacy handling of DAG algorithms @brief Programming environment for DAG applications -SimDag provides functionnalities to simulate parallel task scheduling +SimDag provides functionalities to simulate parallel task scheduling arranged in DAGs (Direct Acyclic Graphs). Only centralized algorithms can be expressed with SimDag; consider using @ref MSG_API "MSG" for distributed algorithms). -SimDag is the oldest interface in SimGrid, even if it was temporarly +SimDag is the oldest interface in SimGrid, even if it was temporarily removed when the new superfast kernel was added in SimGrid v3.0. It will certainly be deprecated by future releases of the S4U API, when inter-activity dependencies are added. diff --git a/doc/doxygen/module-xbt.doc b/doc/doxygen/module-xbt.doc index b43ac117c2..d3dc154d1f 100644 --- a/doc/doxygen/module-xbt.doc +++ b/doc/doxygen/module-xbt.doc @@ -40,7 +40,7 @@ /** @defgroup XBT_ex Exception support (C++) */ /** @defgroup XBT_ex_c Exception support (C) */ /** @defgroup XBT_log Logging support */ - /** @defgroup XBT_error Assert macro familly */ + /** @defgroup XBT_error Assert macro family */ /** @defgroup XBT_config Configuration support */ /** @defgroup XBT_mallocator Mallocators */ /** @} */ diff --git a/doc/doxygen/outcomes_logs.doc b/doc/doxygen/outcomes_logs.doc index e22541c2f3..bdebfd449c 100644 --- a/doc/doxygen/outcomes_logs.doc +++ b/doc/doxygen/outcomes_logs.doc @@ -236,7 +236,7 @@ The most common setting is to control which logging event will get displayed by setting a threshold to each category through the threshold keyword. -For example, @verbatim --log=root.threshold:debug@endverbatim will make +For example, @verbatim --log=root.thresh:debug@endverbatim will make SimGrid extremely verbose while @verbatim --log=root.thres:critical@endverbatim should shut it almost completely off. @@ -245,7 +245,7 @@ Note that the threshold keyword can be abbreviated here. For example, all the following notations have the same result. @verbatim --log=root.threshold:debug ---log=root.threshol:debug +--log=root.threshold:debug --log=root.thresho:debug --log=root.thresh:debug --log=root.thres:debug @@ -261,7 +261,7 @@ The full list of recognized thresholds is the following: - trace: enter and return of some functions - debug: crufty output - verbose: verbose output for the user wanting more - - info: output about the regular functionning + - info: output about the regular functioning - warning: minor issue encountered - error: issue encountered - critical: major issue encountered diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc index 2e9967f6f6..831b6ec8c9 100644 --- a/doc/doxygen/platform.doc +++ b/doc/doxygen/platform.doc @@ -111,7 +111,7 @@ c-99.me is set to ``Cluster``. The ``<cabinet />`` tag is, like the @ref pf_tag_cluster "<cluster>" tag, -a meta-tag. This means that it is simply a shortcut for creating a set of (homogenous) hosts and links quickly; +a meta-tag. This means that it is simply a shortcut for creating a set of (homogeneous) hosts and links quickly; unsurprisingly, this tag was introduced to setup cabinets in data centers quickly. Unlike <cluster>, however, the <cabinet> assumes that you create the backbone and routers yourself; see our examples below. @@ -159,7 +159,7 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste etc. -@subsection pf_ne Network equipments +@subsection pf_ne Network equipment There are two tags at all times available to represent network entities and several other tags that are available only in certain contexts. @@ -514,7 +514,7 @@ router1 must belong to zone1 and router2 must belong to zone2. The purpose of this entity is to define a route between two NetZones. Recall that all zones form a tree, so to connect two -sibiling zones, you must give such a zoneRoute specifying the source +sibling zones, you must give such a zoneRoute specifying the source and destination zones, along with the gateway in each zone (ie, the point to reach within that zone to reach the netzone), and the list of links in the ancestor zone to go from one zone to another. @@ -780,7 +780,7 @@ you say that the file trace must be used by the entity. | Attribute name | Mandatory | Values | Description | | --------------- | --------- | ---------------------- | ----------- | | id | yes | String | Identifier of this trace; this is the name you pass on to @c trace_connect. | -| file | no | String | Filename of the file that contains the information - the path must follow the style of your OS. You can omit this, but then you must specifiy the values inside of <trace> and </trace> - see the example below. | +| file | no | String | Filename of the file that contains the information - the path must follow the style of your OS. You can omit this, but then you must specify the values inside of <trace> and </trace> - see the example below. | | trace_periodicity | yes | String | This is the same as for @ref pf_tag_host "hosts" (see there for details) | Here is an example of trace when no file name is provided: diff --git a/doc/doxygen/uhood.doc b/doc/doxygen/uhood.doc index 14350bdd0e..747aa5ee76 100644 --- a/doc/doxygen/uhood.doc +++ b/doc/doxygen/uhood.doc @@ -24,13 +24,13 @@ We provide an uniform interface to them: - the Maestro object and the corresponding S4U object have the same lifetime (and share the same reference count). -The ability to manipulate thge objects thought pointers and have the ability +The ability to manipulate the objects through pointers and have the ability to use explicit reference count management is useful for creating C wrappers to the S4U and should play nicely with other language bindings (such as SWIG-based ones). Some objects currently live for the whole duration of the simulation and do -not have refertence counts. We still provide dummy `intrusive_ptr_add_ref(p)`, +not have reference counts. We still provide dummy `intrusive_ptr_add_ref(p)`, `intrusive_ptr_release(p)` and `FooPtr` for consistency. In many cases, we try to have a API which is consistent with the API or @@ -203,7 +203,7 @@ The current implementation of the model-checker uses two distinct processes: - the SimGrid model-checker (`simgrid-mc`) itself lives in the parent process; - - it spaws a child process for the SimGrid simulator/maestro and the simulated + - it spawns a child process for the SimGrid simulator/maestro and the simulated processes. They communicate using a `AF_UNIX` `SOCK_SEQPACKET` socket and exchange messages @@ -218,7 +218,7 @@ process using the following techniques: - the model-cheker `ptrace()`s the model-checked process and is thus able to know the state of the model-checked process if it crashes; -- DWARF debug informations are used to unwind the stack and identify local +- DWARF debug information are used to unwind the stack and identify local variables; - a custom heap is enabled in the model-checked process which allows the model @@ -245,11 +245,11 @@ Additional helper class include: [ELF](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file and dynamic libraries file format. -[DWARF](http://dwarfstd.org/) is a standard for debug informations. +[DWARF](http://dwarfstd.org/) is a standard for debug information. Both are used on GNU/Linux systems and exploited by the model-checker to understand the model-checked process: - - `ObjectInformation` represents the informations about a given ELF module + - `ObjectInformation` represents the information about a given ELF module (executable or shared-object); - `Frame` represents a subprogram scope (either a subprogram or a scope within diff --git a/doc/doxygen/uhood_arch.doc b/doc/doxygen/uhood_arch.doc index f8663f4332..732ff1cc56 100644 --- a/doc/doxygen/uhood_arch.doc +++ b/doc/doxygen/uhood_arch.doc @@ -3,7 +3,7 @@ This page presents the current code organization, as you will see it if you dig into the src/ directory. But things will change during the current Gran Refactoring leading to SimGrid 4. So take the -information on this page with a grain of salt, and don't be affraid if +information on this page with a grain of salt, and don't be afraid if things are not exactly as documented here. At some point, we at least extend this page to present the overall @@ -26,7 +26,7 @@ page. @section ug_overview Overview of the toolkit components -@subsection ug_overview_envs Programing environments layer +@subsection ug_overview_envs Programming environments layer SimGrid provides several programming environments built on top of a unique simulation kernel. Each environment targets a specific audience and -- 2.20.1