PureBasic

Un petit code qui permet de récupérer des informations musicales grâce à l'API de Discogs.
Il n'a pas la prétention d'être parfait ni de gérer toutes les types d'appels ou de données de l'API.
En effet, n'est pas géré tout ce qui a trait à la vente, aux statistiques et aux données communautaires.
De même, la fenêtre "Résultats de recherche" n'a pas pour vocation d'être graphiquement ou ergonomiquement agréable mais seulement permettre d'appréhender les données récupérables.

Pour pouvoir l'utiliser, il vous faut obtenir deux clés API auprès du site. Une clé principale et une clé secrète.
Si cela vous intéresse, l'inscription se fait par ici et c'est gratuit !
Pour obtenir vos clés, cliquez sur votre avatar puis sur "Paramètres", "Développeurs" et enfin "Créer une application" ( Lien ).
Une fois votre application créée et vos clés obtenues, il vous suffira alors de modifier la valeur des constantes #DISCOGSCLE et #DISCOGSCLESECRETE du source.




Je lance un appel aux spécialistes des threads. L'exécution du code est uniquement séquentielle. Y aurait-il un intérêt à utiliser des threads ? Si oui, où et comment ? . Merci d'avance

N'hésitez pas à me faire part de vos remarques et/ou possibilités d'améliorations/optimisations.

En raison de sa longueur et de la limitation du nombre de caractères par message, le code ne peut être publié directement sur le site.
Vous pouvez le télécharger ici.

Nouvelle version.
Petite correction apportée au niveau de l'affichage des résultats de recherche générale.
Les données Codes-Barres et Genres n'étaient pas affichées dans les bons gadgets dédiés.

Boddhi a écrit :Je lance un appel aux spécialistes des threads. L'exécution du code est uniquement séquentielle. Y aurait-il un intérêt à utiliser des threads ? Si oui, où et comment ? . Merci d'avance

Y a-t-il un intérêt ? J'en sais rien.

En tout cas, comment ? Ça, je sais. Un thread, pour résumer simplement, c'est une procédure que tu vas appeler différemment des procédures habituelles, grâce à CreateThread().

Pour communiquer entre un thread et la partie principale de ton programme, tu peux créer une structure. Cette structure te permettra de faire échanger des ordres et des infos entre le thread et la partie principale du programme.

Boddhi a écrit :Je lance un appel aux spécialistes des threads. L'exécution du code est uniquement séquentielle. Y aurait-il un intérêt à utiliser des threads ? Si oui, où et comment ? . Merci d'avance

Y a-t-il un intérêt ? J'en sais rien.

En tout cas, comment ? Ça, je sais. Un thread, pour résumer simplement, c'est une procédure que tu vas appeler différemment des procédures habituelles, grâce à CreateThread().

Pour communiquer entre un thread et la partie principale de ton programme, tu peux créer une structure. Cette structure te permettra de faire échanger des ordres et des infos entre le thread et la partie principale du programme.

Une convention importante dans la structure qui fait lien, c'est de bien séparer les variables en fonction du sens directionnel de l'information :
- il y a ce qui rentre vers un thread
- il y a ce qui sort d'un thread

Techniquement, on peut mélanger les deux sens de flux, mais comme un thread s'exécute "en défiant le temps", si on n'utilise qu'une seule variable pour faire circuler des données en tout sens (un peu comme le principe d'ethernet), on ne sait pas qui a écrit quoi donc rendez-vous au club des bugs et plantages...

Salut Ollivier,

Merci pour ta réponse.

Je dirais en gros que je comprends le principe des threads mais leur mise en oeuvre reste encore un écueil pour moi !

