Actualité du Projet GL 2009

De Ensiwiki
Aller à : navigation, rechercher
AttentionCette page est obsolète. Elle a été utilisée pour le Projet GL 2009, 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_2009&feed=atom&action=history
RSS: https://ensiwiki.ensimag.fr/index.php?title=Actualit%C3%A9_du_Projet_GL_2009&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

27/01/2008 - Points à aborder pour le bilan

Pour vous aider à organiser et rédiger votre bilan, voici quelques points que vous pouvez aborder en plus de ceux décrits dans A_Rendre.txt.

Ce message d'information arrive un peu tard, et il est entendu que vous n'avez pas à le prendre en compte pour le bilan que vous avez déjà rendu il y a quelques dizaines de minutes, mais ce sont des points que vous pouvez développer pendant la partie « bilan sur l'organisation du projet » de la soutenance. Vous pouvez ajouter du contenu au document papier « Bilan » que vous apporterez le jour de la soutenance, mais il ne sera pris en compte que par votre enseignant d'informatique.

Ce bilan sera utilise a la fois pour vous évaluer et pour aider l'équipe enseignante a progresser pour l'année prochaine.

  • Gestion de projet : Y a-t-il eu des différences entre le planning prévisionnel et le planning effectif ? Comment avez-vous géré les imprévus ? Avez-vous rencontré des tâches plus difficiles que prévu ?
  • Méthodes de travail : quelle politique d'utilisation de l'archive avez-vous appliqué ? comment s'est déroulée la communication entre les membres de l'équipe ? Quelle a été la répartition du travail ?
  • Environnement de travail et outils utilisés : Qu'avez-vous pensé des outils que vous avez eu à utiliser (ex : planner) ? Avez-vous rencontré des problèmes relatifs à ces outils ?
  • Pour chaque étudiant, vous pouvez indiquer, si vous le souhaitez:
    • le principal enseignement positif tiré de ce projet
    • la principale difficulté ressentie
  • Bilan global : Si tout était à refaire, qu'est-ce que vous garderiez et qu'est-ce que vous changeriez ?
  • Et un dernier point qui intéresse l'équipe pédagogique cette année : Estimez-vous avoir été bien préparé à l'aspect compilation avant le début du projet (en particulier le stage SLE/Télécom pour ceux concernés).

25/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 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 regle de ne plus commiter de code avec le debug active (on active les traces emporairement dans sa copie locale).

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 checkout du projet ailleurs que ~/Projet_GL/, 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 checkout doit être fait par chacun des membres de l'equipe.

Preparation de la soutenance :

  • Bien travailler le bilan, en particulier l'organisation du projet.

22/01/2009 (bis) : Erreur fréquente avec les scripts de tests

Certains groupes ont codé en dur dans leurs scripts de tests le fait que le projet devait être dans ~/Projet_GL/. Dans ce cas, la batterie de tests ne passera pas chez les enseignants.

Pour vérifier si vous avez ce problème, vous pouvez faire quelque chose comme :

cd
mv Projet_GL Projet_GL.ailleurs
cd Projet_GL.ailleurs
make
make check
cd
mv Projet_GL.ailleurs Projet_GL

22/01/2009 : Problème et solution avec gcov

Certains étudiants n'arrivaient pas à compiler leur projet avec gcov (une erreur à propos de /usr/bin/gcc). Un problème commun est d'avoir la mauvaise version de GNAT en premier dans son $PATH. Pour vérifier :

ensibm:~>which gnatmake
/usr/local/gnat/bin/gnatmake

et si ce n'est pas le cas, relisez Seance_Machine.txt.

21/01/2009 : Echéancier des remises à faire en fin de projet

  • Lundi 26 janvier à 16h : ramassage automatique des versions de vos archives svn en l'état trouvé à 16h. Doit contenir au moins : code source, base de test, documentation des bogues connues (Bugs.txt)
  • Lundi 26 janvier 20h : remise du manuel utilisateur; la version électronique doit être committée dans l'archive, répertoire Docs. Version papier : selon accord avec votre encadrant.
  • Mardi 27 janvier 20h : ramassage automatique des fichiers contenus dans le répertoire Planning : Bilan.pdf, Planning.pdf, Realisation.pdf (et non pas à la soutenance comme indiqué pour le bilan).
  • Soutenance : apporter un seul exemplaire du Bilan, de la documentation de conception et de validation.


19/01/2009 (ter) : Précisions sur la sémantiques des options -n et -b

