freem a écrit 5059 commentaires

Pour l'indentation, je fais différemment (je ne connaissais pas le '==', merci). Je passe en mode visuel, sélectionne les lignes qui m'intéressent et puis '<' ou '>', précédé ou pas d'un nombre pour indenter plus d'une fois.

Sinon, lg semble servir à lire un fichier d'erreur, chez moi, selon l'aide:

:lg[etfile] [errorfile] :lg :lgetfile
Same as ":cgetfile", except the location list for the
current window is used instead of the quickfix list.

et donc:

:cg[etfile] [errorfile] :cg :cgetfile
Read the error file. Just like ":cfile" but don't
jump to the first error.

Je vois donc assez mal le lien avec l'indentation? (et bien entendu, chez moi, après :lg<enter> il me dit: E40: Impossible d'ouvrir le fichier d'erreurs errors.err)

C'est vrai, que c'est un peu de travail, mais ce n'est pas bien difficile.

Le souci, c'est s'il faut apprendre un nouveau langage, et régler au poil de fesse le moindre logiciel, même en utilisant un nombre restreint de logiciels, ça fait quand même pas mal d'heures à régler des outils. Certes, la puissance qui en résulte est sûrement impressionnante, mais bon, je suis sceptique.
Franchement, j'aime beaucoup la mécanique modale de vi, c'est pour ça que je reste à vim, mais il fait bien trop de choses, et ça le rend bien trop complexe à mon goût. Un éditeur de texte qui partage la philosophie de i3, ça, ce serait génial: modal, pas de config par défaut hard-codée, fichier de conf qui n'est pas un script mais un vrai fichier de conf, doc détaillée mais simple sur la config.
Ça n'existe pas encore, à ma connaissance?

La coloration syntaxique, l'auto-complétion & co, ne me semblent pas justifier la complexité de la config de vim. Et je le dis en sachant que je risque d'éveiller du troll… tant pis.

Je testerai, mais à première vue, je suis complètement perdu. Diagrammes faits via un langage, je suppose?

• meld → diff/vimdiff ;

J'ai déjà utilisé diff. Très bien pour les scripts, ou pour générer des patchs. Pas pour un usage interactif, j'ai beau ne pas être gêné outre mesure (voire je les préfères, au moins y'a pas besoin de prendre la souris pour s'en servir) par les IHM en TUI, j'ai malgré tout une grande préférence pour les applications interactives, je le reconnaît.

Après, entre vimdiff et meld, je pense meld toujours supérieur, après un essai rapide. Le visuel est beaucoup plus clair dans meld que dans vimdiff.
Surtout que quand j'utilise meld, c'est en général sur deux (voire 3) arborescences, quand j'essaie de comprendre ce qu'on fait les gens qui ont maintenu un projet avec le trop célèbre VCS cpold.

• zim → arborescence de fichiers texte dans un dépôt git ?

Euh, oui, mais non en fait, enfin, je versionne mon wiki, mais git n'est pas un wiki, ou alors je ne comprend pas ce que tu veux dire?

• cgdb → gdb ;

cgdb est juste une IHM autour de gdb, qui "ajoute" un mode interactif, plus classique et moins délicat à apprendre. Pour le reste, pas le choix d'utiliser gdb (cgdb intègre gdb), du coup je commence à savoir m'en servir vaguement.
Mais ce petit ajout de cgdb est quand même très utile: pouvoir placer des breakpoints via un explorateur de code et avoir la coloration syntaxique est quand même vital pour moi.

• UML → graphviz.

Je me suis déjà dit que ça pourrait être intéressant d'utiliser direct le langage dot, en effet, mais le type d'outil auquel je pense est le genre d'outil capable de reverser du code, voire d'en générer.
Un truc comme BoUML ou rational rose, en somme.
Ça dépanne à mort sur des projets non documentés. Je sais que doxygen permets d'aider légèrement à la rétro ingénierie, mais c'est insuffisant: on ne voit que l'arborescence des classes par exemple, pas les agrégations par exemple. Ou alors je n'ai pas trouvé le bon réglage.
La génération de code est bien utile aussi, quand tu crées tes diagrammes et que tu n'as pas à te taper le pissage de code, c'est quand même agréable, plus qu'a remplir les trous…
D'ailleurs, Dia à un module permettant ça… le souci, c'est que tout est généré dans un seul fichier, et que ça tombe en marche plus qu'autre chose j'ai l'impression. Pas vraiment exploitable quand on dépasse les 5-6 classes.

