Discussion :

[Fluorine]

Bonjour,

Oui parce que les directives et les macros en # sont traitées par le pré-processeur. Il n'en reste rien après la compilation… ni même avant ! Elles sont censées avoir toutes été substituées le cas échéant par leur motif final au moment où le compilateur proprement dit est appelé. Avec gcc, tu peux utiliser l'option -E pour lui demander

...

Merci, c'est très clair.
Le # permet d'obtenir un exécutable plus propre et plus rapide.
À préférer, même si le calcul obtenu ne change pas.

Jette un coup d’oïl sur le C# c'est un bon compromis entre la complexité du C++ et la lenteur Python dans l'envirenement windows , un langage disponible sur tous les pc qu'on peut l’utiliser à partir du Notepad++ sans rien d'autre... il supporte les chaînes texte nativement et le surcharge des opérateurs pour implémenter de nouveaux types de donné en math, et supporte également les générateurs ou énumérateurs pausables qui sont très pratiques pour gérer les séquences complexes

Merci.
Je ne connaissais pas cette utilisation du C#.
Je vais voir cela mais pour le moment je ne veux pas me disperser.
Je note précieusement.

Fluorine #10 :

Alors dans ce cas pourquoi ne pas faire un plus grand plongeon en écrivant un programme qui va transcrire un source BASIC en source C ?

Ouille !!! Ce n'est pas rien.
J'y ai songé, c'était un peu mon idée avec MID$.
J'avais commencé une ébauche qui transcode les instructions BASIC ( REM, FOR, WHILE,... ) en parfum C ( //, for, while ), et des ; pour terminer les lignes.
Cela allège l'usage du clavier lors de nombreux polynômes, sauce Horner, transcodé en C.
Cela aide un peu, tout comme la moulinette de l'AI.
Je me retrouve ainsi avec un code BASIC et des instructions parfum C...
C'est plus compliqué pour les boucles, même l'AI cafouille.

Finalement je me contente d'un programme qui me transcode les majuscules en minuscules.

-------------------------------

J'ai un peu avancé dans mes transcodage de BASIC en C.
Cela se passe plutôt bien.
J'avais largement abusé des DOUBLE, je modifie en adaptant vu qu'un double pour un compteur de 1 à 10...
J'étais une débutante, pas de livre "BASIC pour les nulles" et cela n'avait pas de nuisance visible.
Un abus de variables globales. Je transcode en deux temps, de BASIC en C, puis j'intègre les variables globales en locales.
Je constate avec certains programmes que j'étais vraiment une débutante. Heureusement, un code plutôt structuré et des commentaires. Le jour et la nuit, je constate mon évolution ( l'âge aussi )...
D'autres programmes de sources inconnues sont parfois incompréhensibles. Du spaghetti hors date limite de consommation.
Du code parfois peu judicieux alors que d'autres méthodes existent.

Je continue mes transcodages lorsque j'ai un moment. Cela avance doucement.
J'évite de me disperser hors du C pour le moment.

Merci à tous/toutes pour toutes ces sympathiques informations qui me sont très utiles. Je me sent moins seule dans ce travail de longue haleine.
Je suis en pleine transition du C vers le C, mais de l'ancien vers le moderne.
Des articles pdf sur le forum, que j'ai téléchargés.

[henderson]

En faisant une toute petite recherche, il y aurait ceci : https://www.bcxbasiccoders.com/

Je ne sais pas du tout ce que ça vaut !

Par contre, si ça génère des fichiers *.c ou *.cpp ça te permettrait de voir comment les autres font !

[Obsidian]

Bonjour,

Le # permet d'obtenir un exécutable plus propre et plus rapide.
À préférer, même si le calcul obtenu ne change pas.

Pas tout-à-fait.

Cela va être indiqué dans le présent pour définir des constantes symboliques sans avoir besoin d'instancier inutilement des ressources dans l'exécutable et ça, c'est une bonne chose en soi. Le préprocesseur sert également à des dizaines d'autres choses, comme par exemple faire de la compilation conditionnelle pour insérer ou non des ressources qui dépendent du système pour lequel on compile, ou pour tenir compte de contextes tel qu'un « mode Debug », par exemple.

