Outils

Hot Line

Pour toutes vos questions techniques
  • Concernant les systèmes de gestion de versions Git : Hot Line Git
  • Concernant Java : Hot Line Java
  • Concernant Caml : Hot Line Caml
  • Indiquez impérativement dans le sujet du message :

    [PLRICM3] numéro du groupe : thème de la question

Outils de gestion de version

Un système de gestion de version est un outil indispensable pour la gestion sûre de développements en équipe.

Il vous sera très utile pour ce projet et toute votre carrière pour le travail coopératif ou même le travail personnel dès lors que vous souhaitez archiver automatiquement les versions précédentes.

Un tel système maintient une version partagée, stable, de chacun des fichiers, permet de gérer les modifications, revenir en arrière, gérer les tentatives parallèles, les fusionner, ...

Il en existe un grand nombre de système de gestion de version. Vincent Danjean suit de près les évolutions des systèmes de gestion de version afin de vous présenter le plus stable, le plus utilisé intégrant les dernières nouveautés. En 2011, c'est Git.
  • git : présentation de git réalisée par Vincent Danjean

Biblothèques graphiques pour Java

  • JavaFx : une révolution dans le domaine des interfaces graphiques (intégré par défaut dans NetBeans)
  • Swing : pour l'interface graphique
  • Jgraph : pour dessiner des graphes

Parsers en Ocaml

Un analyseur syntaxique (parser en anglais) est une fonction qui prend en entrée un flux de caractères (ie. une liste, une chaîne, un flot ou un fichier de caractères) et qui retourne une structure de données qui correspond à l'analyse du flux de caractères à condition que le contenu du flux respecte une certaine grammaire.

Tous les compilateurs commencent par parser le fichier source pour analyser le programme à traduire en langage machine. L'analyse du programme fonctionne uniquement si le programme respecte la syntaxe du langage : c'est cette convention d'écriture partagée par le programmeur et le compilateur qui leur permet de se comprendre. Et si vous ne respectez pas cette convention le parser s'arrête sur le terrible reproche : syntax error !

Comment éviter d'avoir à écrire un parser (si on est pressé par le temps et pour une version prototype)

  • L'idée
    1. fournissez vos données sous la forme d'une structure de données OCaml
    2. codez en Ocaml les fonctions de traduction des données vers le format de sortie souhaité
    3. utilisez le parser et l'interprète ocaml pour traduire les données dans le format de sortie souhaité

  • C'est la bonne façon de faire pour un prototype : elle permet de manière peu couteuse de pouvoir traiter des données dans des fichiers

  • Exemple: génération de liste au format html avec numérotation automatique des items

    translate.ml, input1.ml, input2.ml

Comment réaliser un parser (si vous avez le temps et pour une version professionelle de votre logiciel)

Le principe générale de conception d'un parser est toujours le même quels que soient le langage et les outils d'implantation utilisés :
  1. On définit la grammaire des expressions à reconnaître
  2. On affine le grammaire afin qu'elle soit non ambigüe c'est à dire qu'on doit pouvoir décider en lisant 1 caractères dans quel cas on se trouver (ie. quelle règle de la grammaire on doit appliquer). En RICM4 vous verrez des extensions où l'on décide après la lecture de k-caractères.
  3. Ensuite on étend la grammaire avec des attributs qui construisent le résultat souhaité (en générale une structure de donnée bien organisée).
  4. On construit un parser pour la grammaire, ie. une fonction récursive de type flux -> structure de donnée qui implante la grammaire attribuée.
  5. En général pour se faciliter la tâche, on conçoit des parsers de bases pour les identificateurs, les entiers, les espaces, les opérateurs, ... ; ensuite on les combine pour construire des parsers plus complexes. Enfin, ce n'est pas obligatoire mais c'est partique, on peut définir des opérateurs de combinaisons de parsers, appelés combinateurs, comme par exemple :
    • la séquence de deux parsers p1 et p2, notée p1 <.> p2
    • le choix ordonné entre deux parsers p1 et p2, noté p1 <|> p2
    • l'itération d'un parseur p (l'étoile des expressions régulières) noté: (star p) ou (some p)
    • on peut en définir bien d'autres selon les besoins, comme le choix non déterministe noté <+> qui essaie tous les parsings possibles en cas d'ambiguités, ....
    • Au début on trouve ça difficile, une fois qu'on y a gouté on ne peut plus s'en passer.
Voici deux version d'implantation de parsers qui peuvent vous servir de point de départ:
  1. La version déterministe [det_parser.ml] nécessite que votre grammaire ne soit PAS ambigüe! Cette version présente aussi des exemples de définition de combinateurs et leur utilisation qui rend l'écriture de parsers drastiquement plus simple.
  2. La version non déterministe [nondet_parser.ml] accepte les grammaires ambigües. Cette version est une extension de la précédente qui explore tous les parsings possibles : le résultat du parser est alors une liste des parsings possibles du flux d'entrée :
    • La liste peut être vide si le flux ne respecte la grammaire ; autrement dit [] = syntax error
    • La liste ne contient qu'un résultat si le parsing du flux d'entrée n'était pas ambigü.
    • La liste contient plusieurs parsings possibles si l'anlyse du flux d'entrée est ambigüe.
Responsable: Michaël PÉRIN