Suivez-nous sur Mastodon
|
|
|
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
|
|
|
|
Point de vue : Le développement de Rave (dixième partie)
(Article écrit par Daniel Jedlicka et extrait de Rear Window - avril 2026)
|
|
Un plantage de trop.
Il y a une vieille blague qui dit que la programmation, c'est comme le sexe : une seule erreur, et c'est
la galère pour le restant de ses jours. Il y a du vrai dans cette affirmation - et de l'expérience -
car même les plans les mieux conçus des développeurs peuvent être mis à mal par des problèmes imprévus.
C'est exactement ce qui m'est arrivé avec la mise à jour 1.9 de Rave que j'ai publiée en
février 2026.
La publication en elle-même s'est déroulée sans problème, mais très vite, des signalements ont commencé
à arriver : l'éditeur plantait à l'ouverture de la fenêtre des paramètres. C'était pour le moins curieux,
car je jure que je n'avais pas touché à cette partie du code depuis des mois, voire des années. Le
plus intéressant, c'est que tous les signalements provenaient d'utilisateurs d'AmigaOne X1000. Ces
plantages spécifiques à certaines machines étaient une nouveauté pour moi, et cela a mis en lumière une
triste réalité : même en testant sur trois systèmes AmigaOS 4 différents, comme je le fais, ce n'est pas
toujours suffisant.
Bien sûr, cela n'aurait pas fait un article très intéressant si la cause avait été évidente et que j'avais
corrigé le bogue immédiatement. L'impossibilité de reproduire le plantage sur mes machines n'a certainement
pas arrangé les choses, et les rapports d'erreur qu'on m'envoyait pointaient mystérieusement vers un
composant sans rapport. Heureusement, la partie du code concernée est assez simple, et grâce à l'aide -
et à la patience - du bêta-testeur Niels Bache, j'ai finalement pu identifier la cause du problème :
une routine auxiliaire qui vérifie le chemin d'accès aux fichiers d'annulation de Rave. En résumé :
j'avais utilisé un tampon de texte défini trop localement, ce qui rendait le pointeur de tampon invalide
avant que le gadget bouton n'ait fini de l'utiliser, provoquant ainsi une condition de concurrence assez
gênante.
Cependant, corriger le code en cause ressemblait plus à un palliatif, et je me suis demandé pourquoi
une telle situation s'était produite. Mon code avait peut-être mis le bouton dans une situation critique,
mais pourquoi ne pouvait-il pas s'en sortir ? J'étais de plus en plus convaincu que le véritable problème
résidait dans la classe "button.gadget". Sachant que le problème était dû à une chaîne de caractères
à durée de vie trop courte, j'ai analysé attentivement l'utilisation du pointeur et il est vite apparu
que le gadget était un peu trop désinvolte quant à la gestion du contenu textuel.
Un bon gadget BOOPSI est une entité binaire très méfiante qui ne sous-estime jamais la créativité sans
bornes du programmeur Amiga. De ce fait, la plupart des classes s'assurent de "posséder" tout texte fourni
en en créant une copie interne. Le gadget bouton le faisait - et en même temps, non. En réalité, le
bouton transmettait immédiatement le texte à "bevel.image" (qui gère l'affichage du texte et du cadre),
et une copie y était créée. Je suppose que c'était le comportement prévu à l'origine, et je suis sûr que
c'était bien intentionné et que cela fonctionnait, car le pointeur de chaîne n'était plus référencé après
son passage à "bevel".
Malheureusement, au fil des années et des ajouts de fonctionnalités par divers contributeurs, la vision
d'ensemble s'est peu à peu perdue, et le pointeur de chaîne d'origine s'est retrouvé référencé à plusieurs
endroits. Cela a créé une vulnérabilité, et Rave en a été la victime involontaire. Heureusement, pas pour
longtemps !
Corriger un bogue est toujours gratifiant, mais cette fois-ci, ma joie était quelque peu tempérée par
la pensée que les utilisateurs de Rave - ceux qui avaient découvert et signalé le bogue -
devraient se contenter de ma solution de contournement jusqu'à la publication du bouton corrigé. Alors,
en guise de remerciement, j'ai décidé de faire de Rave 1.10 bien plus qu'une simple mise à jour corrective.
J'ai passé en revue ma longue liste de tâches, espérant trouver une fonctionnalité qui réponde aux trois
critères essentiels : "réalisable", "satisfaisante pour les utilisateurs" et "utile pour moi-même".
Après réflexion, j'en suis arrivé à la conclusion qu'il était grand temps d'intégrer une règle temporelle
à l'affichage de la forme d'onde dans Rave - un outil permettant au moins de se repérer dans l'échantillon.
J'avais déjà tenté d'implémenter cette fonctionnalité par le passé, mais j'avais toujours fini par l'abandonner
face aux problèmes de zoom, d'échelle et autres complications liées au dessin simultané d'éléments dépendant
du temps et des pixels. Le fait que de nombreux éditeurs audio Amiga s'en passent montre bien que sa mise
en oeuvre est loin d'être simple.
Cette fois-ci, cependant, je l'ai abordée avec un esprit plus ouvert et sans idées préconçues, et j'ai
réussi à trouver une solution fonctionnelle en un seul week-end (certes chargé). L'implémentation actuelle
est volontairement simple : elle indique simplement le temps ou la position de l'échantillon. Mais la
règle remplit sa fonction et, plus important encore, elle ouvre la voie à l'ajout de fonctionnalités
plus utiles à l'avenir.
Affichage de la forme d'onde avec la règle de la ligne de temps
C'est tout pour le moment. Rave 1.10
arrive juste à temps pour le week-end de Pâques, avec quelques
correctifs importants et une petite nouveauté bien pratique. J'espère maintenir le rythme et publier
d'autres mises à jour plus tard cette année, idéalement sans mauvaises surprises. En attendant,
passez de bonnes fêtes et bon bidouillage audio !
|
