Script Debugger

Avec enthousiasme, le 26 février 2022 Í  13:44, BenoÍ®t L. écrivit :

Bonjour,

Juste pour dire que je suis passé Í  Script Debugger et c'est vraiment un
cran au-dessus. Surtout, comme son nom l'indique, pour débuguer un script.

La 1.0.7 est en phase de test final.

Normalement tout roule. Tout du moins tant que vous ne l'avez pas entre
les mains. :)

Reste Í  faire un read-me.

Reste bien plus Í  faire puisqu'après quelques «Â corrections »,
maintenant je n'arrive plus Í  écrire dans mes fichiers :

open for access file signatureFile
set eof of file signatureFile to 0

=> Fichier non ouvert avec autorisation en écriture.

Je ne comprends plus rien. Quand le fichier existait et n'avait donc pas
besoin d'être créer tout allait bien. Je refais un test en partant de 0
et je n'ai plus accès aux fichiers nouvellement créés.

Si quelqu'un sait me dire o͹ mon code est parti en vrille, je l'en
remercie, mon email est valide.

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

•••••••••••••••••••••••••••••••••••••••••••
Le dimanche 27 février 2022 12:07:52, dans le message
Message-ID <news:svfpio$e2l$1@shakotay.alphanet.ch>,
"BenoÍ®t L." <benoit@leraillez.com.invalid> écrivait :
•••••••••••••••••••••••••••••••••••••••••••

Je ne comprends plus rien. Quand le fichier existait et n'avait donc pas
besoin d'être créer tout allait bien. Je refais un test en partant de 0
et je n'ai plus accès aux fichiers nouvellement créés.

Ma réponse ne va pas t'apporter la clé de ton énigme actuelle, parce que
je n'ai pas tes derniers développements.
Mais je voudrais te dire que quand on développe un projet un tant soit
peu complexe, la méthode est de toujours garder dans un dossier
d'archive les 3 ou 4 dernières versions qui marchaient, et
"verrouillées" : de cette façon lorsqu'on remanie le code dans la
version en développement, si on crée un bug apparemment insoluble, l'on
a un code qui fonctionnait Í  comparer.

Une piste néanmoins : Ton histoire me fait penser Í  un pb de
permissions.
Aurais-tu par hasard changé de Mac, ou de session pour cette version de
travail par rapport aux précédentes ?
En effet quand on travaille sur les Libraries, y compris celle du User,
depuis quelques versions l'OS est très vigilant aux droits de
créateur/propriétaire du fichier. Le fait de récréer un fichier de prefs
lui a réinitialisé les permissions qu'Applescript, qui peut en avoir
gardé traces des anciennes, ne reconnait plus.
Quitter Applescript, Redémarrer le Mac, bien sÍ»r toujours travailler
dans la même session lors du développement, et relancer le script.



--
Si maintenant on introduit le concept de normalité des bugs, o͹ va
l'informatique ?
Chez Microsoft ? Ah oui, pas faux ça.
-+- GG in Guide du Macounet Pervers : R i F, you'll be Buggified -+-

Ni vu ni connu, le 27 février 2022 Í  14:51, Joseph-B osa écrire :

•••••••••••••••••••••••••••••••••••••••••••
Le dimanche 27 février 2022 12:07:52, dans le message
Message-ID <news:svfpio$e2l$1@shakotay.alphanet.ch>,
"BenoÍ®t L." <benoit@leraillez.com.invalid> écrivait :
•••••••••••••••••••••••••••••••••••••••••••

Je ne comprends plus rien. Quand le fichier existait et n'avait donc pas
besoin d'être créer tout allait bien. Je refais un test en partant de 0
et je n'ai plus accès aux fichiers nouvellement créés.

Ma réponse ne va pas t'apporter la clé de ton énigme actuelle, parce que
je n'ai pas tes derniers développements.
Mais je voudrais te dire que quand on développe un projet un tant soit
peu complexe, la méthode est de toujours garder dans un dossier
d'archive les 3 ou 4 dernières versions qui marchaient, et
"verrouillées" : de cette façon lorsqu'on remanie le code dans la
version en développement, si on crée un bug apparemment insoluble, l'on
a un code qui fonctionnait Í  comparer.