MicroDevWeb avait fait un tuto qui ne m'avait pas permis d'approfondir le sujet (Bref, j'avais pigé que dalle )
Les mutex et sémaphores sont tjs restés des gros mots à mes yeux et une de mes dernières tentatives, pour des opérations en tâche de fond sur des fichiers, ayant provoqué des résultats inattendus, j'ai fini par lâcher l'affaire et revenir à une exécution du code plus "classique".

Olliver a écrit :Y a-t-il un intérêt ? J'en sais rien.

Moi aussi, je n'en sais rien.

La raison de mon questionnement est la suivante :
L'API Discogs, malgré des paramètres très précis fournis, renvoie tout un tas de données plus ou moins pertinentes. En gros, il faut reconnaître qu'il y qd même beaucoup de déchets. On peut ainsi atteindre parfois des milliers voire des dizaines de milliers de résultats. Sachant qu'on est limité à 100 résultats maximum par page, tu imagines alors fort bien le nombre de requêtes à lancer et l'incidence sur l'exécution du programme qui aura tendance à freezer très rapidement.

D'où mon interrogation... Est-ce que l'utilisation de thread(s), à un endroit ou à un autre, serait-elle pertinente ?
Genre : Pendant que j'interroge l'API et réceptionne les résultats des pages, je gère en parallèle le traitement des données déjà reçues et l'affichage d'informations sur l'écran...

Issu de la très vieille école séquentielle (j'ai commencé sur un ZX81, c'est dire !), totalement autodidacte (avec un peu l'aide de Science&Vie, Hebdogiciel et autres revues antédiluviennes), j'ai complètement raté le train du multitâche et des threads. D'où parfois mes interrogations sur l'utilité et la pertinence d'un recours potentiel à ces threads...

Ben si t'as complètement raté le train des multi-tâches et de s threads, mon code plus haut est suffisant pour tout comprendre.

Il est concis. Excepté ma simulation de boucle principale, qui est un gros coup de flemmingite aigüe (une boucle repeat...until aurait été plus attrayante, mais aurait compliqué lourdement l'explication autour du fonctionnement de ce simple thread), tout l'essentiel y est.

Après tout, le séquentiel ne permet-il pas d'opérer deux tâches distinctement ?

Un porte OU logique, n'est-ce pas mettre deux interrupteurs en parallèle ?

Le multi-thread n'est pas forcément combinatoire : le multi-thread ne nécessite pas forcément de mémoire.

Sans mémoire, un multi-thread ça fait "de la merde", parce que ça ne sert à rien d'utile sauf pour comprendre le multi-thread.

Petit rappel du grafcet qui ne t'apprendra pas grand chose, mais te rappellera tout le nécessaire, rien que le nécessaire.Et moi, mon code plus haut a juste besoin d'être compris.

Pendant le Delay(5000) toute la procédure threadée unThread() s'exécute en boucle.

C'est d'ailleurs un boucle qui attends un signal : le champ de structure ArrêterThread.

Signal qui arrive après le Delai(5000) dans le programme principal.

Dans le thread, que se passe-t-il avec ce signal ? La boucle cesse, et, un second signal ThreadArrêté est officialisé.

Dans le programme principal, une boucle attend le signal ThreadArreté et, comme ce signal est arrivé : fin totale du programme.

Et tout le reste dans un système multi-exécution suit ce principe de paires de données qui se croisent :

- Faire la chose
- Chose faite

(comme une étape d'un grafcet toujours suivie d'une condition)

Et les deux vraies difficultés avec les threads c'est d'une part, la familiarité en langue française de la terminaison des verbes :
Chanter vs Chanté

C'est, d'autre part, le fait que les accents sont interdits dans le code source : eh oui Sans accent, on peut s'emmêler les pinceaux.

Après les noms d'oiseau et de lutin, comme "mutex" et "sémaphore", ça n'est que des suppléments à connaître plus tard, une fois l'usage des threads familiarisé : c'est Fred qui a imaginé que toutes ces données de synchronisation obligatoirement programmées par paire, le compilateur pouvait en gérer certaines et ça fait économiser l'affichage de données explicites dans le code.

Avec des mutex et des sémaphores, les diverses synchronisations peuvent devenir implicites.

En préambule, merci de prendre le temps de tenter de me répondre et de tenter de m'expliquer le fonctionnement des threads.

J'ai conscience d'être parfois un peu long à la détente dès lors qu'une interrogation persiste dans mon petit crâne.

Ollivier a écrit :Petit rappel du grafcet qui ne t'apprendra pas grand chose, mais te rappellera tout le nécessaire, rien que le nécessaire.

Euuuh, comment te dire ? J'ai pas bité grand chose !
Et je défie tout non-initié d'y piger quelque chose !

Si le principe du thread consiste en :
• Lancement d'une tâche principale
• Appel, initialisation et activation d'un thread
• Retour à la tâche principale et son exécution avec attente d'un message du thread signalant un traitement à effectuer ou la fin de son exécution (par le biais de variables ou avec l'utilisation éventuelle des instructions PauseThread(), ResumeThread(), PostEvent(), etc.)
Ca, je l'ai compris.

Après, c'est la mise en pratique qui me pose souvent problème et comme j'ai pas envie de passer un temps fou à tenter qq chose avec une construction programmatique dont je ne suis pas même certain de la bonne logique, au mieux j'y renonce, au pire, je n'envisage même pas la chose.

Ollivier a écrit :Après les noms d'oiseau et de lutin, comme "mutex" et "sémaphore", ça n'est que des suppléments à connaître plus tard, une fois l'usage des threads familiarisé

Ok, d'accord ! Mais du coup, comment tu fais pour savoir si tu en as besoin ou non quand tu comprends pas vraiment ce que c'est, à quoi ça sert et/ou comment ça fonctionne ?

Dans mon cas, avec une exécution séquentielle, où j'ai à récupérer plusieurs pages internet de données et à traiter ces résultats, mon code consiste en :
1) Je récupère une page
2) Je traite les données de la page reçue
3) Je relance 1
4) Je relance 2
x) 1 et 2 autant de fois qu'il y a de pages à récupérer