Decac.txt n'est pas très précis sur la sémantique des options -n et -b. Voici quelques précisions :

  • decac -b affiche une bannière, et termine immédiatement. Le comportement de decac -b fichier.deca est indéfini.
  • decac -n désactive les vérifications de débordement. Plus précisément, les débordements sont (cf. Semantique.txt pour les détails) :
    • débordement arithmétique
    • débordement mémoire
    • déréférencement de null

19/01/2009 (bis) : Encore une précision sur la version béta

Encore un rappel important : toutes les traces (messages informatifs, informations pour le debogage) doivent être supprimés. Le compilateur ne doit produire une sortie sur le terminal que pour les options le demandant explicitement, ou en cas d'erreur.

(Une bonne convention est de ne plus jamais commiter de code avec les traces de debug activées à partir de la version béta, pour être certain que ce soit le cas pour la finale)

19/01/2009 : N'oubliez pas la version béta !

Nous vous rappelons que la version béta de votre compilateur est à « rendre » (i.e. à commiter dans votre archive) ce mercredi soir, minuit. Il est conseillé de bien relire Decac.txt et de s'assurer que l'interface du compilateur a bien été testée, et d'être particulièrement attentif aux régressions dans les heures qui précèdent la version béta.

8/01/2009 : Transparents en ligne pour la séance « GL » du projet

Certains enseignants ont projeté des transparents pendant la 4ème séance de stage. Ils sont en ligne (ici: Media:Stage-gl-handout.pdf).

7/01/2009 : $PATH, Jolis emacs, moins jolis Emacs ...

On me fait très justement remarquer en page de discussion que les consignes proposées dans Seance_Machine.txt poussent à mettre /usr/bin/ au début du $PATH, et du coup, avant /usr/local/bin/. Au contraire, il est important que /usr/local/bin/ reste au début du $PATH, pour que les logiciels qui y sont installés soient pris en priorité.

On peut donc par exemple mettre ceci en fin de ~/.bashrc :

export PATH="/usr/local/GL/Global/Bin:/usr/local/gnat/bin:$HOME/Projet_GL/Exec:$PATH"

Si vous avez /usr/bin/ en double dans le $PATH, supprimez la première occurence.

Exemple concret, Emacs 22 est installé dans /usr/local/bin/, alors qu'un Emacs 21 un peu vieillot est dans /usr/bin/. Pour vérifier que vous utilisez la version la plus récente, essayez les commandes « emacs » et « emacs22 », et comparez, ou bien vérifiez avec la commande "type" :

ensibm:~>type emacs
emacs is /usr/local/bin/emacs

6/01/2009 : Petit bug avec GL_Pour_Linux/

Un petit bug a été corrigé dans le Makefile de GL_Pour_Linux. En fait, toute la partie sur "tabul", en plus d'être inutile, levait une erreur sur la commande "rehash", il fallait donc supprimer cette partie.

/usr/local/GL/Global/Linux/Makefile est à jour, mais si vous avez déjà compilé aflex, ayacc et ima, vous n'avez rien d'autre à faire.

5/01/2009 (ter) : Précisions sur les clés SSH

Pour ceux qui veulent travailler depuis leur machine personnelle, copier la clée privée contenue dans ~/.ssh/ n'est pas toujours suffisant. Il faut aussi que ssh sache que c'est celle là qu'il faut prendre. Si la clé s'appelle ~/.ssh/id_projet_gl, on peut mettre ceci dans le ~/.ssh/config (à créer s'il n'existe pas) :

Host ensibm.imag.fr
User gl42
IdentityFile ~/.ssh/id_projet_gl

Cette manipulation permet entre autres de garder les anciennes clés en parallèle avec la nouvelle sans problème.

5/01/2009 (bis) : Problème avec planner résolu

Ceux qui ont essayé d'ouvrir les fichiers Planning.planner et Realisation.planner se sont rendus compte que ça ne marchait pas. En fait, nous avions préparé ces squelettes avec une nouvelle version de planner, et la version un peu ancienne disponible sur ensibm n'est pas capable de les ouvrir.

La solution :

cd Projet_GL/Planning/
fix-planner.sh

(fix-planner.sh est un script qui fait principalement perl -pi.bak -e 's/ *work-start="[^"]*" */ /' *.planner)

5/01/2009 : Début du projet, précision sur SSH

Précision sur les droits que vous avez sur les comptes glXX@ensibm :

  • Vous ne pouvez pas vous logger dessus, seulement utiliser SVN,
  • La clé ssh utilisée pour vous connecter est soit celle que vous aviez déjà (~/.ssh/*.pub), soit une créée pour vous pendant les vacances de Noel (~/.ssh/id_projet_gl). Pour travailler de chez vous, il suffit de recopier cette clé sur votre machine.