J’ai Time Machine pour ça, mais ! je suis parti en vacances Í  Paris. Je
n’ai pas de disque avec moi et les TM locaux sont inutiles (hier ou
aujourd’hui).

Une piste néanmoins : Ton histoire me fait penser Í  un pb de
permissions.
Aurais-tu par hasard changé de Mac, ou de session pour cette version de
travail par rapport aux précédentes ?
En effet quand on travaille sur les Libraries, y compris celle du User,
depuis quelques versions l'OS est très vigilant aux droits de
créateur/propriétaire du fichier. Le fait de récréer un fichier de prefs
lui a réinitialisé les permissions qu'Applescript, qui peut en avoir
gardé traces des anciennes, ne reconnait plus.
Quitter Applescript, Redémarrer le Mac, bien sÍ»r toujours travailler
dans la même session lors du développement, et relancer le script.

Merci, je teste. Et ça marche car Script Debugger m’a demandé des droits
d’accès cette fois-ci.

Par contre Í  vouloir corriger, le code est parti en vrac. Je me rends
compte qu’il y a des routines qui ne sont pas utilisées Í  certains
endroits, mais effectuées «Â en direct ». Donc deux endroits, donc deux
corrections Í  effectuer donc le bordel*.

Je reprends tout Í  0 en reprenant les routines les unes parès les
autres. Bref je recommence tout, mais avec un plan et j’ajoute les
routines étape par étape.


* Un exemple :
L’ajout d’un bouton Importer m’a permis de créer une routine
importFile(). Ok, mais s’il n’y a pas de fichier dans les préférences je
ne passe pas par importFile(), je fais tout ça «Â Í  la main ».

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

Le 27 février 2022 Í  18:01, BenoÍ®t L. d'un élan de joie s'exprima
ainsi :

Je reprends tout Í  0 en reprenant les routines les unes après les
autres. Bref je recommence tout, mais avec un plan et j’ajoute les
routines étape par étape.

À force de rajouter des bricoles Í  droite et Í  gauche, on finit par
poser des emplÍ¢tres sur une jambe de bois. Et ça ne marche pas ! On n’a
pas une, mais deux jambes de bois. :/

1.0.7 out, 1.0.8 avec une page blanche.

Puisque je vise le développement d’une appli*, ne serait-il pas
intéressant, Í  terme, de faire un script par routine ?

Je pose la question parce que dans ce cas on a un script principal
«Â léger » facile Í  lire et pas des «Â tonnes » de lignes au milieu
desquelles on se promène Í  la recherche de l’erreur. (Même si le «Â step
by step », les «Â breakpoints » et l’affichage en temps réel de la valeur
des variables sont de vraies aides.)




* Je dis ça parce que dans ce cas je devrais savoir o͹ se trouvent les
scripts complémentaires, pour les ouvrir, via un «Â container to (path to
me) ». Après, reste Í  savoir les fermer. Pour la 1.X avec X≠0

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

"Benoͮt L." <benoit@leraillez.com.invalid> wrote:

Puisque je vise le développement d'une appli*, ne serait-il pas
intéressant, Í  terme, de faire un script par routine ?

Je pose la question parce que dans ce cas on a un script principal
« léger » facile Í  lire et pas des « tonnes » de lignes au milieu
desquelles on se promène Í  la recherche de l'erreur.

L'idée que tu émets de structurer une "appli" en différents scripts qui
seront appelés en cas de besoin par le handler principal s'applique déjÍ 
et en premier au handler maͮtre.

Quand tu as une succession de lignes de commandes, effectuant une action
ou retournant une valeur, susceptible de constituer une routine Í  part
entière, crée-la en lui donnant un nom et des paramètres, ce qui permet
ensuite de l'appeler depuis n'importe o͹, et autant de fois que
nécessaire, depuis le handler maÍ®tre.
D'ailleurs, de la même manière cette routine pourra appeler une ou
plusieurs sous-routines construites sur le même principe. (toutefois,
attention de ne pas trop saucissonner les routines, pour ne pas les
rendre incompréhensibles Í  leur tour).

