OK
AJAX error!

Les forumsGrammalecteAdaptation pour NodeJS

Adaptation pour NodeJS

J'ai fait vite fais une adaptation pour node : www.poeme-france.com… (dico non inclut) (basé sur le check-in: f3f1cc9e30)
Ca permet de pouvoir tester plus rapidement des modifications dans le code javascript sans devoir reconstruite toute la web-extension et faire les tests avec une cli.

Note :
1- J'ai ajusté les paramètres pour la vérification de la syntaxe pour l'éditeur (maintenant aussi bien jshint ou jslint sont reconnu)
2- J'ai inclut directement le contenu des fichiers qui sont inclut par le builder
3- Ajout de test pour savoir si on est sur node si c'est le cas les changement nécessaire sont fait.
4- Correction de quelques ; manquant
5- Création d'un répertoire "test" qui contient un fichier "performance.js" qui permet juste d’instancier graphspell et de verifier des mots (il est là pour servir d'exemple) donc dans le répertoire faire un "node performance.js" permet de tester.

=> j'ai pas tester de "compiler" le web-extension avec l'adaptation pour node mais a part le point 2 (qu'il faut rétablir comme avant) ça ne devrais pas poser de problème.

=> je pense qu'il ne devrais pas y avoir de problème pour appliquer ses changements sur le source actuel (sauf le 2- à rétablir)

=> si cette méthode d'adaptation du code pour node te conviens, je peux essayer de faire de même pour tout le reste de dicollecte.
le 09 octobre 2018 à 20:32
Je me suis permis de créer une branche pour supporter nodejs.

Tout fonctionne correctement sur nodejs, j'ai également tester les modifications sous Firefox et ça fonctionne toujours ;)
Par contre j'ai pas tester s'il y avait un impact sous Thunderbird vu que je ne l'utilise pas du tout...
le 10 octobre 2018 à 14:48
Désolé pour le délai de réponse. Ce n’est pas parce que je ne commite pas que je ne fais rien. Je suis en train de refaire le site web, et je prépare un serveur de dictionnaires. Ça va me prendre du temps.

En ce qui concerne NodeJS, je suis dubitatif. NodeJS ne fait pas partie des logiciels que je souhaite particulièrement supporter, alors ça m’ennuie de voir qu’il faille créer une syntaxe particulière d’importation et de lecture de fichiers. Surtout que ces if-else encore nécessaires pour Thunderbird seront bientôt de l’histoire ancienne. D’ici quelques mois, je compte passer l’extension Thunderbird en WebExtension autant que possible, et la syntaxe serait donc enfin unifiée (ce qui ne serait pas du luxe). Donc, voir ajoutée une nouvelle pile d’exceptions syntaxiques ne me réjouit pas du tout.

J’attends impatiemment que Mozilla intègre la syntaxe import/export (que NodeJS comprend, si j’ai bonne mémoire), afin que tout le code JS ressemble enfin à quelque chose de potable, au lieu d’avoir tous ces hacks dégueulasses.

Cela dit, je ne suis pas imperméable à l’idée que vous entreteniez une branche pour NodeJS, mais là ça va poser problème, attendu que vous faites des corrections syntaxiques sans raison particulière.

Pourquoi transformer les doubles quotes en simples ?
Pourquoi supprimer les parenthèses de typeof (c’est plus sécurisé ainsi, si j’ai bonne mémoire) ?

Pour les points-virgules manquantes et les erreurs de code, c’est bon (merci pour ça), mais il faudrait le faire dans des commits à part que je puisse intégrer. (Évitez aussi de supprimer mes commentaires.)

Si vous voulez entretenir une branche pour NodeJS, il faut se contenter d’y mettre uniquement ce qui est nécessaire à NodeJS et fusionner trunk dans cette branche quand c’est nécessaire.
le 11 octobre 2018 à 09:26
Ah oui, j’oubliais… Supprimer l’intégration du code suppléant aux objets natifs de JS ne peut, a priori, pas fonctionner. Je ne me souviens plus très bien quelle est la nécessité exacte de les coller un peu partout, mais c’est dû au fait que ça ne fonctionne pas de la même manière sur Firefox et Thunderbird.

Ajout : Finalement, si, en fait, ça fonctionne quand même à cause de la permissivité dans le remplacement du moteur de templates de Python.
le 11 octobre 2018 à 09:29
Il n'y a pas de soucis pour le délais. J'avais vu qu'il y avait eut des demande sur le forum pour NodeJS et vu que pour tester c'est plus facile de lancé une petit cli, je me suis dit autant le faire vu le peut de modification que ça demande.

Pour les quelque modification de quotte j'avais voulu les unifier vu que dans le code les simples et les doubles sont utilisées sans raison particulière. Donc aux endroits où je faisais les modifications je n'ai utilisé que des simples, je ne sais pas si c'est aussi le cas en javascript mais en PHP les simple sont plus rapide que les doubles donc en générale j'utilise au maximum les simples.

Pour le typeof en javascript c'est une opérande et donc les parenthèses en théorie ne sont utilisé que si c'est pour vérifié genre une résultat exemple (pour des raisons de lisibilité) : typeof('bb' + 'aa'). Si tu préfère avec les parenthèses je peux les rétablir dans cette branche.

Pour les commentaires j'ai un peut unifier les entêtes, je ne crois pas avoir modifier ailleurs. Il faudrait je pense définir un type d'entête de fichier et toujours l'utilisé.

La branche que j'ai commencé est légèrement différente du zip que j'avais placé ici vu que le zip c'était pour que ça fonctionne direct ;) ) donc dans la branche les ${map}... sont laissé tel quel. (sauf oubli car temporairement je les commentes pour voir se que les vérificateurs disent). Sinon là ça fonctionne (malgré les oubli des //) car la première ligne des fichiers inclus sont des commentaires. Normalement l'inclusion n'est nécessaire qu'une fois par contexte donc dans le content_script, dans le worker...

Pour ajouté un cli en NodeJS du même type que celui en python ou est-ce le mieux de le mettre (gc_lang\fr\node-cli) ?

Note: avec le portage NodeJS il devient facile de généré un fichier qui permettrait d’exécuter Grammalecte à placer sur un site (sans installation de web-extension).
De plus le support NodeJS peut permettre de créer des extension pour certain éditeur comme 'Visual Studio Code", "Atom" ...

Note2: je ne connais pas les condition de publication des web-extensions mais ne serait-il pas possible de "minifier" tous les fichiers JS avec par exemple github.com… en plus ça permttrait de diminuer le nombre de fichiers nécessaire.
le 11 octobre 2018 à 12:25
Pardon, je n’ai pas été clair. Je ne vois aucun problème à ce que tu fasses des modifications pour NodeJS. Le problème, c’est que je ne connais pas cet univers (et je n’ai pas particulièrement envie de le connaître) et c’est toujours embêtant de dire qu’on supporte quelque chose s’il n’y a pas de suivi derrière. Comme je ne connais pas la syntaxe de NodeJS, j’aimerais que la syntaxe demeure aussi vanilla/standard que possible, car je ne veux pas avoir à l’avenir à plonger dans la doc de NodeJS pour comprendre pourquoi quelque chose ne fonctionne plus.

C’est pourquoi il faut absolument séparer les modifs que tu veux faire pour NodeJS et les autres éventuelles modifications (comme les corrections syntaxiques annexes, points-virgules, etc.). Donc, si tu veux rectifier la syntaxe du code, fais-le avant de faire les modifs pour NodeJS.

En Python et en JavaScript, les quotes simples et doubles ont le même effet. Usuellement, j’utilise plutôt des quotes doubles. Parfois les simples, souvent pour éviter des caractères d’échappement, ou parfois sans raison précise. Si tu penses qu’il faut harmoniser, alors ce sera les doubles (je les emploie bien plus souvent, ça évitera de modifier tout le code, et les doubles sont même requises dans certains cas). Mais ne t’embête avec ça. Ça ne sert à rien de changer tout le code juste pour ça. Utilise les quotes simples si tu veux, ça ne me dérange pas, mais évite de modifier les autres.

Pour typeof, oui, je sais, mais comme j’avais lu que c’était plus sûr de mettre des parenthèses, j’en ai mis partout. Si tu penses qu’il vaut mieux les enlever, soit. Je ne suis pas expert pour en juger.

Si tu veux faire une CLI en NodeJS, tu peux la mettre dans la racine, comme celle en Python.

Quant à minifier le code, il faut le faire à part. Mozilla vérifie le code, et si on fusionne tous les fichiers, ils vont râler, ce ne sera pas accepté. Je suis déjà assez à la limite. Pour Google, je ne sais pas, ils ne m’ont jamais rien dit.

Quant au code suppléant aux objets natifs, oui, on peut commenter les références puisque ça ne change rien au final. J’avais bêtement oublié que Python faisait le remplacement dans tous les cas.

Normalement l'inclusion n'est nécessaire qu'une fois par contexte donc dans le content_script, dans le worker...


En théorie, oui, mais ce n’est pas comme ça que Thunderbird fonctionne apparemment. Comme je l’ai dit, Thunderbird a un fonctionnement différent de Firefox.
le 11 octobre 2018 à 13:30
C'est dommage pour la "minification" car ça simplifierait pas mal le code vu que si on regarde bien les principal modification pour NodeJS c'est juste des problèmes avec les chemins des "require".

Sinon c'est sans doute une question bête mais dès qu'on change le code javascript c'est bien

make.py LANG -js

(j'ai un doute car sur la page http://212.47.254.152:8080/doc/trunk/doc/build.md c'est indiqué First build et plus dit il est dit que -js c'est pour construire le javascript) qu'il faut faire ? Si c'est le cas il reconstruit à chaque chaque fois un graphe (je pense pour la grammaire) donc ça ne serait pas possible de le mettre tout se travail en cache pour juste faire le minimun ?

J'ai remis la synthax que tu utilisais pour les typeof et au les guillemets. Si ça te dérange pas pourrait'on mettre les ${map} ${string} ${map} en commentaire vu qu'avec la construction au finale ça change rien au code. ça permet de mieux repéré les erreur de code vu que ça empêche les vérificateurs.
le 11 octobre 2018 à 18:15
Tu peux minifier, mais il faut le faire après la genèse du code pour les extensions, dans un dossier de _build. Pourquoi pas _build/node ? Le make sert justement à générer tous les cas particuliers.
Il y a une procédure pour LibreOffice, une pour Firefox, une pour Thunderbird. Rien n’empêche de faire une procédure annexe pour NodeJS. Tu remixer le package grammalecte-js dans un seul fichier. C’est juste qu’il sera fait ailleurs que dans grammalecte-js qui restera le produit standard en attendant une hypothétique uniformisation.

Oui, il faut l’option -js dès que tu modifies le code en JS.

Je suis effectivement embêté moi aussi par la reconstruction des graphes à chaque build (car c’est un peu lent), donc quand j’aurai le temps, je mettrai le résultat en cache histoire d’aller plus vite.

Comme je l’ai dit, pour typeof, je m’en moque, fais comme tu veux. Il n’y avait que les guillemets qui me posent problème, parce qu’il y en a des milliers dans le code.

Oui, tu peux commenter les références aux ajouts de code pour les objets natifs de JS.

Je vais être absent pour quelques jours. Ne t’étonne pas si je ne réponds pas.
le 12 octobre 2018 à 08:04
Désolé pour mon silence mais j'ai eut quelques imprévus ;)

J'ai fait le commit pour une première version d'une cli pour nodejs. Elle est encore incomplète mais propose déjà les principale fonctionnalités.

Cependant j'aurais besoin d'un petit coup de main pour faire le build :
Il faudrait un répertoire avec le contennu : gc_lang\fr\nodejs et lui copier dedans grammalecte-js (sous le nom grammalecte)
et la cli sera fonctionnel.

J'ai essayer de faire une aide mais c'est absolument pas mon point fort ;)

PS: Merci pour le cache dans le build ça fait gagner beaucoup de temps.
le 15 octobre 2018 à 13:54
Les dossiers gc_core, gc_lang, graphspell, graphspell-js servent de sources.
Les dossiers grammalecte et grammalecte-js servent pour y mettre le produit final ou quasi-final.

Le dossier gc_lang servant de source, on ne va pas y mettre le résultat final pour NodeJS. Soit on produit le résultat final dans _build, si ça se présente sous la forme d'une archive ou d'une extension (je n'ai aucune idée de ce à quoi ressemble une extension pour NodeJS), soit on met ça dans un répertoire idoine /nodejs à la racine.

Je rentre chez moi demain, je compléterai le make en Python pour NodeJS, mais il faut que tu me dises ce dont tu as besoin, ce qu'il faut faire.
le 15 octobre 2018 à 14:09
Je me suis mal exprimé, je parlais du résultat dans _build donc effectivement il faudrait dans _build que ça créer un répertoire nodejs ou a la racine ça copie le contenu de gc_lang\fr\nodejs puis dans le répertoire _build/nodejs copier le grammalecte-js comme pour la web-extension.

J'ai essayer de faire un minimum de changement dans le core, je me suis permis de changer le Textformater en y incluant du code qui était dans la web-extension pour évité une duplication de code.

Actuellement c'est pas un module a proprement parler, il manque le fichier de description de module (actuellement c'est plus pensé pour faire vite fait des tests en ligne de commande pour le dev).

De plus je n'est jamais fait de module "publique" donc je n'ai pas encore étudié pour savoir comment le rendre disponible sur le gestionnaire de module pour nodejs. Je ne pense pas que ça devrait être compliqué ;)