Or, il arrive que lorsqu'un programme se complexifie à mesure qu'il évolue, on recoure de plus en plus souvent à ces macros et qu'elles-mêmes deviennent de plus en plus compliquées et on se retrouve parfois à embarquer des fonctions entières dans des macros au point de déléguer au préprocesseur ce qui devrait être de la responsabilité du compilateur.

En outre, même s'il est possible d'écrire des macros imbriquées, elles restent quand même complètement indépendantes de la structure du programme : le préprocesseur lit le fichier linéairement et fait les substitutions partout où nécessaires mais à dire vrai, il pourrait le faire sur un fichier texte ou sur le code source d'un autre langage et ça marcherait tout aussi bien.

Un exemple simple : typedef. Il est évident qu'en langage C, si l'on souhaite définir un nouveau type, en fait un alias d'un type natif ou composé déjà défini comme une structure, il faut utiliser ce mot-clé typedef pour écrire par exemple typedef int entier et non #define entier int. Dans le second cas, ça fonctionnera quand même mais le compilateur ne saura pas que c'est à ça que cela sert, ne tiendra pas compte de la portée locale du bloc où il est défini et en réalité ne verra jamais apparaître le symbole « entier » du tout puisqu'il aura été résolu en amont par le préprocesseur. Or, ces effets deviennent particulièrement sensibles en C++, spécialement avec les template, où il devient nécessaire qu'un symbole soit reconnu non seulement comme identifiant mais également comme un nom de type valable pour que le tout fonctionne.

En ce sens, on pourrait penser qu'il faudrait justement se passer des macros chaque fois qu'on le peut mais ta question est un excellent contre-exemple.

[Fluorine]

En faisant une toute petite recherche, il y aurait ceci : https://www.bcxbasiccoders.com/

Je ne sais pas du tout ce que ça vaut !

Par contre, si ça génère des fichiers *.c ou *.cpp ça te permettrait de voir comment les autres font !

Un joli programme qui génère du code C, très complexe mais hélas illisible en tant qu'humain. Mais parfois compilable.
Il y a quelques convertisseurs de ce type, mais toujours un code C humainement inexploitable.
J'avais tenté de voir les sources de QB64 dans ce but, mais même problème.
Le spaghetti a parfois l'avantage de pouvoir suivre le spaghetti sauf parfois adapter une fonction spécifique. Peu de risques de sub/fonction à implémenter en se prenant la tête au risque de calvitie fulgurante.
Le résultat fonctionne, mais incompréhensible; je déteste.

Bonjour,

Pas tout-à-fait.
....

.

Hello,

Logique...
Une explication encore très claire.
Merci.

[Guesset]

Bonjour,

La traduction Basic vers C n'a pas besoin d'être faîte entièrement à la main. Il existe des transpileurs (mot clé à utiliser our la recherche) qui font le travail. J'en ai trouvé plusieurs mais ne sais quels sont les meilleurs. Quoiqu'il en soit, le code C résultant (même quand il marche correctement) n'est généralement des plus beaux. Il convient donc de le reprendre ne serai-ce qu'en contrôle.

Salutations

[Fluorine]

Bonjour,

La traduction Basic vers C n'a pas besoin d'être faîte entièrement à la main. Il existe des transpileurs (mot clé à utiliser our la recherche) qui font le travail.

...

Salutations

Hello,

Il y en a quelques-uns en effet.
BCX, BaCo, B2C, QBasicToCpp, BASIC256,...
Hélas le code C obtenu est - humainement - illisible et très compliqué. Pas toujours compilable non plus.
Finalement j'ai mon petit programme en C, une moulinette, qui reconnait les principales commande de mes programmes-code BASIC comme FOR, SIN, COS,... que je convertis en minuscule. Je change les : en ; et ajoute ; en fin de ligne.
J'ai un programme BASIC qui me supprime les numéros de lignes inutiles, fourni par QB4.5, et compilé sous QB64.
Ce sont des anciens programmes même pas toujours QBASIC à l'origine et des LET à supprimer.
Un PRINT devient un printf un peu bizarre, surtout avec des USING et ###.

Bien sûr je me retrouve parfois avec du code aux commandes C mais avec la syntaxe BASIC.
Cela va bien comme un Y=COS( ... ): qui devient Y= cos(...);
J'ai nombre de formules mathématiques, cela aide.
Les boucles FOR, DO, WHILE,... et MID$ sont complètement à réviser à la main.
Des passages par référence ou par valeur (selon les parenthèses) qu'il faut passer en pointeur.

