Langage pour literalinclude

diff --git a/doc/en/gui_create_yacs.rst b/doc/en/gui_create_yacs.rst
index 0a846c582b9082d7668d1df771ab1cdc0c8adae6..e14c0827da06986b2a4114626e009c8ce6a545c1 100644 (file)
--- a/doc/en/gui_create_yacs.rst
+++ b/doc/en/gui_create_yacs.rst
@@ -109,21 +109,25 @@ These tests ares done into the node "Analyse" of the schema, as described in :do
 The maximal number of iterations is given by the variable `NbCalcMax`:
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 112-112
 
 The value for the test is saved in a list all along the calculations:
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 137-141
 
 and the test is calculated after the second iteration:
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 143-148
 
 If this test is modified, it must be done here. But the instructions when it is converged must be kept to guarantee a good execution:
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 146-148
 
 Examples

diff --git a/doc/en/gui_create_yacs_aster.rst b/doc/en/gui_create_yacs_aster.rst
index 87660e11f0662bf6874f761f9211097295797efc..a187fec60fac193f2b895f9f0b7a5a09bfcd4ab8 100644 (file)
--- a/doc/en/gui_create_yacs_aster.rst
+++ b/doc/en/gui_create_yacs_aster.rst
@@ -27,11 +27,13 @@ To get back the test value ``V_TEST``, the script fetches in the file ``resu`` a
 For that purpose, the best way consists in placing the test value in an entitled table ``V_TEST``, for example after an extraction from a result:
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 53-59
 
 Then print this table for the two parameters ``INTITULE`` and component:
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 63-64
 
 To drive the adaptation
@@ -41,6 +43,7 @@ If the adaptation is driven by a field, it will be necessary to write this field
 For example :
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 68-78
 
 The script

diff --git a/doc/en/tutorials.rst b/doc/en/tutorials.rst
index 983d67ccb98df08bb8de5aa426d14d770a829482..a299ad800a4b95f42d5f3878f7cf4b6a821d888d 100644 (file)
--- a/doc/en/tutorials.rst
+++ b/doc/en/tutorials.rst
@@ -37,6 +37,7 @@ One will make here three successive uniform refinements of the mesh contained in
 
 
 .. literalinclude:: ../files/tutorial_1.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -56,6 +57,7 @@ Refinement by zones
 One proceeds here to refinement according to zones. To pass from the initial mesh to the mesh 'M_1', one uses a box framing the z=1 plane and a sphere centered on the origin with radius 1.05. Then to pass from the mesh 'M_1' to the mesh 'M_2', one replaces the sphere by a box framing the cube on side 0.5, pointing on the origin and the meshes in the very first zone are unrefined.
 
 .. literalinclude:: ../files/tutorial_2.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -75,6 +77,7 @@ One proceeds here to refinement according to a field. The hypotheses are used to
 To adapt the H_1 mesh resulting from the Iter_1 iteration, two alternatives are applied. In the first, Iter_2, the field is a scalar field of indicators of error and one cuts out the 1.5% of elements where the error is largest. In the second alternative, Iter_2_bis, one is based on a vector field and one examines the jump of this vector between an element and its neighbors: one will cut out where the infinite standard of this jump is higher than the absolute threshold of 0.0001.
 
 .. literalinclude:: ../files/tutorial_3.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -98,6 +101,7 @@ The driving of refinement is the following: uniform refinement of all the elemen
 Scheme YACS carrying out this adaptation is downloadable.
 
 .. literalinclude:: ../files/tutorial_4.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -134,6 +138,7 @@ The instructions to adapt a 2D mesh are exactly identical to those necessary to
 In the case presented here, one for the first time refines all the elements contained in a bored disk, then in one second iteration, all the elements contained in a rectangle. One will note the use of the follow-up of the circular borders of the field.
 
 .. literalinclude:: ../files/tutorial_5.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 

