Mr. Guitton

But du projet :


• Réaliser un sous ensemble d'OpenGL et voir ce que LISP peut apporter â un tel projet.



• Analyser les performances obtenues et vérifier que l'on a des résultats raisonnables.



• Vérifier que LISP est un langage adapté â ce type de développement graphique.

Mr. Strandh

• Utilisation de CLX pour l'affichage



• Voir dans OpenGL les facilités que peut apporter l'utilisation de Lisp et des avantages des macros par exemple.



• Des blocs sont définis par GL_begin et GL_end, pour OpenGL il n'y a pas de vérification (erreurs lors de l'exécution) tandis que Lisp permettra cette vérification lors de la compilation. On appelle cela la vérification syntaxique statique, il faut donc mettre en avant cet interêt de Lisp (l'extension syntaxique).



• La réunion â permis de voir que l'utilisation de CLOS pour la réalisation du projet n'était pas recommandée.



• Le mémoire est jugé en fonction du choix des outils, des techniques et des langages, il faut discuter le choix des outils dans le rapport.



• Outils de gestion de version :
  • rcs: simple
  • cvs: mieux (marche sur machines distantes)
  
  
• Debuggage : dur â voir



• Profiler : chercher un gprof



• Discuter le choix de Lisp, ne pas poser tel quel le choix du langage, il faut le justifier.



• Mr. Narbel nous a laissé une grande liberté sur le sujet du projet. Il faut donc savoir la gérer, c'est â dire, ne pas se lancer dans un gros projet. Il faut la qualité et non la quantité.



• Points importants :
  • maintenabilité
  • pas de duplication de code



• Méthode de travail :
  • pas de conditions de performances, écriture propre plutôt souhaitée.
  • analyse de performance
  • lecture de la doc CMU
  • s'il y a de réels problèmes de performances, on essaie de faire moins performant
  
  
• Chercher un debugger qui analyse un code compilé



• Chercher des outils de couverture : permet de vérifier si toutes les lignes de code ont été exécutées au moins une fois. ATTENTION, cela ne prouve pas la cohérence du programme, mais il faut tout de même le faire.
  Si on ne trouve pas d'outil semblable, il faut tout de même en parler dans les différents rapports.



• Faire des comparaisons entre CMU-CL, Allegro, Arlequin pour Common LISP : le meilleur Carnegie-Mellon Universty Common Lisp.



• Conseil : détecter au plus vite les grosses erreurs et en faire part â Mr. Strandh, communiquer les idées par e-mail.



• Remarques : l'avantage de notre projet est que l'on part d'un noyau réalisable que l'on incrémente au fur et â mesure.



• Calendrier : besoin du cahier des charges d'abord, on ne doit pas donner la priorité au code ou sinon pour s'entrainer un peu. Le cahier des charges n'est pas regardé â la fin du projet, souvent il ne correspond plus. Mais il faut le suivre â la lettre si on veut faire quelque chose d'utilisable.



• 75% des projets ne sont pas utilisés donc le cahier des charges sert surtout â réfléchir au sujet sèrieusement.



• Matrice : se limiter a des floats pour le contenu des matrices, on va gagner ainsi en efficacité par rapport au C. En effet, il faut absolument typer au maximum pour que cela ne pose plus de problème par la suite.