Beaucoup d'adaptation avec les variables globales et mon abus de DOUBLE en débutante.

J'exclus de passer un code source "sensible" sur un transpileur en ligne.
J'ai fait quelques test par AI... Pas terrible.
Tout cela permet de dégrossir sommairement le code concerné en économisant l'usage du clavier.

Merci.

[henderson]

Si on est en mode console, comment fait-on LOCATE ?

[Fluorine]

Si on est en mode console, comment fait-on LOCATE ?

Hello,

Aucune idée, je n'ai pas eu le problème.
printf aligne les résultats, à la suite sans adresse particulière de la console.

Peut-être un mode copiant le MSDOS qui répond aux interruptions du processeur en mode assembleur.
Voir:
Ralph Brown Interrupt List
... des odeurs de naphtaline...
J'avais bidouillé avec cela, cela date.

J'ai trouvé:
https://learn.microsoft.com/en-us/wi...sole-functions

[Obsidian]

Bonjour,

Si on est en mode console, comment fait-on LOCATE ?

Aucune idée, je n'ai pas eu le problème.
printf aligne les résultats, à la suite sans adresse particulière de la console.

Sans surprise, on commence par vérifier si le viewport (ici la console) en est capable ou non dans l'absolu. C'est évident une fois qu'on le dit, mais le problème concerne en fait beaucoup de projets et est à la source de pas mal d'erreurs de conception. De là, il y a deux possibilités :

• La console en est capable. On honore donc la commande. Sur PC, la console est en général un terminal DEC ANSI plus ou moins bien émulé, donc le curseur peut être replacé avec des commandes CSI. Il y en a plusieurs, mais le placement absolu se fait avec H : la séquence ESC [ 13,8 H (sans les espaces) place le curseur en ligne 13, colonne 8. Sur les Thomson 8 bits, équipés de différentes versions du BASIC Microsoft, c'était le Videotex qui était utilisé et ils pouvaient se piloter comme un Minitel ;
• La console n'en est pas capable : soit on ignore la commande silencieusement, soit on déclenche une erreur Device I/O Error.

Le dernier point soulève un point important, par lequel tout projet devrait commencer ou qui au moins devrait être défini assez tôt dans son développement : l'environnement minimum exigible.

Ici, il y a deux choses à déterminer :

1) doit-on toujours disposer d'une console ? Si on se réfère au fonctionnement du QBasic, le code source se développait soit dans une interface dédiée, soit depuis un éditeur distinct. À l'exécution, par contre, l'interpréteur préparait l'écran au démarrage (ce qui nous paraissait complètement implicite) en le vidant totalement et en le mettant de fait à la disposition du programme. Si les instructions du BASIC en dépendent, il faut peut-être l'émuler en mémoire quitte à ne pas l'afficher. Par contre, on pouvait également faire l'inverse : travailler en mode fichier vers le bon périphérique de sortie : « CASS: » pour écrire sur la cassette (oui…), « LPRT: » pour écrire vers l'imprimante et… « SCRN: » pour écrire vers l'écran, comme on le fait normalement avec PRINT en dehors de tout descripteur ouvert.

2) la prise en charge des erreurs. Jusqu'à présent, on a fait l'hypothèse que les commandes et instructions réussissaient toujours. En cas d'erreur, en revanche, il y a deux cas possibles : soit un arrêt immédiat avec un message (à renvoyer vers la bonne sortie et seulement si elle est disponible), soit une prise en charge avec ON ERROR GOTO/GOSUB puis RESUME.

Ce n'est pas forcément très difficile compte tenu du fait que le jeu d'instruction BASIC est limité et que son environnement l'était aussi, ce qui limite le nombre de cas de figures différents à prendre en charge. Mais il est certain que cela va demander de plancher dessus dès que l'on va dépasser les quelques fonctions initiales exposées ici.

[henderson]

Surtout si on fait face à des sources BASIC très anciens qui effectuaient des appels à des fonctions système ... comme sur l'AMSTRAD et il me semble que c'était aussi le cas avec le ZX81 via l'instruction CALL ...!
Ca remonte a plus de quarante ans !

[Fluorine]

Surtout si on fait face à des sources BASIC très anciens
...
avec le ZX81 via l'instruction CALL ...!
Ca remonte a plus de quarante ans !