Comme ces tâches sont exécutées les unes à la suite des autres, cela finit, à un moment ou à un autre, par freezer l'appli et rendre difficile l'affichage en temps réel d'informations. Je biaise par des While WindowEvent():Delay(x):Wend mais ce n'est pas toujours convaincant.

Et là, je me dis : "Y aurait-il un intérêt à utiliser un thread ? Peut-être bien ! Oui mais tu maîtrises pas bien. Eh bien, fais comme Coluche le préconisait : Demande-moi si tu en as besoin et je te dirai comment t'en passer !!!"
Le cas échéant, si toi, tu étais confronté à ce type de problématique, quel serait ton schéma d'écriture ou d'exécution du code ?

Ollivier a écrit :Et les deux vraies difficultés avec les threads c'est d'une part, la familiarité en langue française de la terminaison des verbes :
Chanter vs Chanté
C'est, d'autre part, le fait que les accents sont interdits dans le code source : eh oui

Il y a longtemps, j'ai été confronté à ce problème et je partage ton point de vue.
Du coup, j'ai pris pour habitude de nommer mes variables ainsi :
• (Substantif ou Verbe) + Nom commun ➞ Action à effectuer à un moment donné.
    Ex. : ArretThread ou ArreterThread consistera à déterminer si à un moment donné de l'exécution, l'action d'arrêter le thread devra être effectuée ou non
• Nom commun + Participe passé ➞ Récupération ou affectation d'un état
    Ex. : ThreadArrete consistera à déterminer à un moment donné l'état du Thread

Après, comme toujours, il s'agit d'une convention personnelle et il arrive que, considérant que l'usage de deux variables soit inutile parce que redondantes, je sois contraint de choisir entre l'un ou l'autre type

Ah... tu bites rien au grafcet? Je savais pas. Ben si tu bites rien au grafcet, une méthode pédagogique, non sans pragmatisme, consiste à n'en avoir absolument rien à faire des grafcets, comme si ça n'avait jamais existé.

Comme ça, on va gagner un du temps. C'était juste un dessin qui représente toute sortir possible de process séquentiel (recette de cuisine, consigne de changement de pièce auto, programme informatique, etc...).

C'est le mot "séquentiel" qui, de suite m'a inspiré une convention de schéma séquentiel.

Par la mëme, j'ai regardé "séquentiel" et "combinatoire", et, visiblement, ça fait presque 30 ans que j'inverse systématiquement les deux logiques. Traduction : toute mon explication plus haut (message précédent) est effectivement beurrée complêtement. Tout faux.

Pour faire simple, t'as mon code plus haut : c'est tout ce que tu as besoin. À la limite, tu le copies à la main sans les commentaires, depuis cette page jusqu'à ton IDE, car tu en auras toujours besoin pour les threads.

Ce code, c'est un thread qui est exécuté (c'est la procédure nommée unThread() ) en même temps que Delay(5000).

Voilà, c'est tout ! Ce code, c'est ça mon schéma de code !

Pour ton cas, tu remplaces Delay(5000) par ta boucle principale à toi, et puis tu fourres dans la procédure unThread() (que tu peux renommer comme bon te semble) tout ce que tu veux qui s'exécute en même temps que l'exécution de ta boucle principale.