A mon avis si on veux le publier dans le gestion de module en faite il faudra le pensé en deux module : le core et la client (qui installera le core)
ça permettra que ceux qui veulent créer quelque chose avec grammalecte auront juste besoin de mettre la dépendance vers le core dans leur code, et pour avoir grammalecte en ligne de commande ça installera automatiquement tout se qu'il faut.

Ajout: Rien n'est pressé pour le build.
le 15 octobre 2018 à 15:24
Branche de dev : http://212.47.254.152:8080/timeline?r=nodejs

Résumer :
Apport des changement nécessaire pour faire fonctionner Grammalecte sur NodeJS.
Création de deux modules :
* le coeur : Grammalecte-js avec une api simplifié
* le cli: Permet d'utiliser Grammalecte en ligne de commande

!!! Etat au 15/10/2018 : fonctionnel mais en manque de fonctionnalité pour le cli
Vu que les modules ne sont pas publiés pour le moment voici les commandes pour tester en local la cli :
cd _build/nodejs/core/
npm link
cd _build/nodejs/cli/
npm link grammalecte
npm install -g
Après dans un terminal la commande gramma-cli devrait être fonctionnelle.

PS: le dossier _build pour le moment est fait à la main (j'aurais besoin d'aide pour intégrer ses copies dans le make.py), son contenu est :
la copie du répertoire : gc_lang/fr/nodejs/ dans _build/nodejs/
puis la copie de grammalecte-js/ dans _build/nodejs/core/grammalecte/

