Requête: pour un débugage plus efficace du code javascript

[tilleul]

Bonjour

j'ai remarqué que lorsqu'on joue avec du code JS sur un équipement générique (le code JS étant considéré comme une "commande"), au moment de sauver celui-ci, la LD vérifie le code javascript. Je suis vraiment peiné de voir comment cette vérification a été implémentée.

1) la vérification syntaxique se fait par EXECUTION du script (de la commande). Cela signifie que sur une installation "vivante", vous allez exécuter une commande qui pourrait avoir une incidence sur le bâtiment où est installée la LD. Je trouve que c'est au mieux désagréable, au pire dangereux.

2) l'utilisation de paramètres (en utilisant les accolades {}) rend cette fausse vérification mais vraie exécution encore plus dangereuse. Normalement ces paramètres ne sont pas faits pour être "vides". Or à la sauvegarde, la commande sera exécutée avec "rien" en lieu et place des paramètres et donc on a un comportement erratique de la commande, voire même des erreurs parce que justement ces paramètres sont vides et que le code ne s'y attend pas.

3) les messages d'erreur renvoyés sont plus que obscurs. Serait-il possible d'avoir des messages plus explicites ? Et le numéro de la ligne sur laquelle l'erreur s'est produite ? Je me demande même d'où sortent ces messages ? Quel moteur JS utilisez-vous pour que les messages soient aussi tordus ?

4) en tout état de cause, comme la vérification se fait par exécution du script, il suffit d'un bloc "IF" dont la condition est fausse au moment de la sauvegarde pour que tout le bloc "IF" soit ignoré par la reconnaissance syntaxique. On peut donc avoir une erreur bien plus tard lors du véritable lancement de commandes liés à l'équipement. On est donc face à une vérification syntaxique incomplète. Et lorsqu'il s'agit de trouver pourquoi du code JS dans le bloc IF ne s'est pas exécuté correctement on est bien démunis: pas de debug dans le journal d'événements, pas "d'alerte" comme pour un automate qui a échoué, pas de message d'erreur.

5) quand la vérification syntaxique indique une erreur, le code dont la sauvegarde vient d'échouer est perdu. Après 5 ou 6 fois (oui, je suis lent), j'en ai eu marre de tout recommencer et depuis j'utilise un éditeur de texte classique (Notepad++ sur PC ou Sublime Text sur Mac) pour écrire mon code. Donc je fonctionne par copier/coller: j'écris mon code dans Notepad++, je le copie, je vais dans le CS, dans le bon objet, la bonne commande et je colle mon code. Puis je sauvegarde. Et si ca plante, je dois retourner dans Notepad++, essayer de découvrir où est le problème, corriger ce que j'espère être le problème, copier mon code dans le presse-papiers, repasser sur le CS, retourner dans le bon objet, la bonne commande, sélectionner tout le code, l'effacer et coller le code que j'ai dans le presse-papiers. Puis je sauvegarde. En espérant que ce soit bon. Je crois que je n'ai jamais utilisé rien d'aussi peu pratique comme environnement de développement. Et pourtant je viens de loin: j'ai commencé avec un Apple II en 1985. Je crois que seuls ceux qui ont fait des programmes sur cartes perforées ont eu plus indigeste que l'environnement JS proposé par LD.

Quand du code JS plante, pour découvrir où est le souci, bien souvent je me retrouve à retirer tout le code en ne laissant que les lignes simples qui sont censées fonctionner et à replacer morceau par morceau le reste du code jusqu'à ce que ca ne marche plus. Ben oui, parce qu'en plus quand du code JS plante, tous les "états" (les fameuses VARiables string, double et List) restent inchangés. Car ceux-ci ne sont "validés" (et disponibles pour les autres parties de la LD) que lorsque le code a fini de s'exécuter SANS ERREUR.

Donc, je ne peux même pas faire quelque chose du genre:

Code PHP :

nEtape = 0;  // nEtape est une VARiable, un retour d'état de mon objet universel

//(1er bloc de code douteux)

nEtape = 1; // si j'arrive ici je sais que le 1er bloc douteux n'est pas problématique

//(2e bloc de code douteux)

nEtape = 2; // idem pour le 2e bloc

etc... 