Si tu as des choses à communiquer entre les deux entités (le thread vs la boucle principale), tu insères de nouvelles variables dans la structure lien que tu peux aussi renommer comme bon te semble.

Exactement comme ton facteur qui te ramènes un ticket gagnant de loto d'une valeur de 100 millions d'euros, et qui t'appelle depuis la Lune pour te raconter qu'il est exceptionnellement en retard aujourd'hui, tu vas :
1) lui dire de te ramener illico le ticket
2) tu vas attendre qu'il te dise "oui" (sinon tu atomises la lune)

Et bien la boucle principale et le thread ont exactement la même relation de communication que toi, avec ton facteur :
pour une action, deux variables.

ramenerTicketIllico.i
et
TicketBienRevenu

Pourquoi deux variables ? Procédons par élimination et imaginons que l'on se borne à travailler avec une seule variable :
EtatTicket.i par l'exemple.

Convenons, dans notre bêtise que :
EtatTicket = 1 signifie << ordre de ramener le ticket de loto >>
EtatTicket = 2 signifie << ordre reçu, ticket rendu >>

Quel bug peut survenir ?

bug numéro 1) le coup du "facteur trop compétent"
-> Tu n'as pas fini de lui donner l'ordre (code 1) que lui, il t'a ramené le ticket en t'avertissant (code 2). Résultat : le CPU réécrase le code 2 avec ton code 1 dans la variable.
Traduction : tu atomises la lune pour tuer le facteur (qui semble ne pas répondre) avant de remarquer que tu as le ticket à 100 millions dans ta boîte au lettre.

bug numéro 2) le coup du "facteur trop malchanceux"
-> Tu lui as envoyé le code 1. Le facteur t'a donc ramené le ticket à 100 millions d'euros. Mais son avertissement n'est pas encore arrivé.
Traduction : tu atomises la lune pour tuer le facteur (qui semble ne pas répondre) avant de remarquer que tu as le ticket à 100 millions dans ta boîte au lettre, puis de recevoir son message (code 2) qui t'indique << Je t'ai mis ton ticket dans ta boîte aux lettres >>.

Pour éviter ces bugs caractéristiques de la simultanéïté des threads, on compose une variable en deux emplacements distincts.

Et tu as mon exemple dans mon code, dans la structure, des deux variable pour stopper le thread.

Tu peux faire pareil pour mettre ton thread en pause, et n'utiliser que ces seules fonctions natives dans ce petit code plus haut, plutôt que d'utiliser toutes les autres et te compliquer la vie au départ.

Pourquoi ce conseil ? Parce qu'en te contraignant à tout mettre tes doubles variables dans cette structure, tout est explicite. En cas de pépin, tu peux mettre une sécurité dans ton programme principal, qui sauvegarde très simplement ta structure dans un fichier (avec readData() et writeData()). Donc tu as alors tous tes états qui sont sauvegardés sur fichier avant un bug.

Tu peux aussi enregistrer en temps réel ce qui se passe pendant quelques secondes, et écraser en temps réel, les données périmées (plus vieilles qu'une seconde, par exemple). Pour débuguer ça aide.

Puis, quand viendra le moment d'utiliser plus qu'un seul thread dans un nouveau projet, là tu auras une belle expérience initiale pour utiliser toutes les autres fonctions natives que celles contenues dans ce seul petit code.

erratum : En regardant en diagonale ta présentation de programme, oui, il y a une stratégie de programmation : ne rien mettre dans ta procédure "thread" sauf les instructions ou groupe d'instructions qui mettent plusieurs secondes. Dans ta procédure thread, tu fais une boucle qui attend des ordres, et répond qu'elle les exécute. Et si tu as des instructions de téléchargement, effectivement, tu peux utiliser PauseThread si tu veux que quelquechose s'exécute rapidement (normalement). Dans ton cas, comme ton thread est seul, il ne fera qu'une seule chose à la fois. Donc si tu lui envoies plusieurs ordres à la fois, il ne va pas répondre de suite qu'il a tout fait.

Par exemple, pour que la boucle principale télécharge une musique, tu vas écrire : Et à chaque fin de cycle de boucle principale, tu vas raffraîchir : Ici, si le carnet de commandes est saturé, force cette fois-ci un vrai freeze pour qu'au moins un des 256 téléchargements soit achevé.

Note : x & 255 c'est le modulo x par 256, et ça correspond rigoureusement au nombre 256 dans la structure.

Ollivier a écrit : C'est le mot "séquentiel" qui, de suite m'a inspiré une convention de schéma séquentiel
[...}
Puis, quand viendra le moment d'utiliser plus qu'un seul thread dans un nouveau projet, là tu auras une belle expérience initiale pour utiliser toutes les autres fonctions natives que celles contenues dans ce seul petit code.

Tout ce que tu m'expliques, ça, je pense déjà l'avoir assimilé par mes tentatives antérieures. Je vais tenter d'expliquer au mieux ce que j'en avais retenu :

Deux approches possibles, donc :
1) On lance un thread et parallèlement on a une boucle d'exécution d'instructions au cours de laquelle on vérifie l'état du thread à l'aide par exemple d'une variable structurée (Ex : EtatThread\Pause.a, EtatThread\Arret.a EtatThread\Fin.a)
2) On lance un thread et parallèlement on a une boucle d'évènements qui intercepte et gère des messages PostEvent() envoyés à partir du thread.

