# 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
You are at the right place... To understand what you can do or
cannot do with SimGrid, you should read the
<a href="https://simgrid.org/tutorials.html">tutorial
-slides</a> from the SimGrid's website. You may find more uptodate
+slides</a> from the SimGrid's website. You may find more up-to-date
material on the
<a href="http://people.irisa.fr/Martin.Quinson/blog/SimGrid/">blog of
Martin Quinson</a>.
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?
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
@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.
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:
~~~~
}
~~~~
-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.
~~~~
- 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_<name>(<args>)`.
To simplify the simcall creation, a python script generates most of
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<T>` 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:
~~~
- 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
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
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 <project/directory>/tools/tesh/generate_tesh can
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.
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.
@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
@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.
/** @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 */
/** @} */
displayed by setting a threshold to each category through the
<tt>threshold</tt> keyword.
-For example, @verbatim --log=root.threshold:debug@endverbatim will make
+For example, @verbatim --log=root.thresh:debug@endverbatim will make
SimGrid <b>extremely</b> verbose while @verbatim
--log=root.thres:critical@endverbatim should shut it almost
completely off.
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
- 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
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.
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.
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.
| 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:
- 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
- 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
- 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
[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
This page presents the current code organization, as you will see it
if you dig into the src/ directory. <b>But things will change during
the current Gran Refactoring leading to SimGrid 4</b>. 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
@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