Enfin, c'est vrai que graphviz serait plus confortable que dia pour créer des diagrammes. Vais essayer d'apprendre à m'en servir.

P.S. : en français on ne met pas d'espace du coté intérieur d'une parenthèse.

Bon bah je vais essayer de me soigner alors.

Pour ce qui est de la calculatrice, c'est quoi la différence entre bc et dc? Enfin, je pense que j'irai voir les man, ces outils m'intéressent, surtout que j'imagine qu'il doit être possible de passer directement le calcul à faire en ligne de commande, ce qui me ferait un bien fou.

Configurer comme ça ne semble pas enregistrer dans les préférences, et l'instance suivante repars donc sur un truc blanc casse-œil.
Donc, il faut aller modifier le fichier de config de gvim, qui ressemble probablement à celui de vim, qui est un fichier de config que j'essaie de n'ouvrir qu'en cas de force majeure, parce qu'à mon humble avis, un fichier de configuration qui utilise un langage de programmation, c'est révélateur d'un problème.
Enfin, c'est mon avis, et je comprend très bien que d'autres aient un avis différent ainsi que le fait que ça ouvre d'immenses possibilités, mais c'est exactement la raison qui fait que j'ai choisi i3, et pas je ne sais plus quel twm qui se config en list ou lua ou…

Mon avis très personnel sur vim, est que c'est le moins mauvais des éditeurs de code que j'aie testé, pas qu'il est bon. Mais bon, c'est simple de critiquer quand on ne fait rien :)

Désolé, ma Debian me conviens bien pour le moment, pas besoin de changer de système d'exploitation :D

Bon, je tenterai quand même le mode debug, sait-on jamais.
Rxvt, il faudrait que j'apprenne à le configurer, mais je me suis déjà fait cette remarque à plusieurs reprises.

en guise de calculatrice j'utilise speedcrunch.

Je teste ça. Certains points ont l'air intéressants, mais l'absence de "mode" binaire/hexa (j'ai vu qu'on peut convertir une valeur en hexa/binaire, mais devoir me taper tout le temps l'appel aux fonctions de conv me semble rédhibitoire? Il y à peut-être une autre solution que je n'ai pas trouvée en moins de 2 minutes, ceci dit.)

Je ne suis pas certain de comprendre la distinction que tu fais entre éditeur de code et éditeur de texte. Dans les deux cas, j'utilise vim et je trouve qu'il fait très bien son boulot.

C'est simple: un éditeur de texte, c'est pour faire du texte normal, ou une ligne peut être plus longue que la largeur d'un terminal, et dans ce cas, un éditeur de texte normal la met à la ligne (bon, ça, vim le fait aussi) et on peut se déplacer d'un morceau de ligne à un autre très facilement. Avec vim, chez moi, si je demande d'aller au début de la ligne, à la fin de la ligne ou à la ligne suivante, bah il le fait par rapport au texte réel, pas par rapport à la représentation à l'écran du texte, ce qui est pratique pour du dev, mais pas pour écrire un texte normal, sauf à mettre des fins de lignes partout, c'est à dire, sauf à m'adapter à mon outil, et ça, c'est hors de question.
Contrairement à un éditeur "de texte".

Autre truc qui m'agace avec vim, c'est que je l'ai configuré pour les numéros de ligne, des tab qui s'affichent sur 2 espaces, et qu'il me fasse mon indentation automatiquement. Le problème, c'est que quand on copie un bout de code sur le net, il indente. C'est gentil, mais comme le code est souvent déjà indenté, faut remettre un coup d'astyle à chaque fois. Franchement, la flemme, perso, alors je lance un leafpad temporaire, quitte à juste sauvegarder pour ensuite ouvrir avec vim (wm en tuile, donc cette procédure même si casse pied est très rapide, disons, 5 raccourcis clavier.).
Je suis sûr que tout ça se configure, mais je sais pas faire, le langage de config de vim est trop riche pour moi. Du coup, mes réglages sont très bien pour coder mes trucs à moi, mais dès que je dois interagir avec le monde extérieur, je préfère passer par un truc plus classique.

