Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:memocommit

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:memocommit [2016/06/16 16:22] – [0. Hypothèses de départ] papeleuxcommit:memocommit [2018/05/04 15:49] (current) – ↷ Links adapted because of a move operation boman
Line 1: Line 1:
-===== Je commite en 9 leçons ou comment faire un bon commit =====+====== Je commite en 9 leçons ======  
 +... ou comment faire un bon commit
  
 ==== Avertissement ==== ==== Avertissement ====
  
-Cette page, la plus visitée du beau site de Metafor, explique aux développeurs comment faire un bon commit. Cependant, vu l'évolution très rapide de Metafor, cette page est rarement à jour, ce qui peut être déroutant pour un nouveau à qui on dit juste RTFM. Bah oui, si le Fucking Manual n'est plus bon, ça complique les choses..+Cette page, explique aux développeurs comment faire un bon commit. Cependant, vu l'évolution très rapide de Metafor, cette page n'est pas toujours à jour. 
  
-J'ai doncen date du __**15/06/2016**__remis cette page à jour, en espérant qu'elle le reste le plus longtemps possible. Cependantj'ai fait cette mise à jour de tête, et comme mon ratio de commits réussis sur commits totaux n'est pas si élevé que ça, je ne garantis pas l'exactitude de cette page. +Cependant, n'oublie pascher collègueque tu peux aussi faire de ce monde un monde meilleur! Il te suffit de cliquer à droite de cette page sur le bouton "Edit this page" et tu peux immédiatement corriger une erreur! Merveilleux, n'est-il pas?
  
-Cependant, n'oublie pas, cher collègue, que tu peux aussi faire de ce monde un monde meilleur ! Il te suffit de cliquer à droite de cette page sur le bouton "Edit this page" et tu peux immédiatement corriger une erreur ! Merveilleux, n'est-il pas? +Je te souhaite donc un bon commit! 
- +
-Je te souhaite donc un bon commit ! +
  
 ==== Introduction ==== ==== Introduction ====
