todo.org



Failures spotted by non reg tests (13)
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:’-

  ./lus2lic -o bug_map_fby.lic bug_map_fby.lus
    map<<fby, n>> pas supporté

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  :’-

  ./lus2lic -2c should_work/cond01.lus -n cond01
    the type of + in condact<<+,0>> is not inferred
  ./lus2lic -2c should_work/filter.lus -n filter
    a false cycle is detected

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:’-

  ../utils/test_lus2lic_no_node should_work/filter.lus
    spurious cycle detected (cf plus haut)
  ../utils/test_lus2lic_no_node should_work/Gyroscope.lus
  ../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
  ../utils/test_lus2lic_no_node should_work/cond01.lus
    cf plus haut (polymorphisme et iterateur)

lus2lic -2C
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
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 ?
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]

lic2c : Ca plante si un identificateur lustre se nomme double…

  State “TODO”       from “”           [2014-06-13 Fri 16:59]

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
lic2c : slice en partie gauche pas traitée

  file:test/should_work/morel.lus lus2lic -2c should_work/morel.lus -n morel
  file:test/should_work/morel2.lus lus2lic -2c should_work/morel2.lus -n morel2
  file:test/should_work/morel3.lus lus2lic -2c should_work/morel3.lus -n morel3
  file:test/should_work/morel4.lus lus2lic -2c should_work/morel4.lus -n morel4
  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)
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 ?
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.
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

  ./myec2c -o modes3x2_v4.c modes3x2_v4.ec
  ./myec2c -o modes3x2_v3.c modes3x2_v3.ec
    -> le merge de type enum n’est pas expansé.
  ./myec2c -o test_merge.c test_merge.ec
    -> genere un “when not clk” pas supporté pas ec

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 ? !!
  *)
fixer le commentaire “OBSOLETE ET UN PEU FAUX”
  file:/~/lus2lic/src/lic.ml::440
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
Quand tous les test sont ok: comprendre pourquoi test_lus2lic_no_node et rdbg divergent

  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
[#B] utiliser rdbg -lurette a la place de lurettetop dans les test de non reg

  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…
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é…
Écrire un test qui mette en jeu exhaustivement tous les operateurs

  State “TODO”       from “”           [2013-03-19 Tue 10:38]

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

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

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.
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
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.
lus2lic -ee -exec devrait utiliser des enums (a la ecexe)

  State “TODO”       from “”           [2013-05-07 Tue 16:36]

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
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
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.
lus2lic : reprendre unifyClock.ml proprement

  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
Soc2cIdent.key_op2str est faux

  State “TODO”       from “”           [2014-08-13 Wed 17:33]

Extern and ec
lus2lic should_work/decl.lus -n decl -ec
generates incorrect ec code instead of raising an error.
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’
le with devrait opérer sur une val_exp, pas sur un ident.

  State “TODO”       from “”           [2013-02-12 Tue 18:31]

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]

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

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

bon, y’a plus d’erreur, mais ca ne compile pas. Est-ce choquant ?
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.
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 !
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

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 (?)  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.
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
Fix ‘make rel-test’  in release-v6 dir
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
Generate macro for simple predef op in -2c mode.
Add a –2c-stack that favor the use of stack vs heap
indeed, currently, a soc call is done like that
set_input(ctx, i1);
step(ctx);
get_output(ctx,o1);

by using the stack, I mean something like
step(i,o);

in Soc2cextern.cpy_def: shouldn’t I use macro instead of function to be consistent ?
file:~/lus2lic/src/soc2cExtern.ml::28
I could even define a default version using memcpy as for arrays BTW.