Actualité du Projet GL 2010

De Ensiwiki
Aller à : navigation, rechercher
AttentionCette page est obsolète. Elle a été utilisée pour le Projet GL 2010, et n'est gardée que pour mémoire

Utilisation de cette page

Il est impératif de consulter régulièrement cette page. Une solution simple est de la mettre comme page d'accueil de votre navigateur pour la durée du projet. Sinon, vous pouvez aussi utiliser un des flux suivant :

Atom: https://ensiwiki.ensimag.fr/index.php?title=Actualit%C3%A9_du_Projet_GL_2010&feed=atom&action=history
RSS: https://ensiwiki.ensimag.fr/index.php?title=Actualit%C3%A9_du_Projet_GL_2010&feed=rss&action=history

(A donner à un agrégateur RSS comme Thunderbird, Feedly, netvibes, ... Voir par exemple ces explications pour suivre un fil RSS depuis Thunderbird). La page Ensiwiki:Suivre les modifications du wiki sur ce Wiki donne quelques informations supplémentaires.

Les Nouvelles

25/01/2010 : Rappels sur les consignes de rendu

Nous vous rappelons que les documentations utilisateur et le bilan doivent être ajoutés dans l'archive (cf. A_Rendre.txt) dans le répertoire Docs/ et au format PDF. Ces documentations sont ramassées automatiquement, si vous ne respectez pas les noms de fichiers imposés, nous ne pourons pas récupérer les documents.

24/01/2009 : Derniers conseils pour la fin du projet

A l'approche de la date de rendu, voici quelques conseils pour bien terminer le projet :

Des maintenant :

  • On peut se donner une discipline plus stricte sur ce qui va dans l'archive (si vous ne l'avez pas déjà). Par exemple, ne commiter (ou ne faire un push) que si tous les tests de non-regression passent. Une bonne idee est de supprimer toutes les traces de debug et de se fixer comme règle de ne plus commiter de code avec le debug active (on active les traces emporairement dans sa copie locale si besoin).

Avant le dernier commit :

  • S'assurer que toutes les traces sont supprimées, y compris les affichages d'arbres, de programmes decompiles et d'exceptions levees.
  • Recompiler et re-executer tous les tests pour être sûr que le programme rendu ne regresse pas.
  • Faire un clone du projet ailleurs que ~/Projet_GL/ (en ayant supprimé/renommé le ~/Projet_GL/ original), verifier que ça compile, et que "make check" passe toujours. Cela permet de verifier entre autres que :
    • il n'y a pas de chemins codes en dur ;
    • les fichiers de l'archive sont suffisants.

De preference, ce clone doit être fait par chacun des membres de l'equipe.

Beaucoup d'étudiants ont des chemins en dur (~/Projet_GL/.../*.deca par exemple) dans leurs scripts, donc c'est un point a ne pas négliger.

Preparation de la soutenance :

  • Bien travailler (entre autres) le bilan, en particulier l'organisation du projet.

20/01/2010 : Format des messages d'erreur

Beaucoup d'étudiants posent la question du format précis du message d'erreur du compilateur. Decac.txt donne ce format, mais voici quelques précisions pour être sûr que vos compilateurs passeront correctement dans nos scripts de tests :

  • Les messages « Line » au lieu de « Ligne » sont acceptés.
  • Il doit y avoir au moins un espace entre « Ligne » et le numéro de ligne.
  • Il peut y avoir un nombre quelconque d'espaces entre « Ligne » et « : ».
  • Le message qui suit le « : » est essentiel pour l'utilisateur humain, mais ignoré par nos scripts.

En d'autres termes, vos messages doivent correspondre à l'expression régulière '^[Ll]ig*ne *[0-9][0-9]* *:'.

19/01/2010 (ter) : ATTENTION changement de dates de remises

Report de la date de remise de la version intermédiaire (version bêta)

La version intermédiaire devra être remise pour jeudi 21 janvier à 10h00. C'est la version de l'archive à cette heure là qui sera prise en compte.


Nouvelle consigne pour la remise du bilan

Afin de permettre aux enseignants SME qui assureront les soutenances (et dont certains n'auront d'ailleurs pas participé aux suivis) d'étudier votre bilan avant la soutenance, la date de rendu du bilan est avancée.