Sachant que les deux méthodes peuvent aussi être combinées...

Après, ce qui m'échappe, c'est à quoi servent les mutex et les sémaphores. J'ai beau avoir essayé de me pencher sur le sujet, la documentation est trop souvent théorique ou absconse pour avoir réussi, dans mon coin, tout seul comme un grand, à appréhender leur utilité et leur fonctionnement.
Et l'intérêt indubitable, puisqu'ils existent, que leur utilisation pourrait avoir dans certaines situations.

Ollivier a écrit :erratum : En regardant en diagonale ta présentation de programme
[...]
Dans ton cas, comme ton thread est seul, il ne fera qu'une seule chose à la fois..

Bon, si j'ai bien compris, y a pas vraiment d'intérêt dans mon cas à utiliser un thread ?!

Le "erratum", c'est uniquement pour te dire que le PauseThread() (en BP) peut être utilisé.

À partir du moment où tu ne veux pas de "freeze", mais qu'à la place, tu veux une interface graphique qui continue d'être opérationnelle avec des avertissements (ex : << En cours de traitement... >> ) sur les tâches de download/importation/acquisition, alors les threads sont utiles.

Un seul thread qui ne fait qu'une chose à la fois ne veut pas dire "mono-tâche". Pour clarifier, on va parler autrement :

1) Un programme normal sans lancement de thread, c'est un programme mono-thread. Il n'y a qu'un seul thread, et c'est le thread principal.

2) Si tu lances un thread, alors tu te retrouves avec un programme dont le thread principal a lancé un thread secondaire. Donc un seul thread lancé te permet de voir deux process s'exécuter en même temps.

Tu parles de PostEvent() : il faut vérifier si c'est une instruction autorisée dans un thread (à tester donc).

Tu parles de mutex et sémaphore : je te dis de zaper ça pour l'instant. Pourquoi ?
Parce que tu n'as besoin que de deux exécutions en parallèle : le thread principal, et le thread que tu as lancé, le thread secondaire.

Les mutex et sémaphore, c'est surtout utile quand tu as plus de deux exécutions en parallèle (3 exécutions ou plus). Ce sont des éléments de synchronization (donc des ralentissements automatisés) pour que les threads nombreux s'exécutent dans l'ordre que tu veux.

Toi, avec seulement deux exécutions en parallèle (thread principal et thread secondaire lancé avec CreateThread() ), ce n'est pas la peine de monter la barre trop haut.

Ce qui t'importe vraiment c'est de comprendre que...... c'est bien ça et uniquement ça qui te crées une branche d'exécution en parallèle.

Grosso modotemporellement, ça donne ça :lundi + mercredi sont exécutés en même temps, donc dans la pratique, tu vas obtenir deux résultats possibles au hasard :

soit : lundi avant mercredi
soit : lundi après mercredi

Petite remarque : impossible d'accéder à ton code source.
Combien de lignes fait-il ?

Salut Ollivier,

Un grand merci pour tes explications.
Comme je suis, en ce moment, sur un autre truc, je me pencherai un peu plus tard sur ce sujet.
Je reviendrai vers toi, si cela ne te dérange pas, pour continuer cet échange intéressant.

