Vous avez reçu un message "Your GitLab account has been locked ..." ? Pas d'inquiétude : lisez cet article https://docs.gricad-pages.univ-grenoble-alpes.fr/help/unlock/

TODO 5.24 KB
Newer Older
1
2
3
4
5
6

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


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

7

8

9
* Traiter les variables stables (signaux purs)
10

11
12
13
14
15
16
* 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
17
  (noeuds transiants/stationnaires + formula = ...)
18
19
20
21
22
23
24
25
26
27


(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 !!!

28
29
30
31
* 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.

32
33
34
* remplacer l'epaisseur de formules par un taux de couverture


35
36
37
38
39
40
41
* rajouter une option qui dit si les formules doivent etre tronquees
  dans show_luc



* Faire un gestionnaire de sessions comme le propose Pascal

42
43
44
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
  toutes les possxibilités), mais au moins, ca donnerais une solution
  dans des cas ou les polyedres peteraient...
 
49
50
51
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

* 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é.
78
  (cf code commenter dans store.ml)
79
80
81
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

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