llia_phon

["Roger.Mampey" <Roger.Mampey@cert.fr>]

Bonjour,

Après discussions à l'Oxford et équipée à Bordeaux, voilà comment je vois la 
suite des opérations en ce qui me concerne.

Mon objectif principal est de revenir à FranFest, c'est-à-dire utiliser les 
données rassemblées par Frédéric Béchet pour remplacer le lexique de 6Mo 
actuellement indispensable à FranFest. Ca ne signifie pas abandonner Llia_Phon 
mais je rappelle que FranFest avait seulement été mis en sommeil. 

On s'était également entendu sur le fait que la version actuelle de LLia_Phon 
était caractérisée par le fait qu'on ne touchait pas à la structure des fichiers 
de données de Frédéric. Jusqu'ici, on a seulement éliminé le passage par 
certains fichiers dérivés (précompilés) mais la logique des évolutions sur 
Llia_Phon nous conduit à faire un peu plus pour les fichiers de données 
statistiques. Comme tous ces fichiers de données doivent être conçus comme 
variables au cours du temps (ajout/retrait d'entrées dans les lexiques, de 
règles dans les catalogues, modification des données statistiques), il vaut 
mieux spécifier une bonne fois le contenu de ces fichiers, les liens qu'ils ont 
entre eux (lexiques et données statistiques) ainsi que les opérations de 
pré-compilation indispensables si une modification doit être faite.

Même si la structure superficielle des fichiers n'est pas la même pour FranFest 
et pour Llia_Phon, ce travail de spécification est identique dans les 2 cas.

Ca donne en gros, et dans cet ordre :

1/ Blocage des évolutions sur la version courante de Llia_Phon, ce qui ne 
signifie pas qu'il n'y a plus rien à y faire, j'en parle plus bas.

2/ Création d'une nouvelle version de FranFest. Ce qui nécessite de voir de plus 
près comment la version courante a été intégrée dans Oralux par Pierre Lorenzon.

3/ Création d'une nouvelle version de Llia_Phon. Outre la redéfinition des 
fichiers de données, il faudrait peut-être aussi étudier de plus près la 
possibilité de passer à une structuration client/serveur.

En ce qui concerne le point 1/ il y a, à mon sens, 2 choses à faire avant de 
considérer la version courante comme intéressante à "porter" sous Windows ou 
Apple ou Sun ou ...

a/ Fournir une autre prosodie et donner à l'utilisateur la possibilité de les 
paramétrer (j'ai vu la vitesse que Nath et David estiment raisonnable alors 
qu'elle n'est pas modifiable dans la version courante). On n'aura pas une 
prosodie satisfaisante avant un bout de temps si un linguiste (prosodiste de 
surcroit) ne nous rejoint pas, mais on peut faire mieux que ce qu'on a. 
   Je vise fin janvier au plus tard sur ce point.

b/ Faire la chasse aux sources d'erreurs dans le code. Il y en a au moins 3 qui 
vont demander un certain travail, vous allez sans doute en trouver d'autres.

*/ Eliminer tous les appels aux fonctions de gestion des chaines ascii qui   
ignorent les lettres accentuées (isupper, tolower, ...). Remplacer par les 
fonctions fr_ introduites récemment dans util.c

*/ Eliminer toutes les lectures de fichier qui présupposent une organisation 
binaire particulière en mémoire (suite à la remarque de Franz à l'Oxford). Après 
enquête, il en reste pas mal dans l'étiquetage grammatical.

*/ Eliminer tous les risques de débordements de tableau et de pointeurs non 
définis. Ca, c'est un gros boulot, il y a des réservations à la louche un peu 
partout dans le code et il y a déjà eu au moins un bug de débordement corrigé de 
façon complétement supercielle.
   Pour l'instant, je vise aussi fin janvier sur ce point (avec l'aide de Phil   
   évidemment).
   
Pour évaluer une date au plus tard sur le point 2/ il faut que je me replonge un 
peu dans Festival. Une date vraiment au plus tard serait fin juin mais il y 
faudrait une résistance inattendue. Quant au point 3/ je pense qu'il va 
progresser au même rythme que le 2/ en ce qui concerne les modifications sur les 
fichiers de données.

   	Roger