Edit : Oupps j'avais pas vu ton dernier message
Pour moi, le lien est parfaitement fonctionnel !
Je le remets au cas où : Lien

Si tu souhaites revenir vers moi (pour x raisons perso), il y a la messagerie privée sur le forum anglais (mon pseudo 'olli'). Dans ce cas on échangera nos mails que je consulte plus souvent.

Si tu souhaites revenir vers moi publiquement, aucun souci. Si ça peut te rassurer, d'autres membres pourront certainement prendre le relais, comme ça tu es sûr que ce sujet ne te passera pas à côté.

Juste une remarque, je ne parviens toujours pas à downloader ton programme. Mais, ce qui m'intéresse en priorité, c'est :

- de savoir combien de lignes il fait
- et puis si tu as un peu de temps, nous raconter le temps consacré, peut-être les difficultés rencontrées. Ce sont des petits détails certes inutiles, mais humains. Je m'y attache un peu personnellement.

Ollivier a écrit : Juste une remarque, je ne parviens toujours pas à downloader ton programme

Est-ce ça ne viendrait pas de ton navigateur (bloqueur de scripts, de pubs ?) ?
Parce que pour moi, c'est OK !
Normalement, tu dois tomber sur cette page :

Et tu n'as plus qu'à cliquer sur 'Télécharger'...

Ollivier a écrit : Si tu souhaites revenir vers moi (pour x raisons perso), il y a la messagerie privée sur le forum anglais (mon pseudo 'olli'). Dans ce cas on échangera nos mails que je consulte plus souvent.
Si tu souhaites revenir vers moi publiquement, aucun souci. Si ça peut te rassurer, d'autres membres pourront certainement prendre le relais, comme ça tu es sûr que ce sujet ne te passera pas à côté.

Ollivier a écrit : - et puis si tu as un peu de temps, nous raconter le temps consacré, peut-être les difficultés rencontrées. Ce sont des petits détails certes inutiles, mais humains. Je m'y attache un peu personnellement.

Merci .

Après, je n'ai pas de besoin particulier concernant les threads.
Lorsque j'ai abordé le sujet dans mon premier message, c'est juste pour avoir l'avis des experts en la matière, s'ils venaient à jeter un coup d'oeil sur mon code. Qu'ils me fassent savoir si, selon eux, il y aurait un intérêt quelconque à recourir à un thread et, le cas échéant, où, quand, comment ?
Peut-être qu'il y en a absolument aucun. En tout cas, le code est tout à fait opérationnel sans et, en conséquence, peut s'en passer sans souci.

De plus, ce code est principalement fourni à la 'communauté' au cas où certains seraient intéressés par la possibilité de récupérer des données via l"API Discogs même si, par ailleurs, certains de ses aspects, comme l'appel à une API internet, la manipulations des données JSON, le recours aux dialogues XML, etc pourront peut-être aussi intéresser les moins experts d'entre nous en la matière.

Pour info, j'avais développé un gestionnaire de BDD de pistes audio, avec également analyse "binaire" (métadonnées et blocs audio ID1, ID3, ASF, VORBIS, RIFF) des formats MP3, M4A, FLAC, OGG, WMA et WAV et, intéressé par le fait de pouvoir récupérer certaines données automatiquement sans avoir à me les taper moi-même, je me suis lancé dans le recours aux API. C'est en développant et en intégrant à mon gestionnaire ces fonctionnalités-là que m'est venu l'idée d'en partager les contours.
J'avais fait de même avec l'API TheMovieDatabase parce que j'étais intéressé par récupérer certaines informations automatiquement qu'auparavant je me farcissais à taper à la main ou à abuser du copier/coller afin d'alimenter mon gestionnaire de BDD vidéos. Et surtout, aussi, pour récupérer les affiches de films par un simple clic sur un bouton !!!
En ce moment, je m'attaque à l'API MusiXMatch car elle permet de récupérer les paroles en VO ou en version traduite (si elles existent) des chansons pour pouvoir directement les injecter dans le bloc ID3 de mes pistes.
Je devais le faire avec l'API Genius mais j'ai laissé tombé car trop chiant et compliqué d'obtenir des résultats intéressants sans faire 36000 requêtes. Même pour des trucs hyper simples.

Ollivier a écrit : - de savoir combien de lignes il fait

Un peu plus de 2300 lignes et 150ko en caractères bruts.