todo.org

Types alias

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

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 suggerer 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_solcer

Packages, modeles, etc.

Il ne detecte plus les erreurs d’instanciation de modeles

• State “TODO” from “” [2012-12-21 Fri 11:08]

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

file:test/should_fail/type/parametric_node2.lus

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

pb d’instance de package ???

• State “TODO” from “” [2013-01-19 Sat 09:43]

./lus2lic { -o /tmp/packages.out should_work/broken/packages.lus} ./lus2lic -ec -o /tmp/packages.ec should_work/broken/packages.lus Error in file “/home/jahier/lus2lic/test/should_work/broken/packages.lus”, line 22, col 27 to 29, token ‘int’: syntax error

file:test/should_work/broken/packages.lus::22

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}

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

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

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 ?

Languages issues

Verifier les boucles combinatoires

quand on genere du ec (car ec2c ne fait pas la verif !) [2010-06-07 Mon]

On pourrait peut-etre le faire en modifiant celui la : file:src/l2lCheckOutputs.ml ?

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.

Merge is not working

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

Rajouter le with à la caml pour les structures

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

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]

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

Intégrer le résultat de mly2bnf dans le manuel

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