Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : GFA Basic - Débogage et traces
(Article écrit par Denis Obriot et extrait d'Amiga News Tech - avril 1990)
|
|
Parmi les facteurs qui permettent de juger de l'efficacité d'un langage, la rapidité d'exécution est
la plus souvent citée ainsi que la taille du code généré. Même si ces deux facteurs sont réellement importants,
je crois que c'est une erreur de leur accorder la priorité. Si votre programme est fait pour être utilisé
une seule fois, à quoi cela vous servira-t-il qu'il s'exécute en dix secondes plutôt qu'en cinq minutes ?
Vous me répondrez que c'est toujours cinq minutes de gagnées.
Ceci reste encore à prouver car tout dépend du temps que vous avez passé à mettre au point le programme, qui
doit être comptabilisé dans la comparaison, surtout pour les programmes ne devant pas servir beaucoup. A
ce moment-là, on se rend compte qu'un programme développé en deux heures va plus vite qu'un programme
développé en deux jours. Même si les tests montrent que le deuxième programme est celui qui s'exécute
en dix secondes. Il ne faut donc jamais oublier les temps de mise au point quand on veut avoir une bonne
idée d'un langage.
Le débogage en GFA Basic est relativement simple, c'est ce que nous allons voir. Le programme numéro 1
est un très bon exemple de programme faux. Tapez-le sous l'éditeur et lancez-le. Vous verrez qu'il ne
s'arrête jamais. C'est exactement le genre d'erreur agaçante car on ne sait pas où le programme cloche.
Programme 1
La méthode la plus connue pour déboguer un programme tel que celui-ci consiste à mettre ce que l'on appelle
des traces (ou des mouchards) dans le programme.
Le programme numéro 2 montre cette méthode, utilisée selon le principe dichotomique. Il s'agit de séparer
le programme en petits bouts afin de savoir où le problème se pose. Il permet de deviner en trois secondes
que la boucle WHILE ne se finit pas. C'est alors qu'on modifie le programme numéro 2 en enlevant le commentaire
devant l'instruction PRINT. Cela suffit pour se rendre compte qu'il passe à 0 aussitôt après avoir valu 255.
Ce qui est tout à fait logique puisqu'il est un octet, c'est-à-dire un nombre entre 0 et 255.
Programme 2
Il ne nous reste plus qu'à réparer l'erreur en modifiant le test faut donc modifier à nouveau notre programme pour réparer
l'erreur (programme 3).
Programme 3
Après cela, on se rend compte que la boucle DO...LOOP ne fonctionne pas correctement.
Si on avait enlevé les traces, on aurait plutôt pensé que la boucle WHILE...WEND n'avait pas été
correctement réparée, méfiez-vous de cela. Je suppose que vous avez compris que la boucle ne marche
pas parce qu'il ne pourra jamais être négatif (il fallait mettre LOOP UNTIL i|=0). Laissons maintenant
de côté ce petit programme.
Cette manière de tracer un programme est une sorte de standard puisqu'elle fonctionne dans pratiquement
tous les langages, y compris l'assembleur. C'est une bonne méthode puisqu'elle nous a permis de trouver
ce qui n'allait pas. Par contre, quand l'erreur produit un plantage du système, on se rend compte qu'il
est très important de trouver l'erreur du premier coup pour éviter des manipulations excessives. Sinon,
il faudra placer quelques mouchards suivis d'instructions DELAY ou PAUSE, sauver le programme, le lancer,
bien observer à chaque fois entre quels mouchards a eu lieu le plantage, regarder un magnifique plantage
du système (le fameux mode Fireworks), redémarrer l'Amiga, etc. Je vais peut-être vous décevoir mais mon
programme numéro 4 ne cause pas de plantage du système, il se contente de vous faire une petite erreur division
par zéro.
Programme 4
D'ailleurs quand vous appuyez sur "Entrée", le curseur est sur la ligne contenant l'erreur, ce qui n'arrive pas
quand un Guru se produit. Comment auriez-vous fait si ce programme avait réellement produit un Guru ?
Ce qui est réellement important maintenant, c'est de savoir sur quelle instruction le programme plante et aussi
avec quelles valeurs. Le programme 5 permet de s'en faire une idée très précise.
Programme 5
L'instruction utilisée ici est TRON. Cette instruction permet d'afficher la prochaine instruction qui va être exécutée.
J'ai utilisé une forme un peu compliquée de cette instruction qui utilise une procédure pour afficher la trace.
Je crois qu'il est très utile d'avoir des procédures de ce genre, celle-ci est intéressante car on peut faire défiler
le programme rapidement en appuyant sur un bouton de la souris et même tout arrêter en le lâchant.
Pour finir, je vais vous donner mes procédures préférées en matière de traces (programme 6). Celles-ci sont générales,
c'est à vous d'afficher vos variables à l'intérieur de ces procédures si vous en avez besoin.
Programme 6
|