diff --git a/doc/en/yacs.rst b/doc/en/yacs.rst
index e0b1625d27be723188215c768ab0ddd368124f73..94cbeadc8c8fd5ee9f3f02bbaaa18c8c4950fd3f 100644 (file)
--- a/doc/en/yacs.rst
+++ b/doc/en/yacs.rst
@@ -46,6 +46,7 @@ DataInit
 This box is type PresetNode's elementary node. Its only function is to initialize the variable MeshFile that contains the name of the file of the initial mesh.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 37-41
 
 Study_Initialisation
@@ -64,11 +65,13 @@ The box Study_Initialisation launches the component HOMARD inside SALOME. It is
 The python node StudyCreation initialize the SALOME study that is given through the output:
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 43-59
 
 The service UpdateStudy connects this study to an instance of HOMARD.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 60-64
 
 
@@ -93,6 +96,7 @@ Results
 This box is a node python that takes in input a character string, MessInfo. If everything passed well, this message is empty. A window QT appears to confirm the convergence. If there was a problem, the message contains messages emitted during the calculations. The window QT shows this message.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 398-411
 
 
@@ -117,6 +121,7 @@ Computation
 This box is a node python that is going to drive the calculation. In input, we find the number of the calculation (0 at first) and the name of the file which contains the mesh on which to calculate. In output, we find an integer which represents the error on this calculation (0 so everything goes well) and a dictionary python gathering the results of the calculation. The body of the node is established by the launch of a script python that activates the calculation.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 70-90
 
 In this example, we must define:
@@ -157,19 +162,23 @@ Iter_1
 This box begins by creating the case HOMARD by calling the CreateCase service.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 200-207
 
 The name of the case CaseName is imposed on "Computation". The name of the case MeshName is imposed on "BOX". The parameters of input FileName arise from the output of the previous calculation. The parameter of output is an instance of case.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 435-438
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 475-478
 
 The options of this case must be now given. It is made by the node python CaseOptions. It is imperative to give the directory of calculation. We shall look at the description of the functions in :doc:`tui_create_case`. In output, we get back the instance of the iteration corresponding to the initial state of the case.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 208-220
 
 Finally, a hypothesis is created by calling the CreateHypothese service. The parameter of output is an instance of hypothese.
@@ -187,31 +196,37 @@ Once initialized, the adaptation can be calculated. It is the goal of the Homard
 The directory of calculation is recovered. The name of the mesh is given.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 237-242
 
 ../..
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 317-325
 
 The hypothesis transmitted in input parameter characterized (look :doc:`tui_create_hypothese`) :
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 246-270
 
 It is necessary to establish a name for the future iteration. To make sure that the name was never used, one installs a mechanism of incremental naming starting from the name of the initial iteration. As this initial name is the name of the initial mesh, one obtains a succession of names in the form: M_001, M_002, M_003, etc
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 272-282
 
 The iteration is supplemented : hypothesis, future mesh, field (look :doc:`tui_create_iteration`) :
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 284-303
 
 The iteration is calculated. If it were correct, variable OK equals 1: one will be able to continue the execution of the scheme. If there were a problem, variable OK equals 0 to mean that calculation must stop; an error message then is given.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 305-316
 
 After this execution, the process leaves the Adaptation_HOMARD node, then Adaptation node. One arrives then at the node of analysis.
@@ -242,6 +257,7 @@ Loop_Stop
 The Loop_Stop block is present to only make forward variables because the input parameters of the nodes must always be filled. It is a very simple python:
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 165-176
 
 Analysis