Quelques questions :
Si on rend officiels les modules qui les publie ?
Vu mon niveau en anglais, j'ai écrit les readme en français, faut-il les traduire en anglais ?
Est-ce que les descriptions ... te conviennent ?

Toutes remarques ou suggestion sont les bienvenues !
le 15 octobre 2018 à 18:27
J’ai adapté le make pour faire le package comme spécifié, mais je n’ai pas testé.
Attendu que Grammalecte n’est pour l’instant que pour le français, inutile de traduire en anglais.

J’ai fait quelques ajustements et corrections, mais rien d’important. Il faudrait peut-être effectivement utiliser une langue plus concise dans l’aide pour NodeJS, mais je n’ai pas le temps de m’y attarder pour l’instant, je verrai ça plus tard.

Note : Il eût été préférable de faire les modifs du formateur de texte dans trunk puis de les intégrer dans la branche nodejs, pour plus de clarté, mais ce n’est pas très grave. Essayez de procéder ainsi, s’il vous plaît. (Je ne suis pas parfait sur ma manière de commiter non plus, mais j’essaie.)

Pour les commits concernant NodeJS, utilisez le tag njs s’il vous plaît. Le tags js et py n’ont pas d’existence en tant que tags dans la base de données, je m’en sers juste parfois dans l’intitulé d’un commit pour signaler que la modif ne concerne que JavaScript ou Python.