En quelque sorte le script contient le handler maͮtre ET sa propre
bibliothèque de routines et sous-routines au même niveau, ce qui les
rend très facilement accessibles (Í  déboguer) et allègera la lisibilité
du handler maͮtre, qui apparaͮtra en quelque sorte l'architecte de
l'application au lieu de le noyer dans l'exécution de tÍ¢ches
"subalternes".

Au niveau de la modestie (sans offense de ma part) en terme de volume de
lignes de code du projet auquel tu t'attaques, nul besoin d'enregistrer
une sous-routine dans un script indépendant qu'il faudra aller
positionner dans un dossier "Libraries" du dossier "Resources" de
l'application.*

Par commodité de lecture, en général on sépare le handler maÍ®tre des
sous-routines positionnées en dessous par une barre de commentaire.
Mais c'est purement conventionnel et selon l'idée que l'on se fait du
pratique de la chose.

Le recours Í  des "script-objects" (dans le jargon) mis Í  disposition
dans le /Libraries des /Resources du bundle ne se justifie que s'ils
sont eux-mêmes de très grosses entités et définitivement stabilisés.
L'exemple en est justement les Dialog Tool kit Plus, si tu vas regarder
comment cette application (ou scptd, je ne me rappelle plus) est
organisé.


*Néanmoins, si tu y tiens essentiellement, une explication de la méthode
ici.
<https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/UseScriptLibraries.html>

ou cette série d'articles, qui bien qu'Í  but de vulgarisation, me paraÍ®t
plus "confusionnante"
<https://macosxautomation.com/mavericks/libraries/index.html>
et une mise en exemple
<https://macosxautomation.com/mavericks/libraries/simple.html>

--
J. B.

Après mÍ»re réflexion, le 28 février 2022 Í  12:25, Joseph-B eu l'idée
d'écrire :

"Benoͮt L." <benoit@leraillez.com.invalid> wrote:

Puisque je vise le développement d'une appli*, ne serait-il pas
intéressant, Í  terme, de faire un script par routine ?

Je pose la question parce que dans ce cas on a un script principal
« léger » facile Í  lire et pas des « tonnes » de lignes au milieu
desquelles on se promène Í  la recherche de l'erreur.

L'idée que tu émets de structurer une "appli" en différents scripts qui
seront appelés en cas de besoin par le handler principal s'applique déjÍ 
et en premier au handler maͮtre.

Quand tu as une succession de lignes de commandes, effectuant une action
ou retournant une valeur, susceptible de constituer une routine Í  part
entière, crée-la en lui donnant un nom et des paramètres, ce qui permet
ensuite de l'appeler depuis n'importe o͹, et autant de fois que
nécessaire, depuis le handler maÍ®tre.

C’est exactement pourquoi je l’ai fait. Cela permet aussi de vraiment
séparer le code en éléments auxquels on ne touche plus une fois
«Â validés ».

D'ailleurs, de la même manière cette routine pourra appeler une ou
plusieurs sous-routines construites sur le même principe. (toutefois,
attention de ne pas trop saucissonner les routines, pour ne pas les
rendre incompréhensibles Í  leur tour).

Je suis déjÍ  tombé dedans, mais juste un étage au-dessus du rdc.

Au niveau de la modestie (sans offense de ma part) en terme de volume de
lignes de code du projet auquel tu t'attaques, nul besoin d'enregistrer
une sous-routine dans un script indépendant qu'il faudra aller
positionner dans un dossier "Libraries" du dossier "Resources" de
l'application.*

Je l’avais deviné en créant un :
tell application "Finder" to set pathToMe to (container of (path to me))
as text
Mais je ne l’utilise pas pour le moment.

Par commodité de lecture, en général on sépare le handler maÍ®tre des
sous-routines positionnées en dessous par une barre de commentaire.
Mais c'est purement conventionnel et selon l'idée que l'on se fait du
pratique de la chose.
[…]
*Néanmoins, si tu y tiens essentiellement, une explication de la méthode
ici.
<https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/UseScriptLibraries.html>