@@ -255,31 +271,37 @@ Analysis
 The Analysis block is a script python which ensures the complete control of the process by examining the causes of possible error successively.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 96-108
 
 ../..
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 154-162
 
 One starts by analyzing the return of the computer code:
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 110-115
 
 Checking of the presence of the name of the result file in the dictionary of the results:
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 117-124
 
 Checking of convergence. That supposes that the value to be tested is present in the dictionary under the key 'V_TEST'. Here, one set up a test on the variation of the value of one calculation at the other. With the first passage, nothing is tested. In the following passing, one tests if the relative variation is lower than 1 thousandths. One could have set up an absolute test if one had recovered a total level of error for example.
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 126-146
 
 Lastly, it is checked that a maximum nomber of adaptations is not exceeded:
 
 .. literalinclude:: ../files/yacs_01.en.xml
+   :language: xml
    :lines: 146-151
 
 

diff --git a/doc/files/yacs_01.en.xml b/doc/files/yacs_01.en.xml
index 7ce832f3b8464f17d6dd4cbc4f784cdf35d2f91d..4d06d149c7474ac5bc5ff03eff1764b7d75d15f3 100644 (file)
--- a/doc/files/yacs_01.en.xml
+++ b/doc/files/yacs_01.en.xml
@@ -302,7 +302,7 @@ Iter.SetMeshFile(MeshFile)
 FileName = dict_resu["FileName"]
 Iter.SetFieldFile(FileName)
 #
-# Computationation
+# Computation
 # ===========
 Error = Iter.Compute(1,1)
 #

diff --git a/doc/fr/gui_create_yacs.rst b/doc/fr/gui_create_yacs.rst
index d16ea88d9f5692c12df7fb2b6b50a5cf69c8897c..006fef046aed0e6b8c4ef804bd03c6d93c1f4171 100644 (file)
--- a/doc/fr/gui_create_yacs.rst
+++ b/doc/fr/gui_create_yacs.rst
@@ -110,21 +110,25 @@ Ces tests sont réalisés dans le noeud python "Analyse" du schéma, comme décr
 Le nombre maximal d'itérations est modifiable par la variable `NbCalcMax` :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 112-112
 
 La valeur de test est stockée dans une liste au fur et à mesure des passages :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 137-141
 
 et le test a lieu à partir du deuxième passage :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 143-148
 
 Si on veut remplacer ce test par un autre, c'est ici qu'il faut le faire. Il faut simplement conserver le contenu produit à la convergence pour assurer la bonne marche de la suite du schéma :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 146-148
 
 Exemples

diff --git a/doc/fr/gui_create_yacs_aster.rst b/doc/fr/gui_create_yacs_aster.rst
index 3a005b941b5bef251f24ae8b8afda9d06fdae954..0f29d9a82bb30584623c9831421d38e6f0b31b89 100644 (file)
--- a/doc/fr/gui_create_yacs_aster.rst
+++ b/doc/fr/gui_create_yacs_aster.rst
@@ -27,11 +27,13 @@ Pour récupérer la valeur de test ``V_TEST``, le script va chercher dans le fic
 Pour cela, la meilleure façon consiste à placer la valeur à tester dans une table intitulée ``V_TEST``, par exemple après une extraction depuis un résultat :
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 53-59
 
 puis à imprimer cette table en se limitant aux deux paramètres ``INTITULE`` et composante retenue :
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 63-64
 
 Le pilotage de l'adaptation
@@ -41,6 +43,7 @@ Si on souhaite piloter l'adaptation par un champ, il faudra écrire ce champ dan
 Par exemple :
 
 .. literalinclude:: ../files/yacs_aster_01.comm
+   :language: python
    :lines: 68-78
 
 Le script

