Vos questions (et mes réponses)
Les accents
Nous sommes face à une difficulté qui n'a lieu que sous windows. Elle a
rapport à l'implémentation des accents.
Quand on rentre au clavier une lettre accentuée, elle n'est pas reconnue de
la même façon qu'une lettre accentuée du dictionnaire (le é est transformé
en ???). (Cela fait la même chose quand on lance la classe cat que vous nous
avez fourni sur le site internet, elle affiche les accents bizarrement).
Nous ne savons pas trop comment régler ce problème. Y a t'il une solution à
ce problème ?
Les caractères accentués ne sont pas représentés de la même façon en Unix
et en Windows. Dans les deux systèmes et dans un fichier texte chaque
caractère est codé sur 8 bits, mais les valeurs des caractères accentués
ne sont pas les mêmes dans les deux systèmes.
En Unix et en France, on a tendance, (mais c'est pas obligé) à les
représenter selon la norme ISO-8859-1 (dite aussi latin1) où le e
accent aigu est l'octet 233. En Window c'est autre chose (disons x).
Les fichiers-dictionnaires que je vous ai donnés sont en latin1. C'est à dire
que ce sont des suites d'octets dans lesquelles 233 représente le e
accent aigu.
En java les caractères sont représentés sur 16 bits (type char).
La valeur numerique du char qui représente e accent aigu est à priori une
troisième valeur y (mais il se trouve que c'est 233, bon).
Au moment de la lecture d'un fichier il s'opére une traduction 8 bits
vers 16 bits
qui dépend bien entendu de l'encodage adopté. Or le traducteur par défaut
sous Windows ne convient pas à mes fichiers.
Il y a deux solutions :
-
Transcoder mes fichier vers l'encodage Windows, à l'aide d'un
utilitaire quelconque, ou du programme
Cat modifié (voir ci-desous). - Lire le dictionnaire à l'aide de l'encodage adapté, qui doit
être spécifié explicitement. Par exemple, voici comment modifier
Cat.
Il faut remplacer la ligne 21 :
| BufferedReader b = new BufferedReader (new FileReader (o.dico)) ; |
par les lignes :
| // Ouvrir le fichier, o.dico, comme un flot d'octets (byte)
FileInputStream is = new FileInputStream (o.dico) ;
// Construire le flot de char, le traducteur est explicite
InputStreamReader rd = new InputStreamReader (is, "ISO-8859-1") ;
BufferedReader b = new BufferedReader (rd) ; |
Pour info, la démarche est expliquée rapidement dans la doc java,
au début de la page qui documente FileReader.
Un avantage majeur de donner explicitement l'encodage est que le programme
fonctionnera à la fois en Unix et Windows avec les mêmes dictionnaires
conventionellement codés en latin1.
Pour un fonctionnement sous Windows uniquement, il est logique de
transcoder nv.txt une fois pour toutes. Vous remarquerez que
le programme Cat modifié permet de transcoder le dictionnaire,
puisque l'affichage (System.out…) se fait à l'aide de
l'encodage par défaut. Votre programme fonctionnera alors en Unix et
Windows, mais avec des dictionnaires codés différemment.
L'option « -v »
Nous ne savons pas quels commentaires afficher sur le déroulement du
programme : nous ne nous en sommes pas du tout servi nous-même, et à
part afficher au fur et à mesure les mots créés par l'algorithme nous
ne voyons pas trop à quoi ça sert. Que désirez vous savoir sur le
déroulement du programme ?
Je suppose qu'il s'agit des commentaires à afficher quand on donne
l'option « -v » au programme.
Je n'utiliserai normalement pas cette option. Si j'ai
raconté tout ce baratin à propos des messages de diagnostic, c'est afin
de ne pas être gêné par ces messages quand j'exécuterai votre programme.
Donc si vous avez bien compris que votre programme doit envoyer son résultat
sur la sortie standard et rien d'autre, c'est l'essentiel.
Le rapport
Pour le rapport, nous pensions d'abord présenter la structure d'objets dont
nous nous sommes munis, puis expliquer les plus grosses méthodes, et mettre en
fin de rapport une mini-documentation sur les fonctions utilisées. Y'a-t-il
autre chose que vous souhaiteriez y voir ?
Deux principes (et demi) :
-
Ce qui m'intéresse c'est comment vous avez résolu le problème posé.
- J'ai lu l'énoncé.
- Le rapport n'a pas besoin d'être très long.
Donc en gros, ce que j'aime voir dans les rapports :
-
Description, de style algorithmique, de votre solution
(surtout si elle diffère des suggestions de l'énoncé).
- Description de haut niveau du programme. Un point intéressant est une
description des structures de données utilisées pour implémenter
les automates et les stocks de lettres, avec justification des choix.
- Détails de codage si vous les jugez dignes. En ce qui concerne
les « mini-documentation sur les fonctions utilisées », la bonne place
me semble un commentaire dans le source, si nous sommes d'accord sur
ce qu'est une documentation de méthode !
Mais ça peut dépendre, à vous de juger.
- Je suis preneur d'analyses du
comportement de votre programme (tests de correction, graphiques de
performance).
- Et pourquoi pas une analyse des difficultés rencontrées
et des solutions apportées (mais c'est plus pour l'oral en fait).
Par ex. si vous affichez des messages de diagnostic : à quoi
ont-il servi ? Si vous avez changé de structures de données en cours de
route pourquoi, comment ?
Ce que je n'aime pas voir dans les rapports :
-
Toute répétition exagérée de l'énoncé, en particulier l'interface
étant imposée, un manuel de l'utilisateur est inutile. Si vous
éprouvez le besoin d'en écrire un, ce n'est pas bon signe.
- Une copie du source du programme, puisque je l'aurai déjà par ailleurs.