En ce qui concerne l’officialité du paquet pour NodeJS, je veux bien le publier moi-même, mais je ne veux pas en être le mainteneur.

Pour ma part, tant que l’écosystème JavaScript sera incohérent et qu’il ne sera pas possible d’utiliser import/export, je considère que Grammalecte n’existe pas indépendamment en JavaScript, seulement comme élément des logiciels dans lequel il est intégré (Firefox, Chrome, Thunderbird et à présent NodeJS). En théorie, l’API principale devrait être dans le module grammalecte-js. Comme ce n’est pas possible, c’est déporté dans chaque logiciel où Grammalecte est intégré.

Autre point : Si je publie moi-même le module pour NodeJS, alors le versionnage devra suivre celui utilisé pour les autres logiciels. Si vous préférez publier vous-même Grammalecte pour NodeJS, vous faites comme bon vous semble.
le 17 octobre 2018 à 16:37
Merci pour les changements du make et les ajustements.

Pour l'aide c'est vraiment pas mon fort mais j'ai pensé que c'était important ça évite que ceux qui veulent l'utiliser doivent consulter le code pour comprendre comment ça fonctionne. Il faudrait d'ailleurs surement ajouter les fonctions disponibles dans le readme de la partie core.

Il n'y a pas de problème pour que je maintienne la version pour nodejs, au pire, tu auras juste à me prévenir quand tu auras fait des modifications sur le core pour que je fasse les changements nécessaires ;) pour la publication, c'est comme tu veux (que ce soit toi ou moi, il y a des avantages et inconvénients)...