ou cette série d'articles, qui bien qu'Í  but de vulgarisation, me paraÍ®t
plus "confusionnante"
<https://macosxautomation.com/mavericks/libraries/index.html>
et une mise en exemple
<https://macosxautomation.com/mavericks/libraries/simple.html>

Je garde ça pour plus tard. Merci,


En attendant, voici la 1.0.8 avec laquelle je ne trouve pas de problèmes
(étonnant, non ?)
<https://www.cjoint.com/data/LBCr6YfpxAt_SignAuPif-1.0.8.zip>
L’appli et le script pour ceux qui ne veulent pas chercher dans l’appli.
(mon premier avec Script Debugger qui, comme son nom l’indique, est le
rêve pour qui veut débugué)

Nouveautés :
— On peut remplacer le fichier de signature quand on le souhaite ;
— Le tirage au sort ne permet plus de revoir une signature tant que
toutes les autres n’ont pas été présentées ;
— Des raccourcis clavier. Mais le bouton «Â Copier » n’a pas de raccourci
affiché. La raison est que si on clique sur le bouton on copie le texte
d’origine et cela ne tient pas compte de modification ou de sélection de
texte, alors que le cmd-c est préempté par le système et copie
uniquement la sélection. (Mes tentatives de system event et keystrokes
ont, pour l’instant, échouées.)


P.S. Je n’arrive pas Í  avoir de problème quoi que je fasse. Cela étant,
je suis sÍ»r que tu sauras en dénicher. :)

Prochaine étape (je l’espère) pouvoir saisir des signatures, les
modifier… Et rédiger un read me.

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

Le 28 février 2022 Í  19 h 10, BenoÍ®t L. a tenu les propos suivants :

En attendant, voici la 1.0.8 avec laquelle je ne trouve pas de problèmes
(étonnant, non ?)

Étonnant en effet : lancement de l'applet :
<https://www.dropbox.com/s/5zfvogrutoxpoyb/Ecran%2020.png?dl=0>

Lancement du script : message d'erreur "theChechbox n'est pas défini"
ou quelque que chose du genre.

Je vire mon dossier SignauPif au cas o͹.
Ça marche !

Je tente l'import d'un fichier de signatures : en fait d'import, c'est
un simple remplacement de l'ancien fichier par le nouveau fichier… Je
regarde le contenu du script et plus particulièrement de «Â on
importfile() »Â : tout ça pour ça ? ;-)

Je teste la case "Ajouter le délimiteur de signature" (*) cochée ou pas :
aucune différence… La signature copiée n'a pas de délimiteur.

Je demande une nouvelle signature : la case que j'avais décochée est
maintenant cochée.

Je demande Í  copier la signature : la case que j'avais décochée est
maintenant cochée.

Je décoche la case et je quitte : Í  la relance, la case est bien
décochée mais ensuite j'obtiens l'inverse de ci-dessus… J'ai beau
cocher la case, elle revient décochée après soit une nouvelle signature
soit le bouton copier.

Je ne vois guère de changement dans le comportement de ton script par
rapport Í  la semaine dernière.

Cela étant, je suis sÍ»r que tu sauras en dénicher.

Oups… pardon… Tu ne t'adressais qu'Í  Joseph-B ! ;-)

* Il y a une erreur d'ailleurs : un délimiteur de signature n'est pas
"tiret, tiret, espace"
--
- Papa ! Papa ! PAAAAAAAAApppppppaaaaaaaaa !
- Oui Ben qu'est-ce-qu'il y a ?
- Y'a quelqu'un qui a touché Í  mon kernel !
+BL in Guide du Macounet Pervers : MOSXS est un long fleuve tranquille+

Avec enthousiasme, le 28 février 2022 Í  20:01, M.V. écrivit :

Le 28 février 2022 Í  19 h 10, BenoÍ®t L. a tenu les propos suivants :

En attendant, voici la 1.0.8 avec laquelle je ne trouve pas de problèmes
(étonnant, non ?)

Étonnant en effet : lancement de l'applet :
<https://www.dropbox.com/s/5zfvogrutoxpoyb/Ecran%2020.png?dl=0>

