Remove last mentions of SimDAG in docs.

diff --git a/README.coding b/README.coding
index 37d3e72..e3eed40 100644 (file)
--- a/README.coding
+++ b/README.coding
@@ -74,7 +74,7 @@ We use @ as a command marker, not \ (so, use @brief not \brief)
 **
 *****************************************************
 
-SimGrid3 legacy interfaces (ie, MSG and SimDag) are following these rules:
+SimGrid3 legacy interface (ie, MSG) is following these rules:
 
   - ???_t is a valid type (built with typedef)
   - s_toto_t is a structure (access to fields with .)

diff --git a/docs/source/Configuring_SimGrid.rst b/docs/source/Configuring_SimGrid.rst
index 0c352a5..1ef79f1 100644 (file)
--- a/docs/source/Configuring_SimGrid.rst
+++ b/docs/source/Configuring_SimGrid.rst
@@ -242,8 +242,7 @@ models for all existing resources.
   end, you have two host models: The default one allows aggregation of
   an existing CPU model with an existing network model, but does not
   allow parallel tasks because these beasts need some collaboration
-  between the network and CPU model. That is why, ptask_07 is used by
-  default when using SimDag.
+  between the network and CPU model.
 
   - **default:** Default host model. Currently, CPU:Cas01 and
     network:LV08 (with cross traffic enabled)
@@ -943,7 +942,7 @@ Configuring the Tracing
 -----------------------
 
 The :ref:`tracing subsystem <outcome_vizu>` can be configured in
-several different ways depending on the used interface (S4U, SMPI, SimDag)
+several different ways depending on the used interface (S4U, SMPI)
 and the kind of traces that needs to be obtained. See the
 :ref:`Tracing Configuration Options subsection
 <tracing_tracing_options>` for a full description of each
@@ -953,7 +952,7 @@ We detail here a simple way to get the traces working for you, even if
 you never used the tracing API.
 
 
-- Any SimGrid-based simulator (MSG, SimDag, SMPI, ...) and raw traces:
+- Any SimGrid-based simulator (MSG, SMPI, ...) and raw traces:
 
   .. code-block:: none
 
@@ -963,7 +962,7 @@ you never used the tracing API.
   tells it to trace host and link utilization (without any
   categorization).
 
-- MSG or SimDag-based simulator and categorized traces (you need to
+- MSG-based simulator and categorized traces (you need to
   declare categories and classify your tasks according to them)
 
   .. code-block:: none

diff --git a/docs/source/application.rst b/docs/source/application.rst
index 4e46704..2cd7745 100644 (file)
--- a/docs/source/application.rst
+++ b/docs/source/application.rst
@@ -31,16 +31,13 @@ to mix several interfaces in the same simulation.
    MPI profilers). You can reuse this mechanism for any kind of trace
    that you want to replay, for example to study how a P2P DHT overlay
    reacts to a given workload.
- - Simulating algorithms with one of the legacy interfaces: :ref:`MSG
-   for distributed algorithms <MSG_doc>` (in :ref:`C <MSG_doc>` or
-   :ref:`Java <Java_doc>`) and SimDAG for
-   centralized algorithms (in C). SimGrid was founded in 1998, and
-   many interfaces were proposed along the way. MSG (introduced
-   around 2002) and SimDag (introduced before 2000), are still present
-   in SimGrid. They do not evolve anymore, but given their popularity,
-   they will not be removed until at least 2020. That being said, our
-   goal is to make S4U so useful that these legacy APIs become useless
-   and obsolete.
+ - Simulating algorithms with the legacy interface: :ref:`MSG for distributed
+   algorithms <MSG_doc>` (in :ref:`C <MSG_doc>` or :ref:`Java
+   <Java_doc>`). SimGrid was founded in 1998, and many interfaces were proposed
+   along the way. MSG (introduced around 2002) is still present in SimGrid. It
+   does not evolve anymore, but given its popularity, it will not be removed
+   until at least 2020. That being said, our goal is to make S4U so useful that
+   this legacy API becomes useless and obsolete.
  - We are currently working on the ability to modify any existing
    application so that it can run on top of SimGrid. This project,
    called `Remote-SimGrid