Bon, clairement, les problèmes que j'ai avec vim, ils sont entre la chaise et le clavier hein. Je ne sais juste pas m'en servir réellement ou efficacement, mais ma maîtrise de vim me suffit pour écrire mes programmes/scripts/fichiers de conf.

Pour les diagrammes j'utilise pgf/tikz, couplé avec Qtikz et ca donne des résultats magnifiques. Ici la galerie.

Ça, je sens que ça va m'intéresser. Va falloir que j'approfondisse ma maîtrise de latex, mais ça ne me dérange pas trop, surtout que l'alternative c'est word&co (quand je dois utiliser un de ces foutus outils de bureautique, j'ai toujours mon réflexe de lancer une malédiction sur le type qui à inventé ces horreurs: pas de contrôle de version possible, pas de diff efficace possible, des IHM hyper lourdes et compliquées pour que dalle, un rendu des plus aléatoires en fonction des phases de la lune, etc. Bref…)

Skype c'est un protocole, je te parle d'applis.

T'en fais exprès? Allez, je vais me fendre d'un lien…

Pour rappel, Skype n'est pas un protocole, c'est un logiciel qui utilise un protocole hyper fermé, que seul le logiciel nommé Skype est capable d'utiliser. Ou alors, cites-moi un seul logiciel qui utilise le protocole de skype, et n'a pas besoin que Skype lui-même soit installé?

je présume qu'il serait préférable, pour des devs d'applis, de faire un choix et de designer avec un bureau bien précis en tête ; le résultat sera de plus grande qualité qu'en le calquant sur une UX Windows 9x et en essayant de faire multiplateforme à tout prix.

Figures toi que ce qui m'a permis de passer à linux en réduisant grandement les souffrances, c'est le fait d'utiliser des logiciels portables pour mes tâches principales: codeblocks et firefox/opera.

Un grand nombre de personnes estiment, à raison, que la portabilité c'est important, et pas juste pour un point de vue de "ça marche partout", mais aussi parce qu'un logiciel portable et porté sur de nombreuses plate-formes, ça signifie, entres autres, la possibilité d'utiliser divers outils de compilation, par exemple.
Et ça, ça permets d'améliorer la qualité, pour de vrai, contrairement au délire de suivre bêtement les choix d'un bureau qui change d'apparence et casse la compatibilité tous les 6 mois. Parce que c'est ça qui fait rager le plus dans le cas gnome, à ce que je peux voir: déjà, on vire des fonctionnalités, qui fonctionnent. On fait régresser des applications pour rien? Woa, c'est déjà super bizarre, pour moi, mais passons. En plus de ça, on pète la compatibilité ( notamment au niveau des thèmes ) du toolkit sous-jacent qui n'a pas été conçu pour gnome, mais pour gimp à la base, pour être portable. Et ces deux faits la, ce sont des choses qui dégradent la qualité, pas qui l'améliorent.
On ne peut pas maintenir une cathédrale quand on n'est pas capable de bâtir des choses sans détruire l'environnement, sans être compatible avec l'existant.

PS: l'IHM de win98, comme tu dis, ben, ça marche juste bien, tout le monde peut apprendre à s'en servir en un temps record. Je n'en dirait pas tant de celle de windows 8, ou d'Ubuntu. Pour gnome, je ne sais pas, j'utilise pas, quand je l'avais testée je l'avais trouvée mal foutue, mais bon, question de goûts, et ça remonte.

Et c'est si grave que ça pour le reste du monde libre ?

Non, ce n'est absolument pas grave, quand l'un des deux toolkits les plus utilisés par le libre supprime des fonctionnalités utilisées par de très nombreux projets sans prévenir et sans raison technique.
Bien sûr que non. Ou alors pas beaucoup. Juste un p'tit chouïa.

Je ne suis pas de ceux qui pensent que la quantité réduit la qualité ( les alternatives permettent aussi de faire les choses différemment, avec des objectifs autres, comme par exemple cibler des matos particuliers. Un spécialiste est parfois plus pertinent qu'un généraliste ).
C'est même le contraire: par exemple, la naissance de la SFML à donné un coup de pied au cul de la SDL, qui est redevenue active plutôt que dormir sur ses lauriers.

Mais c'est vrai qu'on peut toujours forker, en effet.

Peut-être, mais regrettable de voir que tout le monde adopte le même. Et si demain Qt deviens une horreur, comment on fait?

Je veux dire, il existe aussi wxwidgets ( même si malheureusement le port linux est basé sur gétéqua, mais au moins c'est sûr la v2, et il me semble qu'il existe un port pour Xorg directement? ), fltk ( bien que leurs versions soient clairement bordélique… ) et sûrement bien d'autres, qui n'obligent pas à ajouter un outil à la chaîne de compilation ( oui je sais, je sais, ce n'est pas gênant pour nombre de gens, mais je me souviens de la galère à avoir essayé de compiler un truc sous windows sans utiliser le même IDE que le dev, à savoir qtcreator et son ihm absolument immonde^W inadaptée à mes goûts et habitudes ).

il me semble que bitbucket te permet de créer des dépôts privés

Je confirme. 5 pour un nouvel utilisateur qui ne paye pas, avec une taille d'équipe maxi limitée à 5 personnes.
On peut "parrainer" des gens ( faire de la pub en fait ) histoire d'augmenter le nombre de dépôt jusqu'a 5 ( +1 par personne amenée ).

Outre ça, je trouve bitbucket bien plus agréable que le lent et bordélique github ( bien que j'y aie un compte également pour contribuer aux projets des autres, de temps en temps ).

Sinon, +1 pour l'explication, bien que ça rejoigne le lien posté par Jiehong, mais au moins c'est en français ( pour certains, ça compte )

C'est en effet le seul lecteur à lire tous mes formats de musique

mpd ne les supporte pas? Je n'ai pas de fichiers dans ces formats ( je les connaissait même pas de nom en fait ) mais la seule chose qu'il ait été incapable de lire chez moi jusqu'à présent, c'est les fichiers wma.
Enfin, la liste selon wikipedia:

Plays Ogg Vorbis, FLAC, Opus, WavPack, MP2, MP3, MP4/AAC, MOD, Musepack, wave files and any other files supported by FFmpeg.

On y retrouve certains de tes formats, après, tous, je ne sais pas…

un des rares à ne pas proposer une utilisation en mode "bibliothèque" bordélique car basée sur les métadonnées des fichiers (alors que souvent les métadonnées sont absentes ou erronées, et si j'ai fait des dossiers c'est pas pour rien !).

Hum… perso, mpd supporte les 2 façons de faire, ce qui est bien utile. Enfin, j'avoue ne pas me servir des métadonnées, mais au vu des différentes vues de ncmpcpp, je pense qu'il peut s'en servir.

Et bien sûr, l'avantage ultime de mpd sur la vaste majorité des players, c'est qu'il y a pleins d'ihm différentes, avec tous les toolkit. Y'a pas mieux de ce côté :)

C'est quoi le rapport entre les VMs et le php/mysql?

Pas besoin d'imaginer, je connaît :D

Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.

Ça n'arrivera pas. Je préfère rester sous un X retardé et non maintenu plutôt que de revenir à un gestionnaire de fenêtre stacking. D'un autre côté, je pense qu'il doit être possible d'implémenter un serveur wayland minimaliste donnant la main à un WM externe, pourquoi pas via un mécanisme de plug-in.

Sincèrement, je vois d'un bon œil l'idée de Wayland ( je suis de ceux qui pensent que se débarrasser d'un truc implémentant des choses qui ne sont plus utilisées est une bonne chose, quitte à casser la compat. Reste à définir "plus utilisées" ), et j'aurai bien aimé jouer avec, mais je n'ai pas trouvé de code pour booter mon cerveau dessus. Weston est trop complet ( en même temps, c'est une démo technique ) alors que ce qu'il me faudrait ce serait un serveur minimal. J'avoue ne pas avoir cherché des masses aussi, mais… si quelqu'un connaît un projet dans ce style en cours de dev, je serai curieux de tenter de voir à quoi ça ressemble, et pourquoi pas de coder pour.

Je pense que tu te prends beaucoup trop la tête sur la « propreté » d'un code :-) Tu n'en mourras pas, de publier des trucs « pas propres ». Au contraire, je pense que ça t'apprendra d'autant plus, car c'est en essayant et en se plantant qu'on apprend à s'améliorer.

Accessoirement, un code qui nous paraît propre à un moment donné nous semble parfois à vomir 6 mois plus tard :)

À l'époque de SVN, les développeurs faisaient ce travail à la main, avec 3 sous dossiers principaux ( dans les projets que j'ai pu voir en fouillant sans contribuer ):

• trunk
• branch
• tag

Chacun de ces dossiers contenait un copier/coller des sources.

Cette façon de travailler à été automatisée—et nettoyée—par git ( et par mercurial j'imagine? ): maintenant, trunk est une branche comme les autres, et l'on tague les commit.

La problématique que tu décris permets d'utiliser ça assez facilement, et d'ailleurs pas mal de projets libres utilisent cette méthodo:

• master, ou stable, pour les bug fixes ( une fois la première stable atteinte, naturellement )
• experimental, ou devel, peu importe le nom, pour la future version stable
• une branche par fonctionnalité ou tâche à effectuer, que l'on merge dans experimental quand ça semble marcher.

Puis les tags sont apposés sur des commits précis d'une branche pour définir l'état de la branche au moment de ce commit: numéro de version, release candidate, etc.

Et deux choses sont fondamentalement différentes entre X et Wayland.

Tu as oublié la transparence réseau, qui, si j'ai bien compris, permets de faire tourner une application d'une machine en déportant ses entrées/sorties sur une autre.
C'était plus intéressant à l'époque ou les machines coûtaient la peau du cul j'imagine, mais ça reste à mon avis une raison de ne jamais qualifier X de pourri, ou merdique. Obsolète, éventuellement, mais ce n'est pas pareil: je connais une société qui fait des logiciels pourris et merdiques modernes et les vends à énormément de gens, qui régulièrement leur préfèrent les versions obsolète de la même société ^{^}

X, qu'on le veuille ou non, c'est du rendu d'application déporté. Les clients envoient leurs requêtes de dessin […] ont arrêté de faire ça car c'était trop lent,

Du coup, petite question: pourquoi est-ce trop lent? Que l'image soit créée par une application qui fait le travail "directement" (en envoyant à OpenGL en fait?) ou que les requêtes soient envoyées à une application spécialisée qui fasse le rendu ne devrait pas avoir une énorme surcharge, dans l'absolu?

Est-ce à cause du fait que la plupart des ressources graphiques soient matricielles? Si on utilisait majoritairement du vectoriel, ce problème se résorberait-il? Parce qu'au final, le fonctionnement que tu décris me semble particulièrement adapté à du rendu vectoriel, même si l'on garde une légère surcharge ( le serveur faisant le rendu, probablement via OpenGL, on garde un intermédiaire ) je doute que la différence de vitesse soit flagrante, surtout de nos jours. Par contre, oui, sur du matriciel, envoyer 4*1024*768 ( soit 3 Mio, tout rond en plus! ) pour dessiner un écran entier de faible résolution, ça doit bouffer, surtout s'il n'est pas possible d'utiliser une compression sans perte efficace ( genre des photos ).

C'est un fait, je n'ai pas cherché particulièrement loin ( bookmark, quoi ). J'ai vu une MaJ de mes RSS, suivi 2 liens exactement, et je me suis dit que, peut-être, linuxfr serait intéressé. Mea culpa si je me suis trompé?

Ben non, il se rappelle qu'on le lui a demandé, donc il a dû choisir ça.

3- par expérience, sauf besoin spécifiques, il faut se passer un maximum des types uintXX_t.

Je serais intéressé de savoir quels problèmes tu as eu avec ces types? Mis à part qu'ils peuvent ne pas être définis sur une archi ( contrairement aux types least et fast ), je ne vois pas de problème particulier?

En fait, j'ai l'impression que c'est même le contraire, dans un code:

• écrit par des gens ne connaissant pas stdint et donc les macros maxi/mini pour les int/char/short/long : on ne m'a jamais parlé de stdint.h à l'école, c'était pourtant en 2006, ça existait… à la place de ça, les profs nous disaient qu'un int c'est toujours 32 bits, la même taille qu'un long ( Chance pour moi: j'avais appris en autodidacte sur du C 16bits, avec un compilo différent, et un peu pratiqué du 32bits avec ce même compilo, du coups j'ai tilté qu'il est plus sûr d'utiliser short et long plutôt qu'int, moins de variations sur les plate-formes que je connaissait à l'époque ). Et là, je parle d'un étudiant. Un vieux roublard des intel x86 aura lui, potentiellement acquis des habitudes pas clean, et aurait pu utiliser les mêmes trucs crades de comparer à des constantes numériques faites main. Par exemple, je ne serais pas surpris de voir ce type de choses dans le moteur de certains vieux quake ou de duke nukem.
• écrit avant 1999: stdint.h, c'est le standard C99
• écrit pour être compatible avec du C++ pré 2011: stdint.h n'est standard que depuis C++11

voir des constantes numériques faites main pour tester la valeur maxi lors d'une itération n'est pas rare. Et bien sûr, la portabilité prend un sacré coup dans la gueule ( voire même la stabilité s'il s'est planté, mais bon… ). Alors que des types XintYY_t, quitte à ce qu'ils soient redéfinis ( comme le fait la SDL 1.2, par exemple ) peuvent être comparés au premier coup d'œil à la valeur testée: 0xFFFF et 0x7FFF pour les signés, -1 pour les non signés ( ça au moins ça marche toujours… je crois? ).

Ce que je veux dire, c'est qu'au moins, avec un uint16_t les valeurs mini/maxi/maxi non signé numériques sont fiables ( même si je suis d'accord qu'il faut éviter, mais les codes sources n'ont pas tous la possibilité d'être compilé avec des compilos respectant C99 ( 15 ans c'est jeune comparé au langage C ).

Une dernière petite question: est-ce-que travailler avec des uint*_t en mémoire plutôt que les classiques int, long est moins performant ?

Oui et non. Déjà, parce que performance, ça veut rien dire: performance en calcul, ou en place?
Aussi parce que sur les plates-formes ou uint32_t ( par exemple ) est un define du int, non, par exemple, mais ça peut varier.

Si la performance à ce niveau t'intéresse tant, je te conseille une petite lecture du fichier stdint.h. Plus précisément:

/* Small types.  */

/* Signed.  */
typedef signed char   int_least8_t;
typedef short int   int_least16_t;
typedef int     int_least32_t;
#if __WORDSIZE == 64
typedef long int    int_least64_t;
#else
__extension__
typedef long long int   int_least64_t;
#endif

/* Unsigned.  */
typedef unsigned char   uint_least8_t;
typedef unsigned short int  uint_least16_t;
typedef unsigned int    uint_least32_t;
#if __WORDSIZE == 64
typedef unsigned long int uint_least64_t;
#else
__extension__
typedef unsigned long long int  uint_least64_t;
#endif

/* Fast types.  */

/* Signed.  */
typedef signed char   int_fast8_t;
#if __WORDSIZE == 64
typedef long int    int_fast16_t;
typedef long int    int_fast32_t;
typedef long int    int_fast64_t;
#else
typedef int     int_fast16_t;
typedef int     int_fast32_t;
__extension__
typedef long long int   int_fast64_t;
#endif

/* Unsigned.  */
typedef unsigned char   uint_fast8_t;
#if __WORDSIZE == 64
typedef unsigned long int uint_fast16_t;
typedef unsigned long int uint_fast32_t;
typedef unsigned long int uint_fast64_t;
#else
typedef unsigned int    uint_fast16_t;
typedef unsigned int    uint_fast32_t;
__extension__
typedef unsigned long long int  uint_fast64_t;
#endif

Donc, voila: en fonction de tes besoins, tu as des types différents.

Sinon, j'ai noté l'utilisation d'un char, au milieu de types stdint, pourquoi ne pas avoir utilisé uint8_t? Ça me semblerait plus cohérent.

Enfin, si tu ne veux pas utiliser packed mais que tu veux contrôler l'alignement, il existe de mémoire une syntaxe pour les bitfields en C. Je ne m'en souviens plus, c'est pas le genre de trucs que j'utilise souvent, mais c'est simple à retrouver.

Bon, je mentionne surtout ça parce que tu risques d'y être confronté, et que c'est parfois intéressant si tu sais que tel variable est plus petite qu'un octet et que tu cherches une performance de taille maximale sans avoir à compresser par algo. Dans ton usage précis par contre, je ne pense pas que ce soit une solution acceptable.

Je dirais que c'est toujours mieux d'avoir de l'intégration continue, même si tous les tests ne passent pas immédiatement. Ça donne une piste pour les corriger, au moins.