Projet de programmation impérative : Spacer (2011-2012)
Survol du projet
Le but de ce projet est de pouvoir se promener dans le code d'un gros projet en offrant différents outils à cet effet. Le plus visible d'entre eux doit être la génération de fichiers HTML contenant le code présenté de façon visuelle et interactive.
L'outil (ou l'ensemble d'outils) fourni devra permettre de lire les fichiers source d'un projet et d'en extraire des informations comme le fichier et le numéro de ligne auquel est défini un identificateur, puis de fournir à partir de cette brique de base des services comme : afficher les lignes autour de la définition d'un identificateur, afficher tout le code d'une fonction de nom donné, générer des fichiers HTML avec des liens hypertextes pour tous les identificateurs connus, etc...
L'outil (ou l'ensemble d'outils) fourni devra permettre de lire les fichiers source d'un projet et d'en extraire des informations comme le fichier et le numéro de ligne auquel est défini un identificateur, puis de fournir à partir de cette brique de base des services comme : afficher les lignes autour de la définition d'un identificateur, afficher tout le code d'une fonction de nom donné, générer des fichiers HTML avec des liens hypertextes pour tous les identificateurs connus, etc...
Quelques spécifications et idées supplémentaires
_Le langage visé est uniquement le langage C, et votre logiciel
fera l'hypothèse que le source est correct. Il ne garantira rien si le
code source n'est pas du C ou s'il contient des erreurs de
syntaxe. Aussi, vous devrez analyse le code source, mais cette analyse
doit être minimaliste : vous devrez savoir détecter les
commentaires, les mots-clés, et trouver les identificateurs. Vous
utiliserez des heuristiques comme "si un identificateur est suivi
d'une parenthèse ouvrante, et qu'on rencontre une accolade ouvrante
avant un point-virgule, c'est probablement la définition de la
fonction associée", ou le plus drastique "si un identificateur
commence une ligne, c'est la définition de la fonction associée".
Les noms des fichiers HTML devront être choisis soigneusement pour qu'ils ne changent pas quand on ré-exécute l'outil sur des versions similaires du code source (utiliser le nom du fichier source dans le nom du fichier HTML est probablement une bonne idée, dupliquer la hiérarchie des répertoires aussi).
Les fichiers HTML ne devront pas dépendre du serveur HTTP les servant, aussi il n'est pas demandé depuis les pages HTML de fournir un formulaire de recherche d'un identificateur arbitraire (pas de scripts CGI ou d'Ajax). En revanche, l'outil s'exécutant dans le shell devra offrir la fonctionnalité de recherche d'un identificateur et affichera l'URL relative où trouver l'identificateur. Par exemple : src/tools/main-c.html#usage. Ceci permettra facilement de demander à un navigateur de se placer sur un identificateur souhaité.
L'utilisation de code Javascript est encouragée pour fournir des fonctionnalités comme "cacher les commentaires" ou "ne pas afficher le corps d'une fonction" etc. En revanche, il faudra vérifier que lorsque l'exécution de code Javascript n'est pas activée, les fichiers HTML ont un rendu acceptable et utilisable. L'utilisation de feuilles de style en cascade est possible et encouragée.
Comme le projet doit être réalisable sans utiliser l'allocation dynamique, il est parfaitement accepté de fixer des bornes aux quantités comme la taille des identificateurs possibles, le nombre d'identificateurs possibles dans un programme, etc. En revanche, ces limites seront très probablement atteintes par certains gros projets et en conséquence, votre programme doit se comporter grâcieusement pour l'utilisateur lorsqu'il rencontre une de ces limites. De plus, votre code devrait être architecturé pour que ces limites puissent facilement être levées (autrement dit, l'utilisation des maximaux doit être concentrée dans le moins d'endroits possible).
Une idée utile serait de pouvoir fournir le code d'une seule fonction dans un bloc HTML suffisamment propre et peu intrusif pour pouvoir être incorporé tel quel dans une page HTML existante.
Vous pouvez aussi choisir de sortir des fichiers dans d'autres formats que HTML si vous le souhaitez (LaTeX ou Texinfo par exemple).
Les identificateurs inconnus pourront être redirigés vers l'URL d'une page de manuel supposée existante, ou bien vous pourrez maintenir une base de données de quelques fonctions C standard pour mener vers leur page de manuel quand on clique dessus.
Vous pourrez aussi implémenter une fonctionnalité qui permet à votre outil de générer un fichier de tags pour se substituer au choix à ctags ou à etags. Indépendamment de la sortie ou non dans ces formats, il est probablement une bonne idée pour l'efficacité de maintenir la table des emplacements des identificateurs dans un fichier à réutiliser d'une fois sur l'autre.
Pour la génération HTML, toutes les idées qui rendront la navigation plus agréable sont bienvenues. La coloration syntaxique devra être désactivable au moins par une option en ligne de commande, peut-être en fournissant des CSS différents.
Les noms des fichiers HTML devront être choisis soigneusement pour qu'ils ne changent pas quand on ré-exécute l'outil sur des versions similaires du code source (utiliser le nom du fichier source dans le nom du fichier HTML est probablement une bonne idée, dupliquer la hiérarchie des répertoires aussi).
Les fichiers HTML ne devront pas dépendre du serveur HTTP les servant, aussi il n'est pas demandé depuis les pages HTML de fournir un formulaire de recherche d'un identificateur arbitraire (pas de scripts CGI ou d'Ajax). En revanche, l'outil s'exécutant dans le shell devra offrir la fonctionnalité de recherche d'un identificateur et affichera l'URL relative où trouver l'identificateur. Par exemple : src/tools/main-c.html#usage. Ceci permettra facilement de demander à un navigateur de se placer sur un identificateur souhaité.
L'utilisation de code Javascript est encouragée pour fournir des fonctionnalités comme "cacher les commentaires" ou "ne pas afficher le corps d'une fonction" etc. En revanche, il faudra vérifier que lorsque l'exécution de code Javascript n'est pas activée, les fichiers HTML ont un rendu acceptable et utilisable. L'utilisation de feuilles de style en cascade est possible et encouragée.
Comme le projet doit être réalisable sans utiliser l'allocation dynamique, il est parfaitement accepté de fixer des bornes aux quantités comme la taille des identificateurs possibles, le nombre d'identificateurs possibles dans un programme, etc. En revanche, ces limites seront très probablement atteintes par certains gros projets et en conséquence, votre programme doit se comporter grâcieusement pour l'utilisateur lorsqu'il rencontre une de ces limites. De plus, votre code devrait être architecturé pour que ces limites puissent facilement être levées (autrement dit, l'utilisation des maximaux doit être concentrée dans le moins d'endroits possible).
Une idée utile serait de pouvoir fournir le code d'une seule fonction dans un bloc HTML suffisamment propre et peu intrusif pour pouvoir être incorporé tel quel dans une page HTML existante.
Vous pouvez aussi choisir de sortir des fichiers dans d'autres formats que HTML si vous le souhaitez (LaTeX ou Texinfo par exemple).
Les identificateurs inconnus pourront être redirigés vers l'URL d'une page de manuel supposée existante, ou bien vous pourrez maintenir une base de données de quelques fonctions C standard pour mener vers leur page de manuel quand on clique dessus.
Vous pourrez aussi implémenter une fonctionnalité qui permet à votre outil de générer un fichier de tags pour se substituer au choix à ctags ou à etags. Indépendamment de la sortie ou non dans ces formats, il est probablement une bonne idée pour l'efficacité de maintenir la table des emplacements des identificateurs dans un fichier à réutiliser d'une fois sur l'autre.
Pour la génération HTML, toutes les idées qui rendront la navigation plus agréable sont bienvenues. La coloration syntaxique devra être désactivable au moins par une option en ligne de commande, peut-être en fournissant des CSS différents.
Critères d'évaluation
_Le nombre de fonctionnalités que vous aurez été capables de réaliser
ne sera pas un indicateur fiable de votre note. Le fait de réaliser
plus de fonctionnalités permet principalement de se convaincre que
votre logiciel est écrit de manière extensible. Mieux vaut peu de
fonctionnalités, mais un logiciel prêt à accueillir des extensions,
que beaucoup de fonctionnalités empilées les unes sur les autres dans
un code illisible.
Nous lirons le code que vous aurez écrit.
Nous lirons le code que vous aurez écrit.