todo.org



Packages, modeles, etc.
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]

cd test; ./lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node2.lus

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 ? !!
  *)
mauvais numero de ligne lors d’erreur d’instanciation de parametres de noeud

  State “TODO”       from “”           [2012-12-21 Fri 10:58]

cd src; ../objlinux/lus2lic -vl 2 --nonreg-test should_fail/type/parametric_node.lus

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
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?
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
les (nouveaux) tests ne capturent pas les changements de # lignes dans les should_fail

  State “TODO”       from “”    [2013-01-11 Fri 11:15]

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.
Aesthetes issues
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.
Définir les fonctions de UglyStuff proprement

  State “TODO”       from “”           [2012-12-10 Mon 16:38]

file:~/lus2lic/src/uglyStuff.ml
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 ?
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]

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]

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]

le Eff.WITH (aka if statique) n’a pas lieu d’être !
y virer !!

  State “TODO”       from “”           [2012-10-26 Fri 14:59]

const_to_val_eff n’a vraiment rien à faire dans UnifyClock !!!

  State “TODO”       from “”           [2013-01-29 Tue 14:26]

file:src/unifyClock.ml::271
aucune fonction dans Lic.*_to_string ne devrait dependre des options de compil

  State “TODO”       from “”           [2013-02-01 Fri 17:54]

cf le XXX  file:src/lic.ml::655
Languages issues
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.
Rajouter le with à la caml pour les structures

  State “TODO”       from “”           [2012-10-26 Fri 14:59]

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

Divers