todo.org

lus2lic -exec

revoir l’intégration à rif_base et genlex

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

Unifier les modules Data de Lustre V6 et Lutin

• State “TODO” from “” [2013-04-02 Tue 08:33]

ie. rajouter les tableaux, struct, et enum en lutin quitte à ne pas s’en servir tout de suite.

Ca va facilité l’utilisation sans duplic de code du module rif_base

Integrer ce mode -exec dans lurette, à la facon dont je l’ai fait pour Lutin

• State “TODO” from “” [2013-03-30 Sat 14:35]

Question : comment j’integre ? via un lus2lic.a ?

file:~/lurette/source/common/lustreRun.mli

Trouver un moyen d’automatiser des tests

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

via lurette ? en comparant le mode -exec avec le résultat obtenu via ec puis ec2c

faudrait rajouter une option dans lurette qui, en cas de variables manquantes, genere le programme lutin qui va bien (loop true) plutot que de lancer luciole

–auto-stubs

Écrire un test qui mette en jeu exhaustivement tous les operateurs

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

fonctions externes

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

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

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

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]

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.

Divers

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

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]

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.

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

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.