Hello,

Oui.
J'ai connu avec le Spectrum Sinclair. Les PEEK et POKE pour l'accès direct mémoire, son BASIC et l'extension BetaBasic.
Les cassettes, variante des diskettes.
Et cela fonctionnait avec seulement 64 puis 128K de mémoire. Cela semble impossible maintenant !
Mes débuts en assembleur sur Z80 de Zilog...

[henderson]

Une époque lointaine où chaque octet gagné était une victoire !
Le CPC d'AMSTRAD tournait aussi avec un Z80.
Contrairement à l'idée reçue, le Z80 pouvait adresser 2 * 64K : grâce au bon usage de IN n,(C) et OUT(C),n avec le contenu de B sur le MSB du bus d'adressage et C sur le LSB !
Au niveau des ports on n'utilisait que la partie basse de l'adresse, laissant croire que ...!

Pour en revenir à nos moutons : ne pas oublier la bonne vieille notion de cahier des charges pour aller dans le sens de ce que nous dit Obsidian !
Je pense que le BASIC est suffisamment intuitif pour qu'on puisse assez facilement transcrire ce qu'il fait en C ou C++ quand bien même on puisse y laisser trainer des goto à gogo ou des routines à multiples points d'entrée !
Tout ça, ça ce code non pas pour être contemplé mais pour être exécuté !

[Fluorine]

Une époque lointaine où chaque octet gagné était une victoire !
Le CPC d'AMSTRAD tournait aussi avec un Z80.
Contrairement à l'idée reçue, le Z80 pouvait adresser 2 * 64K : grâce au bon usage de IN n,(C) et OUT(C),n avec le contenu de B sur le MSB du bus d'adressage et C sur le LSB !
Au niveau des ports on n'utilisait que la partie basse de l'adresse, laissant croire que ...!

Pour en revenir à nos moutons : ne pas oublier la bonne vieille notion de cahier des charges pour aller dans le sens de ce que nous dit Obsidian !
Je pense que le BASIC est suffisamment intuitif pour qu'on puisse assez facilement transcrire ce qu'il fait en C ou C++ quand bien même on puisse y laisser trainer des goto à gogo ou des routines à multiples points d'entrée !
Tout ça, ça ce code non pas pour être contemplé mais pour être exécuté !

Hello,

Le Z80 a des fonctions non officielles qui sont parfois révélés, mais qui peuvent varier d'une production à l'autre.
Ce n'est pas exclusif à ce processeur.

Le but reste de transcoder en C depuis le BASIC... mais dans un code C "humainement" clair.
Mon "expérience" de ces jours me permet de constater que cela se passe bien pour mes programmes à parfum mathématique. Des équations style polynômes et les interfaces utilisateurs plutôt basiques. Des codes simples à la base sans interactions obscures ou compliquées.
C'est plutôt facile avec un peu de patience.
J'ai tenté de traiter des codes sources pro pour tester !!! C'est autre chose ! Trop compliqué, j'ai renoncé. En passant des heures, probable que je puisse y arriver.
Les goto... Cela donne des dermatites fulgurantes à nombre de programmeurs ( moi aussi ), mais il faut reconnaitre que cela reste efficace malgré tout. Si cela est conforme au résultat attendu, pourquoi pas, c'est le but recherché si le code reste clair.

J'envisage de contribuer aux codes sources en C du site pour des programmes d'intérêt général. Un peu de ruban pour la décoration et un code commenté pour être compréhensible.

===============

