 |
Programmez un Tetris en Java 360 pages PDF pour apprendre à votre rythme. Développez des jeux vidéo en Java. www.jdevmaker.com |
Ce document est sous un contrat Creative Commons.
Si quelqu'un vous dit un jour "Moi ! J'écris des programmes qui ne sont jamais bogués !!", ne le croyez surtout pas.
Les bogues (bug en anglais) sont des erreurs, le programme n'étant alors plus en mesure d'assurer sa fonction. On peut distinguer des niveaux : mineur, majeur, etc... suivant la "gravité". Par extension, on peut parler de bogue pour des oublis, des incorrections, des imperfections, etc... de programmation. Le débogage consiste donc à supprimer les bogues.
Un script dans Gimp est bien plus simple qu'une application, ainsi les bogues le sont aussi.
Loin d'être révélateur d'une quelconque stupidité, les bogues font partis du parcours d'un programme. Ils obligent à repenser, creuser et améliorer. Le bogue est indubitablement un élément évolutif en terme d'amélioration.
L'expérience, dans l'action de déboguer tient un rôle prépondérant, et au plus vous développerez de script, au plus cela sera facile. Non seulement parce que vous commettrez moins d'erreurs à la base, mais aussi parce qu'elles vous apparaîtront plus clairement.
Je ne peux que vous faire profiter de ma modeste expérience, et encore une fois ne peut prétendre faire le tour du sujet. Aussi me bornerais-je a vous donner seulement quelques conseils.
Il est des situations bien différentes dans lesquelles on peut être amené a déboguer.
Si c'est votre propre script que vous écrivez, le meilleur conseil est sans doute de le faire petit à petit, en vérifiant très régulièrement le résultat. Ainsi, lorsqu'une erreur apparaît, vous savez tout de suite d'où elle vient.
Si vous l'avez déjà écrit ou que c'est celui de votre petit frère ou encore un script trouvé sur le net, ce conseil ne vaut rien. Et il faudra chercher. Divers trucs ou "techniques" peuvent vous y aider.
Comprendre l'origine du problème.
Dans un script de Gimp, il ne peut guère y avoir que deux cas de figure, et encore le dernier résultant des deux autres.
1. Si une erreur survient c'est qu'il y a quelque chose que l'interpréteur Scheme ne comprends pas. C'est donc ou une erreur syntaxique ou grammaticale.
Il faut chercher ces erreurs dans le programme lui même, dans le code. La console d'erreur vous donne souvent des indications, assez imprécises toutefois (nous y reviendrons).
2. Si le résultat ne correspond pas à ce que vous attendez, il faut chercher cela dans la conception même de vos tâches, dans leurs agencements, la manière dont elles se succèdent, dont elles s'imbriquent les unes avec les autres. Il suffit généralement de refaire ligne par ligne le parcours du script pour se rendre compte que l'on a oublié une étape ou omis de penser à telle ou telle chose. Le parcours du script doit correspondre en détail avec la manière dont vous vous acquitteriez de cela dans Gimp, sans le script.
Un paramètre juste mais inexact, une couleur déclarée qui n'est pas celle prévue, des coordonnées inexactes, un zéro en plus ou en moins, une virgule mal placée, un ordre des tâches inadéquat... beaucoup de choses peuvent influencer le mauvais résultat du script.
Ce "diagnostique" peut aider a chercher dans telle ou telle direction plutôt que dans une autre. Avec de l'expérience, on sait souvent d'où vient le problème juste a voir comment il s'exprime, même si on ne connaît pas encore exactement sa nature.
L'interpréteur Scheme de Gimp est le SIOD, pas le R5RS. Aussi, soyez certain que le Scheme que vous employez sera compris par le SIOD.
Erreur durant l'exécution de
(load "C:\\Program Files\\GIMP-2.0\\share\\gimp\\2.0\\+ de Scripts\\exemple.scm")
ERROR: end of file inside list
La première partie du message d'erreur vous permet de situer l'erreur. Elle vous indique (bien que parfois cela ne soit pas très explicite) le script qui comporte l'erreur. Ce qui est particulièrement utile si votre script utilise d'autres scripts par exemple. Ou bien encore, il peut écrire la fonction invoqué avec les paramètres éventuels qui l'accompagnent.
Le seconde partie du message d'erreur contient le type d'erreur en elle-même.
Voici une liste non exhaustive, les causes des erreurs sont décrites a titre d'exemples, on ne saurait leur attribuer pour la plupart d'entre eux une seule cause possible :
ERROR: end of file inside list
Une parenthèse(s) de fermeture a été omise, ou un guillemet(s) est en trop ou omis.
ERROR: unexpected close paren
Une parenthèse(s) de fermeture est en trop.
attempted to install a procedure with invalid UTF-8 strings.
Un caractère invalide dans le script tel é,è, ç, ù, à, etc...
ERROR: too few arguments (see errobj)
Un ou plusieurs arguments sont manquants. Dans l'emploi d'un plug-in, d'une procédure, ou il y plus de variables correspondant aux paramètres du script-fu-register que de paramètres.
ERROR: Procedural database execution failed:
Suit à ce message l'écriture de la procédure en question avec ses paramètres. Le plus souvent un paramètre(s) est incorrect.
ERROR: Invalid type for argument
Suit a ce message le numéro de l'argument, puis de la procédure en question. C'est une erreur souvent vicieuse car sa source peut n'avoir aucun rapport avec la ligne en question. Le type d'un argument (une variable) est incorrect.
ERROR: not a number (see errobj)
Cela arrive par exemple quand une variable contient une liste incorrect.
ERROR: bad function (see errobj)
Mauvaise Fonction. Le plus souvent la fonction a été omise ou mal orthographiée.
ERROR: unbound variable (errobj olgolo)
Variable inconnue. Notez le nom de la variable en cause entre parenthèses.
Comme le Scheme est basé sur des fonctions ou des procédures, il cherche a identifier une fonction, et il sait ensuite si il soit trouver une variable, un paramètre... De sorte, en cas d'omission ou de mauvaise syntaxe de l'un ou de l'autre il risque d'être rapidement perdu... cela débouche souvent sur ce type d'erreur.
Si vous utilisez la Console Script-fu, vous pouvez connaître l'objet qui pose problème en tapant :
(print errobj)
Une méthode assez efficace bien qu'imparfaite et même parfois vicieuse, est d'utiliser les ;; en début de ligne afin de supprimer l'action de certaines lignes dans votre script en les transformant en commentaires. On enregistre le fichier, on rafraîchit les script et on teste. Pour les remettre il suffit juste d'effacer les ;; c'est très rapide.
Par cette méthode on peut rapidement voir si la ou le groupe de ligne dont on a suspendu l'action par ce simple moyen est en cause. Si le script s'exécute c'est que l'on a supprimé l'erreur, donc l'erreur est contenue dans la ou les lignes en question. On procède ainsi peu à peu, par élimination. Cela peut amener à comprendre d'où vient l'erreur, mais c'est tatônner, et il faut avoir l'habitude d'utiliser la méthode. Mais c'est en forgeant que l'on devient forgeron.
Méfiez vous tout de même car cela peut rajouter d'autres erreurs. Par exemple, de manière simple, si vous supprimez une ligne où une variable est déclarée, une autre erreur surviendra lorsque cette variable sera utilisée plus loin. Il faut donc analyser un minimum le code, on ne peut pas faire n'importe quoi en espérant trouver l'origine du problème. Soyons patient et procédons lentement par élimination : le fait de savoir que l'erreur ne provient pas de tel ou tel groupe de ligne est déjà un pas vers la victoire. Le bogue force à la réflexion, et bien souvent on ne le voit pas, mais paradoxalement il devient on ne peut plus évident lorsqu'on l'a découvert !!!!
Vous pouvez aussi utiliser la procédure gimp-message afin de faire apparaître des commentaires dans la console. Utilisé conjointement avec la précédente méthode cela s'avère très efficace afin de cerner l'erreur. En effet, par une succession de message dans votre script, il suffit ensuite de constater lesquels apparaissent dans la console, et lesquels n'apparaissent pas. Fort logiquement, l'erreur survient entre le dernier message affiché dans la console, et le premier qui n'est pas affiché !
Il est possible de connaître la valeur de vos variables numériques avec un peu de Scheme.
Enregistrez le script suivant et testez-le :
(define (script-fu-exemple img drw)
(set! n 50)
(gimp-message n)
)
(script-fu-register "script-fu-exemple"
"<Image>/Script-Fu/exemple"
""
""
""
""
""
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0
)
Une erreur survient. C'est que gimp-message ne peut qu'afficher des variables chaînes. Ainsi remplacez,
(set! n 50)
par
(set! n "texte")
Et testez de nouveau. Ici tout va bien. Seules les chaînes peuvent ainsi être affichées, pas les variables de types listes ou numériques.
Heureusement nous pouvons effectuer des conversions, c'est à dire transformer une variable numérique en chaîne. Ce qui nous permettra de les afficher par gimp-message.
Cette conversion se fait par :
number->string [nombre]
Ainsi,
(define (script-fu-exemple img drw)
(set! n 50)
(set! n-converti (number->string n))
(gimp-message n-converti)
)
(script-fu-register "script-fu-exemple"
"<Image>/Script-Fu/exemple"
""
""
""
""
""
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0
)
nous permet d'afficher le contenu de la variable n dans la console.
Vous voudrez aussi sans doute afficher un petit laïus indiquant le nom de la variable. Plutôt que d'écrire cela sur 2 lignes avec 2 procédures comme ci-dessous :
(set! n-converti (number->string n))
(gimp-message "n=")
(gimp-message n-converti)
voici la forme ci-dessous où l'on a "assemblé" 2 chaînes ensemble par la fonction string-append, et qui équivaut à la précédente si ce n'est que cela s'affiche sur une seule ligne :
(set! n-converti (string-append "n=" (number->string n)))
(gimp-message n-converti)
Note : la fonction list->string (conversion d'une list en chaîne) existe, mais en R5RS, pas avec le SIOD.
Vous pouvez plus facilement lister une variable quel que soit son type par la commande print.
=> (set! a '(1 2 3))
(1 2 3)
=> (print a)
(1 2 3)
()
Vous pouvez aussi connaître explicitement l'objet qui a provoqué l'erreur avec la syntaxe suivante : (print errobj)
=> (gimp-edit-clear)
ERROR: too few arguments (see errobj)
=> (print errobj)
((drawable))
()
