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 .)
 
   - ???_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
   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)
 
   - **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
 -----------------------
 
 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
 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.
 
 
 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
 
 
   .. code-block:: none
 


@@ -963,7 +962,7 @@ you never used the tracing API.
   tells it to trace host and link utilization (without any
   categorization).
 
   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
   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.
    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
  - 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