Vous devrez rendre votre bilan en format PDF, dans l'archive sous Docs/Bilan.pdf, pour le mercredi 27 janvier à 9h00.

Ces consignes remplacent celles définies dans Introduction.txt p I-1 et pour le bilan en II-40 (qui demandait une remise le jour de la soutenance).

19/01/2010 (bis) : Quelques conseils pour le rendu intermédiaire

Le rendu intermédiaire sera ramassé automatiquement dans votre archive partagée Git jeudi matin, à 10h00.

Quelques conseils :

  • Vous assurer en priorité que les choses simples marchent.
  • Relisez bien Decac.txt, et vérifiez que vous êtes conformes à la spécifications pour les options en ligne de commande (les options -v et -p sont très utilisées par notre infrastructure de tests en particulier).
  • Assurez-vous que vous n'avez pas de traces de debug activées (Put_Line sauvages, Mise_Au_Point, ...)
  • Vérifiez que le code qui se trouve dans l'archive partagée marche, en refaisant un git clone et en testant le résultat.

Profitez de ce rendu intermédiaire pour vous mettre d'accord sur la procédure à suivre pour faire un rendu sans faute : le prochain rendu sera décisif !

19/01/2010 : Rectification sur le barème de la notation SME

Dans le message précédant du 13/01/2010, Précisions sur le barème de la note « Gestion de projet », nous annoncions un point « Evaluation par les membres du groupe » noté sur 3 points dans l'évaluation SME.

En fait, cette auto-évaluation est expérimentale cette année, et ne sera pas appliquée dans tous les groupes. Les étudiants sont donc invités à suivre les consignes que l'enseignant SME de leur groupe leur a donné à l'oral ou par email. Si vous n'avez pas eu de consignes autre que le message du 13/01 sur ce wiki, c'est que vous n'êtes pas concernés.

18/01/2010 : Problème avec gcov

Certains étudiants ont des problèmes avec gcov, qui ne trouve pas les fichiers .gcno. Un problème fréquent est d'avoir fait make gcovclean, qui a effacé ces fichiers, et qui ne sont pas régénérés par le prochain make gcov. Une solution a été appliquée sur ensibm, ceux qui travaillent chez eux peuvent appliquer la modification sur init.make :

diff --git a/Etudiants/Global/init.make b/Etudiants/Global/init.make
index da0a0cc..94f686c 100644
--- a/Etudiants/Global/init.make
+++ b/Etudiants/Global/init.make
@@ -222,7 +222,6 @@ yacc: ${SYN_ADB}
 clean: cleanobj
 
 realclean: cleanobj gcovclean
-       $(MAKE) GCOV=gcov cleanobj
        $(AT)for use in ${USES} ${COUR} ; do \
            cd ${ROOT}/$${use}/Src && \
            ${MAKE} clean-lex-yacc-exec ; \
@@ -236,6 +235,9 @@ realclean: cleanobj gcovclean
 clean-lex-yacc-exec: cleanlex cleanyacc cleanexec
 
 gcovclean: force
+# delete the *.o files whenever we delete the *.gcno. This way,
+# make gcovclean; make gcov; regenerates everything.
+       $(MAKE) GCOV=gcov cleanobj
        $(RM) *.gcda *.gcno *.gcov
 
 # Keep *.gcno files (reset the recorded data only, not the compile-time one)

On peut appliquer la modification à la main, ou bien avec

cd $GL_GLOBAL
patch -p1

La commande patch attends un patch sur son entrée standard, il suffit de copier-coller le texte ci-dessus, et de terminer avec Control-D.

14/01/2010 (ter) : Attributs protégés en Deca

Certains étudiants ont du mal à comprendre la règle 3.87 sur les attributs protégés. Effectivement, la raison d'être de cette règle est particulièrement difficile à intuiter ... Une petite page d'explication est disponible ici : Attributs protégés en Deca.

14/01/2010 (bis) : adabody sur machine personnelle

Vous avez probablement remarqué que le script adabody que nous vous fournissons ne marche pas ailleurs que sur ensibm (il utilise une version patchée maison de gnatstub).

