todo.org

#+TODO: TODO(!) STARTED(!) WAITING(!) | DONE(d!) CANCELED(c)
#+CATEGORY: lv6

* lus2lic -exec

** TODO Extern node not yet supported

oops: lus2lic internal error
   - State "TODO"       from ""           [2013-05-13 Mon 08:11]

../utils/test_lus2lic_no_node should_work/decl.lus
	File "objlinux/lic2soc.ml", line 870, column 14
 when compiling lustre program should_work/decl.lus


../utils/test_lus2lic_no_node should_work/simple.lus
	File "objlinux/socExec.ml", line 202, column 22
 when compiling lustre program should_work/simple.lus

** pb gen-autotest
../utils/test_lus2lic_no_node should_work/plus.lus
 + ./lus2lic _plus_oracle.lus -n plus_oracle -lv4 -eei -en --no-prefix -o lv4_plus_oracle.lus

 Error in file "/home/jahier/lus2lic/test/_plus_oracle.lus", line 6, col 28 to 28, token '=':
 tuple size error: 
 the tuple size is
	4 for the left-hand-side, and 
	1 for the right-hand-side (in c_bis,d_bis,e_bis,f_bis = a + b)

et aussi :
../utils/test_lus2lic_no_node should_work/bred.lus
../utils/test_lus2lic_no_node should_work/alias.lus
../utils/test_lus2lic_no_node should_work/bred_lv4.lus
../utils/test_lus2lic_no_node should_work/minus.lus


** TODO Lurette trouve un mismatch sur ce prog au step 0
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]
../utils/test_lus2lic_no_node should_work/exclusion.lus
../utils/test_lus2lic_no_node should_work/mapdeRed.lus
../utils/test_lus2lic_no_node should_work/matrice.lus
../utils/test_lus2lic_no_node should_work/over2.lus
../utils/test_lus2lic_no_node should_work/mapiter.lus
../utils/test_lus2lic_no_node should_work/arrays.lus
../utils/test_lus2lic_no_node should_work/nested.lus    

** TODO Lurette trouve un mismatch sur ce prog au step 1
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]

../utils/test_lus2lic_no_node should_work/pipeline.lus

** TODO Lurette trouve un mismatch sur ce prog au step 2
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]
../utils/test_lus2lic_no_node should_work/X2.lus
../utils/test_lus2lic_no_node should_work/cond01.lus

** TODO Lurette trouve un mismatch sur ce prog au step 7
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]

 ../utils/test_lus2lic_no_node should_work/call07.lus

** TODO Lurette trouve un mismatch sur ce prog au step 6
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]

file:test/should_work/deSimone.lus 

../utils/test_lus2lic_no_node should_work/deSimone.lus

** TODO Lurette trouve un mismatch sur ce prog au step 0
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]
file:test/should_work/predefOp.lus
../utils/test_lus2lic_no_node should_work/predefOp.lus

** TODO Lurette trouve un mismatch sur ce prog au step 2
   - State "TODO"       from ""           [2013-05-10 Fri 17:08]
../utils/test_lus2lic_no_node should_work/test.lus


** TODO fonctions externes  pas supportées en mode -exec (ni dans les tests du coup)
   - State "TODO"       from ""           [2013-03-19 Tue 10:33]
* 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 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     

** 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 Fix a bug occurring using -en and -esa together.
   - State "TODO"       from ""           [2013-04-24 Wed 09:22]

#+begin_src sh
./lus2lic _assertion_oracle.lus -n assertion_oracle   -en  -esa
#+end_src

*** Error in file "/home/jahier/lus2lic/test/_assertion_oracle.lus", line 38, col 3 to 7, token 'v02_1':
*** 
*** Variable _0v02_1_1 is already defined.
#+end_src

-> on verra ca quand les autres  test passeront ; je ferai alors une passe
complete qur le nommage des variables fraiches.

** 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 lus2lic genere du ec mal typé !!
   - State "TODO"       from ""           [2013-05-10 Fri 17:24]

 ../utils/test_lus2lic_no_node should_work/predef03.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 Le test de noeuds qui ont des types enum ne fonctionne pas
   - State "TODO"       from ""           [2013-04-24 Wed 10:12]

../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 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

* Performances
Ceux là sont particulierement long (dont certains vraiment sans raison)
en fait, quand ecexe se plante (oracle), il bloque tout le monde...

# of unresolved testcases	20

../utils/test_lus2lic_no_node should_work/left.lus 
../utils/test_lus2lic_no_node should_work/assertion.lus
../utils/test_lus2lic_no_node should_work/normal.lus
../utils/test_lus2lic_no_node should_work/Gyroscope2.lus
 ../utils/test_lus2lic_no_node should_work/ELMU.lus
 ../utils/test_lus2lic_no_node should_work/aux.lus
../utils/test_lus2lic_no_node should_work/X1.lus
../utils/test_lus2lic_no_node should_work/alarme.lus
../utils/test_lus2lic_no_node should_work/onlyroll2.lus
../utils/test_lus2lic_no_node should_work/integrator.lus
../utils/test_lus2lic_no_node should_work/over2.lus

* Divers

** TODO msg d'erreur un peu mavais sur ce programme

#+begin_src lustre
node argos_oracle(a:bool;b:bool;s0:bool;s1:bool;s2:bool) returns(ok:bool;s0_bis:bool;s1_bis:bool;s2_bis:bool);
let
  (s0_bis,s1_bis,s2_bis) = argos(a,b);
s0=s0_bis;
  s1=s1_bis;
  s2=s2_bis;
tel;
#+end_src

** TODO ce noeud ne compile pas en mode -ec
   - State "TODO"       from ""           [2013-04-17 Wed 15:51]

#+begin_src lustre
node trivial3(e: int ^2) returns (x: int ^6);
var
  c: int ^6;
let
  c = e|e|e;
  x[0..2] = c[3..5];
  x[3..5] = c[0..2];
 
tel
#+end_src

** TODO lic2c -ec ne genere pas du ec correct en présence de merge
   - State "TODO"       from ""           [2013-05-15 Wed 10:14]
./lus2lic -ec should_work/test_merge.lus 


** 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 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

* 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 la aussi il semble y avoir un pb de self loop
   - 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


** WAITING Ya un probleme avec ce fichier lustre (compilait avant)
   - State "WAITING"    from "STARTED"    [2013-01-17 Thu 10:48]
   - State "STARTED"    from "TODO"       [2013-01-17 Thu 10:48]
file:test/should_work/call/call04.lus

il semble y avoir une confusion entre parametre et arguments lors
d'appels de noeuds définis via des itérateurs de tableau

idem pour
file:test/should_work/fab_test/morel2.lus
et pleins d'autres. hm, y'aurait pas d'itérateurs dans celui la.

-> ok  : c'était à  de l2lAliasType (que  j'ai déranché du  coup) qui
faisait  que les  types lic  n'étaient plus  uniques et  du coup  les
substitutions  dans  l'expansion  des  noeuds ne  se  faisaient  plus
correctement.

je met en attente en attendant de savoir ce qu'on fait de ce module.
moi j'ai bien envie de virer AbstractType de Lic.type_. En effet, j'avais 
fait attention à tous les virer pour éviter les soucis, mais le plus 
propre c'est d'y virer vraiment. 

Pascal lui, s'en  est servi pour faire des types  alias, alors que ca
n'est pas fait pour. Cela dit, si  on créé des types alias, on risque
d'avoir le meme genre de soucis. A quoi ca sert d'avoir de tels types
?  pour moi le role de la compil ca serait plutot de les virer que de
les rajouter, mais bon. A discuter. cf point d'apres

** 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.