diff --git a/doc/fr/tutorials.rst b/doc/fr/tutorials.rst
index 5562fb6fab15a5c8610bdc70bd91e1f7d345c7ec..49caa5516fd460396de3ed6183f0940499e427b0 100644 (file)
--- a/doc/fr/tutorials.rst
+++ b/doc/fr/tutorials.rst
@@ -36,6 +36,7 @@ On fera ici trois raffinements uniformes successifs du maillage contenu dans le
   * le maillage produit porte toujours le même nom. Cela ne pose pas de problème car il est stocké dans des fichiers différents.
 
 .. literalinclude:: ../files/tutorial_1.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -54,6 +55,7 @@ Raffinement par des zones
 On procède ici au raffinement selon des zones. Pour passer du maillage initial au maillage 'M_1', on utilise une boîte encadrant le plan z=1 et une sphère centrée sur l'origine de rayon 1.05. Puis pour passer du maillage 'M_1' au maillage 'M_2', on remplace la sphère par une boîte encadrant le cube de côté 0.5, pointant sur l'origine et on déraffine les mailles contenues dans la toute première zone.
 
 .. literalinclude:: ../files/tutorial_2.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -73,6 +75,7 @@ On procède ici au raffinement selon un champ. Les hypothèses servent à défin
 Pour adapter le maillage H_1 issu de l'itération Iter_1, deux variantes sont appliquées. Dans la première, Iter_2, le champ est un champ scalaire d'indicateurs d'erreur et on découpe les 1.5% de mailles où l'erreur est la plus grande. Dans la seconde variante, Iter_2_bis, on se base sur un champ vectoriel et on examine le saut de ce vecteur entre une maille et ses voisines : on découpera là où la norme infinie de ce saut est supérieure au seuil absolu de 0.0001.
 
 .. literalinclude:: ../files/tutorial_3.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -96,6 +99,7 @@ Le pilotage du raffinement est le suivant : raffinement uniforme de toutes les m
 Le schéma YACS réalisant cette adaptation est téléchargeable.
 
 .. literalinclude:: ../files/tutorial_4.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -112,6 +116,7 @@ Si la géométrie sous forme de CAO n'est pas disponible, on peut l'approcher ai
 des frontières analytiques pour décrire les différentes surfaces des tuyaux et une frontière discrète pour décrire les lignes d'intersection des deux tuyaux. Il suffit de remplacer la définition des frontières.
 
 .. literalinclude:: ../files/tutorial_6.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 
@@ -133,6 +138,7 @@ Les instructions pour adapter un maillage 2D sont exactement identiques à celle
 Dans le cas présenté ici, on raffine une première fois toutes les mailles contenues dans un disque percé, puis dans une seconde itération, toutes les mailles contenues dans un rectangle. On notera l'utilisation du suivi des frontières circulaires du domaine.
 
 .. literalinclude:: ../files/tutorial_5.py
+   :language: python
    :start-after: Début des commandes
    :end-before: Fin des commandes
 

diff --git a/doc/fr/yacs.rst b/doc/fr/yacs.rst
index b2b6f7676dc6992bc583569bc6e05ee0a63c5639..ac1e9b154a16bdc70d62bb1d4fe51d6af839c8e0 100644 (file)
--- a/doc/fr/yacs.rst
+++ b/doc/fr/yacs.rst
@@ -46,6 +46,7 @@ DataInit
 Cette boîte est un noeud élémentaire de type PresetNode. Sa seule fonction est d'initialiser la variable MeshFile qui contient le nom du fichier du maillage initial.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 37-41
 
 Etude_Initialisation
@@ -64,11 +65,13 @@ La boîte Etude_Initialisation lance le composant HOMARD dans SALOME. C'est un b
 Le noeud python StudyCreation sert à initialiser l'étude SALOME qui est fournie en sortie :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 43-59
 
 Le service UpdateStudy affecte cette étude à une instance de HOMARD.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 60-64
 
 
@@ -93,6 +96,7 @@ Bilan
 Cette boîte est un noeud python qui prend en entrée une chaîne de caractères, MessInfo. Si tout s'est bien passé, ce message est vide. Une fenêtre QT apparaît pour confirmer la convergence. S'il y a eu un problème, le message contient les messages émis au cours des calculs. La fenêtre QT affiche ce message.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 398-411
 
 