Line 15: Line 14:
 [[https://fr.wiktionary.org/wiki/commiter|Commiter]]. Voilà un beau mot qu'il n'est pas facile d'utiliser en dehors du B52. Pourtant, en tant que développeurs de code, c'est une étape indispensable qu'il va falloir réaliser régulièrement (la notion de "régulièrement" étant très variable selon les personnes).  [[https://fr.wiktionary.org/wiki/commiter|Commiter]]. Voilà un beau mot qu'il n'est pas facile d'utiliser en dehors du B52. Pourtant, en tant que développeurs de code, c'est une étape indispensable qu'il va falloir réaliser régulièrement (la notion de "régulièrement" étant très variable selon les personnes). 
  
-En effet, lorsque l'on est plusieurs à travailler sur le même code, il est indispensable d’utiliser un système de version. La version officielle de Metafor se trouve bien sagement dans le "repository", et chaque développeur fait une copie de cette version sur son PC (checkout) pour pouvoir travailler dans son coin. Après avoir réalisé des développements, il arrive souvent un point où on souhaite réintégrer ceux-ci à la version officielle de Metafor (commiter), afin de sauvegarder son travail, d'avoir une nouvelle base de référence pour continuer à programmer, de permettre aux autres d'utiliser ses nouveaux développements...+En effet, lorsque l'on est plusieurs à travailler sur le même code, il est indispensable d’utiliser un système de version. La version officielle de Metafor se trouve bien sagement dans le "repository", et chaque développeur fait une copie de cette version sur son PC ("checkout") pour pouvoir travailler dans son coin. Après avoir réalisé des développements, il arrive souvent un point où on souhaite réintégrer ceux-ci à la version officielle de Metafor ("commiter"), afin de sauvegarder son travail, d'avoir une nouvelle base de référence pour continuer à programmer, de permettre aux autres d'utiliser ses nouveaux développements...
  
-Cependant, il ne suffit pas de brutalement aller modifier la version officielle ! Avant de pouvoir commiter, il faut vérifier +Cependant, il ne suffit pas de brutalement aller modifier la version officielle! Avant de pouvoir commiter, il faut vérifier 
   * que les nouveaux développements sont portables, en compilant sur différentes plateformes et compilateurs   * que les nouveaux développements sont portables, en compilant sur différentes plateformes et compilateurs
-  * qu'il n'y a pas de régression dans les capacités de Metafor (c'est-à-dire que l'on est pas aller pourrir le travail des collègues), via l'execution d'une batterie de tests sur différentes configurations.+  * qu'il n'y a pas de régression dans les capacités de Metafor (c'est-à-dire que l'on est pas aller pourrir le travail des collègues), via l’exécution d'une batterie de tests sur différentes configurations.
  
 Les différentes plateformes sur lesquelles la compilation doit être possible et la batterie lancée sont les suivantes :  Les différentes plateformes sur lesquelles la compilation doit être possible et la batterie lancée sont les suivantes : 
  
-          ^   OS     ^  compiler  ^  nb core  ^  Bacon  ^  GUI   Battery  ^  Nice value   Fichier CMake       +           ^   OS      ^  compiler  ^  nb core  ^  Bacon  ^  GUI  ^  Fichier CMake                     
-^ thorgal   |  Linux64 |    gcc        2*4    |  oui    |  oui  |  oui      |    19        |  <wrap em>thorgal.cmake</wrap>   +^ thorgal    |  Linux64  |    gcc        2*4    |  oui    |  oui  | ''thorgal.cmake''      
-blueberry |  Linux64 |    icc        4      |  oui    |  oui  |  oui      |    19        |  <wrap em>blueberry.cmake</wrap>  +spring     |  Linux64  |    icc        4      |  oui    |  oui  | ''spring.cmake''       | 
-^ PC Windows |  Win64  |   VS2012      -      |  oui    |  oui  |  oui      |            |  <wrap em>win64-vs2012.cmake</wrap>  |+^ gaston     |  Linux64  |    clang      6/12    oui    |  oui  | ''gaston.cmake''       
 +^ PC Windows |  Win64    |   VS2012      -      |  oui    |  oui  | ''win64-vs2012.cmake'' |
  
 Quand on essaie de réaliser cette procédure de commit, on oublie toujours une chose ou l'autre quand on n'a pas l'habitude. Voici donc une petite marche à suivre qui détaille, étape par étape, tout ce qu'il faut faire pour faire un beau commit pas foireux. Quand on essaie de réaliser cette procédure de commit, on oublie toujours une chose ou l'autre quand on n'a pas l'habitude. Voici donc une petite marche à suivre qui détaille, étape par étape, tout ce qu'il faut faire pour faire un beau commit pas foireux.
Line 33: Line 33:
  
   * On considère que les sources stations vont être dans ''/home/$USER/Metafor''   * On considère que les sources stations vont être dans ''/home/$USER/Metafor''
- +  * [[doc:devel:svnconfig|SVN est correctement configuré sur son PC]] 
-  * [[doc:devel:svnconfig| SVN est correctement configuré sur son pc]]  +
   * Idéalement, il faut aussi savoir se connecter sur les stations sans mot de passe. Pour ce faire, suivez les instructions [[devel:password|décrites ici]]. Ce n'est pas obligatoire, mais cela évite de taper son mot de passe deux cents fois par commit.    * Idéalement, il faut aussi savoir se connecter sur les stations sans mot de passe. Pour ce faire, suivez les instructions [[devel:password|décrites ici]]. Ce n'est pas obligatoire, mais cela évite de taper son mot de passe deux cents fois par commit. 
- 
   * Les programmes suivants (disponibles sur le NAS) doivent être installés sur son PC:   * Les programmes suivants (disponibles sur le NAS) doivent être installés sur son PC:
     * Samcef (normalement inclus dans les libs-vs2012)     * Samcef (normalement inclus dans les libs-vs2012)
Line 43: Line 40:
     * Scilab     * Scilab
     * GhostScript (dans les libs)     * GhostScript (dans les libs)
- +  * Sous Windows, les chemins complets vers ces programmes doivent être définis à travers l'application "externalProgramPathGui.pyw" (présente dans "linuxBin") ou être dans le PATH users de Windows.
-  * Sous windows, les chemins complets vers ces programmes doivent être définis à travers l'application "externalProgramPathGui.pyw" (présente dans linuxBin) ou être dans le path users de Windows (n'est plus défini par défaut dans les libs)...+
  
  
 ==== 1. Mise à jour complète ==== ==== 1. Mise à jour complète ====
  
-Personnellement, c'est l'étape que j'oublie une fois sur trois. Pour pouvoir commiter sa nouvelle version, il faut évidemment être à jour et posséder la version la plus récente de Metafor. A l'heure actuelle (juin 2016), Metafor est composé de 4 différents dossiers, qui fonctionnent avec deux systèmes de version différents. +Pour pouvoir commiter sa nouvelle version, il faut évidemment être à jour et posséder la version la plus récente de Metafor. A l'heure actuelle (juin 2016), Metafor est composé de 4 différents dossiers, qui fonctionnent avec deux systèmes de version différents. 
  
-Les trois dossiers ''oo_meta''''oo_nda'' et ''linuxbin'' sont gérés par SVN. Pour mettre à jour, il suffit de sélectionner ces trois dossiers, clic droit, SVN Update. +Les dossiers ''oo_meta'' et ''oo_nda'' sont gérés par "SVN". Pour mettre à jour, il suffit de sélectionner ces deux dossiers, clic droit, SVN Update. 
  
-{{:commit:svnupdate4.png?|}}+{{ :commit:svnupdate4.png?direct&600 }}
  
-Le dossier ''parasolid'', lui, est géré par Git (voir le [[commit:05_02#Info sur compilation|commit de Romain]] pour installer et comprendre git). Pour mettre à jour, on sélectionne le dossier, clic droit, TortoiseGit, Pull. +Le dossiers ''parasolid'' et ''linuxbin'' sont gérés par "git" (voir le [[commit:2016:05_02#Info sur compilation|commit de Romain]] pour installer et comprendre git). Pour mettre à jour, on sélectionne le dossier, clic droit, TortoiseGit, Pull. 
  
-{{:commit:gitupdate3.png?|}}+{{ :commit:gitupdate3.png?direct&600 }}
  
-La fenêtre suivante s'ouvre. On laisse bien ''remote : origin'', ''remote Branch :  master'', et on clique sur OK.+La fenêtre suivante s'ouvre. On laisse bien ''remote : origin'', ''remote branch :  master'', et on clique sur OK.
  
-{{:commit:gitupdate2.png?|}}+{{ :commit:gitupdate2.png?direct&500 }}
  
 Lors de la mise à jour des sources, des conflits peuvent évidemment arriver, si jamais les modifications réalisées ne sont pas compatibles avec celles introduites dans les derniers développements commités par les collègues. Dans ce cas-là il faut résoudre les conflits à la main. Plus on attend longtemps avant de commiter, plus le nombre de ces conflits augmente, donc il est intéressant de commiter régulièrement.  Lors de la mise à jour des sources, des conflits peuvent évidemment arriver, si jamais les modifications réalisées ne sont pas compatibles avec celles introduites dans les derniers développements commités par les collègues. Dans ce cas-là il faut résoudre les conflits à la main. Plus on attend longtemps avant de commiter, plus le nombre de ces conflits augmente, donc il est intéressant de commiter régulièrement. 
  
-Une fois les sources mises à jour, il faut faire de même avec son projet Windows, d'abord en utilisant CMake, puis en compilant sous Visual Studio. Personnellement, je préfère toujours supprimer complètement mon projet et le recréer depuis le début (créer un dossier ''oo_metaB'' ou ''MetaBin'', ouvrir fenêtre de commande, taper ''cmake  -C ..\oo_meta\CMake\win64-vs2012.cmake ..\oo_meta'', ouvrir le projet visual studio et complier), mais on peut (souvent mais pas toujours) aussi simplement utiliser CMake GUI, dans les libs de Luc : +Une fois les sources mises à jour, il faut faire de même avec son projet Windows, d'abord en utilisant CMake, puis en compilant sous Visual Studio. Personnellement, je préfère toujours supprimer complètement mon projet et le recréer depuis le début (créer un dossier ''oo_metaB'' ou ''MetaBin'', ouvrir fenêtre de commande, taper ''cmake  -C ..\oo_meta\CMake\win64-vs2012.cmake ..\oo_meta'', ouvrir le projet Visual Studio et complier), mais on peut (souvent mais pas toujours) aussi simplement utiliser CMake GUI, dans les libs de Luc: 
  
-{{:commit:cmake.png?|}}+{{ :commit:cmake.png?direct&600 }}
  
-On vérifie bien que la première ligne pointe vers ''oo_meta'', la seconde vers ''oo_metaB'', puis on clique d'abord sur ''Configure'', et ensuite sur ''Generate''. Il reste ensuite à recompiler son projet visual studio+On vérifie bien que la première ligne pointe vers ''oo_meta'', la seconde vers ''oo_metaB'', puis on clique d'abord sur ''Configure'', et ensuite sur ''Generate''. Il reste ensuite à recompiler son projet Visual Studio
  
 ==== 2. Transférer les sources sur les stations ==== ==== 2. Transférer les sources sur les stations ====
  
-Une fois les sources à jour, l'idée est de les compiler et de lancer la batteries de tests sur les stations linux, Blueberry et Thorgal. Il faut donc déplacer les sources sur les stations en question. +Une fois les sources à jour, l'idée est de les compiler et de lancer la batteries de tests sur les stations linux, spring et thorgal. Il faut donc déplacer les sources sur les stations en question. 
  
 === 2.1 Nettoyage === === 2.1 Nettoyage ===
Line 79: Line 75:
 Avant de déplacer les sources, deux petites opérations de nettoyage :  Avant de déplacer les sources, deux petites opérations de nettoyage : 
  
-  * Premièrement, dans ''oo_meta'', on ouvre une fenêtre de command et on tape ''python clean.pyw''. Cela ouvre un petit utilitaire qui permet de nettoyer les crasses du projet. Cela n'est pas obligatoire, mais cela permet de supprimer les .pyc par exemple, ou des dossiers ''workspace'' qui traîneraient où il ne faut pas, pour éviter par la suite de commiter des fichiers qui ne doivent pas l'être. Attention qu'il ne faut pas aveuglément cliquer sur Go et tout supprimer, il me semble que cela supprime parfois des fichiers requis par certains cas-tests (à vérifier...) +  * Premièrement, dans ''oo_meta'', on ouvre une fenêtre de commande et on tape ''python clean.pyw''. Cela ouvre un petit utilitaire qui permet de nettoyer les crasses du projet. Cela n'est pas obligatoire, mais cela permet de supprimer les ''.pyc'' par exemple, ou des dossiers ''workspace'' qui traîneraient où il ne faut pas, pour éviter par la suite de commiter des fichiers qui ne doivent pas l'être. Attention qu'il ne faut pas aveuglément cliquer sur [Goet tout supprimer, il me semble que cela supprime parfois des fichiers requis par certains cas-tests (à vérifier...) 
-  * Deuxièmement, il est également bon de faire un SVN Clean Up de ''oo_meta''''oo_nda'' et ''linuxbin'', sans quoi les dossiers pourraient être trop gros pour être zippés correctement. Les options par défaut peuvent être laissées, attention de ne __pas__ cocher "Delete unversioned files and folders", "Delete ignored files and folders" et "Revert all changes recursively".+  * Deuxièmement, il est également bon de faire un "SVN Clean Upde ''oo_meta'' et ''oo_nda'', sans quoi les dossiers pourraient être trop gros pour être zippés correctement. Les options par défaut peuvent être laissées, attention de ne __pas__ cocher "Delete unversioned files and folders", "Delete ignored files and folders" et "Revert all changes recursively".
  
 === 2.2 Archivage === === 2.2 Archivage ===
  
-Une fois le nettoyage réalisé, on peut zipper les sources avec [[http://www.win-rar.com/|WinRar]]. Faire un fichier qui peut s'appeler, par example, ''MetaforDate.zip'' (attention, pas un fichier ''.rar'') avec les quatre dossiers ''linuxbin'', ''oo_meta'', ''oo_nda'' et ''parasolid''.+Une fois le nettoyage réalisé, on peut zipper les sources avec [[http://www.win-rar.com/|WinRAR]]. Faire un fichier qui peut s'appeler, par example, ''MetaforDate.zip'' (attention, pas un fichier ''.rar'') avec les quatre dossiers ''linuxbin'', ''oo_meta'', ''oo_nda'' et ''parasolid''.
  
-{{ :commit:winrar3.png}}+{{ :commit:winrar3.png?direct&600 }}
  
 === 2.3 Transfert === === 2.3 Transfert ===
    
 Ensuite, on transfère l'archive en question sur les stations en utilisant par exemple [[https://filezilla-project.org/|Filezilla]]. Pour se connecter aux stations :  Ensuite, on transfère l'archive en question sur les stations en utilisant par exemple [[https://filezilla-project.org/|Filezilla]]. Pour se connecter aux stations : 
-    * Hôte : ''blueberry.ltas.ulg.ac.be'' et ''thorgal.ltas.ulg.ac.be''+    * Hôte : ''spring.ltas.ulg.ac.be''''thorgal.ltas.ulg.ac.be'' ou ''gaston.ltas.ulg.ac.be''
     * Compléter identifiant et mot de passe     * Compléter identifiant et mot de passe
-    * Port 22 +    * Port22 
-    * Cliquer sur connexion rapide +    * Cliquer sur "connexion rapide"
  
 Une fois connecté, il suffit alors de faire glisser l'archive zip dans un sous-dossier adapté, par exemple DateBaterry Une fois connecté, il suffit alors de faire glisser l'archive zip dans un sous-dossier adapté, par exemple DateBaterry
  
-{{ :commit:filezilla2.png}}+{{ :commit:filezilla2.png?direct&600 }}
  
 ==== 3. Faire passer les batteries sur les stations ==== ==== 3. Faire passer les batteries sur les stations ====
  
-Maintenant qu'on a déplacé les sources sur les stations, il reste à lancer les batteries dessus. Pour cela, il faut compiler les sources et lancer la batterie sous Linux64-gcc (thorgal) et Linux64-icc (blueberry).+Maintenant qu'on a déplacé les sources sur les stations, il reste à lancer les batteries dessus. Pour cela, il faut compiler les sources et lancer la batterie sous Linux64-gcc (thorgal)Linux64-icc (spring) et Linux64-clang (gaston).
  
 === 3.1 Se connecter sur les stations === === 3.1 Se connecter sur les stations ===
  
 On se connecte sur les stations grâce à [[http://www.putty.org/|PuTTY]] :  On se connecte sur les stations grâce à [[http://www.putty.org/|PuTTY]] : 
-  * Dans hôte, on tape ''blueberry.ltas.ulg.ac.be'' ou ''thorgal.ltas.ulg.ac.be''+  * Dans hôte, on tape ''spring.ltas.ulg.ac.be''''thorgal.ltas.ulg.ac.be'' ou ''gaston.ltas.ulg.ac.be''
   * Dans port, 22   * Dans port, 22
-  * On clique Open+  * On clique "Open"
   * On tape son identifiant, puis son mot de passe   * On tape son identifiant, puis son mot de passe
   * On se positionne dans le bon dossier : ''cd DateBattery''   * On se positionne dans le bon dossier : ''cd DateBattery''
  
-{{ :commit:putty5.png}}+{{ :commit:putty5.png?direct&600 }}
  
-Une fois connecté, on commence par taper la commande ''top'' pour vérifier que personne n'est occupé sur la machine. Sur l'image ci-dessous, par exemple, 4 noeuds sont déjà occupés par Marco. Il est bien aussi de se renseigner pour voir si des collègues n'ont pas un commit super urgent prévu et ne pas leur voler la priorité. C'est donc l'occasion d'aller papoter un peu dans les bureaux. +Une fois connecté, on commence par taper la commande ''top'' pour vérifier que personne n'occupe la machine. Sur l'image ci-dessous, par exemple, 4 noeuds sont déjà occupés par Marco. Il est bien aussi de se renseigner pour voir si des collègues n'ont pas un commit super urgent prévu et ne pas leur voler la priorité. C'est donc l'occasion d'aller papoter un peu dans les bureaux. 
-{{ :commit:top.png}}+ 
 +{{ :commit:top.png?direct&600 }}
  
 === 3.2 Lancer les batteries via ''comp.py'' === === 3.2 Lancer les batteries via ''comp.py'' ===
  
-Si personne n'est sur la machine, on lance alors le (magnifique) script de Romain ''comp.py''+Si personne n'est sur la machine, on lance alors le script ''comp.py''
  
-{{ :commit:comppy.png |}}+{{ :commit:comppy.png?direct&600 }}
  
 Pour faire son choix dans le menu, il suffit de taper la lettre ou le chiffre précédant la commande en question dans le menu. Pour faire son choix dans le menu, il suffit de taper la lettre ou le chiffre précédant la commande en question dans le menu.
  
 Parmi les lettres, seules les options 'b' et 'j' doivent être modifiées :  Parmi les lettres, seules les options 'b' et 'j' doivent être modifiées : 
-    * b. Archive name. Chemin et nom des sources zippées de Metafor. Il faut donc taper b, puis écrire le chemin vers l'archive zip transférée précédemment (un simple tab suffit si on est dans le bon dossier). +    * b. Archive name. Chemin et nom des sources zippées de Metafor. Il faut donc taper b, puis écrire le chemin vers l'archive zip transférée précédemment (un simple TAB suffit si on est dans le bon dossier). 
-    * j. Nombre de CPU pour la compilation et la batterie (voir tableau ci-dessous pour le nombre de CPU des différentes machines). Mettre à 4.+    * j. Nombre de CPUs pour la compilation et la batterie (voir tableau ci-dessous pour le nombre de CPU des différentes machines). Mettre généralement à 4.
  
 Les autres options, décrites ci-dessous, sont en général laissées par défaut :  Les autres options, décrites ci-dessous, sont en général laissées par défaut : 
     * a. e-mail address. Adresse à laquelle les résultats de la batterie seront renvoyés.      * a. e-mail address. Adresse à laquelle les résultats de la batterie seront renvoyés. 
-    * f. build options. Donner le nom du fichier de config CMake (voir tableau ci-dessous).+    * f. build options. Donner le nom du fichier de config CMake (voir tableau ci-dessous - le nom par défaut est généralement OK).
     * g. debug mode. Laisser ''False''     * g. debug mode. Laisser ''False''
-    * h. nice value. Priorité de calcul pour la batterie.+    * h. nice value. Priorité de calcul pour la batterie: laisser 0 - priorité haute.
     * k. Nombre de threads pour le calcul en parallèle.      * k. Nombre de threads pour le calcul en parallèle. 
-    * m. run Method. Laisser batch.  +    * m. run Method. Laisser "batch".  
-    * q. is bacon present? Bacon est présent sur toutes les machines.+    * q. is bacon present? Bacon est présent sur toutes les machines de batterie.
  
 Concernant les chiffres :  Concernant les chiffres : 
Line 143: Line 140:
     * 1. Indique où sont les sources. Trois possibilités :      * 1. Indique où sont les sources. Trois possibilités : 
       * ''zip'' - les sources zippées et viennent d'être transférées par Filezilla. Attention, cela efface tout résultat de batterie précédent !        * ''zip'' - les sources zippées et viennent d'être transférées par Filezilla. Attention, cela efface tout résultat de batterie précédent ! 
-      * ''checkout'' - les sources doivent être obtenues par checkout depuis le repository. Attention, cela ne marche que si on peut se connecter aux stations sans mot de passe ! Utile seulement pour compiler la version officielle de Metafor. +      * ''checkout'' - les sources doivent être obtenues par checkout depuis le repository. Attention, cela ne marche que si on peut se connecter aux stations sans mot de passe! Utile seulement pour compiler la version officielle de Metafor. 
       * ''present'' - les sources sont présentes dans le même dossier. C'est ce qu'il faut cocher si Metafor a déjà été compilé et qu'on souhaite juste relancer quelques tests.        * ''present'' - les sources sont présentes dans le même dossier. C'est ce qu'il faut cocher si Metafor a déjà été compilé et qu'on souhaite juste relancer quelques tests. 
  
-    * 2. compile''True'' ou ''False''. Attention, si ''True'', cela efface tous les résultats de batteries précédents ! +    * 2. compile''True'' ou ''False''. Attention, si ''True'', cela efface tous les résultats de batteries précédents ! 
  
-    * 3. battery ''True'', ''False'' ou ''continue''. Attention, ''True'' efface toute la batterie et la relance entièrement. ''continue'' ne relance que les tests qui n'ont pas tourné ou ne sont pas passés. +    * 3. battery''True'', ''False'' ou ''continue''. Attention, ''True'' efface toute la batterie et la relance entièrement. ''continue'' ne relance que les tests qui n'ont pas tourné ou ne sont pas passés. 
  
-    * 4. installer ''False''+    * 4. installer''False''
  
 Dans ce cas-ci, où on vient de transférer les sources par Filezilla, on veut avoir :  Dans ce cas-ci, où on vient de transférer les sources par Filezilla, on veut avoir : 
Line 157: Line 154:
   * 3 battery - True   * 3 battery - True
  
-Une fois qu'on est satisfaits avec les options, on appuie sur G et ça démarre ! Pour info : +Une fois qu'on est satisfaits avec les options, on appuie sur "Get ça démarre! Pour info : 
  
   * G. Lancer le script en batch.    * G. Lancer le script en batch. 
Line 163: Line 160:
   * Q. Quitter le script   * Q. Quitter le script
  
-On répète ensuite l'opération avec la deuxième machine, Thorgal+On répète ensuite l'opération avec la deuxième machine, thorgal; puis la troisième, gaston
  
 Une dizaine de minutes plus tard, on reçoit un mail qui indique si la compilation s'est bien passée ou non. Si non, il faut donc comprendre pourquoi. Si ça compile sous Windows mais pas sous Linux, l'erreur la plus fréquente est un problème de casse. Sous Windows, ce n'est pas grave de remplacer 'a' par 'A', mais sous Linux bien.  Une dizaine de minutes plus tard, on reçoit un mail qui indique si la compilation s'est bien passée ou non. Si non, il faut donc comprendre pourquoi. Si ça compile sous Windows mais pas sous Linux, l'erreur la plus fréquente est un problème de casse. Sous Windows, ce n'est pas grave de remplacer 'a' par 'A', mais sous Linux bien. 
  
-Si la compilation s'est bien passée, quelques heures plus tard, les fichiers de résultats de la batterie sont envoyés automatiquement par email. On recevra notamment un mail avec un fichier html reprenant les diff sur la machine, qu'il faudra ensuite analyser. +Si la compilation s'est bien passée, quelques heures plus tard, les fichiers de résultats de la batterie sont envoyés automatiquement par email. On recevra notamment un mail avec un fichier html reprenant les diffs sur la machine, qu'il faudra ensuite analyser. 
  
-Pour info, voici le tableau qui permet de choisir les paramètres pour configurer ''comp.py'' selon les machines. 
  
-|             OS      compiler  ^  nb core  ^  Bacon  ^  GUI  ^  Battery  ^  Nice value  ^  Fichier CMake       ^ +==== 4. Faire passer la batterie sur son PC Windows ====
-^ thorgal    Linux64 |    gcc        2*    oui    |  oui  |  oui      |    19        |  <wrap em>thorgal.cmake</wrap>   | +
-^ blueberry |  Linux64 |    icc        4      |  oui    |  oui  |  oui      |    19        |  <wrap em>blueberry.cmake</wrap> +
-PC Windows |  Win64  |   VS2012      -      |  oui    |  oui  |  oui      |            |  <wrap em>win64-vs2012.cmake</wrap>  |+
  
- +Les batteries tournent déjà sur spring, thorgal et gaston, pour vérifier la portabilité sous Linux. Sous Windows, malheureusement, il n'y a pas de machine réservée, donc il faut faire tourner la batterie sur son propre PC. Pour ce faire: 
-==== 4. Faire passer la batterie sur son PC Windows ==== +
-Les batteries tournent déjà sur Blueberry et sur Thorgal, pour vérifier la portabilité sous Linux. Sous Windows, malheureusement, il n'y a pas de machine réservée, donc il faut faire tourner la batterie sur son propre PC. Pour ce faire : +
  
 Dans ''oo_metaB\bin\Release'', on ouvre une invite de commande. D'abord, on tape ''python battery.py clean'' pour effacer les résultats de batteries antérieures.  Dans ''oo_metaB\bin\Release'', on ouvre une invite de commande. D'abord, on tape ''python battery.py clean'' pour effacer les résultats de batteries antérieures. 
Line 184: Line 175:
 Toujours dans la fenêtre de commande, on tape à présent ''python battery.py -j 4 -l run''. Cela lance la batterie de tests sur 4 processeurs (-j 4), en priorité faible (-l, pour continuer à pouvoir utiliser l'ordinateur en même temps).      Toujours dans la fenêtre de commande, on tape à présent ''python battery.py -j 4 -l run''. Cela lance la batterie de tests sur 4 processeurs (-j 4), en priorité faible (-l, pour continuer à pouvoir utiliser l'ordinateur en même temps).     
              
-{{ :commit:battery3.png |Je lance la batterie sur mon PC Windows}} +{{ :commit:battery3.png?direct&600 |Je lance la batterie sur mon PC Windows}} 
  
-Une fois la batterie finie, toujours dans l'invite de commande, on tape ''python battery.py verif'' puis ''python battery.py diff''. Cela génère, dans le dossier ''oo_metaB\bin\Release\verif'', un fichier ''Windows-diffs.html'' qui contient toutes les différences entre les résultats des tests lancés ici et ceux de la version officielle. Le fichier ressemble à l'image ci-dessous :  +Une fois la batterie finie, toujours dans l'invite de commande, on tape ''python battery.py verif'' puis ''python battery.py diff''. Cela génère, dans le dossier ''oo_metaB\bin\Release\verif'', un fichier ''Windows-diffs.html'' qui contient toutes les différences entre les résultats des tests lancés ici et ceux de la version officielle. Le fichier ressemble à l'image ci-dessous : 
-{{ :commit:diffhtml.png |J'examine le fichier diff obtenu.}}+ 
 +{{ :commit:diffhtml.png?direct&600 |J'examine le fichier diff obtenu.}}
  
 ==== 5. Obtenir des résultats de batterie satisfaisants ==== ==== 5. Obtenir des résultats de batterie satisfaisants ====
Line 193: Line 185:
 === 5.1 Analyse des résultats de batterie === === 5.1 Analyse des résultats de batterie ===
  
-A présent, on a donc lancé les batteries sur ThorgalBlueberry, et son PC. On a donc reçu deux fichiers diffs par email, et le troisième se trouve dans ''oo_metaB\bin\Release\verif''. Il faut maintenant comprendre ces fichiers pour décider si on peut commiter ou non.+A présent, on a donc lancé les batteries sur thorgalspringgaston et son PC. On a donc reçu fichiers diffs par email, et le troisième se trouve dans ''oo_metaB\bin\Release\verif''. Il faut maintenant comprendre ces fichiers pour décider si on peut commiter ou non.
  
-Première chose à regarder : les failed. C'est assez simple, tant que au moins un des trois fichiers de diff commence par la section 'FAILED' on ne commite pas ! Cela veut dire que certains tests n'ont pas réussi à tourner jusqu'au bout (d'où le nom de failed). Il faut donc comprendre pourquoi, modifier son code et/ou ses tests, et relancer les tests. +Première chose à regarder : les "FAILED". C'est assez simple, tant que au moins un des trois fichiers de diff commence par la section 'FAILED' on ne commite pas! Cela veut dire que certains tests n'ont pas réussi à tourner jusqu'au bout (d'où le nom de failed). Il faut donc comprendre pourquoi, modifier son code et/ou ses tests, et relancer les tests. 
  
-{{:commit:failed.png?|}}+{{ :commit:failed.png?direct&600 }}
  
-Deuxième chose à regarder, le rouge ! Un résultat est affiché en rouge si la donnée que l'on est censé observé est manquante. Il y a deux cas possibles : +Deuxième chose à regarder, le rouge! Un résultat est affiché en rouge si la donnée que l'on est censé observé est manquante. Il y a deux cas possibles : 
     * Si on a ajouté un nouveau test, il n'était pas dans la batterie précédemment. Par conséquent, la donnée manquante (''missing!'') se trouve dans la colonne ''old'' (voir ci-dessus, test ''filageExtrusion''). C'est un cas tout à fait normal.     * Si on a ajouté un nouveau test, il n'était pas dans la batterie précédemment. Par conséquent, la donnée manquante (''missing!'') se trouve dans la colonne ''old'' (voir ci-dessus, test ''filageExtrusion''). C'est un cas tout à fait normal.
-    * Par contre, si le ''missing!'' se trouve dans la colonne ''new'', c'est plus embêtant, cela veut dire qu'une grandeur qui était obtenue précédemment, dans la version officielle, ne l'est plus ! Plusieurs possibilités : +    * Par contre, si le ''missing!'' se trouve dans la colonne ''new'', c'est plus embêtant, cela veut dire qu'une grandeur qui était obtenue précédemment, dans la version officielle, ne l'est plus! Plusieurs possibilités : 
       * Soit le test correspondant est également dans la section des failed. Facile à comprendre, le test n'a pas pu tourner jusqu'au bout, donc n'a pas pu écrire les résultats, ce qui explique le ''missing!''. Il faut comprendre pourquoi et refaire tourner le test (voir ci-dessus, test ''backwardExtrusion3DRemeshing'').       * Soit le test correspondant est également dans la section des failed. Facile à comprendre, le test n'a pas pu tourner jusqu'au bout, donc n'a pas pu écrire les résultats, ce qui explique le ''missing!''. Il faut comprendre pourquoi et refaire tourner le test (voir ci-dessus, test ''backwardExtrusion3DRemeshing'').
       * Soit le test correspondant n'est pas dans les failed, mais l'utilisateur a volontairement modifié les données qui sont écrites. Dans ce cas-là tout va bien.        * Soit le test correspondant n'est pas dans les failed, mais l'utilisateur a volontairement modifié les données qui sont écrites. Dans ce cas-là tout va bien. 
       * Enfin, le test n'est toujours pas dans les failed, mais l'utilisateur n'a normalement rien modifié. C'est une situation anormale, il faut investiguer.        * Enfin, le test n'est toujours pas dans les failed, mais l'utilisateur n'a normalement rien modifié. C'est une situation anormale, il faut investiguer. 
  
-Troisième chose à regarder, les diffs proprement dites. Une fois qu'on n'a plus de tests dans les failed, et qu'on a compris tout ce qui est en rouge, on regarde les valeurs. C'est ici que c'est difficile, et que ça demande de l'expérience pour vraiment comprendre, car beaucoup de test changent légèrement selon les machines. Blueberry est normalement la plus stable; je conseille donc de d'abord regarder les changements sur cette machine-là. Quelques conseils : +Troisième chose à regarder, les diffs proprement dites. Une fois qu'on n'a plus de tests dans les failed, et qu'on a compris tout ce qui est en rouge, on regarde les valeurs. C'est ici que c'est difficile, et que ça demande de l'expérience pour vraiment comprendre, car beaucoup de tests changent légèrement selon les machines. La machine spring est normalement la plus stable; je conseille donc de d'abord regarder les changements sur cette machine-là.  
 + 
 +Quelques conseils: 
   * La première série, "STP", affiche le nombre de steps d'une simulation. Cela peut changer d'un cas à l'autre, mais normalement pas beaucoup. Regarder donc que la variation relative ne soit pas trop élévée.   * La première série, "STP", affiche le nombre de steps d'une simulation. Cela peut changer d'un cas à l'autre, mais normalement pas beaucoup. Regarder donc que la variation relative ne soit pas trop élévée.
   * Deuxième série, "ITE", nombre d'itérations mécaniques d'une simulation. Même remarque que pour les steps.    * Deuxième série, "ITE", nombre d'itérations mécaniques d'une simulation. Même remarque que pour les steps. 
Line 216: Line 210:
   * Huit, "MEM", mémoire, idem CPU.   * Huit, "MEM", mémoire, idem CPU.
  
-Il faut noter qu'il y a des tests qui sont connus pour être instables. Il est assez fréquent que, les tests "mtFrequencyAnalysis", "mtSuperElement", "apps.XFEM" et d'autres présentes des diffs sans raison apparente. Petit conseil pour distinguer les "vrais diffs" des autres, lancer deux séries de batteries, une avec la version officielle de Metafor à laquelle on ne touche pas, une avec la version de développement. Ca permet de détecter les diffs à prendre en compte et celles qui ne sont pas graves (si pas de diff entre les diffs de Offi et Dev, on peut commiter)+Il faut noter qu'il y a des tests qui sont connus pour être instables. Il est assez fréquent que, les tests "mtFrequencyAnalysis", "mtSuperElement", "apps.XFEM" et d'autres présentes des diffs sans raison apparente. Petit conseil pour distinguer les "vrais diffs" des autres, lancer deux séries de batteries, une avec la version officielle de Metafor à laquelle on ne touche pas, une avec la version de développement. Ça permet de détecter les diffs à prendre en compte et celles qui ne sont pas graves (si pas de diff entre les diffs de Offi et Dev, on peut commiter)
  
 === 5.2 Relancer certains tests === === 5.2 Relancer certains tests ===
Line 224: Line 218:
 Si par contre les erreurs proviennent des tests eux-mêmes (donc que l'on a modifié les tests mais pas le code source), il suffit alors de relancer juste les tests en question. Si par contre les erreurs proviennent des tests eux-mêmes (donc que l'on a modifié les tests mais pas le code source), il suffit alors de relancer juste les tests en question.
  
-<note important> La moindre erreur de manipulation à ce stade conduit très vite à effacer tous les résultats de votre batterie ! Attention donc, quand ça arrive, on râle... </note>+<note important> La moindre erreur de manipulation à ce stade conduit très vite à effacer tous les résultats de votre batterie! Attention donc, quand ça arrive, on râle... </note>
  
-Sur les stations. Plusieurs façons de faire, j'en présente une qui me semble la plus simple : +Sur les stations. Plusieurs façons de faire, j'en présente une qui me semble la plus simple: 
   * Transférer via Filezilla les différents tests qui ont été modifiés.    * Transférer via Filezilla les différents tests qui ont été modifiés. 
   * Toujours via Filezilla, se rendre dans ''oo_metaB/bin'' et supprimer les fichiers .res des tests en question.    * Toujours via Filezilla, se rendre dans ''oo_metaB/bin'' et supprimer les fichiers .res des tests en question. 
Line 242: Line 236:
  
 ==== 6. Le commit proprement dit ==== ==== 6. Le commit proprement dit ====
 +
 Le moment tant attendu arrive enfin: on commite ! Le moment tant attendu arrive enfin: on commite !
  
 === 6.1 Commiter sur son PC === === 6.1 Commiter sur son PC ===
  
-D'abord, on parcourt l'ensemble des fichiers modifiés pour écrire proprement sa page de commit. Cette page a pour but garder des traces des changements et d'expliquer aux collègues le travail réalisé. Il faut donc qu'elle soit suffisamment détaillée pour donner une idée précise de ce qui a été fait, mais il faut aussi éviter de rentrer trop dans les détails pour qu'on en aille pas marre de lire après un paragraphe (et qu'on rate des infos super importantes écrites à la ligne 124587).+D'abord, on parcourt l'ensemble des fichiers modifiés pour écrire proprement sa page de commit. Cette page a pour but de garder des traces des changements et d'expliquer aux collègues le travail réalisé. Il faut donc qu'elle soit suffisamment détaillée pour donner une idée précise de ce qui a été fait.
  
 <note>Si on modifie dans son commit des fonctions qui sont utilisés pour construire un cas-test, il faut le préciser dans sa page de commit, [[doc:user:general:syntaxchange|sur cette page]] et également mettre une petite bombe à coté de son commit ! </note> <note>Si on modifie dans son commit des fonctions qui sont utilisés pour construire un cas-test, il faut le préciser dans sa page de commit, [[doc:user:general:syntaxchange|sur cette page]] et également mettre une petite bombe à coté de son commit ! </note>
  
-Ensuite, on clique droit successivement sur ''linuxbin'', ''oo_meta'', ''oo_nda'', puis on va sur "Tortoise SVN" et sur "Check for modifications". Dans la fenêtre qui s'ouvre, on coche "show unversioned files" et "show ignored files".{{ :commit:svncheck.png |Je regarde mes fichiers modifiés.}}{{ :commit:svncheck2.png?688 |Je regarde mes fichiers modifiés.}}+Ensuite, on clique droit successivement sur ''oo_meta'', ''oo_nda'', puis on va sur "Tortoise SVN" et sur "Check for modifications". Dans la fenêtre qui s'ouvre, on coche "show unversioned files" et "show ignored files". 
 + 
 +{{ :commit:svncheck.png?direct&500 |Je regarde mes fichiers modifiés.}} 
 + 
 +{{ :commit:svncheck2.png?direct&600 |Je regarde mes fichiers modifiés. }} 
 + 
 +Concernant les "non-unversioned" (c'est à dire les nouveaux fichiers que l'on a créé), on rajoute ceux qu'il faut ajouter. Cela se fait par clique droit sur les fichiers, ''tortoise svn add'', sans oublier d'indiquer '' \$Id\$ '' au début de chaque fichier. 
  
-Concernant les "non-unversioned" (c'est à dire les nouveaux fichiers que l'on a créé), on rajoute ceux qu'il faut ajouter. Cela se fait par clique droit sur les fichiers, ''tortoise svn add'', sans oublier d'indiquer '' \$Id: \$ '' au début de chaque fichier. {{ :commit:svnadd.png |J'ajoute mes nouveaux fichiers.}}+{{ :commit:svnadd.png?direct&600 |J'ajoute mes nouveaux fichiers.}}
  
-Ensuite, on clique droit sur oo_meta, oo_nda et/ou linuxbin (seulement ceux où des modifications doivent être commitées) et on clique sur "SVN commit". On prend note des fichiers ajoutés, supprimés et déplacés avant de fermer la fenêtre svn pour vérifier que se page de commit est bien complète {{ :commit:svncommit.png |Je commite mes brols!}}\\+Ensuite, on clique droit sur oo_meta, oo_nda (seulement ceux où des modifications doivent être commitées) et on clique sur "SVN commit". On prend note des fichiers ajoutés, supprimés et déplacés avant de fermer la fenêtre SVN pour vérifier que se page de commit est bien complète {{ :commit:svncommit.png |Je commite mes brols!}}\\
  
-=== 6.2 Commiter sur Blueberry  ===+=== 6.2 Commiter sur spring  ===
  
 On se connecte avec [[http://www.putty.org/|PuTTy]] et on tape : On se connecte avec [[http://www.putty.org/|PuTTy]] et on tape :
Line 291: Line 292:
 </code> </code>
  
-=== 6.3 Commiter sur Thorgal === +=== 6.3 Commiter sur thorgal et gaston ===
-<code> +
-cd /home/$USER/Metafor/oo_meta/apps/verif +
-svn commit *Linux64-gcc.txt +
-</code>+
  
-L'éditeur de texte ''vi'' [[http://www.unix-manuals.com/tutorials/vi/vi-in-10-1.html|vi Tutorial]] se lance dans l'invite de commande. Si on ne désire pas ajouter de commentaires supplémentaires dans le fichier texte ouvert, on tape  +Faire la même chose sur thorgal (''*Linux64-gcc.txt'') et gaston (''*Linux64-clang.txt'').
-<code> +
-:wq +
-</code> +
-c'est-à-dire "write" et "quit"+
  
-Ensuite, il suffit de choisir l'option "continue", c'est-à-dire taper "c", et d'insérer son mot de passe "svn" pour effectuer le commit. 
-<code> 
-Log message unchanged or not specified 
-(a)bort, (c)ontinue, (e)dit :  
-</code> 
  
-<code> +==== 7Vérifications ====
-+
-Password: +
-Sending    CPU-Linux64-gcc.txt +
-Sending    EXT-Linux64-gcc.txt  +
-Sending    EXW-Linux64-gcc.txt +
-Sending    INW-Linux64-gcc.txt +
-Sending    ITE-Linux64-gcc.txt +
-Sending    LKS-Linux64-gcc.txt +
-Sending    MEM-Linux64-gcc.txt  +
-Sending    STP-Linux64-gcc.txt +
-Transmitting file data ........ +
-Committed revision 1676. +
-</code>+
  
-==== 7. Vérifications ==== 
 A présent, le commit est supposé terminé, les étapes suivantes sont de la vérification. A présent, le commit est supposé terminé, les étapes suivantes sont de la vérification.
-  * Sur PC : refaire un checkout des sources, puis recompiler le projet (ou mettre à jour sa version officielle et la recompiler). Puis on lance ''apps.qs.cont2'' pour voir si tout va bien. +  * Sur PC : refaire un checkout des sources, puis recompiler le projet (ou mettre à jour sa version officielle et la recompiler). Puis on lance par exemple ''apps.qs.cont2'' pour voir si tout va bien. 
-  * Sur les stations, on fait un check out des sources et on recompile les sources avec comp.py avec les options suivantes : +  * Sur les stations, on fait un checkout des sources et on recompile les sources avec ''comp.py'' avec les options suivantes : 
     * 1 source - checkout     * 1 source - checkout
     * 2 compile - True     * 2 compile - True
Line 334: Line 308:
 <note important>Le checkout via comp.py nécessite de pouvoir se connecter sans mot de passe. Sinon, on va juste se faire bannir, ce qui n'a pour seul intérêt que de mettre Luc de mauvais humeur... [[devel:compillinux|Procédure alternative]]</note> <note important>Le checkout via comp.py nécessite de pouvoir se connecter sans mot de passe. Sinon, on va juste se faire bannir, ce qui n'a pour seul intérêt que de mettre Luc de mauvais humeur... [[devel:compillinux|Procédure alternative]]</note>
  
-{{ :commit:verif.png |Je vérifie que tout compile encore sur les stations.}}+{{ :commit:verif2.png?direct&600 |Je vérifie que tout compile encore sur les stations.}}
  
 ==== 8. Informer les autres ==== ==== 8. Informer les autres ====
Line 349: Line 323:
 ==== 9. Fêter ça ==== ==== 9. Fêter ça ====
  
-Amener de la tarte ou du gâteau pour fêter son commit réussi. Malheureusement, il s'agit d'une tradition qui se perd, on ne mange plus du gateau que pour les anniversaires. C'est bien triste, surtout quand on voit comme ils étaient heureux à l'époque : +Amener de la tarte ou du gâteau pour fêter son commit réussi. Malheureusement, il s'agit d'une tradition qui se perd, on ne mange plus du gâteau que pour les anniversaires. C'est bien triste, surtout quand on voit comme ils étaient heureux à l'époque: 
  
-{{ :commit:fetecommit.jpg |Youpi! J'ai fini mon commit!}}+{{ :commit:fetecommit.jpg?direct&600 |Youpi! J'ai fini mon commit!}}
commit/memocommit.1466086943.txt.gz · Last modified: 2016/06/16 16:22 by papeleux

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki