From ac38cbc6d0941f0646ac81b3b31010ee86932a2f Mon Sep 17 00:00:00 2001
From: erwan <erwan.jahier@univ-grenoble-alpes.fr>
Date: Thu, 26 Aug 2021 15:56:40 +0200
Subject: [PATCH] docs: some fixes
---
guides/contributors/README.org | 26 +++++++++++++++---------
lib/algo/algo.mli | 37 ++++++++++++++++++++--------------
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/guides/contributors/README.org b/guides/contributors/README.org
index 724eec0f..7e00b5fa 100644
--- a/guides/contributors/README.org
+++ b/guides/contributors/README.org
@@ -5,21 +5,27 @@ Self-stabilizing Algorithms SimulAtor
Contributors Guide
file:dune-deps.pdf
-file:module-dep.pdf
+file:module-deps.pdf
+
+(cf file:Makefile to update them)
* Releases Notes
-https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/releases
+https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/releases
* Compiling sasa sources
You will need:
- =make=
-- a set of tools installable via [[https://opam.ocaml.org/][opam]]
- - =dune=
- - =ocamlgraph=
- - =lutin= (not for compiling actually, but for using sasa with custom daemons)
+- =opam=
+- the =sasa= =opam= dependencies, that you can install by:
+
+#+BEGIN_SRC sh
+opam add repo verimag http://www-verimag.imag.fr/DIST-TOOLS/SYNCHRONE/opam-repository
+opam update
+opam install --deps-only sasa
+#+END_SRC
cf the test job in the Gitlab CI script: [[file:../../.gitlab-ci.yml][../../.gitlab-ci.yml]]
for a working installation process.
@@ -69,7 +75,7 @@ values. It can also by simulated by =lutin= programs via the use of
- [[file:../../lib/sasacore/demon.mli][../../lib/sasacore/daemon.mli]]
- [[file:../../lib/sasacore/demon.ml][../../lib/sasacore/daemon.ml]]
-custom Lutin programs that mimick the built-in modes can be generated
+custom Lutin programs that mimic the built-in modes can be generated
by:
#+INCLUDE: "../../lib/sasacore/genLutin.mli" src ocaml
@@ -130,14 +136,14 @@ Examples of use can be found in:
The [[file:../../lib/sasacore/sasaVersion.ml][../../lib/sasacore/sasaVersion.ml]] is automatically generated
- by [[file:../../Makefile.version][../../Makefile.version]]
- using git tags that are automatically generated using the =release=
- job of the CI script, which is based on [[https://www.npmjs.com/package/semantic-release-gitlab][semantic-release-gitlab]]
+ job of the CI script, which is based on [[https://github.com/semantic-release/gitlab][@semantic-release/gitlab]]
In order to generate sensible version numbers, please follow in your
commit messages the conventions described here:
-https://www.npmjs.com/package/conventional-changelog-eslint
+https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format
This also permits to generate some Releases Notes:
-https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/releases
+https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/releases
* Pluging =sasa= on Synchronous tools
diff --git a/lib/algo/algo.mli b/lib/algo/algo.mli
index 14c7b661..58103e35 100644
--- a/lib/algo/algo.mli
+++ b/lib/algo/algo.mli
@@ -1,4 +1,4 @@
-(* Time-stamp: <modified the 09/04/2021 (at 10:39) by Erwan Jahier> *)
+(* Time-stamp: <modified the 27/08/2021 (at 14:37) by Erwan Jahier> *)
(** {1 The Algorithm programming Interface}
A SASA process is an instance of an algorithm defined via this
@@ -27,17 +27,18 @@ type 's step_fun = 's -> 's neighbor list -> action -> 's
need into this state (an integer, a structure, etc.). The only
constraint is that all algorithms should use the same type.
- - The second argument holds the process neighbors (its successors
- in the graph). Note that SASA processes, that live in graph nodes,
- can only access to their immediate neighbors. From each neighbor,
- a process can access to various information (cf [state], [reply],
- and [weight] functions below).
+ - The second argument holds the process neighbors it can read the
+ state of (i.e., its predecessors in the graph). Note that SASA
+ processes, that live in graph nodes, can only access to their
+ immediate neighbors. From each neighbor, a process can access to
+ various information (cf [state], [reply], and [weight] functions
+ below).
[enable_fun] returns the list of enable actions.
- [step_fun], which also takes an action in input, returns the new value
- of the local state resulting from the execution of the action.
-*)
+ [step_fun], which also takes an action in input, returns the new
+ value of the local state resulting from the execution of the
+ action. *)
type 's state_init_fun = int -> string -> 's
(** The initial value of the local state can be set using an
@@ -116,18 +117,23 @@ val links_number : unit -> int
val diameter : unit -> int
(** {3 Trees} *)
+
+(** a tree is an a-cyclic and connected graph (directed or not) *)
val is_tree : unit -> bool
+(** an in-tree is a _directed_ tree where all nodes have at most one _predecessor_ *)
val is_in_tree : unit -> bool
+(** an out-tree is a _directed_ tree where all nodes have at most one _successor_ *)
val is_out_tree : unit -> bool
-(** returns true if the graph is an undirected rooted tree
- (i.e. every node has exactly one parent except the root, which has none),
- false otherwise *)
-val is_rooted_tree : unit -> bool
+(** {3 Rooted Trees}
+ A rooted tree in a tree where one vertex is distinguished.
-(* The following 4 functions only work on rooted trees
- (in-trees and out-trees generated by gg are ok) *)
+ By convention, sasa considers a tree to be rooted if exactly one
+ node id contains the string "root".
+
+ The following 4 functions only work on rooted trees
+*)
(** maps each node to the size of the corresponding sub-tree *)
val sub_tree_size : string (* the node id *) -> int
@@ -142,6 +148,7 @@ val level : string (* the node id *) -> int
for the tree root. *)
val parent : string (* the node id *) -> int option
+val is_rooted_tree : unit -> bool
(** It is possible to set some global parameters in the dot file
using graph attributes. This function allows one the get their
--
GitLab