sasa issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues2021-08-04T11:35:34+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/23Sasa does not stop execution on the first legitimate state on unison2021-08-04T11:35:34+02:00Gwennan EliezerSasa does not stop execution on the first legitimate state on unisonI would expect Sasa to stop at the first legitimate state as it does with Dijkstra ring. However, even on the `make test`, it doesn't. As you can see, the second step is already legitimate, but the execution went through the whole 5 step...I would expect Sasa to stop at the first legitimate state as it does with Dijkstra ring. However, even on the `make test`, it doesn't. As you can see, the second step is already legitimate, but the execution went through the whole 5 steps is had as timeout threshold. Maybe sasa should return an error when no legitimate state is encountered instead of exiting with 0 (except with an option maybe, otherwise the test2 would be unreproducible without an error).
```sh
$ make test1
sasa -l 5 fig41.dot -sd -rif
[sasa] The sasa random engine seed is set to 876107293
====> The Graph Diameter is 3
#inputs
#outputs "p1_c":int "p2_c":int "p3_c":int "p4_c":int "p5_c":int "p6_c":int "p7_c":int "p8_c":int "Enab_p1_g":bool "Enab_p2_g":bool "Enab_p3_g":bool "Enab_p4_g":bool "Enab_p5_g":bool "Enab_p6_g":bool "Enab_p7_g":bool "Enab_p8_g":bool "p1_g":bool "p2_g":bool "p3_g":bool "p4_g":bool "p5_g":bool "p6_g":bool "p7_g":bool "p8_g":bool
#seed 876107293
1 2 1 6 3 2 4 1 t f t t t f t t t f t t t f t t
2 2 2 2 2 2 2 2 t t t t t t t t t t t t t t t t
3 3 3 3 3 3 3 3 t t t t t t t t t t t t t t t t
4 4 4 4 4 4 4 4 t t t t t t t t t t t t t t t t
5 5 5 5 5 5 5 5 t t t t t t t t t t t t t t t t
6 6 6 6 6 6 6 6 t t t t t t t t t t t t t t t t
#q
```https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/22Sasa can stack overflow in the toy example sum2021-08-02T09:53:23+02:00Gwennan EliezerSasa can stack overflow in the toy example sumGiven the following dot file, sasa has a stack overflow when launching:
```dot
graph test {
graph [min_deg=1
mean_deg=1.5
max_deg=2
is_connected=true
is_cyclic=false
is_tree=true
links_number=3
is_rooted=false]
root [algo="p.ml...Given the following dot file, sasa has a stack overflow when launching:
```dot
graph test {
graph [min_deg=1
mean_deg=1.5
max_deg=2
is_connected=true
is_cyclic=false
is_tree=true
links_number=3
is_rooted=false]
root [algo="p.ml" init="{pid=root ; input=12}"]
p1 [algo="p.ml" init="{pid=p1 ; input=5}"]
p2 [algo="p.ml" init="{pid=p2 ; input=10}"]
p3 [algo="p.ml" init="{pid=p3 ; input=3}"]
p1 -- p2
p1 -- root
p2 -- p3
}
```
After deleting everything that wasn't tracked in `sasa/test/toy-example-sum` on master, here is my execution:
```
$ make test.cmxs
sasa -reg test.dot
[sasa] The sasa random engine seed is set to 933869547
[sasa] The file test.ml has been generated
[sasa] Warning: state.ml already exist.
[sasa] Warning: config.ml already exist.
[sasa] Hint: you may wish to generate test.cmxs out of test.ml with:
[sasa] ocamlfind ocamlopt -package algo -shared state.ml p.ml config.ml test.ml -o test.cmxs
[sasa] The sasa random engine seed is set to 472782834
ocamlfind ocamlopt -bin-annot -package algo -shared state.ml p.ml config.ml test.ml -o test.cmxs
$ sasa test.dot
[sasa] The sasa random engine seed is set to 704438567
# Automatically generated by /home/neogalaxy/.opam/ocaml-base-compiler.4.12.0/bin/sasa version "4.6.0-34-g9a7813d" ("9a7813d")
# on neogalaxy-FeelPad-MK02 the 2/8/2021 at 9:49:13
#sasa test.dot
#seed 704438567
#inputs
#outputs "root_input":int "root_sub":int "root_res":int "p1_input":int "p1_sub":int "p1_res":int "p2_input":int "p2_sub":int "p2_res":int "p3_input":int "p3_sub":int "p3_res":int "Enab_root_S":bool "Enab_root_Rr":bool "Enab_root_Rp":bool "Enab_p1_S":bool "Enab_p1_Rr":bool "Enab_p1_Rp":bool "Enab_p2_S":bool "Enab_p2_Rr":bool "Enab_p2_Rp":bool "Enab_p3_S":bool "Enab_p3_Rr":bool "Enab_p3_Rp":bool "root_S":bool "root_Rr":bool "root_Rp":bool "p1_S":bool "p1_Rr":bool "p1_Rp":bool "p2_S":bool "p2_Rr":bool "p2_Rp":bool "p3_S":bool "p3_Rr":bool "p3_Rp":bool potential:real
Stack overflow
q
#quit
%!
```
I have no idea on how to debug this.https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/21Sasa does not check if trigger is enabled2021-07-30T16:25:36+02:00Gwennan EliezerSasa does not check if trigger is enabledSasa does not check if each trigger is in the list of the enables. Shouldn't we implement it (with maybe an option that disable this check for perfs)? If not, should we then implement it into the explorers to be sure that the explorers o...Sasa does not check if each trigger is in the list of the enables. Shouldn't we implement it (with maybe an option that disable this check for perfs)? If not, should we then implement it into the explorers to be sure that the explorers outputs valid executions?https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/14Change the graph created by "gg BA" on the m0 first nodes.2019-07-12T09:37:59+02:00Gwennan EliezerChange the graph created by "gg BA" on the m0 first nodes.In the [Barabási-Albert model](https://en.wikipedia.org/wiki/Barab%C3%A1si%E2%80%93Albert_model), we need a arbitrary graph of m0 nodes, to start with, and the only constraint is that each node has an edge (i.e. link to a neighbor). For ...In the [Barabási-Albert model](https://en.wikipedia.org/wiki/Barab%C3%A1si%E2%80%93Albert_model), we need a arbitrary graph of m0 nodes, to start with, and the only constraint is that each node has an edge (i.e. link to a neighbor). For the moment, in the graph generated by using `gg BA ...`, the base graph is a star of m+1 nodes.
The goal is to change this base graph, allowing the user to choose the graph they want, and to set the base graph to a clique by default.
Stephan Devismes suggested to use the following syntax to allow the user to choose the graph they want :
`m0:(a1,a2);(b1,b2);(c1,c2)...`
with `m0` being the number of nodes, and `(a1,a2)` meaning there's a link between the node of index `a1` and the one of index `a2`https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/6Add options to prevent algo to access to forbidden information2021-07-27T11:05:44+02:00erwanerwan.jahier@univ-grenoble-alpes.frAdd options to prevent algo to access to forbidden informationFor instance, some algo should work without being allowed to access to:
- the identity of the neighbor (cf the `pid` field of `Algo.neighbor` vars)
- the possibility for a neighbor to access to the channel number of a process (the `reply...For instance, some algo should work without being allowed to access to:
- the identity of the neighbor (cf the `pid` field of `Algo.neighbor` vars)
- the possibility for a neighbor to access to the channel number of a process (the `reply` field of `Algo.neighbor` vars)erwanerwan.jahier@univ-grenoble-alpes.frerwanerwan.jahier@univ-grenoble-alpes.frhttps://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/5Allow the simulation to have inputs2019-07-03T11:38:09+02:00erwanerwan.jahier@univ-grenoble-alpes.frAllow the simulation to have inputsRequire to add a(n optional) `Algo.reg_inputs` function which would be similar `reg_vars`.
Then of course one could use Lutin to provide sasa such inputsRequire to add a(n optional) `Algo.reg_inputs` function which would be similar `reg_vars`.
Then of course one could use Lutin to provide sasa such inputshttps://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/2The generated synchronous Lutin demon is wrong2019-07-03T10:40:15+02:00erwanerwan.jahier@univ-grenoble-alpes.frThe generated synchronous Lutin demon is wrongIndeed, sasa -gld generates something like that
```lutin
loop
(Enab_p1_a = p1_a) and (Enab_p1_b = p1_b) and (Enab_p1_c = p1_c) and
(Enab_p2_a = p2_a) and (Enab_p2_b = p2_b) and (Enab_p2_c = p2_c) and
(Enab_p3_a = p3_a) and (Enab_p3_b...Indeed, sasa -gld generates something like that
```lutin
loop
(Enab_p1_a = p1_a) and (Enab_p1_b = p1_b) and (Enab_p1_c = p1_c) and
(Enab_p2_a = p2_a) and (Enab_p2_b = p2_b) and (Enab_p2_c = p2_c) and
(Enab_p3_a = p3_a) and (Enab_p3_b = p3_b) and (Enab_p3_c = p3_c) and
(Enab_p4_a = p4_a) and (Enab_p4_b = p4_b) and (Enab_p4_c = p4_c)
```
whereas exactly one rule should be activated an the same step in the same algo
```lutin
loop
(xor(Enab_p1_a = p1_a, Enab_p1_b = p1_b, Enab_p1_c = p1_c)) and
(xor(Enab_p2_a = p2_a, Enab_p2_b = p2_b, Enab_p2_c = p2_c)) and
(xor(Enab_p3_a = p3_a, Enab_p3_b = p3_b, Enab_p3_c = p3_c)) and
(xor(Enab_p4_a = p4_a, Enab_p4_b = p4_b, Enab_p4_c = p4_c))
```https://gricad-gitlab.univ-grenoble-alpes.fr/verimag/synchrone/sasa/-/issues/1Generate a Lutin node implementing a central demon2019-06-20T13:59:17+02:00erwanerwan.jahier@univ-grenoble-alpes.frGenerate a Lutin node implementing a central demon