Une version plus portable est maintenant installée sur ensibm dans /usr/local/GL/Global/Bin/adabody. Il vous suffit de recopier ce fichier chez vous pour pouvoir l'utiliser.

14/01/2010 : Rappel/précision sur les documents à rendre

Vos enseignants vous en ont déjà parlé pendant le stage de lancement du projet : vous aurez plusieurs documents à rendre en fin de projet. Plus précisément, il y a 4 documents distincts à rendre :

  • Manuel utilisateur
  • Documentation de conception
  • Documentation de validation
  • Bilan

Un descriptif de ces documents se trouve dans le document A_Rendre.txt, page II-38.

13/01/2010 : Précisions sur le barème de la note « Gestion de projet »

Le Projet GL donne lieu à deux notes : une donnée par votre enseignant d'informatique, et l'autre donnée par l'enseignant de sciences de l'entreprise (présent au premier ou au deuxième suivi avec votre enseignant d'informatique, seul interlocuteur pour le dernier suivi, et présent le jour de la soutenance). Vous avez du avoir quelques explications orales sur le barème pendant les suivis, mais voici ces explications par écrit :

Evaluation par les membres du groupe : 3 points

A chaque séance de suivi le groupe évalue la participation de chacun en répartissant 100 points entre ses membres (une hiérarchie doit se dégager : aucune égalité entre étudiants n’est possible) Seule l’évaluation finale sera prise en compte, les autres permettant aux étudiants de se familiariser à ce mode d’évaluation.

Evaluation lors des suivis : 3 points

  • Documents remis, présentation orale

Evaluation lors de la soutenance : 14 points

  • Clarté de la présentation orale
  • Pertinence des points exposés
  • Analyse du fonctionnement du groupe

10/01/2010 : Problèmes avec le mode Ada de Vim, vim 7.2

Ceux d'entre vous qui utilisent le mode Ada pour vim sur ensibm ont pu se rendre compte que ce mode était totalement cassé (une page de messages d'erreur au lancement de vim, et pas grand chose qui marche après). La raison est que le mode Ada de vim est cassé sur les versions 7.0 et 7.1, mais la version 7.2 vient d'être installée sur ensibm, et devrait résoudre ces problèmes.

En cas de problème avec vim 7.2 (/usr/local/bin/vim -> /usr/local/src/vim72/install/bin/vim), l'ancienne version est toujours disponible dans /usr/local/src/vim71/bin/vim.

09/01/2010 : Problèmes pour compiler

Certains étudiants ont des problèmes pour compiler leur projet (par exemple, un message d'erreur « WARNING: ALI or object file not found after compile »). Un problème possible est que des fichiers *.ali aient été déposés dans les répertoires Src/. La solution est simple : supprimer ces fichiers *.ali ! Depuis peu, la cible « make realclean » du Makefile fait ceci pour vous. D'une manière générale (et pas seulement pour le projet GL), « make realclean; make » résout parfois des problèmes mystérieux sur la compilation.

07/01/2010 : Imprimer ou générer un PDF avec Planner

Certains étudiants n'arrivent pas à imprimer avec planner (rassurez-vous, votre serviteur aussi a eu du mal à trouver la solution :-\).

Un problème fréquent est d'oublier de cocher les vues à imprimer, dans le premier onglet de la boite de dialogue d'impression :

Print-planner.png

Pour l'impression, il est recommandé de générer un PDF, et d'imprimer ce PDF depuis votre visualiseur de PDF préféré pour éviter de gaspiller du papier si vous vous trompez ...

05/01/2010 : Clés SSH et machines personnelles

Pour ceux qui ont des problèmes pour utiliser leurs clés SSH sur une machine personnelle, une section « Clés SSH » a été ajoutée à la page Faire le Projet GL sur une machine personnelle.

16/12/2009 : Erreur dans le polycopié

A plusieurs endroits du polycopié, on mentionne la commande

git clone $GITREPO

cette commande va effectivement faire un clone, mais le nom du répertoire créé sera « git/ », alors qu'on voulait le nommer « Projet_GL/ ». La version correcte est donc

git clone $GITREPO Projet_GL

Si vous avez déjà fait git clone $GITREPO, pas de panique, il suffit de renommer le répertoire :

mv git Projet_GL