Bref, pourrait-on prendre un tout petit peu de temps pour envisager de faciliter la vie des développeurs SVP ?

Rien que d'avoir une fenêtre de code plus sympa serait déjà un plus:
- une fenêtre élargie quand on lui donne le focus: on ne voit que 6 lignes actuellement ! 6 lignes ! :eek: On n'est pas sur une machine à écrire électronique Olivetti de 1983 hein ! On est sur des écrans 19 pouces voire plus !
- l'utilisation d'une police "fixed width" comme Courier New, et pas en taille 6, pitié pour nos yeux...
- la possibilité d'utiliser TAB pour faire des tabulations de 4 caractères (pas 16 comme c'est actuellement le cas) (pour info: on peut même PAS utiliser TAB pour le moment car ca nous passe le focus sur le contrôle suivant ! la tabulation n'est disponible que parce que on fait du copier/coller d'un éditeur de texte)

C'est 3 points sont un minimum je crois:le 2e me semble faisable en quelques minutes, le 3e sûrement aussi et le 1er vous pouvez l'ajouter par charité, c'est bientôt Noël, les gars ! :)

Pour le debug, le minimum c'est un message dans le journal d'événements avec le nom de la commande exécutée, un message d'erreur un tout petit peu plus explicite et la ligne où ca a planté. La vérification syntaxique à la sauvegarde peut être virée pour moi car elle est dangereuse et de toutes façons incomplète.

J'utilise énormément le JS car c'est le seul véritable langage disponible sur LD et que les automates et leur look ballon/organigramme c'est gentil, c'est sympa et je comprends l'intérêt de faire quelque chose de simple pour l'utilisateur lambda mais ça a rapidement ses limites, notamment en terme de vitesse de développement et de fonctionnalités: pas de copier/coller, pas de fonctions à passage de paramètres, pas de tableaux, pas de code réutilisable, etc. Il faut quand même se rendre compte que rien que pour faire l'équivalent de cette simple commande:

Code PHP :

maVariable++; 


Je dois:
- créer un item VAR: glisser depuis la boule START (clic), choisir VAR (clic)
- chercher maVariable dans une liste parfois interminable (molette, molette, molette puis clic)
- éditer la fonction f(x)
- tirer un item "+" depuis le START (clic)
- tirer un item "Opérande" depuis le "+" (clic)
- chercher (à nouveau) maVariable dans une liste (à nouveau) interminable (re-molette, molette, molette puis clic)
- tirer un item "Val" depuis le "+" (clic)
- écrire "1" dans cet item (clic dans le textbox, puis écrire)
- cliquer sur enregistrer pour sortir de ma fonction (clic)

En gros, je défie quiconque de faire ca en moins de 30 secondes :p et, pire, je défie quiconque de trouver ca "pratique" quand il faut le faire 10 fois d'affilée.

Globalement en JS ca va plus vite et on peut faire des choses bien plus complexes mais le grand frein c'est le debug: tout le temps qu'on aurait pu gagner est perdu à dénicher la ligne de code qui finit par ":" au lieu de ";" ...

Bref, M'sieurs-dames (?) de l'équipe LD, ayez pitié des pauvres bougres qui osent pousser les limites de la LD dans ses derniers retranchements parce qu'ils ont l'audace de croire en LD... c'est bientôt Noël quoi ? A vot' bon coeur ! :o

[Domo]

+10.000

Merci Tilleul, je n'aurais pas pris le temps de détailler à ce point :)

Christophe

[Domo-TIC]

Bonjour, +X,

même sentiment, la mise en place est beaucoup trop chronophage, et les instabilités + mise à jour peu fiables n'arrangent pas. Je sature sur les déconnexions intempestives.
Je dois mettre en place une matrice Audio 6*6, j'ose même pas commencer car incapable d'estimer le temps que ca va me prendre. Pour ma part, je connais un certains nombre de langages et outils de dev, mais je dois avouer que sur la LD, j'ai abandonné l'idée de passer par du javascipt en l'état. Pas de correction syntaxique ni du pas à pas, bref, rien pour débugger. Un grand retour en arrière. C'est dommage parce que si cette partie était au meme niveau que ce que peut faire la box dans certains domaines, on aurait de quoi s'amuser !
Arnaud