Ce qui est sûr c'est qu'avant la publication la doc de l'api doit être mieux fourni, et pour le client je dois mieux harmonisé le code vu que pour le moment c'est un peu l'anarchie ;)

C'est sûr que le support import/export et fonctionnant pareil simplifierait bien les choses même si certains problèmes viennent à mon avis que la version JavaScript est plus ou moins juste une retranscription de la version python mais aussi de comment fonctionnent les extensions :s

Pour le versionnage je pense qu'il faudrait trouver un moyen pour indiquer la version du core tout en pouvant faire des modifications sur la version du "logiciel". exemple: garder les deux premiers chiffres pour le core et le 3ème serait la version du "logiciel".
Ca permettrait par exemple de savoir que la version 1.0.0 de Thunderbird a le même core que la version 1.0.4 de Firefox (mais que celle-ci a eut des corrections ne concernant qu'elle mais que le moteur est équivalent (v1.0 du core))
Quand une modification mineure du core est faite on augmente le 2ᵉ chiffre donc il devient 1.1 et donc les versions basées sur le core deviennent pour therderbird 1.1.0 et pour firefox 1.1.4
le 17 octobre 2018 à 18:53
La prochaine version, c’est la 1.0, parce que le cœur du correcteur a complètement changé, mais j’ai encore des choses à faire avant la publication (que j’espère faire début décembre).
En ce qui concerne les versions, ce sera x.y.z.i :
— x : version majeure
— y : version mineure
— z : correctif
— i : correctif pour interface (Firefox, Thunderbird, CLI, serveur, NodeJS, etc.)

certains problèmes viennent à mon avis que la version JavaScript est plus ou moins juste une retranscription de la version python


C’est-à-dire, plus précisément ?

Quant aux extensions, oui, ça pose pas mal de contraintes, et c’est pour ça que l’API de Grammalecte est plutôt bas niveau. Ce n’est pas pour rien que je considère toujours qu’elle est en version alpha et que je n’ai pas publié Grammalecte sur PyPI (mais qu’importe, il n’y aucune urgence de ce côté-là).
le 17 octobre 2018 à 20:17
Pour publier le paquet pour NodeJS, comment tu vois ça ? Un zip du répertoire _build/nodejs ?
le 17 octobre 2018 à 20:22
Si on se réfère a la doc docs.npmjs.com… pour publier une fois le compte créer et identifier il suffirait de faire un

npm publish

dans chacun des deux répertoire core puis cli (en 2ème vu qu'il dépend du core) puis pour les mise a jour changer le numéros de version dans les package.json puis faire les

npm publish


Il me semble que cette commande créer un "tgz" avec le contenu du répertoire puis leur envoie automatiquement.
Si comme pour les même raison que PyPi tu prèfère ne pas les publier dans le répertoire des modules publique en faisant

npm pack

(dans les répertoires core et cli) ça créer le <name>-<version>.tgz que tu peux donc mettre sur le site et les personnes peuvent l'installer en l'ayant téléchargé.

Pour le versionnage , je ne suis pas sure qu'on peut publier un module nodejs avec 4 chiffres ça sera à tester ;)

Comme exemple de problème que je trouve à la version javascript c'est par exemple on ne tire pas partie de la lecture des données asynchrone vu comment elles sont utilisés. Donc je pense qu'il faudrait modifier les obj conj / mfsp / phonet (entre autre) en class qui est initialisé avec les données (comme le lexicographe) ceci permettrais de pouvoir charger les donnés d'une manière asynchrone (et donc en parallèle) et une fois lu initialisé le reste (je ne sais pas trop si je suis claire)...
le 17 octobre 2018 à 22:03
Pour publier sur npm, la condition sine qua non à mes yeux, c’est que le paquet grammalecte-js soit modulaire (import/export fonctionnels) et l’API stabilisée. Tant que ce ne sera pas le cas, c’est non pour moi. Mais si tu veux le faire, libre à toi bien sûr.

Comme exemple de problème que je trouve à la version javascript c'est par exemple on ne tire pas partie de la lecture des données asynchrone vu comment elles sont utilisés.


Ce n’est pas parce que le code est adapté de Python que c’est ainsi.

En Python, c’est même l’inverse, les données sont incluses dans le code directement, pas dans des fichiers JSON.

C’est Mozilla qui m’a demandé de mettre toutes ces données dans des fichiers JSON au lieu de les inclure dans le code. Et c’est eux qui m’ont dit de lire les fichiers JSON en mode synchrone. Tu oublies que Grammalecte tourne dans un Worker (donc un thread séparé) dans Firefox, Chrome et Thunderbird, et c’est pourquoi la lecture est synchrone. C’est d’ailleurs ce qui est indiqué dans le commentaire juste à côté de la ligne de code qui fait ça.
Les outils de vérification de code de Mozilla sont apparemment merdiques (écrits en JavaScript) et ne parviennent pas à gérer les gros fichiers de code. Même les fichiers JSON sont censés être limités à 4 Mo.
Tout ça a été une longue suite d’emmerdements.

Mais aucun rapport avec Python. Au contraire, tout est dû à l’écosystème bordélique de JavaScript. ;)
le 18 octobre 2018 à 10:05
Vu que les fichiers générés avec la commande "npm pack" permettent l'installation pour nodejs sans problème (contrairement aux web-extension) je pense que ça suffit de les fournir sur le site. Ça évite déjà au développeur qui veut utiliser que pour nodejs d'installer python et les prérequis pour compiler Grammalecte.

C'est "marrant" qu'ils t'ont demandé de lire les données d'une manière synchrone vu que dans la doc lire les données d'une manière synchrone dans un worker c'est une "tolérance" : l'exemple qu'il donne d'ailleurs c'est le chargement synchrone suite a une réponse d'un message donc effectivement dans ce cas il n'y a pas vraiment besoin que se soit asynchrone (vu que le message l'est).
Mais bon ça fonctionne comme ça donc laissons-le ;)

Le problème de JavaScript c'est que non seulement il a été pensé à l'origine pour le web mais en plus qu'en fonction des navigateurs c'est implémenté différemment...

Sinon est-ce que ça serait difficile d'appliquer la désambiguïsation dans le lexicographe, je trouve que ça serait bien et plus utile d'avoir la forme du mot la plus probable mis en avant. Voir même (mais là c'est beaucoup plus compliqué) que pour le mot mal orthographié qu’on puisse avoir le type de mot probable.
le 18 octobre 2018 à 12:06

Notification par e-mail    1