TODO 5.38 KB
Newer Older
1 2 3 4 5 6

*********** BUGS


*********** A faire maintenant 

7

8 9 10
* Messages d'erreurs par terribles dans le parseur quand :
  - il manque une virgule
  - il y a une erreur dans l'un des mots clefs de champs
11

12
* Traiter les variables stables (signaux purs)
13

14 15 16 17 18 19
* gen_fake_lutin devrait etre une commande lurettetop et non pas code
  en dur dans xlurette... 
  idem pour la sauvegarde des options dans .lurette-rc.


* Mettre a jour le parseur wrt les modifs que j'ai faite a la syntax
20
  (noeuds transiants/stationnaires + formula = ...)
21 22 23 24 25 26 27 28 29 30


(1) Portage pour scade et esterel windows ...
 -> structure, tableau, types structures, etc.

(2) Faire une doc utilisateur pour lurette (moins urgent depuis qu'il y
  a lurettetop et xlurette...)

* Inferer la croix, plutot que de verifier !!!

31 32 33 34
* La notion d'epaisseur est mal branlée, surtout en presence de var
  numériques. Il faudrait un 3eme parametre sui dit le nombre 
  de tirage que l'on fait dans chaque polyedres.

35 36 37
* remplacer l'epaisseur de formules par un taux de couverture


38 39 40 41 42 43 44
* rajouter une option qui dit si les formules doivent etre tronquees
  dans show_luc



* Faire un gestionnaire de sessions comme le propose Pascal

45 46 47 48
* Si jamais on a à faire a des polyedres trop gros, on pourrait
  peut-etre chercher a remettre en cause les choix qui ont été faits
  lors des egalités (ie, le choix de la variable à substituer). Ce calcul
  coute peut-etre un peu cher (car, comment faire autrement qu'essayer
49
  toutes les possibilités), mais au moins, ca donnerais une solution
50 51
  dans des cas ou les polyedres peteraient...
 
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

* zipper et dezipper les .rif a la vollée (cf zlib)

* giro : 
 -> Il faudrait rajouter la possibilité de faire, par ex, des 
    tirages selon une loi normale pour les variables a générer.
 -> En faire un plus realiste


* Rajouter les pragmas suivants :
 -> #locals v* (pour pouvoir les mettre en vert)
 -> #lucky_seed
 -> #test_failure


* Finir le fichier README. Faire un fichier INSTALL.



* utiliser Unix.create_process plutot que Sys.command partout !!


* autoconf : 
 -> tester si gtk est la


* inclure ocaml.opt et camlidl dans la distrib ???

* Chercher a detecter des egalites lors de l'ajout d'une inegalité.
81
  (cf code commenter dans store.ml)
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178

* xlurette :
  - bouton sim2chro ; mettre les locales en vert -> pragma dans sim2chro !!


* Trouver un controlleur non buggé pour pouvoir mettre un oracle 
  qui n'arrete pas le processus...


*********** Cosmétisme

* appeler lurette lurette_exe ???

* changer le nom du type formula en Formula.t (faire pareil partout)
  ce qui devrait permettre d'enlever tout plein de <<open Formula>>

* Le type node n'a rien a faire dans le module formula ...
  de meme pour arc_info. Les mettre dans un module type par exemple.


*********** Performances

* Pour le train, que je fais le produit de tous les environnements,
  j'ai quand meme un pb de perf que je n'avais pas avant. Regarder
  pourquoi (cf version 0.68). D'une maniere générale, Graph.t est elle
  vraiment la bonne structure de donnees pour les sous-graphes ?

* Profiler, profiler, profiler, ...
        o En particulier, verifier que ca ne se casse pas la gueule avec
          un grand nombre de variables, ou bien avec de tres grosses 
          formules.
        o Faire un passage sur le code pour voir si je n'aurais pas
          du utiliser Map plutot que Hashtbl a un certain nombre
          d'endroits...
        o Utiliser une table de hash pour env_state.pre, ou bien
          alors separer les entiers, les reels et les booleans. Parce
          que, tel quel, la recherche des pre peut couter bien cher
          avec beucoup de variables...

*********** A faire  

* LURETTE_PATH n'est peut-etre pas le bon nom. LUCKY_PATH ?

* Ecrire une baterie de test plus sérieux !

* Ecrire un papier qui explique la transformation en automate.

* Gerer proprement les histoires d'évaluation numérique (en creant un
  module numeric, qui, éventuellement, appelle du C) ??


* Réfléchir à une version d'un tireur sans bdd ou les choix seraient
  effectués pendant le parcours de la formule (pas d'équité, mais bon) +
  backtracking quand ca n'est pas satisfiable. Le gros pb a priori 
  est que les probas vont dépendre de la structure de la formule.


* Tirage équitable dans un polyèdre ; projeter dans un espace de
  meme dimension que le polyhedre (quitte à faire un changement de
  variable) puis tirer dans le cube enveloppant.

* Faire un passage pour rendre tail recursive les fonctions qui le méritent.

* dans gne.ml, rajouter partout assertion <<is_a_partition>>


*********** Moins urgent
 
* Tout passer sous noweb ?

* Tirer partis des numeros de lignes (ou de caracteres) associés
  aux formules quand lutin saura les générer. Pour cela, il faut
  que le try rende également la formule utilisé (au moins en mode
  --step-by-step).

* Reconnaitre les extensions des arguments du sut pour
  éventuellement appeler lustre (ou esterel...) si nécessaire

***********************************************************************
*** ??? LIST


* Rajouter un parametre q pour spécifier le nombre de tirage pour
chaque variable numérique ??

* Ajouter les options --use-big-int et --use-float (quoique ...)

* Ne pas lancer sim2chro avec un "... &" mais avec un fork et un exec.

* Faire un passage sur les champs de env_state
   - remplacer le champ `var_names' par `in_var_names' `out_var_names' et 
     `loc_var_names' 
   - Enlever le champ `graph' qui n'est plus utilisé une fois les tables
     construites.