Lancement du script : message d'erreur "theChechbox n'est pas défini"
ou quelque que chose du genre.

Je vire mon dossier SignauPif au cas o͹.
Ça marche !

????

Le tien avait un pb quelque part. Je n’ai jamais eu ça qu’il soit vide
ou non.

Je tente l'import d'un fichier de signatures : en fait d'import, c'est
un simple remplacement de l'ancien fichier par le nouveau fichier… Je
regarde le contenu du script et plus particulièrement de «Â on
importfile() »Â : tout ça pour ça ? ;-)

Import() si pas de fichier, si fichier existant mais vide, si
l’utilisateur le souhaite. Trois fois la même action et on ne va pas en
faire une routine ?

Je teste la case "Ajouter le délimiteur de signature" (*) cochée ou pas :
aucune différence… La signature copiée n'a pas de délimiteur.

Grrrrrr !

Je demande une nouvelle signature : la case que j'avais décochée est
maintenant cochée.

Je demande Í  copier la signature : la case que j'avais décochée est
maintenant cochée.

Bon, merci.

Je décoche la case et je quitte : Í  la relance, la case est bien
décochée mais ensuite j'obtiens l'inverse de ci-dessus… J'ai beau
cocher la case, elle revient décochée après soit une nouvelle signature
soit le bouton copier.

VoilÍ  ce que c’est que tout reprendre Í  0 : on oublie une marche et on
se casse la gueule dans l’escalier. La rambarde n’est pas au bon endroit.

Je ne vois guère de changement dans le comportement de ton script par
rapport Í  la semaine dernière.

Un truc Í  revoir : la gestion du bidule Í  mettre au début de la
signature. Je m’y attelle. (est pris qui croyais prendre)

Cela étant, je suis sÍ»r que tu sauras en dénicher.

Oups… pardon… Tu ne t'adressais qu'Í  Joseph-B ! ;-)

Le piège t’était tendu :)

* Il y a une erreur d'ailleurs : un délimiteur de signature n'est pas
"tiret, tiret, espace"

Non, c’est une ligne avec «Â tiret tiret espace ». Faut savoir lire. ;)

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

Après mÍ»re réflexion, le 28 février 2022 Í  20:01, M.V. eu l'idée
d'écrire :

Je teste la case "Ajouter le délimiteur de signature" (*) cochée ou pas :
aucune différence… La signature copiée n'a pas de délimiteur.

Je demande une nouvelle signature : la case que j'avais décochée est
maintenant cochée.

Je demande Í  copier la signature : la case que j'avais décochée est
maintenant cochée.

J’espère que cette fois-ci je peux passer Í  l’étape suivante. Deux
lignes oubliées lors de la réécriture et effet pas vu lors de mes tests.
https://www.cjoint.com/data/LBCu6XgCEht_SignAuPif-1.0.9.zip

Bonne nuit et merci Í  ceux qui trouveront encore une _erde. :(

--
C'est pas parce qu'on a rien Í  dire qu'il faut fermer sa gueule.
-+- Audiard dans «Â La Grande Luciole avec une chaussure noire » -+-

Le 28 février 2022 Í  21:00, BenoÍ®t L. a tenu les propos suivants :

Import() si pas de fichier, si fichier existant mais vide, si
l’utilisateur le souhaite. Trois fois la même action et on ne va pas en
faire une routine ?

Tu ne comprends pas ce que je dis…
Le problème n'est pas de savoir s'il y a besoin de faire une routine ou
pas : ta routine comporte je ne sais plus combien de lignes (j'ai tout
mis Í  la poubelle) mais remplacer le contenu d'un fichier par le contenu
d'un autre fichier, ça ne prend pas autant de lignes de code.
Puisque tu as juste choisi de remplacer en réalité un fichier par un
autre : supprimer le fichier existant (ou simplement changer son nom) et
copier le nouveau fichier en lui donnant le bon nom dans le bon dossier
Í  l'aide de commandes shell, ça prendra juste quelques lignes.
Une routine oui mais pas une routine loufoque ! ;-)