Obligement - L'Amiga au maximum

Lundi 19 novembre 2018 - 04:14  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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.

GFA Basic
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.

GFA Basic
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).

GFA Basic
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.

GFA Basic
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.

GFA Basic
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.

GFA Basic
GFA Basic
Programme 6


[Retour en haut] / [Retour aux articles]