todo.org

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



* 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 ? !!
   *)

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

** TODO instanciation de noeuds ne marche pas ? 
   - State "TODO"       from ""           [2013-01-19 Sat 10:02]
./lus2lic -o /tmp/multipar.out should_work/broken/multipar.lus
file:test/should_work/broken/multipar.lus::20
 Error in file "/home/jahier/lus2lic/test/should_work/broken/multipar.lus", line 20, col 12 to 12, token 'g':
 unknown node: g
 known nodes are: sil, bok, gup, lis

FAIL: without any option: ./lus2lic {    -o /tmp/multipar.out should_work/broken/multipar.lus} 
** 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'


* Testing process
** TODO try to compile the C code resulting from ec2c at some point
   - State "TODO"       from ""           [2013-01-18 Fri 23:12]
in particuler, are nodes using extern nodes generated properly?

** TODO fix unresolved tests (timeout -> performance bugs)
   - State "TODO"       from ""           [2013-01-11 Fri 11:04]

par ex,  file:./test/should_work/ec.lus prend  un temps  infini alors
qu'il n'est pas si gros (y'a  500 variables, mais bon).  bon, en fait
il prend 26 seconds, ce qui n'est  pas infini, mais bien long tout de
meme.

nb: c'était deja le cas avant les changements de Pascal.

cf file:test/lus2lic.gprof
69% du temps est passé dans unify clock !!!!!
 
J'ai l'impression que  c'est lié au fait que ce  programme ne definit
que  des  contantes.   Or  les constantes  sont  potentiellement  sur
n'importe quelle horloge, ce qui fait que l'algo manipule un gros paquet
de 'clock_var of int' et que l'on passe beaucoup de temps à faire des 
apply_substs2

cf file:test/perf/ contenant les resultats de gprof et ocamlprof sur ec.lus

** 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 Certains programmes dans should_fail n'echouent qu'en ec (ou bien c'est ec2c) ou l'inverse
   - State "TODO"       from "STARTED"    [2013-01-23 Wed 18:26]
du coup les stats sont un peu fausses. a revoir.
par ex file:test/should_fail/semantics/sincos.lus n'echoue qu'en mode -ec
(et pour l'instant il n'est testé qu'en mode lic)


* Aesthetes issues
** 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 Définir les fonctions de UglyStuff proprement
   - State "TODO"       from ""           [2012-12-10 Mon 16:38]
file:~/lus2lic/src/uglyStuff.ml

** TODO Refaire une passe pour virer une fois pour toute cette histoire d'idref dans Eff.
    cf file:/~/lus2lic/src/eff.ml line 189
QU: Pascal l'a fait ?
    


* Languages issues

** TODO Verifier les boucles combinatoires meme quand on ne genere pas de ec
On pourrait utiliser   file:src/misc.ml pour prendre finement en compte les 
struct et les arrays.

** TODO Merge is not working
** TODO Condact is not working
 file:test/should_work/broken/cond01.lus
   - State "TODO"       from ""           [2013-01-18 Fri 23:18]
 ./lus2lic -ec -o /tmp/cond01.ec should_work/broken/cond01.lus

 oops: lus2lic internal error
	File "objlinux/l2lExpandMetaOp.ml", line 310, column 4
 when compiling lustre program should_work/broken/cond01.lus          

** TODO Rajouter le with à la caml pour les structures
  - State "TODO"       from ""           [2012-10-26 Fri 14:59]

** 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 on devrait se passer de 'static_arg list' pour le champ =PREDEF_CALL= 
(c'est censé marcher)
cf file:./src/eff.ml::206
  - State "TODO"       from ""           [2012-10-26 Fri 14:59]

** TODO L'ideal serait de se passer du PREDEF_CALL (et de passer par le  CALL normal)
  - State "TODO"       from ""           [2012-10-26 Fri 14:59]

** TODO le Eff.WITH (aka if statique) n'a pas lieu d'être !
y virer !!
  - 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


* Divers
** STARTED   Intégrer le résultat de mly2bnf dans le manuel 
** 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



* Types alias   
** 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 vie 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 à c'était cause de l2lAliasType  qui faisait que les
types lic n'étaient  plus uniques et du coups  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
transfo llic2lic).

Pascal suggere carrément de 
- definir un type type_ref of string 
- 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 la 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 vois aussi ce qui
sera  le  plus  pratique  quand  je me  remettrai  à  bosser  sur  le
lic2c/licexe