@@ -117,6 +121,7 @@ Calcul
 Cette boîte est un noeud python qui va piloter le calcul. En entrée, on trouve le numéro du calcul (0 au départ) et le nom du fichier qui contient le maillage sur lequel calculer. En sortie, on trouve un entier qui représente l'erreur sur ce calcul (0 si tout va bien) et un dictionnaire python rassemblant les résultats du calcul. Le corps du noeud est constitué par le lancement d'un script python qui active le calcul.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 70-90
 
 Dans cet exemple, il faut définir :
@@ -157,19 +162,23 @@ Iter_1
 Cette boîte commence par créer le cas HOMARD en appelant le service CreateCase.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 200-207
 
 Le nom du cas CaseName est imposé à "Calcul". Le paramètre d'entrée MeshName est imposé à "BOX". Le paramètre d'entrée FileName est issu de la sortie du calcul précédent. Le paramètre de sortie est une instance de cas.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 435-438
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 475-478
 
 Les options de ce cas doivent maintenant être renseignées. C'est fait par le noeud python CaseOptions. Il est impératif de renseigner le répertoire de calcul. On regardera la description des fonctions dans :doc:`tui_create_case`. En sortie, on récupère l'instance de l'itération correspondant à l'état initial du cas.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 208-220
 
 Enfin, une hypothèse est créée en appelant le service CreateHypothese. Le paramètre de sortie est une instance d'hypothèse.
@@ -187,31 +196,37 @@ Une fois initialisée, l'adaptation peut être calculée. C'est le but de la bo
 Le répertoire de calcul est récupéré. Le nom du maillage est rappelé.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 237-242
 
 ../..
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 317-325
 
 L'hypothèse transmise en paramètre d'entrée est caractérisée (voir :doc:`tui_create_hypothese`) :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 246-270
 
 Il faut établir un nom pour la future itération. Pour s'assurer que le nom n'a jamais été utilisé, on met en place un mécanisme de nommage incrémental à partir du nom de l'itération initiale. Comme ce nom initial est le nom du maillage initial, on obtient une succession de noms sous la forme : M_001, M_002, M_003, etc.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 272-282
 
 L'itération est complétée : hypothèse, futur maillage, champ (voir :doc:`tui_create_iteration`) :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 284-303
 
 L'itération est calculée. Si tout s'est bien passé, la variable OK vaut 1 : on pourra continuer l'exécution du schéma. S'il y a eu un problème, la variable OK vaut 0 pour signifier que le calcul doit s'arrêter ; on donne alors un message d'erreur.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 305-316
 
 Après cette exécution, le processus sort du noeud Adaptation_HOMARD, puis du noeud Adaptation. On arrive alors au noeud d'analyse.
@@ -242,6 +257,7 @@ Arret_boucle
 Le bloc Arret_boucle n'est présent que pour faire transiter des variables car les paramètres d'entrée des noeuds doivent toujours être remplis. C'est un python très simple :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 165-176
 
 Analyse
@@ -255,31 +271,37 @@ Analyse
 Le bloc Analyse est un script python qui assure le contrôle complet du processus en examinant successivement les causes d'erreur possible.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 96-108
 
 ../..
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 154-162
 
 On commence par analyser le retour du code de calcul :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 110-115
 
 Vérification de la présence du nom du fichier de résultats dans le dictionnaire des résultats :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 117-124
 
 Vérification de la convergence. Cela suppose que la valeur à tester est présente dans le dictionnaire sous la clé 'V_TEST'. Ici, on a mis en place un test sur la variation de la valeur d'un calcul à l'autre. Au premier passage, on ne teste rien. Aux passages suivants, on teste si la variation relative est inférieure à 1 millième. On aurait pu mettre en place un test absolu si on avait récupéré un niveau global d'erreur par exemple.
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 126-146
 
 Enfin, on vérifie que l'on ne dépasse pas un nombre maximal d'adaptations :
 
 .. literalinclude:: ../files/yacs_01.fr.xml
+   :language: xml
    :lines: 146-151