diff --git a/Outils/bib.rst b/Outils/bib.rst
index f011349ece0bef62bb87889e6dfd7ef88ef23395..e0c502f565a8c6ea5c49c660bfb0f937812b35ab 100644
--- a/Outils/bib.rst
+++ b/Outils/bib.rst
@@ -6,13 +6,17 @@
Bibliographie
*************
+.. spelling::
-.. [DeveloppezMake] Introduction à Makefile, http://gl.developpez.com/tutoriel/outil/makefile/
+ Makefile
+ The
+ Make
+ Honeyford
+ Manual
+.. [DeveloppezMake] Introduction à Makefile, http://gl.developpez.com/tutoriel/outil/makefile/
.. [GNUMake] The GNU Make Manual, http://www.gnu.org/software/make/manual/make.html
-
-
.. [Honeyford2006] Honeyford, M., `Speed your code with the GNU profiler`, http://www.ibm.com/developerworks/library/l-gnuprof.html
diff --git a/Outils/cunit.rst b/Outils/cunit.rst
index ef2f27cecfe2888a076977145c19bba4351c5376..2a303ab58c5198db1b4db421313c4e0e85d72f0e 100644
--- a/Outils/cunit.rst
+++ b/Outils/cunit.rst
@@ -8,7 +8,7 @@ CUnit: librairie de tests
-------------------------
`CUnit <http://cunit.sourceforge.net>`_ est une librairie de tests unitaires
-en C. Cette librarie vous sera utile lors de développement de projets en C.
+en C. Cette librairie vous sera utile lors de développement de projets en C.
Installation
^^^^^^^^^^^^
@@ -76,7 +76,7 @@ tests.
Pour pouvoir concrètement exécuter un ensemble de tests, il est nécessaire
de réaliser les différentes étapes suivantes:
-1. Ecrire les tests
+1. Programmer les tests
2. Initialiser le catalogue
3. Ajouter les suites de tests dans le catalogue
4. Ajouter les tests dans les suites de tests
@@ -89,7 +89,7 @@ Tout d'abord, il est nécessaire d'écrire les tests. Aucune libraire ne peut
les écrire pour vous. Toutefois, CUnit vient avec un certain nombre de macros
permettant de vérifier les propriétés qui nous intéressent. Pour pouvoir
utiliser ces macros, il est nécessaire d'importer ``CUnit.h``. La table
-suivante récapitule les principales macros. Il est important d'appeller ces
+suivante récapitule les principales macros. Il est important d'appeler ces
macros lorsque l'on rédige les tests, ce sont ces appels qui détermineront si
oui ou non, le test est fructueux.
@@ -155,12 +155,17 @@ vérification des tests. Par exemple,
if (CUE_SUCCESS != CU_initialize_registry())
return CU_get_error();
+.. spelling::
+
+ setup
+ teardown
+
Pour ajouter les suites de tests au catalogue, il faut faire appel à la
méthode ``CU_add_suite(const char* strName, CU_InitializeFunc pInit,
CU_CleanupFunc pClean)``. Comme on peut le voir, cette méthode demande un nom
(qui doit être unique pour un catalogue) ainsi que deux pointeurs de fonction.
Ces pointeurs de fonction permettent d'exécuter du code avant (typiquement
-appelé 'setup') ou après (typiquement 'teardown') l'exécution des tests de la
+appelé `setup`) ou après (typiquement `teardown`) l'exécution des tests de la
suite. Ces méthodes sont utiles pour initialiser un environnement d'exécution
pour des tests le nécessitants (par exemple, s'assurer de la présence de
fichier, initialiser certaines variables, etc.). Ces méthodes sont bien sûr
diff --git a/Outils/gcc.rst b/Outils/gcc.rst
index 826d44c880c70e5a6e11a87883079808ef0c2699..511a8084aa2dcbcecb28acce9895fc0161615f16 100644
--- a/Outils/gcc.rst
+++ b/Outils/gcc.rst
@@ -8,11 +8,11 @@ GCC
---
-Comme cela a déja été dit, le compilateur fonctionne selon 4 étapes distinctes:
- * Appel du préprocesseur ``cpp``: Supprime les commentaires, inclus les #includes et évalue les macros
+Comme cela a déjà été dit, le compilateur fonctionne selon 4 étapes distinctes:
+ * Appel du préprocesseur ``cpp``: Supprime les commentaires, inclus les `#include` et évalue les macros
* Appel du compilateur ``cc1``: Génère un fichier assembleur (.as)
* Appel de l'assembleur ``as`` : Génère le fichier objet (.o)
- * Appel du linkeur ``ld`` : Génère l'exécutable
+ * Appel du de l'éditeur de liens ``ld`` : Génère l'exécutable
Différentes options peuvent être utilisé avec gcc :
@@ -26,11 +26,16 @@ Différentes options peuvent être utilisé avec gcc :
* -On : Indique le niveau d'optimisation où n est compris entre 0 et 3
* -Wall : Active tout les warnings
* -Werror : Considère tout les warnings comme des erreurs
+ * --help : Messages d'aide
- * --help
+Notons que les trois premières options ne présentent pas d'intérêt pour ce cours.
-Notons que les trois premières options ne présentent pas d'interêt pour ce cour.
+.. spelling::
+
+ help
+
+
diff --git a/Outils/gdb.rst b/Outils/gdb.rst
index 04a8df09f3f5f891e268516ea5d750667626a454..970c7eacf5598c57b3e7219127d29e7598411f8e 100644
--- a/Outils/gdb.rst
+++ b/Outils/gdb.rst
@@ -1,7 +1,17 @@
.. -*- coding: utf-8 -*-
-.. Copyright |copy| 2012 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch, Grégory Detal et Nicolas Houtain
+.. Copyright |copy| 2012, 2020 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch, Grégory Detal et Nicolas Houtain
.. Ce fichier est distribué sous une licence `creative commons <http://creativecommons.org/licenses/by-sa/3.0/>`_
+.. spelling::
+
+ breakpoint
+ Breakpoint
+ breakpoints
+ frame
+ display
+ displays
+ débugger
+
.. _gdb-ref:
GDB
@@ -18,7 +28,7 @@ Liste des commandes
L'option -g de `gcc(1)`_ place dans l'exécutable les informations sur les noms de variables, mais aussi tout le code source.
-Lancez gdb avec la commande ``gdb my_program``. Ceci va vous ouvrir la console de ``gdb`` qui vous permet de lancer, le programme et de l'analyser. Pour démarrer le programme, tapez ``run``. gdb va arrêter l'exécution au premier problème trouvé. Votre programme tourne encore pour l'instant. Arrètez-le avec la commande ``kill``.
+Lancez gdb avec la commande ``gdb my_program``. Ceci va vous ouvrir la console de ``gdb`` qui vous permet de lancer, le programme et de l'analyser. Pour démarrer le programme, tapez ``run``. gdb va arrêter l'exécution au premier problème trouvé. Votre programme tourne encore pour l'instant. Arrêtez-le avec la commande ``kill``.
Breakpoint
^^^^^^^^^^
@@ -82,7 +92,7 @@ Automatisation
Lors d'un débuggage long et fastidieux, il est parfois nécessaire d'exécuter certaines commandes à chaque breakpoint.
- * ``commands [numerobreakpoint]`` definit une liste de commandes associées à un breakpoint. Celles ci seront exécutées quand on s'arrêtera sur ce breakpoint. Il suffit de taper les commandes à effectuer les unes après les autres et de terminer par ``end``. Si vous ne fournissez pas de numéro, les commandes sont assignées au dernier breakpoint créé.
+ * ``commands [numerobreakpoint]`` définit une liste de commandes associées à un breakpoint. Celles ci seront exécutées quand on s'arrêtera sur ce breakpoint. Il suffit de taper les commandes à effectuer les unes après les autres et de terminer par ``end``. Si vous ne fournissez pas de numéro, les commandes sont assignées au dernier breakpoint créé.
* ``display [variablename]`` affiche la variable à chaque breakpoint.
Gestion des Signaux
@@ -95,9 +105,9 @@ Il est possible de gérer le comportement de `gdb(1)`_ lorsque des signaux sont
Localiser un signal
"""""""""""""""""""
-Avec `gdb(1)`_, il est possible de localiser un signal et de débugguer certaines erreurs comme une erreur de segmentation. En effet, lorsque `gdb(1)`_ interrompt le programme en cours après l'interception d'un signal d'erreur comme ``SIGSEGV``, il est possible de trouver la ligne du programme à laquelle le signal a été intercepté en tapant le mot-clé ``where`` une fois le programme interrompu (il est cependant nécessaire d'avoir compilé le programme avec l'option ``-g`` de ``gcc`` pour trouver la ligne précise). Ensuite, grâce aux commandes expliquées plus tôt, il est possible de vérifier les valeurs des variables lors de l'interception du signal pour trouver l'origine du problème.
+Avec `gdb(1)`_, il est possible de localiser un signal et de débugger certaines erreurs comme une erreur de segmentation. En effet, lorsque `gdb(1)`_ interrompt le programme en cours après l'interception d'un signal d'erreur comme ``SIGSEGV``, il est possible de trouver la ligne du programme à laquelle le signal a été intercepté en tapant le mot-clé ``where`` une fois le programme interrompu (il est cependant nécessaire d'avoir compilé le programme avec l'option ``-g`` de ``gcc`` pour trouver la ligne précise). Ensuite, grâce aux commandes expliquées plus tôt, il est possible de vérifier les valeurs des variables lors de l'interception du signal pour trouver l'origine du problème.
-En plus de localiser facilement les erreurs de segmentation dans un programme, vous pourrez annalyser plus aisément les problèmes de deadlock des threads. En effet, lorsque le programme est lancé sur le shell et que vous remarquez un deadlock, vous pouvez appuyer sur ``CTRL + C`` pour lancer le signal ``SIGINT`` au programme. Cela permettra de trouver les endroits où bloquent les différents threads du programme à l'aide des commandes décrites dans la section de débuggage des threads ci-dessous.
+En plus de localiser facilement les erreurs de segmentation dans un programme, vous pourrez analyser plus aisément les problèmes de deadlock des threads. En effet, lorsque le programme est lancé sur le shell et que vous remarquez un deadlock, vous pouvez appuyer sur ``CTRL + C`` pour lancer le signal ``SIGINT`` au programme. Cela permettra de trouver les endroits où bloquent les différents threads du programme à l'aide des commandes décrites dans la section de débuggage des threads ci-dessous.
Extraction de code assembleur
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -105,13 +115,16 @@ Extraction de code assembleur
* ``disas`` affiche le code assembleur
* ``disas /m blah`` met en correspondance le code assembleur et le code source
-Pour arrêter la console de gdb, tappez ``quit``.
+Pour arrêter la console de gdb, tapez ``quit``.
Illustration avec des exemples
------------------------------
-.. A titre d'exemple, télécharger l'archive :download:`src/gdb.c`. L'archive contient un Makefile qui vous permettra de compiler plusieurs programmes.
+.. spelling::
+ calc
+ factTmp
+ tab
Premier programme
^^^^^^^^^^^^^^^^^
@@ -156,8 +169,10 @@ Premier programme
Deuxième programme
^^^^^^^^^^^^^^^^^^
- Le deuxième programme est appelé :download:`src/recursive.c`. Celui ne présente aucun bug et se déroulera normalement. Toutefois, il est intéressant d'utiliser `gdb(1)`_ pour bien comprendre les différents contextes au sein d'un programme. Mettez un break sur la fonction factTmp avec ``break factTmp`` et ajoutez automatiquement à ce breakpoint la commande ``backtrace``, via ``commands``. Ensuite, lancez le programme.
- ``backtrace`` vous permet de visualiser les appels de fonction effectués. Nous pouvons voir que la fonction factTmp a été appellée par factTerminal, elle même appellée par la fonction main.
+
+
+ Le deuxième programme est appelé :download:`src/recursive.c`. Celui ne présente aucun bug et se déroulera normalement. Toutefois, il est intéressant d'utiliser `gdb(1)`_ pour bien comprendre les différents contextes au sein d'un programme. Mettez un break sur la fonction ``factTmp avec`` ``break factTmp`` et ajoutez automatiquement à ce breakpoint la commande ``backtrace``, via ``commands``. Ensuite, lancez le programme.
+ ``backtrace`` vous permet de visualiser les appels de fonction effectués. Nous pouvons voir que la fonction ``factTmp`` a été appelée par ``factTerminal``, elle même appelée par la fonction ``main``.
.. code-block:: console
@@ -165,10 +180,10 @@ Deuxième programme
#1 0x000000000040057d in factTerminal (a=6) at recursive.c:17
#2 0x0000000000400598 in main (argc=1, argv=0x7fffffffe1b8) at recursive.c:23
- Essayez d'afficher les variable ``globalVar`` puis ``localVar``. Vous remarquerez qu'il n'est pas possible d'afficher ``localVar`` puisque cette variable ne fait pas partie de l'environement contextuel de factTmp. Pour afficher cette variable, il faut remonter la liste des appels. ``up`` permettra de remonter les appels pour pouvoir afficher ``localVar``.
+ Essayez d'afficher les variable ``globalVar`` puis ``localVar``. Vous remarquerez qu'il n'est pas possible d'afficher ``localVar`` puisque cette variable ne fait pas partie de l'environnement contextuel de factTmp. Pour afficher cette variable, il faut remonter la liste des appels. ``up`` permettra de remonter les appels pour pouvoir afficher ``localVar``.
Une fois la variable affichée, redescendez avec ``down`` et continuez 4 fois le programme après le breakpoint. Vous remarquerez que la liste des appels s'allonge à chaque appel récursif, ce qui est tout à fait normal.
- Naviguez dans les appels recursifs de factTmp en affichant les valeur de ``globalTmp``, ``tmp``, ``acc`` et ``nbr``. Il est important de bien comprendre que la variable statique ``globalTmp`` est commune à tous les appels de la fonction ``factTmp`` et un changement de cette variable dans un des appels récursifs modifie la variable des autres appels. A contrario, la variable local ainsi que les arguments sont propres à chaque appel.
+ Naviguez dans les appels récursifs de factTmp en affichant les valeur de ``globalTmp``, ``tmp``, ``acc`` et ``nbr``. Il est important de bien comprendre que la variable statique ``globalTmp`` est commune à tous les appels de la fonction ``factTmp`` et un changement de cette variable dans un des appels récursifs modifie la variable des autres appels. A contrario, la variable local ainsi que les arguments sont propres à chaque appel.
Vous pouvez maintenant terminer le programme.
@@ -200,7 +215,7 @@ Débuggage des threads avec GDB
`gdb(1)`_ est aussi utile pour débugger des programmes avec des threads. Il permet de faire les opérations suivantes sur les threads:
- * Etre notifié lors de la création d'un nouveau thread.
+ * Recevoir une notification lors de la création d'un nouveau thread.
* Afficher la liste complète des threads avec ``info threads``.
* Placer un breakpoint dans un thread. En effet, si vous placez un breakpoint dans une certaine fonction, et un thread passe lors de son exécution à travers ce breakpoint, ``gdb`` va mettre l'exécution de tous les threads en pause et changer le contexte de la console `gdb(1)`_ vers ce thread.
* Lorsque les threads sont en pause, vous pouvez manuellement donner la main à un thread en faisant ``thread [thread_no]`` avec ``thread_no`` étant l'indice du thread comme indiqué par ``info threads``
diff --git a/Outils/git.rst b/Outils/git.rst
index 1ed46aca1af0f075b8bff951cdffec895a5b0ba2..d213164428bb2782aab3e7746a6586742d527f31 100644
--- a/Outils/git.rst
+++ b/Outils/git.rst
@@ -2,34 +2,64 @@
.. Copyright |copy| 2013 by Benoit Legat
.. Ce fichier est distribué sous une licence `creative commons <http://creativecommons.org/licenses/by-sa/3.0/>`_
+.. spelling::
+ kernel
+ committé
+ committées
+ respécifier
+ l'email
+ GitHub
+ remote
+ push
+ pusher
+ pushé
+ staging
+ area
+ committer
+ snapshot
+ noeud
+ noeuds
+ staging
+ Staging
+ committons
+ Committons
+ committés
+ Branching
+ request
+ committait
+ check
+ backtrace
+ git
+
+.. _git-ref:
+
Git
---
Introduction
~~~~~~~~~~~~
-`Git`_ a été développé initialement pour la gestion du code source du kernel Linux.
+`git(1)`_ a été développé initialement pour la gestion du code source du kernel Linux.
Il est aussi utilisé pour la gestion des sources de ce document
depuis https://github.com/obonaventure/SystemesInformatiques.
On l'utilise le plus souvent à l'aide de l'utilitaire `git(1)`_ mais il
existe aussi des
`applications graphiques <http://git-scm.com/downloads/guis>`_.
-Les différentes versions sont enregistrées dans des commits qui sont liées
-au commit constituant la version précédente.
-On sait ainsi facilement voir ce qui a changé entre deux versions
-(pas spécialement, une version et la suivante)
-et même restaurer l'état de certains fichiers à une version sauvegardée
-dans un commit.
-Du coup, si vous utilisez `Git`_ pour un projet, vous ne pouvez jamais
-perdre plus que les changements que vous n'avez pas encore committé.
-Toutes les versions du codes déjà committées sont sauvegardées et facilement
-accessibles.
-Cette garantie est extrêmement précieuse et constitue à elle seule une raison
-suffisante d'utiliser `Git`_ pour tous vos projets.
+Les différentes versions sont enregistrées dans des commits qui sont
+liées au commit constituant la version précédente. On sait ainsi
+facilement voir ce qui a changé entre deux versions (pas spécialement,
+une version et la suivante) et même restaurer l'état de certains
+fichiers à une version sauvegardée dans un commit. Du coup, si vous
+utilisez `git(1)`_ pour un projet, vous ne pouvez jamais perdre plus
+que les changements que vous n'avez pas encore committé. Toutes les
+versions du codes déjà committées sont sauvegardées et facilement
+accessibles. Cette garantie est extrêmement précieuse et constitue Ã
+elle seule une raison suffisante d'utiliser `git(1)`_ pour tous vos
+projets.
Contrairement à `subversion`_, il est décentralisé, c'est à dire que chaque
-développeur a toute l'information nécessaire pour utiliser `Git`_,
+développeur a toute l'information nécessaire pour utiliser `git(1)`_,
il ne doit pas passer par un serveur où les données sont centralisées Ã
chaque commande.
Cela prend éventuellement plus d'espace disque mais comme on travaille
@@ -39,12 +69,12 @@ On a pas besoin d'être connecté au serveur pour l'utiliser,
il est beaucoup plus rapide
et chaque développeur constitue un backup du code, ce qui est confortable.
-De plus, comme on va le voir, `Git`_ supporte une gestion des commits
+De plus, comme on va le voir, `git(1)`_ supporte une gestion des commits
très flexible avec un historique pas linéaire
mais composés de plusieurs branches et il
permet aux développeurs de ne pas avoir toutes les branches en local.
-Cette efficacité de `Git`_ et sa flexibilité sont ses arguments majeurs et
+Cette efficacité de `git(1)`_ et sa flexibilité sont ses arguments majeurs et
leur origine est évidente quand on sait qu'il a été créé pour gérer des projets
aussi complexes que le kernel Linux.
Il est parfois critiqué pour sa complexité mais c'est surtout dû au fait
@@ -58,9 +88,9 @@ qu'il a une façon assez différente de fonctionner des autres.
Utilisation linéaire de Git
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-On peut utiliser `Git`_ Ã plusieurs niveaux.
+On peut utiliser `git(1)`_ Ã plusieurs niveaux.
On peut tout à fait avoir un historique linéaire tout en profitant pleinement
-de `Git`_.
+de `git(1)`_.
Pour ceux dont c'est la première fois qu'ils utilisent un système de contrôle
de version,
il vaut peut-être mieux commencer par ne lire que cette partie et
@@ -79,20 +109,20 @@ Un historique linéaire est un historique comme on l'imagine avec des versions
l'une après l'autre, chaque version étendant la précédente avec
certaines modifications.
On verra par après qu'il est possible d'avoir un historique non-linéaire
-avec `Git`_ mais ce n'est pas indispensable.
+avec `git(1)`_ mais ce n'est pas indispensable.
-Sur `Git`_, on appelle une version un *commit*.
+Sur `git(1)`_, on appelle une version un *commit*.
Chacun de ces commits est documenté en fournissant le nom de l'auteur,
son email, un commentaire et une description (optionnelle).
Pour ne pas devoir respécifier le nom et l'email à chaque fois,
-on le stoque dans le fichier de configuration de `Git`_ ``~/.gitconfig``.
+on le stocke dans le fichier de configuration de `git(1)`_ ``~/.gitconfig``.
Bien qu'on peut l'éditer manuellement, on préfère le faire à l'aide de
la commande `git-config(1)`_.
Pour spécifier le commentaire,
`git-commit(1)`_ ouvrira un éditeur de texte.
Pour entrer une description, laissez une ligne vide puis écrivez la.
-L'éditeur de texte à ouvrir est déterminé par `Git`_ en fonction de la variable
+L'éditeur de texte à ouvrir est déterminé par `git(1)`_ en fonction de la variable
``core.editor`` du fichier de configuration mentionné plus haut.
Vous pouvez aussi spécifier le commentaire à l'aide de l'option ``-m``
de `git-commit(1)`_ comme on verra dans les exemples par après.
@@ -108,13 +138,13 @@ Vous devez bien entendu remplacer les valeurs par celles qui vous conviennent.
$ git config --global core.editor gedit
L'option ``--global`` spécifie qu'on veut que ces configurations s'appliquent
-pour tous nos dépôts (`Git`_ éditera le fichier ``~/.gitconfig``).
+pour tous nos dépôts (`git(1)`_ éditera le fichier ``~/.gitconfig``).
Sinon, `git-config(1)`_ ne modifie que le fichier
``.git/config`` à l'intérieur du *git directory* du projet en cours.
Ce dernier prône bien entendu sur ``~/.gitconfig`` quand une variable
a des valeurs différentes dans ``~/.gitconfig`` et ``.git/config``.
-Vous voilà paré pour créer votre premier dépôt `Git`_
+Vous voilà paré pour créer votre premier dépôt `git(1)`_
mais avant de voir comment faire des nouveaux commits,
il est impératif de comprendre ce qu'est la *staging area*.
@@ -136,8 +166,8 @@ Voyons tout ça avec un programme exemple qui affiche en LaTex
la somme des entiers de :math:`1` Ã :math:`n`.
On va utiliser les commandes
- * `git-init(1)`_ qui permet de transformer un projet en dépôt `Git`_
- (tout est stoqué dans le dossier ``.git``);
+ * `git-init(1)`_ qui permet de transformer un projet en dépôt `git(1)`_
+ (tout est stocké dans le dossier ``.git``);
* `git-diff(1)`_ qui donne la différence entre l'état des fichiers dans le
*working directory* avec leur état dans le *git directory*
au commit actuel;
@@ -174,9 +204,9 @@ Ce programme fonctionne comme suit
On va sauvegarder un premier commit contenant cette version de ``main.c``
-`git-init(1)`_ permet d'initialiser le dépôt `Git`_.
+`git-init(1)`_ permet d'initialiser le dépôt `git(1)`_.
`git-status(1)`_ analyse le contenu du répertoire.
-Il indique que le fichier ``main.c`` n'est pas suivi par `Git`_ (`untracked`).
+Il indique que le fichier ``main.c`` n'est pas suivi par `git(1)`_ (`untracked`).
Ce fichier est ajouté avec la commande `git-add(1)`_.
`git-commit(1)`_ sauvegarde cette version du code dans un commit
dont le commentaire, spécifié avec l'option ``-m``, est *First commit*.
@@ -370,7 +400,7 @@ dans un commit au commentaire *Fix SIGSEV*
Travailler à plusieurs sur un même projet
#########################################
-`Git`_ est déjà un outil très pratique à utiliser seul mais c'est quand
+`git(1)`_ est déjà un outil très pratique à utiliser seul mais c'est quand
on l'utilise pour se partager du code qu'il devient vraiment indispensable.
On se partage le code par l'intermédiaire de *remotes*.
Ce sont en pratique des serveurs auxquels on peut avoir l'accès lecture et/ou
@@ -385,10 +415,10 @@ Alice va créer le projet avec
$ git init
Initialized empty Git repository in /path/to/project/.git/
-puis elle créera une *remote*, c'est à dire un autre dépôt `Git`_ que celui
+puis elle créera une *remote*, c'est à dire un autre dépôt `git(1)`_ que celui
qu'ils ont en local, avec lequel ils vont pouvoir synchroniser leur
historique.
-Supposons qu'ils aient un projet *projectname* sur Github.
+Supposons qu'ils aient un projet *projectname* sur GitHub.
Vous pouvez créer le *remote* comme suit
.. code-block:: bash
@@ -402,14 +432,14 @@ et ajouter vos modifications avec ``git push origin master``.
Si vous exécutez ``git pull origin master``, que vous faites quelques
commits et puis que vous essayer de mettre *origin* Ã jour avec
``git push origin master``,
-il faut qu'aucun autre développeur n'ait pushé de modification entre temps.
-S'il en a pushé, `Git`_ ne saura pas effectuer votre *push*.
+il faut qu'aucun autre développeur n'ait poussé de modification entre temps.
+S'il en a poussé, `git(1)`_ ne saura pas effectuer votre *push*.
Il vous faudra alors faire un *pull*.
-`Git`_ tentera alors de fusionner vos changements avec ceux d'*origin*.
+`git(1)`_ tentera alors de fusionner vos changements avec ceux d'*origin*.
Si ces derniers sont à une même ligne d'un même fichier, il vous demandera
de résoudre le conflit vous-même.
Il est important pour cela que vous ayez commité vos changements avant
-le *pull* sinon `Git`_ l'abandonnera car il ne sait que fusionner des commits.
+le *pull* sinon `git(1)`_ l'abandonnera car il ne sait que fusionner des commits.
C'est à dire que ce qu'il y a dans le *git directory*,
pas ce qu'il y a dans le *working directory* ni dans la *staging area*.
@@ -540,8 +570,8 @@ puis essaie de les pusher
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
-mais `Git`_ lui fait bien comprendre que ce n'est pas possible.
-En faisant le *pull*, on voit que `Git`_ fait de son mieux pour
+mais `git(1)`_ lui fait bien comprendre que ce n'est pas possible.
+En faisant le *pull*, on voit que `git(1)`_ fait de son mieux pour
fusionner les changements mais qu'il préfère nous laisser
choisir quelle ligne est la bonne
@@ -642,29 +672,29 @@ Paul peut alors récupérer les changements avec
La plupart des fusions ne demande pas d'intervention manuelle mais
dans les cas comme celui-ci,
-`Git`_ n'a pas d'autre choix que de nous demander notre avis.
+`git(1)`_ n'a pas d'autre choix que de nous demander notre avis.
Contribuer au syllabus
######################
Dans le cas du syllabus, vous n'avez pas l'accès écriture.
-La manière dont Github fonctionne pour règler ça c'est que vous *forkez* le
+La manière dont GitHub fonctionne pour régler cela c'est que vous *forkez* le
projet principal.
C'est à dire que vous en faites un copie indépendante à votre nom.
À celle là vous avez l'accès écriture.
Vous allez ensuite soumettre vos changements sur celle là puis les
-proposer à travers l'interface de Github qu'on appelle *Pull request*.
+proposer à travers l'interface de GitHub qu'on appelle *Pull request*.
Conventionnellement, on appelle la *remote* du dépôt principal *upstream*
et la votre *origin*.
-Commencez donc par vous connecter sur Github, allez Ã
+Commencez donc par vous connecter sur GitHub, allez Ã
l'`adresse du code du syllabus
<https://github.com/obonaventure/SystemesInformatiques/>`_ et cliquez
sur *Fork*.
Vous pouvez maintenant obtenir le code du syllabus avec la commande
`git-clone(1)`_
-(remplacez ``username`` par votre nom d'utilisateur sur Github)
+(remplacez ``username`` par votre nom d'utilisateur sur GitHub)
.. code-block:: bash
@@ -694,7 +724,7 @@ Une fois vos changements commités, vous pouvez les ajouter à *origin* avec
Votre amélioration devrait normalement être visible via
`https://github.com/obonaventure/SystemesInformatiques/network <https://github.com/obonaventure/SystemesInformatiques/network>`_.
-Vous pouvez maintenant aller sur Github à la page de votre fork et
+Vous pouvez maintenant aller sur GitHub à la page de votre fork et
cliquer sur *Pull Requests* puis *New pull request* et expliquer
vos changements.
@@ -716,7 +746,7 @@ puis faire un nouveau pull request.
Utilisation non-linéaire de Git
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`Git`_ peut créer un historique non-linéaire semblable à celui ci-dessous.
+`git(1)`_ peut créer un historique non-linéaire semblable à celui ci-dessous.
C'est un exemple un peu exagéré de non-linéarité mais il est
pédagogiquement intéressant.
@@ -726,7 +756,7 @@ c'est à dire que les arêtes ont une direction.
Les noeuds sont de 3 types,
- en bleu, on a les commits, c'est comme un snapshot, c'est une
description complète de l'état de tous les fichiers pris en
- charge par `Git`_ à un moment donné.
+ charge par `git(1)`_ à un moment donné.
Ces commits sont
- soit construits comme la version suivante d'un autre commit
@@ -761,7 +791,7 @@ Les noeuds sont de 3 types,
Manipulation de l'historique à travers les commandes Git
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Pour initialiser un dépôt `Git`_,
+Pour initialiser un dépôt `git(1)`_,
il suffit d'utiliser la commande `git-init(1)`_
.. code-block:: bash
@@ -775,7 +805,7 @@ Staging area
############
Commençons par définir les 4 statuts qu'un fichier peut avoir
- - il peut être non-traqué par `Git`_, c'est à dire qu'il n'est
+ - il peut être non-traqué par `git(1)`_, c'est à dire qu'il n'est
ni dans le *git directory*, ni dans la *staging area*.
C'est un fichier que le autres développeurs peuvent ne même pas être
au courant que vous l'avez dans votre *working directory*.
@@ -831,7 +861,7 @@ Dans la partie ``Changes to be committed``,
on a les fichiers au statut *staged*.
Dans la partie ``Changes not staged for commit``,
on a les fichiers au statut modifié.
-Les fichiers au statut non-modifié ne sont pas affichés et ceux non-trackés
+Les fichiers au statut non-modifié ne sont pas affichés et ceux non-suivis
sont dans la partie ``Untracked files`` sauf si on a spécifiquement demandé
de les ignorer dans le fichier ``.gitignore``.
En effet, on peut s'imaginer que dans un gros projet, la partie
@@ -839,12 +869,12 @@ En effet, on peut s'imaginer que dans un gros projet, la partie
distinguer les fichiers qu'il faut penser à ajouter de ceux qu'il faut
ignorer une fois de plus.
-Lorsque `Git`_ voit un fichier ``.gitignore`` dans un dossier,
+Lorsque `git(1)`_ voit un fichier ``.gitignore`` dans un dossier,
il en prend compte pour tous ses fichiers ainsi que tous les fichiers des
sous-dossiers.
La syntaxe est très simple, on spécifie un fichier par ligne,
on utilise un ``*`` pour spécifier n'importe
-quelle chaine de charactères, les commentaires commencent par un ``#``
+quelle chaîne de caractères, les commentaires commencent par un ``#``
comme en Bash et si la ligne commence par un ``!``,
on demande de ne pas ignorer ce fichier à l'intérieur du dossier même
si un ``.gitignore`` d'un dossier parent dit le contraire.
@@ -857,20 +887,20 @@ Dans notre exemple, ``.gitignore`` aura le contenu suivant
# Executable
a.out
-Pour faire passer un fichier du statut modifié au status *staged*,
+Pour faire passer un fichier du statut modifié au statut *staged*,
il faut utiliser `git-add(1)`_.
-Lorsqu'on lui donne en argument un fichier modifié, elle ajoute sa version
+Lorsque l'on lui donne en argument un fichier modifié, elle ajoute sa version
avec toutes les modifications dans la *staging area*.
Si on lui donne un dossier,
elle ajoute tous les fichiers au statut modifié ou
-au statut non-traqué qui ne sont pas ignoré par `Git`_.
+au statut non-traqué qui ne sont pas ignoré par `git(1)`_.
.. code-block:: bash
$ git add .
On peut aussi donner l'option ``-p`` Ã `git-add(1)`_,
-`Git`_ demandera alors pour chaque bloc de modification s'il faut le prendre
+`git(1)`_ demandera alors pour chaque bloc de modification s'il faut le prendre
en compte puis ajoutera dans la *staging area* un fichier avec toutes
ces modifications.
C'est très utile si on a fait différents changements dans un fichier mais
@@ -979,10 +1009,10 @@ Voyons à présent comment committer
les fichiers présents dans la *staging area*.
Comme vu précédemment,
il y a toujours un commit actif,
-c'est comparativement à ce dernier que `Git`_ détermine si un fichier est
+c'est comparativement à ce dernier que `git(1)`_ détermine si un fichier est
modifié ou pas.
-Lorqu'on choisit de committer ce qu'il y a dans la *staging area*,
+Quand on choisit de committer ce qu'il y a dans la *staging area*,
un nouveau commit est créé avec le même état que le précédent plus les
modifications des fichiers au statut *staged*.
Ce nouveau commit a une référence vers le commit précédent.
@@ -1014,10 +1044,10 @@ On voit que la branche active a avancé alors que les autres n'ont pas bougé.
Historique après le commit
-Lorsqu'on fait ``gcc main.c`` un fichier ``a.out`` est généré.
-Il est inutile de suivre ses changements à travers `Git`_ car ses modifications
+Lorsque l'on exécute ``gcc main.c`` un fichier ``a.out`` est généré.
+Il est inutile de suivre ses changements à travers `git(1)`_ car ses modifications
ne sont que l'image des modifications de ``main.c``.
-De plus, ce n'est pas un fichier texte donc `Git`_ ne verra pas ce qui
+De plus, ce n'est pas un fichier texte donc `git(1)`_ ne verra pas ce qui
a changé, il fera comme si tout ``a.out`` avait changé.
.. code-block:: bash
@@ -1059,9 +1089,9 @@ On verra des exemples d'utilisation par après.
Branching
~~~~~~~~~
-Lorsqu'on exécute ``git init``, une branche au nom de ``master`` est créée.
+Quand on exécute ``git init``, une branche au nom de ``master`` est créée.
Beaucoup de petits projets se contentent de cette branche et n'en font pas
-d'autre mais c'est passer à côté d'un des aspects les plus pratiques de `Git`_.
+d'autre mais c'est passer à côté d'un des aspects les plus pratiques de `git(1)`_.
Une utilisation classique des branches sont les *feature branches*.
C'est à dire qu'on a la branche principale ``master`` qui contient un code
@@ -1084,6 +1114,10 @@ chez aucun des deux développeurs.
Créer une branche
#################
+.. spelling::
+
+ pid
+
Pour créer une branche, on utilise la commande `git-branch(1)`_.
`git-branch(1)`_ sert aussi à montrer la liste des branches avec
le caractère ``*`` devant la branche active.
@@ -1091,7 +1125,7 @@ le caractère ``*`` devant la branche active.
Par exemple, supposons qu'on veuille ajouter à notre exemple la possibilité
de changer le message un caractère plus universel pour que le programme soit
utilisable pour tout citoyen de l'univers.
-Mais qu'on veut aussi ajouter un aspect pratique en rajoutant le pid
+Mais qu'on veut aussi ajouter un aspect pratique en rajoutant le `pid`
du processus et du processus parent.
On commencera par créer deux *feature branches*, ``pid`` et ``universal``.
@@ -1178,18 +1212,18 @@ Après le *checkout*, le contenu de ``main.c`` vaut
}
S'il y a des fichiers modifiés au moment du `git-checkout(1)`_,
-`Git`_ va faire du mieux qu'il peut pour changer de branche en gardant
+`git(1)`_ va faire du mieux qu'il peut pour changer de branche en gardant
vos modifications mais si le fichier modifié est justement un fichier
qui diffère entre l'ancienne branche active et la nouvelle branche active,
-`Git`_ va abandonner le changement de branche car mettre ce fichier Ã
+`git(1)`_ va abandonner le changement de branche car mettre ce fichier Ã
la version de la nouvelle branche écraserait les modifications.
Les changements doivent alors soit être committés,
-soit sauvegardés par `git-stash(1)`_ (détailllé plus loin),
+soit sauvegardés par `git-stash(1)`_ (détaillé plus loin),
soit abandonnés.
Pour abandonner des changements et revenir à la version du commit référencé
par la branche active, on utilise aussi `git-checkout(1)`_.
-Avec `Git`_, pas mal de commandes ont de multiples usages.
+Avec `git(1)`_, pas mal de commandes ont de multiples usages.
Dans notre exemple, si on change ``main.c``, cela pose problème car il
diffère entre ``master`` et ``pid`` mais
@@ -1215,7 +1249,7 @@ les a laissées lorsqu'on exécute ``git checkout master``
Fusionner des branches
######################
-Lorsqu'on fusionne deux branches,
+Quand on fusionne deux branches,
le rôle de chaque branche n'est pas le même.
Il y a la branche active et la branche qu'on veut fusionner.
Par la règle *il n'y a toujours que la branche active qui est modifée*,
@@ -1230,14 +1264,14 @@ Deux cas peuvent se présenter
- soit ce commit parent est le commit référencé par la branche active,
dans lequel cas, on dira que la fusion est *fast-forward*.
- `Git`_ fera alors simplement la branche active pointer vers le commit
+ `git(1)`_ fera alors simplement la branche active pointer vers le commit
référencé par la branche qu'on veut fusionner;
- soit ce commit parent est le commit référencé par la branche qu'on veut
- fusionner, dans lequel cas, `Git`_ ne fera rien car le commit référencé
+ fusionner, dans lequel cas, `git(1)`_ ne fera rien car le commit référencé
par la branche active contient déjà les modifications de l'autre puisque
c'est un de ses commits parents;
- soit ce commit est différent des deux commits en question.
- Dans ce cas, `Git`_ créera un commit ayant deux parents, les deux commits
+ Dans ce cas, `git(1)`_ créera un commit ayant deux parents, les deux commits
en questions et tentera de fusionner toutes les modifications depuis
le commit parent commun.
Bien entendu, plus ce commit commun est loin, plus il y aura de modification
@@ -1248,20 +1282,20 @@ Deux cas peuvent se présenter
LÃ encore, il y a deux cas
- - soit `Git`_ arrive à tout fusionner, c'est à dire que les modifications
+ - soit `git(1)`_ arrive à tout fusionner, c'est à dire que les modifications
sont soit dans des fichiers différents, soit à des endroits bien
distincts d'un même fichier;
- soit il n'y arrive pas. Il fusionnera alors le plus possible lui-même
et marquera dans le fichier les confits à gérer à la main.
- Il faudra alors ouvrir le fichier et régler puis avertir à `Git`_
+ Il faudra alors ouvrir le fichier, les corriger puis indiquer à `git(1)`_
qu'il peut terminer la fusion.
- En peut aussi dire qu'on abandonne la fusion et `Git`_ retire tout
+ En peut aussi dire qu'on abandonne la fusion et `git(1)`_ retire tout
ce qu'il a fait pour la fusion.
- Dans les deux cas, si on abandonne pas, `Git`_ créera ce commit
+ Dans les deux cas, si on abandonne pas, `git(1)`_ créera ce commit
de fusion et fera pointer la branche active vers ce dernier.
-Il est important de réinsister sur le fait que
+Il est important d'insister à nouveau sur le fait que
la branche non-active n'a pas été modifiée par la fusion.
Par contre si on la rend active et
qu'on demande de la fusionner avec l'ancienne branche active,
@@ -1399,7 +1433,7 @@ C'est ce qu'on va vérifier
1 file changed, 5 insertions(+)
create mode 100644 Makefile
-On voit que `Git`_ a su faire la fusion sans notre aide sans problème
+On voit que `git(1)`_ a su faire la fusion sans notre aide sans problème
car tous les changements étaient dans le ``Makefile`` qui n'existait pas
pour ``universal``
@@ -1419,7 +1453,7 @@ pour ``universal``
1 file changed, 5 insertions(+)
create mode 100644 Makefile
-`Git`_ nous confirme que c'est *fast-forward*
+`git(1)`_ nous confirme que c'est *fast-forward*
.. figure:: figures/hello_pid_makefile.png
:align: center
@@ -1494,7 +1528,7 @@ Retournons sur notre branche ``universal`` et essayons notre ``Makefile``
make: *** [run] Segmentation fault (core dumped)
Les deux premières lignes sont simplement les commandes que `make(1)`_ exécute.
-La troisième est plus inquiètante.
+La troisième est plus inquiétante.
Elle nous avertit que le programme a été terminé par le signal ``SIGSEV``.
C'est dû au fait qu'on ne vérifie pas que ``argv`` ait au moins 2 éléments
avant d'essayer accéder au deuxième élément.
@@ -1535,7 +1569,7 @@ avant d'essayer accéder au deuxième élément.
Historique après avoir réparé le ``Segmentation fault``
-``universal`` est maintenant prêt à être mergée.
+``universal`` est maintenant prêt à être fusionnée.
.. code-block:: bash
@@ -1580,11 +1614,11 @@ Les conflits sont marqués dans ``main.c``
Il nous faut maintenant éditer ``main.c`` pour résoudre le conflit.
Il n'y a un conflit à un seul endroit du fichier mais le conflit est assez
-large, `Git`_ nous montre ce qu'il y a pour ``HEAD`` c'est à dire
+large, `git(1)`_ nous montre ce qu'il y a pour ``HEAD`` c'est à dire
la branche active ``master`` et ce qu'il y a pour ``universal``.
On va devoir prendre un peu des deux.
-Si on fait `git-diff(1)`_ par la suite, `Git`_ met en début de ligne un
+Si on fait `git-diff(1)`_ par la suite, `git(1)`_ met en début de ligne un
``+`` ou un ``-`` en premier caractère
si c'est une ligne qui vient de la branche qu'on veut fusionner,
en deuxième caractère si ça vient de la branche active et en premier et
@@ -1619,7 +1653,7 @@ deuxième caractère si ça vient d'aucune des deux pour le ``+``.
}
Il n'y a pas besoin de spécifier de commentaire pour une fusion car
-`Git`_ en génère un automatiquement
+`git(1)`_ en génère un automatiquement
.. code-block:: bash
@@ -1855,7 +1889,7 @@ Il ajoutera alors les modifications au commit actuel au lieu d'en créer un
nouveau.
On peut aussi annuler le dernier commit avec ``git reset HEAD^``.
-`Git`_ permet aussi de construire un commit qui a l'effet inverse d'un autre
+`git(1)`_ permet aussi de construire un commit qui a l'effet inverse d'un autre
avec `git-revert(1)`_.
Ce dernier construit un commit qui annulera l'effet d'un autre commit.
Voyons tout ça par un exemple qui pourrait être le code de *Deep Thought*.
@@ -2054,7 +2088,7 @@ supprimons ce dernier commit
Corriger des bugs grâce à Git
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Git permet de garder des traces des nombreux changements qui ont été effectué au
+git(1) permet de garder des traces des nombreux changements qui ont été effectué au
cours de l’évolution d’un programme. Il contient d’ailleurs un outil très
puissant vous permettant de retrouver la source de certaines erreurs, pourvu que
les changements soient faits par petits commits : `git-bisect(1)`_.
@@ -2070,7 +2104,7 @@ important. Ce que vous cherchez, c’est la source de l’erreur ; cela fait, la
corriger sera sans l’ombre d’un doute une tâche aisée. Si seulement il était
possible de voir à partir de quel changement le bug a été introduit…
-C’est là que vous repensez à Git ! Git connaît tous les changements qui ont été
+C’est là que vous repensez à `git(1)`_ ! `git(1)`_ connaît tous les changements qui ont été
effectués, et vous permet facilement de revenir dans le passé pour vérifier si
le bug était présent à un moment donné. En outre, vous vous rappelez vos cours
d’algorithmiques et vous rendez compte que, puisque vous connaissez un point où
@@ -2089,7 +2123,7 @@ bien.
Pour vous montrez comme utiliser cette fonctionnalité, et vous convaincre que
cela marche vraiment, et pas seulement dans des exemples fabriqués uniquement
dans un but de démonstration, nous allons l’appliquer à un vrai programme C :
-mruby, une implémentation d’un langage correspondant à un sous-ensemble de Ruby.
+``mruby``, une implémentation d’un langage correspondant à un sous-ensemble de Ruby.
Intéressons nous à `un des problèmes qui a été rapporté par un utilisateur
<https://github.com/mruby/mruby/issues/1583>`_. Si vous lisez cette page, vous
@@ -2099,7 +2133,7 @@ verrez que le développeur a bien dû changer une ligne introduite dans le commi
qui avait été accusé par l’utilisateur.
Mettons nous dans la peau de l’utilisateur qui a trouvé le bug, et tentons nous
-aussi d’en trouver la cause, en utilisant Git. D’abord, il nous faut obtenir le
+aussi d’en trouver la cause, en utilisant `git(1)`_ . D’abord, il nous faut obtenir le
dépôt sur notre machine (vous aurez besoin de Ruby afin de pouvoir tester),
et revenir dans le passé puisque, depuis, l’erreur a été corrigée.
@@ -2142,7 +2176,7 @@ incluse dans la backtrace :
[0] /home/kilian/code/rb/test.rb:13
/home/kilian/code/rb/test.rb:9: undefined method 'd' for #<A:0xdf1000> (NoMethodError)
-C’est le moment de commencer. Il faut d’abord dire à Git que nous désirons
+C’est le moment de commencer. Il faut d’abord dire à `git(1)`_ que nous désirons
démarrer une bissection et que le commit actuel est « mauvais », c’est à dire
que le bug est présent. Ceci est fait en utilisant les deux lignes suivantes,
dans l’ordre :
@@ -2169,7 +2203,7 @@ utiliser ``make clean`` pour s’assurer de tout recompiler ici) :
[0] /home/kilian/code/rb/test.rb:13
/home/kilian/code/rb/test.rb:9: undefined method 'd' for #<A:0x165d2c0> (NoMethodError)
-Cette fois-ci, tout va bien. Nous pouvons donc en informer Git :
+Cette fois-ci, tout va bien. Nous pouvons donc en informer `git(1)`_ :
.. code-block:: console
@@ -2177,10 +2211,10 @@ Cette fois-ci, tout va bien. Nous pouvons donc en informer Git :
Bisecting: 116 revisions left to test after this (roughly 7 steps)
[fe1f121640fbe94ad2e7fabf0b9cb8fdd4ae0e02] Merge pull request #1512 from wasabiz/eliminate-mrb-intern
-Ici, Git nous dit combien de révisions il reste à vérifier dans l’intervalle en
+Ici, `git(1)`_ nous dit combien de révisions il reste à vérifier dans l’intervalle en
plus de nous donner une estimation du nombre d’étapes que cela prendra. Il nous
informe aussi de la révision vers laquelle il nous a déplacé. Nous pouvons donc
-réitérer notre test et en communiquer le résultat à Git :
+réitérer notre test et en communiquer le résultat à `git(1)`_ :
.. code-block:: console
@@ -2198,7 +2232,7 @@ réitérer notre test et en communiquer le résultat à Git :
Si nous réessayons, nous allons nous rendre compte que notre teste échoue Ã
présent (il manque la ligne ``[1]``): nous somme allés trop loin dans le
-futur. Il nous faudra donc dire à Git que la révision est mauvaise.
+futur. Il nous faudra donc dire à `git(1)`_ que la révision est mauvaise.
.. code-block:: console
@@ -2214,7 +2248,7 @@ futur. Il nous faudra donc dire à Git que la révision est mauvaise.
[9b2f4c4423ed11f12d6393ae1f0dd4fe3e51ffa0] move declarations to the beginning of blocks
Si vous continuez à appliquer cette procédure, vous allez finir par trouver la
-révision fautive, et Git nous donnera l’information que nous recherchions, comme
+révision fautive, et `git(1)`_ nous donnera l’information que nous recherchions, comme
par magie :
.. code-block:: console
@@ -2241,7 +2275,7 @@ par magie :
:040000 040000 5040dd346fea4d8f476d26ad2ede0dc49ca368cd 903f2d954d8686e7bfa7bcf5d83b80b5beb4899f M src
Maintenant que nous connaissons la source du problème, il ne faut pas oublier de
-confirmer à Git que la recherche est bien terminée, et que nous désirons
+confirmer à `git(1)`_ que la recherche est bien terminée, et que nous désirons
remettre le dépôt dans son état normal.
.. code-block:: console
@@ -2277,7 +2311,7 @@ N’oubliez pas de changer les permissions du script pour en permettre l’exéc
Ce test n’est en bien sûr pas infaillible, mais sera suffisant ici. Il faut
-d’abord redonner à Git l’intervalle dans lequel se trouve la révision fautive.
+d’abord redonner à `git(1)`_ l’intervalle dans lequel se trouve la révision fautive.
.. code-block:: console
@@ -2293,7 +2327,7 @@ d’abord redonner à Git l’intervalle dans lequel se trouve la révision faut
Il suffit maintenant d’utiliser ``git bisect run`` avec le nom du script pour
l’utiliser. Il est possible de rajouter d’autres arguments après le nom du
script, qui seront passés au script lors de chaque exécution. Par exemple, si
-vous avez dans votre Makefile une tâche test qui renvoie 0 si tous les tests
+vous avez dans votre ``Makefile`` une tâche test qui renvoie 0 si tous les tests
passent et 1 si certains échouent, alors ``git bisect run make test``
permettrait de trouver à partir de quand les tests ont cessé de fonctionner.
@@ -2318,49 +2352,8 @@ compilations, le même résultat qu’avant :
À nouveau, n’oubliez pas d’utiliser ``git bisect reset`` avant de continuer Ã
travailler sur le dépôt.
-.. `subversion`_ (ou abrégé `svn(1)`_) est un logiciel qui permet à plusieurs utilisateurs de travailler sur les mêmes documents de type texte. `Subversion`_ est fréquemment utilisé pour gérer du code source développé de façon collaborative, mais il peut aussi servir à gérer n'importe quel ensemble de fichiers (de préférence textes) manipulés par plusieurs personnes.
-
-.. Dans le cadre du cours SINF1252 vous devez vous inscrire à subversion dans le projet ``SINF1252_2012`` en suivant le lien et les instructions sur http://wiki.student.info.ucl.ac.be/index.php/Svn
-
-.. Pour commencer l'utilisation de `svn(1)`_ vous devriez faire d'abord un ``checkout`` du répertoire:
-
- .. code-block:: console
-
- $ svn checkout <url de votre répertoire>
- Checked out revision 1.
-
-.. Ceci installe votre répertoire (ici, nommé ``my_rep``) dans le dossier courant. Vous pouvez vous déplacer dans le nouveau dossier et créer un nouveau dossier pour cet premier projet. Il faut explicitement ajouter ce dossier à svn avec la commande ``svn add [nom du dossier]``. Chaque fichier et dossier dont vous voulez qu'il fasse partie du contrôle de version doivent être ajoutés avec cette commande.
-
- .. code-block:: console
-
- $ cd my_rep
- $ mkdir projet_S1
- $ svn add projet_S1
- A projet_S1
-
-.. Ce dossier n'a pas encore été envoyé sur le serveur principal et n'est donc pas encore visible pour d'autres utilisateurs. Pour afficher l'état de votre répertoire utilisez ``svn status``. La lettre ``A`` indique que ceci est un nouveau dossier/fichier pas encore envoyé vers le serveur. ``?`` indique que les fichiers/dossiers ne font pas partie du répertoire svn (on peut les ajouter avec ``svn add``). ``M`` indique que les fichiers sont modifiés localement mais pas encore envoyés vers le serveur. Ces fichiers font partie du répertoire svn.
-
- .. code-block:: console
-
- $ svn status
- A projet_S1
- $ svn commit -m "Projet S1: Initialisation"
- Adding projet_S1
- Transmitting file data .
- Committed revision 2.
-
-.. La commande ``svn commit`` permet de pousser les changements locaux et les nouveaux fichiers vers le serveur. La chaîne de charactères entre les ``"`` est le commentaire qu'il faut ajouter au commit. Il est important de commenter vos commits pour que vous puissiez vous retrouvez dans votre historique. L'historique de votre répertoire peut être affiché avec la commande ``svn log``.
-
-.. Les autres utilisateurs de votre répertoire (c'est-à -dire dans le cadre de ce cours: vôtre binôme du groupe) peuvent à partir de maintenant accéder à ce nouveau dossier en mettant à jour son répertoire local.
-.. Pour mettre à jour le répertoire local, on utilise la commande ``svn update``.
-
- .. code-block:: console
-
- $ svn update
- Updating '.':
- A projet_S1
- Updated to revision 2.
-
-.. Il est recommandé de toujours faire un ``update`` avant de faire un ``commit``. Lors d'un update il est possible qu'un conflit se crée dans votre dossier local. Ceci peut arriver si vous avez modifié une ligne dans un fichier localement et que cette ligne a aussi été modifiée par le commit d'un autre utilisateur. Pour résoudre le conflit, vous devez éditer le fichier que svn a indiqué être en conflit en cherchant des lignes qui commencent par ``<<<``. Corrigez ce fichier et retournez dans la console et tapez ``r`` pour indiquer à svn que ce conflit a été résolu.
+.. spelling::
-.. Pour plus d'informations sur svn regardez les commandes ``svn help``, ``svn help [commande]`` ou http://svnbook.red-bean.com/. Une recherche sur Google vous aidera aussi pour résoudre vos problèmes avec subversion.".."
+ mruby
+ Makefile
+ deadline
diff --git a/Outils/gprof.rst b/Outils/gprof.rst
index d6729663c41daf77bb51e55c604dcabfc6d4d7f4..5f0a950bca3c731c439e96816e032adfc4bab991 100644
--- a/Outils/gprof.rst
+++ b/Outils/gprof.rst
@@ -2,6 +2,10 @@
.. Copyright |copy| 2012 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch et Grégory Detal
.. Ce fichier est distribué sous une licence `creative commons <http://creativecommons.org/licenses/by-sa/3.0/>`_
+.. spelling::
+
+ Profiling
+
.. _gprof:
Profiling de code
diff --git a/Outils/intro-outils.rst b/Outils/intro-outils.rst
index 244cfd856b3710e6d99e2dd95e562997914a89b6..7434c54b044bf7fc739ed989bb5eba7f56281202 100644
--- a/Outils/intro-outils.rst
+++ b/Outils/intro-outils.rst
@@ -5,8 +5,14 @@
Introduction
============
-Outre des compétences théoriques qui sont abordées dans d'autres parties de ce document, la maitrise d'une système informatique implique également une excellente connaissance des outils informatiques qui sont inclus dans ce système. Cette connaissance se construit bien entendu en utilisant activement ces logiciels. Cette section comprend les informations de bases sur quelques logiciels importants qui sont utilisés dans le cadre du cours. Elle est volontairement réduite car de nombreux logiciels pourraient faire l'objet de livres complets. Les étudiants sont invités à proposer des améliorations à cette section sous la forme de patches via https://github.com/obonaventure/SystemesInformatiques
+Outre des compétences théoriques qui sont abordées dans d'autres parties de ce document, la maîtrise d'une système informatique implique également une excellente connaissance des outils informatiques qui sont inclus dans ce système. Cette connaissance se construit bien entendu en utilisant activement ces logiciels. Cette section comprend les informations de bases sur quelques logiciels importants qui sont utilisés dans le cadre du cours. Elle est volontairement réduite car de nombreux logiciels pourraient faire l'objet de livres complets. Les étudiants sont invités à proposer des améliorations à cette section sous la forme de patches via https://github.com/UCL-INFI/SyllabusC
+.. spelling::
+
+ Editeurs
+ emacs
+ Tetris
+
Editeurs
========
diff --git a/Outils/make.rst b/Outils/make.rst
index b07aafff86a93e847dcd1e64a4e27dbfea52fa23..1d5d54b982c03301474c49afbf3f31ec3cbf9754 100644
--- a/Outils/make.rst
+++ b/Outils/make.rst
@@ -2,6 +2,14 @@
.. Copyright |copy| 2012 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch et Grégory Detal
.. Ce fichier est distribué sous une licence `creative commons <http://creativecommons.org/licenses/by-sa/3.0/>`_
+.. spelling::
+
+ Makefile
+ Makefiles
+ Make
+ make
+
+
.. _make:
Introduction aux Makefiles
@@ -60,7 +68,7 @@ Comme ``text.txt`` dépend de ``name.txt``, il faut que ce dernier soit défini
Salut,
Tintin
-Lorsqu'une dépendance change, ``make`` le détecte et ré-exécute les commandes associées à la cible. Dans le cas suivant, le fichier ``name.txt`` est modifié, ce qui force la regénération du fichier ``text.txt``.
+Lorsqu'une dépendance change, ``make`` le détecte et ré-exécute les commandes associées à la cible. Dans le cas suivant, le fichier ``name.txt`` est modifié, ce qui force une nouvelle génération du fichier ``text.txt``.
.. code-block:: console
@@ -113,6 +121,10 @@ Vous pouvez donc très bien utiliser la variable ``$(HOME)`` indiquant le réper
Il existe six différentes manières d'assigner une valeur à une variable. Nous ne nous intéresserons qu'à quatre d'entre elles.
+.. spelling::
+
+ value
+
.. code-block:: make
VARIABLE = value
@@ -186,7 +198,7 @@ Une bonne pratique est de déclarer dans ``.PHONY`` toutes les règles de nettoy
clean:
rm -f *.o
-Cela est aussi pratique pour forcer une re-compilation.
+Cela est aussi pratique pour forcer une nouvelle compilation.
.. code-block:: make
@@ -213,7 +225,7 @@ Cette syntaxe est semblable au script shell.
build:
gcc -o foo foo.c # commentaire en fin de ligne
-Débugger les erreurs de vos Makefiles peut sembler difficile lorsque vous êtes baignés dans un flux d'instructions. Vous pouvez néanmoins régler leur verbosité.
+Corriger les erreurs de vos Makefiles peut sembler difficile lorsque vous êtes baignés dans un flux d'instructions. Vous pouvez néanmoins régler leur verbosité.
Il est possible de rendre silencieuse une commande en plaçant une arobase devant. Ceci indique juste à Make de ne pas imprimer la ligne de commande. La sortie
standard de cette commande restera visible.
diff --git a/Outils/shell.rst b/Outils/shell.rst
index 4369778e6f2d47b3ba2ff34ddb660faa2dd23601..c11a97e442712dd59eb68b86a442f7bf64b31db7 100644
--- a/Outils/shell.rst
+++ b/Outils/shell.rst
@@ -13,7 +13,12 @@ Dans le cadre de ce cours nous utiliserons l'interpréteur `bash(1)`_. Cet exéc
Le shell est un outil très puissant. Il permet d'effectuer de nombreuses opérations qui peuvent difficilement être réalisées manuellement ou via une interface graphique.
+.. spelling::
+ tab
+ regex
+ gz
+
.. note:: Astuce : utilisez la complétion
Lors de la frappe d'un nom de fichier, d'un chemin d'accès ou même d'une commande tapez sur la touche ``<tab>`` pour "compléter" le mot que vous écrivez. Si rien ne se passe tapez deux fois <tab> pour obtenir la liste des possibilités.
@@ -32,6 +37,10 @@ Expressions régulières
Avant de commencer à voir les commandes utiles avec le shell, il est important de définir ce qu'est une expression régulière (`regex(3)`). Les expressions régulières caractérisent des chaînes de caractères et elles sont utiles pour de nombreuses commandes. Nous l'utiliserons notamment pour faire une recherche dans un fichier.
+.. spelling::
+
+ er
+
Dans une regex, certains caractères ont une signification particulière :
============= ==================================== ====================================================
@@ -80,9 +89,13 @@ La commande `ls(1)`_ permet de connaître l'ensemble des fichiers et répertoire
* ``-F`` : Positionne à la fin des noms de fichier un ``/`` pour les répertoires et ``*`` pour les fichiers exécutables
* ``-a`` : Affiche tous les fichiers, y compris les fichiers cachés (ceux qui commencent par le caractère ``.`` )
- * ``-d`` : Evite de lister le contenu d'un répertoire : si `rep` est un répertoire, ``ls -l`` `rep` listera le contenu du répertoire `rep`, alors que ``ls -ld`` `rep` listera la description du répertoire
+ * ``-d`` : Ne liste pas le contenu d'un répertoire : si `rep` est un répertoire, ``ls -l`` `rep` listera le contenu du répertoire `rep`, alors que ``ls -ld`` `rep` listera la description du répertoire
* ``-l`` : Description complète du contenu d'un répertoire (une ligne par fichier)
+.. spelling::
+
+ filename
+
Avec l'option ``-l``, le premier caractère de la ligne indique le type du fichier. Le caractère ``-`` correspond à un fichier standard et ``d`` à un répertoire. Il est aussi possible de connaître le contenu d'un autre répertoire que le répertoire courant en fournissant le nom de ce répertoire comme argument à la commande ``ls``.
.. code-block:: console
@@ -97,6 +110,12 @@ Avec l'option ``-l``, le premier caractère de la ligne indique le type du fichi
Manipulation de fichiers
------------------------
+.. spelling::
+
+ irf
+ opt
+
+
Créer et détruire
^^^^^^^^^^^^^^^^^
@@ -105,25 +124,37 @@ Créer et détruire
* `echo(1)`_ mon_texte > filename crée un fichier avec "mon_texte" dedans.
`rm(1)`_ [-irf] files efface les fichiers
- * -i : intéractif, demande une confirmation sur chaque fichier
+ * -i : interactif, demande une confirmation sur chaque fichier
* -f : force la suppression du fichier
* -r : efface un répertoire et son contenu
Visualiser
^^^^^^^^^^
+.. spelling::
+
+ vET
+ vE
+ cat
+ ctrl
+ sX
+ s'XXX
+
+
* `cat(1)`_ [-opt] f1 f2 concatène et affiche les deux fichiers.
* `cat(1)`_ [-opt] file affiche le fichier sur la sortie standard.
* -v : convertit les caractères spéciaux en caractères affichables
* -n : numérote les lignes
* -b : numérote seulement les lignes non vides
- * -E : affiche le symbôle $ à la fin de chaque ligne
+ * -E : affiche le symbole $ Ã la fin de chaque ligne
* -T : affiche les caractères de tabulation comme ^I
* -A : équivalent à -vET
* -e : équivalent à -vE
* -t : équivalent à -vT
+
+
Avec cat, il est possible d'écrire depuis la console dans un fichier.
Appuyez sur ctrl+D au début d'une ligne pour terminer la saisie
@@ -170,8 +201,8 @@ Modifier
* -a : change uniquement la date d'accès du fichier
`split(1)`_ [-opt] file [out] coupe le fichier en plusieurs petites parties
- * -b nbr : decoupe selon un nombre d'octets
- * -n nbr : decoupe selon un nombre de lignes
+ * -b nbr : découpe selon un nombre d'octets
+ * -n nbr : découpe selon un nombre de lignes
Extraction de données
^^^^^^^^^^^^^^^^^^^^^
@@ -179,9 +210,9 @@ Extraction de données
`grep(1)`_ [-opt] regex file recherche l'expression dans les fichiers.
* -i : ignore la casse
* -v : affiche les lignes ne contenant pas l'expression.
- * -c : compte les lignes ne contenant pas la chaine
+ * -c : compte les lignes ne contenant pas la chaîne
* -n : numérote chaque ligne contenant la chaîne
- * -x : affiche les lignes correspondant exactement à la chaine
+ * -x : affiche les lignes correspondant exactement à la chaîne
`uniq(1)`_ [-opt] filename affiche le fichier en supprimant les lignes qui se répètent successivement.
* -u : Affiche seulement les lignes n'apparaissant qu'une seule fois
@@ -200,7 +231,7 @@ Extraction de données
* -n : compare selon la valeur arithmétique
* -k : spécifie la colonne utilisée pour le tri
- uniq et sort sont souvent utilisés ensemble. Par exemple, cette commande trie les lignes de file.txt selon leur nombre d'apparitions.
+ `uniq(1)`_ et `sort(1)`_ sont souvent utilisés ensemble. Par exemple, cette commande trie les lignes de `file.txt` selon leur nombre d'apparitions.
.. code-block:: console
@@ -282,6 +313,10 @@ Extraction de données
Obtenir des informations
^^^^^^^^^^^^^^^^^^^^^^^^
+.. spelling::
+
+ src
+ dst
`wc(1)`_ [-opt] filename donne sur stdout des informations au sujet de l'entrée standard ou d'une liste de fichiers.
Première colonne est le nombre de lignes, deuxième le nombre de mots et en dernier le nombre d'octets.
@@ -310,13 +345,13 @@ Copier
$ cp test.txt btest.txt ../
$ cp -r repertoire ../repertoirebis
-Déplacer ou renomer
-^^^^^^^^^^^^^^^^^^^
+Déplacer ou renommer
+^^^^^^^^^^^^^^^^^^^^
`mv(1)`_ [-opt] src dst renomme ou déplace src en dst.
* -f : écrase les fichiers existants
* -i : demande confirmation avant d'écraser un fichier existant
- * -n : n'écrase aucun fichier déja existant
+ * -n : n'écrase aucun fichier déjà existant
Note : Si la destination est un répertoire, alors la source peut être une liste de fichiers.
@@ -329,12 +364,36 @@ Déplacer ou renomer
Rechercher
^^^^^^^^^^
+.. spelling::
+
+ rep
+ group
+ mtime
+ atime
+ ctime
+ print
+ find
+ dev
+ null
+ expr
+ xargs
+ supertab
+ block
+ testdirectory
+ grep
+ tarname
+ tar
+ owner
+ tt
+ bz
+ pid
+
Pour les critères de recherche :
* critère1 critère2 = et logique
* !critère = non logique
* critère1 -a critère2 = ou logique
-`find(1)`_ chemin regex recherche les fichiers/répertoires caractérisés par nom, à partir du répertoire rep et affiche le résultat.
+`find(1)`_ chemin regex recherche les fichiers/répertoires caractérisés par nom, à partir du répertoire `rep` et affiche le résultat.
* -name : sur le nom du fichier
* -perm : sur les droits d'accès du fichier
* -links : sur le nombre de liens du fichier
@@ -435,7 +494,7 @@ Pour chaque fichier, il y a trois classes d'utilisateurs
Les permissions accordées à ces trois classes sont :
* r : lecture
* w : écriture
- * x : exécution (Un fichier peut être executé et un répertoire peut devenir répertoire courant)
+ * x : exécution (Un fichier peut être exécuté et un répertoire peut devenir répertoire courant)
`chmod(1)`_ mode files change les permissions du ou des fichiers/répertoires.
@@ -534,9 +593,16 @@ Gestion des processus
$ lsof -i -a -p 2735 = Les connexions ouvertes par le processus 2735
-`kill(1)`_ pid supprime le processus specifié. Si malgré la commande, le processus n'est pas détruit, essayez kill -9 pid.
+`kill(1)`_ pid supprime le processus spécifié. Si malgré la commande, le processus n'est pas détruit, essayez kill -9 pid.
+.. spelling::
+
+ pid
+ cmd
+ wc
+ root
+
Symboles utiles
---------------
@@ -599,11 +665,11 @@ Informations générales
`su(1)`_ passe en mode "root", c'est à dire administrateur
-`whatis(1)`_ cmd explique briévement l'utilité d'une commande
+`whatis(1)`_ cmd explique brièvement l'utilité d'une commande
-`apropos(1)`_ [-opt] motclé recherche dans les man pages les commandes correspondants aux mots clés.
+`apropos(1)`_ [-opt] mot-clé recherche dans les man pages les commandes correspondants aux mots clés.
* -a : Affiche seulement les résultats répondant à tout les mots clés.
- L'inverse est le fonctionnement par défault
+ L'inverse est le fonctionnement par défaut
`date(1)`_ donne l'heure, selon l'horloge de votre ordinateur
@@ -616,6 +682,26 @@ Informations générales
Informations système
^^^^^^^^^^^^^^^^^^^^
+.. spelling::
+
+ node
+ prog
+ cmdfile
+ sed
+ num
+ mtf
+ sbst
+ goto
+ eo
+ awk
+ program
+ while
+ kill
+ txt
+ name
+ nbr
+
+
`time(1posix)`_ programme permet de calculer le temps d'exécution d'un programme
`df(1)`_ [-opt] [file] indique l'espace disque utilisé et disponible sur tous les systèmes de fichiers.
@@ -901,7 +987,7 @@ Après il ne reste plus qu'à l'exécuter et observer le résultat.
Les variables
^^^^^^^^^^^^^
-Bash permet l'utilisation de variables dans les scripts. Il peut s'agir de simples variables ou de tableaux. Bash n'est pas un langage typé, les Int ou les String n'existent pas, toutes les variables sont traitées de la même façon. Pour illustrer ceci nous allons écrire le script `variables.sh <https://raw.github.com/HappyRave/SystInfo1/master/valgrind/variables.sh>`_
+Bash permet l'utilisation de variables dans les scripts. Il peut s'agir de simples variables ou de tableaux. Bash n'est pas un langage typé, les entiers ou les String n'existent pas, toutes les variables sont traitées de la même façon. Pour illustrer ceci nous allons écrire le script `variables.sh <https://raw.github.com/HappyRave/SystInfo1/master/valgrind/variables.sh>`_
.. code-block:: bash
@@ -927,7 +1013,7 @@ Ce script produit comme résultat
Hello,1252
Hello,12 52
-Il est interressant de visiter cette page : http://michel.mauny.net/sii/variables-shell.html
+Il est intéressant de visiter cette page : http://michel.mauny.net/sii/variables-shell.html
Les structures de contrôle
^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/Outils/ssh.rst b/Outils/ssh.rst
index 1409ebac7ebabed68e2ab5dcaccdb85cdc8dbf24..3d57595c5a9e84d7b7e7a34c77aaca86d8ea581c 100644
--- a/Outils/ssh.rst
+++ b/Outils/ssh.rst
@@ -8,9 +8,15 @@
SSH
---
+.. spelling::
+
+ ssh
+ intel
+ sirius
+
`ssh(1)`_ est un outil qui permet de se connecter depuis l'Internet à la console d'une autre machine et donc d'y exécuter des commandes. Dans l'infrastructure INGI vous pouvez vous connecter via ssh aux différents machines des salles en utilisant votre login et mot de passe INGI. Pour savoir les noms de machines, visitez le `student-wiki <http://wiki.student.info.ucl.ac.be/Matériel/Matériel>`_.
-Depuis l'extérieur vous devez passer via ``sirius.info.ucl.ac.be`` pour ensuite pouvoir vous connecter sur les machines des salles.
+Depuis l'extérieur vous devez passer via ``studssh.info.ucl.ac.be`` pour ensuite pouvoir vous connecter sur les machines des salles.
Quelques exemples d'utilisation de `ssh(1)`_ qui vous seront utiles:
@@ -89,4 +95,9 @@ Nous pouvons aussi utiliser `rsync <http://linux.about.com/library/cmd/blcmdl1_r
rsync -avz [hostname]:src/bar /data/tmp
-Maintenant tout les fichiers de la machine hôte, dans le dossier src/bar vont être copiés vers le répertoire local /data/tmp.
+Maintenant tout les fichiers de la machine hôte, dans le dossier ``src/bar`` vont être copiés vers le répertoire local ``/data/tmp``
+
+
+.. spelling::
+
+ src
diff --git a/Outils/valgrind.rst b/Outils/valgrind.rst
index 52d50993006de9b2e97c395c2d44b2135a54c169..2ec3513fd9863dff2a640936265288c160d15d8e 100644
--- a/Outils/valgrind.rst
+++ b/Outils/valgrind.rst
@@ -1,5 +1,5 @@
.. -*- coding: utf-8 -*-
-.. Copyright |copy| 2012 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch, Grégory Detal et Maxime De Mol
+.. Copyright |copy| 2012, 2020 by `Olivier Bonaventure <http://inl.info.ucl.ac.be/obo>`_, Christoph Paasch, Grégory Detal et Maxime De Mol
.. Ce fichier est distribué sous une licence `creative commons <http://creativecommons.org/licenses/by-sa/3.0/>`_
.. _valgrind-ref:
@@ -16,15 +16,26 @@ Le site http://www.cprogramming.com/debugging/ vous donne des techniques de déb
Valgrind permet de détecter des erreurs liées à la gestion de la mémoire dans vos programmes. Pour utiliser valgrind, lancez la commande `valgrind(1)`_ avec votre exécutable comme argument:
- .. code-block:: console
+.. spelling::
- valgrind --leak-check=yes [my binary]
+ ième
+ memory
+ leak
+ leaks
+ free
+ segfaults
+ faults
+ Fault
+
+ .. code-block:: console
+
+ valgrind --leak-check=yes [my binary]
Parmi les erreurs que valgrind est capable de détecter nous avons:
* Mémoire non-désallouée: Lors d'un appel à `malloc(3)`_, vous obtenez un pointeur vers une zone de mémoire allouée. Si vous "perdez" la valeur de ce pointeur, vous n'avez plus le moyen de libérer cette zone de mémoire. Essayez `valgrind(1)`_ avec le petit programme :download:`src/nofree.c`
* Désallouer deux fois la même zone de mémoire: Si vous appelez deux fois `free(3)`_ sur la même zone de mémoire, `valgrind(1)`_ va détecter cette erreur. Essayez-le avec le petit programme :download:`src/twofree.c`
- * Accès en dehors des limites d'une zone mémoire: Si vous allouez une zone de mémoire d'une certaine taille (par exemple un table de 10 chars) et que vous accèdez à une adresse qui excède cette zone (par exemple vous accèdez au 11ième élément) vous aurez probablement une ``Segmentation fault``. Valgrind permet de détecter ces erreurs et indique l'endroit dans votre code où vous faites cet accès. Essayez-le avec le petit programme :download:`src/outofbounds.c`
+ * Accès en dehors des limites d'une zone mémoire: Si vous allouez une zone de mémoire d'une certaine taille (par exemple un table de 10 chars) et que vous accédez à une adresse qui excède cette zone (par exemple vous accédez au 11ième élément) vous aurez probablement une ``Segmentation fault``. Valgrind permet de détecter ces erreurs et indique l'endroit dans votre code où vous faites cet accès. Essayez-le avec le petit programme :download:`src/outofbounds.c`
On vous encourage à lancer `valgrind(1)`_ sur votre projet pour vérifier que vous n'avez pas introduit de memory-leaks sans le vouloir. `valgrind(1)`_ ne remplace pas une écriture attentive du code mais peut permettre de détecter rapidement certaines erreurs courantes. Vous trouverez plus de détails sur les liens suivants:
@@ -84,7 +95,7 @@ La phrase que nous voulons voir après chaque exécution de `valgrind(1)`_ est:
Ce qui indique qu'aucun memory leak ne peut avoir lieu dans notre programme.
-Detecter les memory leaks
+Détecter les memory leaks
^^^^^^^^^^^^^^^^^^^^^^^^^
A présent nous allons montrer comment détecter des fuites de mémoire dans un programme à l'aide de `valgrind(1)`_. Testons le programme :download:`src/nofree.c`:
diff --git a/dict.txt b/dict.txt
index e0593d7c766afc18bf11dd84ce9b0ab132f4a745..0e95bfb12cd05b16ed4ef7a028995f8449796384 100644
--- a/dict.txt
+++ b/dict.txt
@@ -89,3 +89,9 @@ monothreadé
multithreadé
pthread
malloc
+débuggage
+valgrind
+tmp
+stdin
+stdout
+gdb