Un grand merci à tous et à toutes ( oui, une participante, je me sens moins seule ) pour tous vos commentaires constructifs.
Je n'ai pas tout exploité pour le moment.
Cela me permet de progresser dans mon apprentissage du C. Je compte continuer.
Côté maths appliqués ( pas les maths modernes, étant de formation non européenne j'y ait échappé ), je me défend bien et cela aide.
Je veux éviter de me disperser pour le moment, mais j'envisage de m'étendre. J'avais abordé le Python, sans enthousiasme et côté compilation c'est faible. Mais j'envisage plutôt le C++.

[Artemus24]

Le CPC d'AMSTRAD tournait aussi avec un Z80.
Contrairement à l'idée reçue, le Z80 pouvait adresser 2 * 64K : grâce au bon usage de IN n,(C) et OUT(C),n avec le contenu de B sur le MSB du bus d'adressage et C sur le LSB !
Au niveau des ports on n'utilisait que la partie basse de l'adresse, laissant croire que ...!

Tes explications portent à confusion. Le Z80 n'a jamais pu adresser autre chose que du 64Ko.

Le processeur possède un bus d'adresses de 16 bits, ce qui limite directement son espace mémoire adressable à 64 Ko (2¹⁶ = 65 536 octets). En revanche, lors des instructions d'E/S IN et OUT, le Z80 place bien les registres B (octet de poids fort) et C (octet de poids faible) sur le bus d'adresses. Beaucoup de périphériques ne décodaient que les 8 bits de C, mais rien n'interdisait de décoder aussi les 8 bits de B. On obtenait ainsi un espace de 65 536 ports d'E/S, même si, en pratique, la plupart des machines (dont le CPC) ne décodaient qu'une partie de ces lignes.

Mais il existe une subtilité importante : les ports pouvaient servir à sélectionner des banques mémoire, chacun de 64Ko. Un port pouvait contenir un registre de pagination permettant de choisir quelle banque de 64 Ko était visible dans l'espace mémoire. Si tu avais 16 banques de 64 Ko, tu disposais physiquement de 1 Mo de RAM, mais le Z80 n'en voyait toujours que 64 Ko à la fois.

[fred1599]

Ah le CPC 6128 mon premier ordinateur, où j'ai appris aussi le BASIC très jeune (je vois encore cet énorme bouquin)

grâce au bon usage de IN n,(C) et OUT(C)

Il me semble que c'est plutôt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IN r,(C)
OUT (C),r

mais ce n'est qu'un détail... le r représente le terme registre.

La variante avec n, je crois que c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IN A,(n)
OUT (n),A

Au niveau des ports on n'utilisait que la partie basse de l'adresse

J'en suis pas sûr, ça se vérifie dans les docs...

Une époque lointaine où chaque octet gagné était une victoire !

Ouais après j'ai changé de monde avec le PC 1512 d'Amstrad et son extension pour monter à 640 Ko... le bon vieux temps !

[henderson]

S'agissant de OUT (C), r ou IN r, (C)

Description: The contents of register C are placed on the bottom half (A0 through A7) of
the address bus to select the I/O device at one of 256 possible ports. The
contents of Register B are placed on the top half (A8 through A15) of the
address bus at this time.

OUT A et IN A fonctionnaient autrement :

Description: The operand n is placed on the bottom half (A0 through A7) of the address
bus to select the I/O device at one of 256 possible ports. The contents of the
Accumulator (register A) also appear on the top half (A8 through A15) of
the address bus at this time.

[henderson]

Tes explications portent à confusion. Le Z80 n'a jamais pu adresser autre chose que du 64Ko.

Le processeur possède un bus d'adresses de 16 bits, ce qui limite directement son espace mémoire adressable à 64 Ko (2¹⁶ = 65 536 octets). En revanche, lors des instructions d'E/S IN et OUT, le Z80 place bien les registres B (octet de poids fort) et C (octet de poids faible) sur le bus d'adresses. Beaucoup de périphériques ne décodaient que les 8 bits de C, mais rien n'interdisait de décoder aussi les 8 bits de B. On obtenait ainsi un espace de 65 536 ports d'E/S, même si, en pratique, la plupart des machines (dont le CPC) ne décodaient qu'une partie de ces lignes.

Mais il existe une subtilité importante : les ports pouvaient servir à sélectionner des banques mémoire, chacun de 64Ko. Un port pouvait contenir un registre de pagination permettant de choisir quelle banque de 64 Ko était visible dans l'espace mémoire. Si tu avais 16 banques de 64 Ko, tu disposais physiquement de 1 Mo de RAM, mais le Z80 n'en voyait toujours que 64 Ko à la fois.

Dans l'instruction INI par exemple, le CPU adressait avec IORQ (accès au port) pour récupérer un octet puis adressait avec MREQ (accès mémoire) pour le stocker.
Donc 2 espaces de 64Ko en // !

[henderson]

...
C'est une fausse bonne idée très dangereuse en C. Si vous utilisez un buffer global (ou static), vous ne pourrez jamais extraire deux informations sur la même ligne de code. Par exemple, si vous écrivez : printf("Jour 1: %s, Jour 2: %s\n", mid_global(ligne, 0, 3), mid_global(ligne, 3, 3));L'ordinateur va écraser le buffer global lors du deuxième appel avant même que le printf n'ait eu le temps de s'afficher. Vous obtiendrez un affichage buggé du type : Jour 1: MAR, Jour 2: MAR.

Le problème ne vient pas de l'usage à proprement parlé du buffer en global mais du fonctionnement-même de printf.
C'est une histoire de collecte d'adresses qui prime sur l'ordre d'affichage des sous-chaînes.
A ce stade ce n'est même pas un bug ... c'est juste ... la règle !
Ca se contourne avec 2 printf !

[Médinoc]

Tes explications portent à confusion. Le Z80 n'a jamais pu adresser autre chose que du 64Ko.

Le processeur possède un bus d'adresses de 16 bits, ce qui limite directement son espace mémoire adressable à 64 Ko (2¹⁶ = 65 536 octets). En revanche, lors des instructions d'E/S IN et OUT, le Z80 place bien les registres B (octet de poids fort) et C (octet de poids faible) sur le bus d'adresses. Beaucoup de périphériques ne décodaient que les 8 bits de C, mais rien n'interdisait de décoder aussi les 8 bits de B. On obtenait ainsi un espace de 65 536 ports d'E/S, même si, en pratique, la plupart des machines (dont le CPC) ne décodaient qu'une partie de ces lignes.

Mais il existe une subtilité importante : les ports pouvaient servir à sélectionner des banques mémoire, chacun de 64Ko. Un port pouvait contenir un registre de pagination permettant de choisir quelle banque de 64 Ko était visible dans l'espace mémoire. Si tu avais 16 banques de 64 Ko, tu disposais physiquement de 1 Mo de RAM, mais le Z80 n'en voyait toujours que 64 Ko à la fois.

Dans le cas de l'Amstrad CPC 6128, le troisième quart (16Kio) de l'espace adressable pouvait être réglé pour pointer sur l'une des quatre banques mémoire de 16Kio supplémentaires.

Je suis d'avis que cette glorieuse époque où l'on pouvait écrire un programme avec des graphismes et des caractères n'importe où à l'écran, sans même avoir à installer un logiciel tiers, fait grandement défaut de nos jours.
Et hélas, le langage C est probablement le moins approprié pour tenter de reproduire des programmes qu'on pouvait faire en BASIC. La gestion 100% manuelle de la mémoire est à l'opposé de la facilité accordée par le BASIC. Pour cela, je recommanderais C++ au strict minimum, ou C# si l'on accorde peu de valeur à l'intérêt pédagogique de tout réimplémenter.

[Fluorine]

Hello,

Je me régale au passage de ces vieux souvenirs avec ces ordinateurs des débuts.
J'ai largement utilisé les BASIC simplifiés et malgré le peu de décimales utilisables.
C'étaient mes débuts en BASIC, à côté du Fortran et du Flextran ( Tracor Northern ) et la HP41 ( + sa programmation synthétique ) ayant un "IND", tel que STO IND X, pseudo pointeur...

J'en reviens à mes transcodages BASIC vers C.
Mes sources en BASIC sont plutôt bien structurées.
Les autres, il y a de tout. Quelques une bien écrites, d'autres obscures à comprendre. Du spaghetti souvent.
J'utilise parfois une technique consistant à passer toutes ( ou presque ) les variables en mode global, tout le code en "main" et voir si cela passe. Je peste lorsqu'un nom de variables est utilisé dans des fonctions différentes.
Reste ensuite à internaliser ces variables, parfois en créant des fonctions/sub pour cela. Quoique, si cela fonctionne il faut voir si cela en vaut la peine.

J'espère que ces transcodages pourront (me) servir ultérieurement en étant claires. Si nécessaire transcodés ultérieurement en un autre langage.

J'améliore progressivement mes techniques de transcodages.
Pour les sources BASIC Amstrad, Spectrum,... je ne cherche pas à transcoder si de la vidéo est incorporée.
Ce n'est pas fréquent avec les programmes que je vise.
À utiliser avec des émulateurs éventuellement.

Avec mon soutien et une pensée à toutes les victimes des incendies.
Je n'ai eu que les fumées et des irritations. Rien de grave.

Bonne soirée.