#+TODO: TODO(!) STARTED(!) WAITING(!) | DONE(d!) CANCELED(c)
#+CATEGORY: lv6
* Failures spotted by non reg tests (13)
** TODO Front-end error (1)
- State "TODO" from "" [2014-08-26 Tue 10:20]
cat lus2lic*.log | grep "FAIL: without any option:" | sed s/'FAIL: without any option:'/-/
1. ./lus2lic -o bug_map_fby.lic bug_map_fby.lus
map<<fby, n>> pas supporté
** TODO soc2c (2)
- State "TODO" from "" [2014-08-26 Tue 10:20]
cat lus2lic*.log | grep "FAIL: Generate c code :" | sed s/'FAIL: Generate c code :'/-/
1) ./lus2lic -2c should_work/cond01.lus -n cond01
the type of + in condact<<+,0>> is not inferred
2) ./lus2lic -2c should_work/filter.lus -n filter
a false cycle is detected
** TODO Divergences -exec et ecexe (4)
- State "TODO" from "" [2014-07-11 Fri 16:54]
grep "FAIL:" lus2lic*.log | grep "exec" | grep "ecexe" | sed s/'FAIL: Try to compare lus2lic -exec and ecexe:'/-/
1) ../utils/test_lus2lic_no_node should_work/filter.lus
spurious cycle detected (cf plus haut)
2) ../utils/test_lus2lic_no_node should_work/Gyroscope.lus
3) ../utils/test_lus2lic_no_node should_work/Gyroscope2.lus
#ERROR: Output takes on nil
c'est le ec qui a l'air fautif, car j'arrive a reproduire
le pb avec ecexe et lus2lic -exec semble fonctionner
4) ../utils/test_lus2lic_no_node should_work/cond01.lus
cf plus haut (polymorphisme et iterateur)
* lus2lic -2C
** TODO lic2c : le jour ou on genere du code C, y'a peut-etre des trucs a recuperer
- State "TODO" from "" [2012-12-10 Mon 14:32]
chez Cedric Pasteur qui a une implementation pour optimiser la maj
des tableaux
http://www.di.ens.fr/~pouzet/bib/lctes12.pdf
** TODO lic2c : Ca plante si un identificateur lustre comporte un "'"
bin oui, ca n'est pas legal en C. Du coup je fais quoi ?
Je rejete ?
** TODO Reject file name that cannot be used to build valid C ident when using the -2c option
- State "TODO" from "" [2014-05-23 Fri 17:20]
** TODO lic2c : Ca plante si un identificateur lustre se nomme double...
- State "TODO" from "" [2014-06-13 Fri 16:59]
** TODO lic2c : types externes utilisés en I/O du main pas supportés
file:test/should_work/simple.lus lus2lic -2c should_work/simple.lus -n simple
types externes
faire comme pour _assign_EXT_TYPE en s'inspirant de ce que fait ec2c
** TODO lic2c : slice en partie gauche pas traitée
1. file:test/should_work/morel.lus lus2lic -2c should_work/morel.lus -n morel
2. file:test/should_work/morel2.lus lus2lic -2c should_work/morel2.lus -n morel2
3. file:test/should_work/morel3.lus lus2lic -2c should_work/morel3.lus -n morel3
4. file:test/should_work/morel4.lus lus2lic -2c should_work/morel4.lus -n morel4
5. file:test/should_work/left.lus lus2lic -2c should_work/left.lus -n left
Quand ca sera corrigé, rétablir les tests correspondant dans
file:~/lus2lic/test/site.exp (cf proc does_not_contain_left_slices)
** TODO lic2c : polymorphisme
- State "TODO" from "" [2014-07-09 Wed 17:13]
lus2lic -2c should_work/cond01.lus -n cond01
echoue aussi en mode exec.
Je devrais pourvoir accepter celui la, non ?
** TODO Question : remettre en cause le choix de représentation des Soc.key ?
- State "TODO" from "" [2014-06-27 Fri 15:29]
En effet, il ne reste plus que les ite à etre polymorphes, et c'est à cause des
soc polymorphes que je me trimbale le profile du soc dans les Soc.key !
par ailleur, l2lSplit ne devrait pas splitter les ites, si on veut
pouvoir faire l'optimisation qui consiste à n'executer qu'une des 2
branches si les noeuds ne font pas d'effet de bord.
** TODO nommage des soc à mémoires avec valeurs initiales
Pour distinguer les différentes instances de soc à memoire (arrow
et fby), j'utilise le hash de leur valeur initiale, ce qui est faux,
car hash n'est pas une injection.
Est-ce la bonne approche ? Une alternative serait de n'avoir qu'une
seule soc et de faire la bonne initialisation en passant la valeur
initiale en argument de la fonction reset.
Une autre solution serait d'utiliser un générateur de nom unique, par
exemple basé sur un compteur.
[...] sauf qu'en fait, la fonction de hash renvoie toujours la meme
valeur (bug) et que ca marche tres bien. Ce qui prouve bien que ca ne
sert a rien cette affaire.
* lus2lic -ec
** le merge n'est pas expansé et ecexe ne le connais pas
1. ./myec2c -o modes3x2_v4.c modes3x2_v4.ec
2. ./myec2c -o modes3x2_v3.c modes3x2_v3.ec
-> le merge de type enum n'est pas expansé.
3. ./myec2c -o test_merge.c test_merge.ec
-> genere un "when not clk" pas supporté pas ec
* Packages, modeles, etc.
** STARTED Il ne detecte plus les erreurs de type lors d'instanciation de noeuds
- State "STARTED" from "TODO" [2013-01-28 Mon 17:02]
cf échange de mails avec PAscal le 28/01/2013
- State "TODO" from "" [2012-12-21 Fri 11:08]
#+begin_src sh
cd test; ./lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node2.lus
#+end_src
file:test/should_fail/type/parametric_node2.lus
Ah bah oui, c'est écrit ici :
file:src/ast2lic.ml::202
(* NOUVELLE VERSION ÉPURÉE :
ON ne fait AUCUNE vérif de cohérence de types pour les param statiques,
on ne vérifie QUE la nature (pour pouvoir résoudre les args qui sont des idents
A FAIRE + TARD ? !!
*)
fixer le commentaire "OBSOLETE ET UN PEU FAUX"
file:/~/lus2lic/src/lic.ml::440
** TODO mauvais numero de ligne lors d'erreur d'instanciation de parametres de noeud
- State "TODO" from "" [2012-12-21 Fri 10:58]
#+begin_src sh
cd src; ../objlinux/lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node.lus
#+end_src
Opening file /home/jahier/lus2lic/test/should_fail/type/parametric_node.lus
Error in file "parametric_node.lus", line 4, col 17 to 17, token 'n':
can't eval type: bad array size, int expected but get real
le message serait meilleur s'il indiquait la ligne 17 où l'erreur est effectuée
file:src/astInstanciateModel.ml
file:test/should_fail/type/parametric_node.lus
* Testing process
** TODO Quand tous les test sont ok: comprendre pourquoi test_lus2lic_no_node et rdbg divergent
SCHEDULED: <2014-09-08 Mon>
- State "TODO" from "" [2013-12-10 Tue 13:37]
En fait, c'est le bis qui semble avoir raison à chaque fois
a voir quand j'aurais tous les tests qui passent
pour voir la liste des tests que échouent : file:~/lus2lic/test/lus2lic.sum
** STARTED [#B] utiliser rdbg -lurette a la place de lurettetop dans les test de non reg
SCHEDULED: <2014-11-03 Mon>
- State "STARTED" from "TODO" [2013-12-06 Fri 17:37]
- State "TODO" from "" [2013-11-27 Wed 18:18]
Pour cela, il suffit de modifier le fichier file:~/lus2lic/test/site.exp
ca marche, mais c'est plus lent (100->183s). c'est sans doute parce que
je passe par des sockets.
Il faudrait passer par des cmxs pour l'env et l'oracle, mais ca
complique un peu le script car il faut générer les bons cmxs.
[...]
Voila, je passe maintenant par des cmxs. Malheureusement, je passe à
300s car je passe pas mal de temps à generer ces cmxs, et comme je ne
fais que 10 step à chaque fois, c'est cet aspect qui domine...
Bon, sinon, si on regarde juste nested.lus, sur 10 pas, l'overhead a l'air
d'etre autour de 2%
Sur plus.lus pendant 10000 steps, j'ai
|--------------+------|
| rdbg -socket | 9:44 |
| rdbg -cmxs | 8:40 |
| lurettetop | 4:00 |
|--------------+------|
Sur nested.lus pendant 10 steps, j'ai :
|--------------+----------|
| rdbg -socket | 64s |
| rdbg -cmxs | 185s !!! |
| lurettetop | 53.3s |
|--------------+----------|
Comment c'est possible ce truc ???!!!
nested.ec possede certes plus de 7000 variables (dont pres de 6000
sont locales), du coup manipuler des listes n'aide pas. Mais c'est le
cas pour les 3.
Le mode socket ne transmet pas les var locales, d'ou la difference ?
Est-ce une bonne idée d'utiliser des listes d'ailleurs. au niveau des
mli, peut-etre. Mais je devrais peut-etre m'en affranchir plus vite
pour traiter ce genre d'exemple...
** TODO Testing node with enums don't work
- State "TODO" from "" [2013-05-28 Tue 14:46]
indeed, ec requires they are extern const, and lus2lic requires to have int
- one solution would be that -eei generates correct ec, by inlining constant
- I could also add enums in Lutin
Actually, I should do both...
../utils/test_lus2lic_no_node should_work/enum0.lus
en fait, l'option --gen-auto-test traduit les types enums en entier ; du coup
l'appel depuis l'oracle au noeud à tester est mal typé...
** TODO Écrire un test qui mette en jeu exhaustivement tous les operateurs
- State "TODO" from "" [2013-03-19 Tue 10:38]
** TODO try to compile the C code resulting from ec2c at some point
- State "TODO" from "" [2013-01-18 Fri 23:12]
in particular, are nodes using extern nodes generated properly?
** TODO les (nouveaux) tests ne capturent pas les changements de # lignes dans les should_fail
- State "TODO" from "" [2013-01-11 Fri 11:15]
** TODO Nommage des variables fraiches : Reprendre LicVarName.ml
- State "TODO" from "" [2013-01-16 Wed 18:03]
car c'est completement n'importe quoi (j'ai réussit a faire des clashs
entre les var inventées dans split et dans ExpandNodes !!)
Pascal a introduit un mecanisme qui shunte LicName -> en discuter avec lui.
** TODO Il faudrait traiter proprement les programmes lutin (et lustre) qui débordent (int)
- State "TODO" from "" [2013-05-10 Fri 17:28]
../utils/test_lus2lic_no_node should_work/test_node_expand.lus
../utils/test_lus2lic_no_node should_work/test_node_expand2.lus
** TODO au sujet des tests de non-regression
- State "TODO" from "" [2013-04-23 Tue 17:31]
Actuellement, test_lus2lic_no_node, je compare lus2lic -ec + ecexe et lus2lic -exec.
Ca serait bien de faire la meme chose en passant par lus2lic -lv4 +
lus2ec voir.
** TODO lus2lic -ee -exec devrait utiliser des enums (a la ecexe)
- State "TODO" from "" [2013-05-07 Tue 16:36]
** TODO le test des programmes packagés ne fonctionne pas
- State "TODO" from "" [2013-05-10 Fri 10:52]
modifer
file:~/lus2lic/utils/test_lus2lic_no_node
** TODO quand une assertion est violée dans ecexe, ca fait des trucs zzardbi dans lurette
- State "TODO" from "" [2014-09-04 Thu 13:46]
par exemple, decommenter le assert dans file:test/should_work/test_node_expand2.lus
et lancer
/home/jahier/lus2lic/test/../utils/test_lus2lic_no_node should_work/test_node_expand2.lus
il dit 'A SUT input is missing: o1'
tout en cachant la vraie erreur (assert error)
* Divers
** TODO lv4 enum types are not compatible with lutin ones
- State "TODO" from "" [2014-03-28 Fri 15:49]
For lv6, it's ok, so, well...
I'd need to add support for enums in Lutin to fix this one.
-> Or the -eei option could do something else (inlining const definition)
indeed, -ec -eei generates ec code that is not syntactically correct for ecexe.
Should I do this (const inlining) with 'ec -eei only ? it seems fair enough
-> Other idea. Go though V4 and lus2ec.
** TODO lus2lic : reprendre unifyClock.ml proprement
SCHEDULED: <2014-11-10 Mon>
- State "TODO" from "" [2013-09-24 Tue 16:35]
cf file:~/lus2lic/src/unifyClock.ml
http://www.cs.cornell.edu/courses/cs3110/2011sp/lectures/lec26-type-inference/type-inference.htm
** TODO Soc2cIdent.key_op2str est faux
- State "TODO" from "" [2014-08-13 Wed 17:33]
** TODO Extern and ec
lus2lic should_work/decl.lus -n decl -ec
generates incorrect ec code instead of raising an error.
** TODO Revoir le nommage des instances de noeuds parametriques
par ex, pour should_work/NONREG/param_struct.lus
ca invente des noms bien débiles du point de vue du nom du pack.
Style 'mk_tab__param_struct::toto_toto_3'
alors qu'aucun package ne s'appelle 'mk_tab__param_struct'
** TODO le with devrait opérer sur une val_exp, pas sur un ident.
- State "TODO" from "" [2013-02-12 Tue 18:31]
** TODO l2lCheckOutputs.ml Unbound value VarMap.bindings
en mode cross-win32 car pas defini en 3.11
- State "TODO" from "" [2013-02-22 Fri 08:27]
** TODO Découper un peu les fonctions dans src/lic2soc.ml
- State "TODO" from "" [2013-03-19 Tue 10:26]
le role et le perimetre get_leaf en particulier n'est pas clair.
de plus son code est dupliqué.
file:src/lic2soc.ml
** TODO pb sur le GYRO : bug dans le prog ou dans le compilo ???
- State "TODO" from "" [2013-05-31 Fri 16:30]
../utils/test_lus2lic_no_node should_work/Gyroscope2.lus
../utils/test_lus2lic_no_node should_work/Gyroscope.lus
si je lance ecexe dessus, j'obtiens un
"#ERROR: Output takes on nil"
au step 3
Mais curieusement, via lus2lic -exec, je n'ai pas de soucis.
* Pas clair
** WAITING Regarder si on pourrait se passer du PREDEF_CALL (et de passer par le CALL normal)
- State "WAITING" from "STARTED" [2013-02-06 Wed 17:14]
- State "STARTED" from "TODO" [2013-02-06 Wed 17:14]
- State "TODO" from "" [2012-10-26 Fri 14:59]
cf file:./src/lic.ml::206
Mouais. C'est pas clair. Si on regarde par exemple ici :
file:src/ast2lic.ml:407
On voit qu'on n'y fait pas le même traitement.
À voir avec Pascal.
** TODO Dans file:src/eff.ml::195 on pourrait virer la notion de call by name
qui ne sert que pour les structures. Mais au niveau du Eff, on
pourrait s'en être débarrassé au profit d'un appel par position. A
faire au moment de la compilation des expressions.
question : est-ce que cela nous prive d'une optim pour le traitement
du with ?
comment fait caml ?
- State "TODO" from "" [2012-10-26 Fri 14:59]
** TODO operateurs iterables
- State "TODO" from "" [2012-03-30 Fri 17:03]
- mettre dans la doc
- voir si on ne pourrait pas completer la liste
en mettant tous les operateurs unaires de
file:~/lus2lic/src/syntaxTreeCore.ml::91
dans
file:~/lus2lic/src/predef.ml::62
- tout au moins, eviter les assert false sur
#+BEGIN_CENTER lustre :exports bug_map_fby.lus
type state = struct {
idy : int;
leader : int;
level : int
};
const n=5;
const inits = [
state { idy = 33; leader = 5; level = 2} ,
state { idy = 41; leader = 5; level = 3} ,
state { idy = 21; leader = 5; level = 4} ,
state { idy = 10; leader = 10; level = 0} ,
state { idy = 75; leader = 75; level = 0}
] ;
const O = false;
const I = true;
const connect = [
[ O, I, O, O, I ],
[ I, O, I, O, O ],
[ O, I, O, I, O ],
[ O, O, I, O, I ],
[ I, O, O, I, O ]
];
node algo (clk: bool; ps: state; neigh: bool^5) returns (ns: state);
let
ns = if clk then
state { idy = ps.idy ; leader = ps.leader; level = ps.level + 1 }
else
state { idy = ps.idy ; leader = ps.leader; level = ps.level };
tel
node simu(ck:bool^5) returns (s: state^n);
var ps : state^n;
let
ps = map<<fby, 5>>(inits, s);
s = map<<algo, n>> (ck, ps, connect);
tel
#+END_CENTER
bon, y'a plus d'erreur, mais ca ne compile pas. Est-ce choquant ?
** TODO Verifier les boucles combinatoires meme quand on ne genere pas de ec
- State "TODO" from "STARTED" [2013-01-29 Tue 09:49]
./lus2lic should_fail/semantics/deploop.lus
On pourrait utiliser file:src/misc.ml pour prendre finement en compte les
struct et les arrays.
** TODO Faut-il jeter ces self loop ? Sans doute pas.
- State "TODO" from "" [2013-05-10 Fri 17:44]
../utils/test_lus2lic_no_node should_work/filter.lus
../utils/test_lus2lic_no_node should_work/activation2.lus
../utils/test_lus2lic_no_node should_work/activation1.lus
../utils/test_lus2lic_no_node should_work/speedcontrol.lus
solution :
l2lSplit: split access of access in left parts.
indeed, consider the following example:
z.y.y = z.x.x;
which is fine. But if we transform it into
z.y.y = v0.x;
v0 = z.x;
we have a cycle !!!
but what if we split further, it's fine again
v1 = z.y
v1.y = v0.x;
v0 = z.x;
-> split more !
** TODO Enlever Abstract_type_eff de Lic.type_ ou vérifier partout que c'est correct.
- State "TODO" from "" [2012-12-20 Thu 17:26]
dans lic.ml, on definit les types compilés ainsi :
and type_ =
| Bool_type_eff
| Int_type_eff
| Real_type_eff
| Abstract_type_eff of Ident.long * type_
| Array_type_eff of type_ * int
...
Mais est-ce vraiment utile de garder le Abstract_type_eff à ce niveau ?
en effet, ca oblige à traiter les 2 cas en permanence (par ex lors des
transfos l2l).
Pascal suggere carrément de
- definir un type
#+begin_src ocaml
type type_ref of string
#+end_src
- transformer les expressions lic de telle sorte que il n'y ait plus
de type_ mais juste des type_ref
Car en fait, actuellement, le type Lic.type_ sert à faire la verif de
type et a representer le type des expressions lic. Du coup le type
des expressions est inutilement compliqué; d'ou l'idée d'avoir juste
des "type_ref of string" (Ce qui simplifiera (?) le travail des
passes ultérieures, style lic2c).
Bon, je ferai ca quand tous les tests fonctionneront et pendant que
j'essairais de me passer de ulglyStuff/id_solver. A voir aussi ce qui
sera le plus pratique quand je me remettrai à bosser sur le
lic2c/licexe
Autre idée : Dans LicPrg, ne plus utiliser de Lic.type_ mais des
LicPrg.type_ (=string)
+ une table LicPrg.type_ -> Lic.type au cas où
l2lAliasTypes fait plus au moins le boulot. Faudrait intergrer cette
passe à la fonction qui construit le LicPrg initial.
boarf ; ca fait beaucoup de bazard pour pas grand chose. Ce qui
simplifierait les choses pour la suite, c'est de ne plus avoir de
Lic.type_ du tout dans les val_exp et autre.
Autre idée : je fais ca lors du passage à la structure de données
suivante (soc). Oui, ca fait du sens. en plus, les l2l* utilisent les
infos Lic.type_, donc autant attendre un peu avant de s'en passer.
** TODO C'est normal qu'il se plante au step 2 celui la ???
- State "TODO" from "" [2013-05-31 Fri 16:42]
../utils/test_lus2lic_no_node should_work/sincos.lus
* a classer
** TODO bug clock tim
- State "TODO" from "" [2013-09-23 Mon 11:13]
donc c'est file:~/lus2lic/src/l2lExpandNodes.ml le coupable on dirait
en effet, quand on ne branche que l'expansion de noeud
~/lus2lic/objlinux/lus2lic ~/xxx/test.lus -n verify -en > xxx.ec
on obtient
uw1:bool when cw; ici 3
_u1_5:bool when cr; ici 1
puis
_u1_5 = uw1;
ce qui ne peut pas marcher...
===> creating _uw1_1 from uw1 with clock on true(cw) on base
===> creating _u1_5 from u1 with clock on true(cr) on base
uw1 : bool when cw;
u1 : bool when cw;
c'est donc _u1_5 qui n'est pas sur la bonne horloge ?
a l'appel de
OK2 = (mem(cr, ur1) = mem(cw, uw1));
ne se prendrait-il pas les pieds dans le tapi ?
car _u1_5 est créé lors de l'un de ces 2 appels
[...]
bon, si dans mem je renomme cw en clk, ca marche !!!
c'est un probleme de clash de nom de variable !!!
[...]
Finalement, le pb est plutot la il semblerait :
file:~/lus2lic/src/evalClock.ml::83
** Willie's wishes
I would like suggestion something to be added in the C code generation part
of the v6 compiler.
*** Generate a copy of memcpy and replace the sizeof operator with the actual size of the structure.
It seems that the "assert" operator will generate "array" structure where
the number of the element depending on the
number of the arguments to the "assert". The generated C code tries to make
a copy of this structure with
memcpy and giving sizeof(the_structure_to_copy) as the argument.
Since OTAWA does not handle memcpy, could you generate a version of memcpy
(contains a for loop) for each memcpy call.
(Or just to paste the for loop to replace the memcpy call), while the
iteration count of the for loop is given (in actual value)
so that ORANGE can handle it.....
The followings were raised by Pascal:
*** The expansion of nodes with -efn --expand-following-nodes [easy]
the current available options are:
-en, --expand-nodes
Expand the main node (use the first node if no one is
specified).
-den, --do_not-expand-nodes <string>
Do not expand the specified node (meaningful with -en only of
course).
It might be better if another option such as -efn --expand-following-nodes
<string>
The nodes which are not in the string will not be expanded.
*** A option to inline the simple nodes such as AND, OR, NOT etc.