OK
AJAX error!

Les forumsGrammalecteAvancée des travaux

Avancée des travaux

Le dictionnaire orthographique pour Hunspell a été restructuré pour laisser la gestion de l’apostrophe au correcteur grammatical (nouvelles règles de contrôle). La complexité du correcteur orthographique s’en trouve grandement réduite.

Le code de Grammalecte a été réorganisé, à la fois pour simplifier, clarifier et séparer le français du reste du code. Ce travail est toujours en cours. Le dictionnaire grammatical a lui aussi subi une refonte totale de son étiquetage et de sa structure. Toute l’analyse lexicale a été refaite.

Les options concernant la casse et la séparation des mots (ce qui sert de pseudo-tokeniseur) dans les règles grammaticales ont été affinées, de sorte qu’il est possible de gérer les cas particuliers plus aisément.

Le désambiguïsateur est en cours d’écriture. Ça commence à devenir plus ou moins opérationnel, nonobstant les bugs.

La désimbrication de Grammalecte hors de LibreOffice est en cours. Ce point ne pose pas de problème particulier pour l’instant.

J’ai ajouté quelques nouvelles règles grammaticales et fait diverses améliorations ici et là.

Pour résumer, disons que le boulot de réorganisation du code et des données est en cours. Avec tous ces changements, la plupart des règles ont été modifiées, ajustées, réécrites pour tenir compte du reformatage des données et des méthodes pour y accéder. Il y a eu un véritable déluge de bugs et de régressions de toutes sortes, mais je commence à en voir le bout. J’en ai profité pour ajouter quelques contrôles sur l’écriture des règles, car j’ai pas mal transpiré pour dénicher certains bugs subtils. Tout ça est en cours de rodage.

Le gros morceau à venir, outre les bugs restants, ce sont les ajustements à faire dans les règles pour utiliser le désambiguïsateur de manière efficace, et bien sûr rendre Grammalecte autonome.

Je pense que j’en aurai fini avec tout ça en août et que je pourrai commencer à travailler sur Firefox à ce moment-là.

Rien de palpitant pour l’instant, mais ça avance bien. :)
le 01 juillet 2015 à 07:24
Rien de palpitant ? Peut-être... Mais cela semble tout de même un tantinet titanesque !
Bravo pour ces débuts encourageants, et bon courage pour la suite !
le 01 juillet 2015 à 14:31
J’ai pris un peu de retard. Pour deux raisons : la longue canicule de cet été, qui n’a pas vraiment été bénéfique pour ma productivité, et une transformation globale de la manière dont fonctionne Grammalecte qui n’était pas prévue au programme, mais que j’ai quand même jugé bon de mettre en œuvre.
Jusqu’à il y a peu, comme je l’avais expliqué sur LinuxFR, Grammalecte utilisait un moteur multi-passes, où, lors de chaque passe, il exécutait le préprocesseur de texte puis l’analyse du texte. En somme, le préprocesseur et l’analyseur fonctionnaient par bloc de règles successives de même nature.
À présent, nous sommes revenus à deux passes, une paragraphe par paragraphe, une phrase par phrase, qui nous offrent les mêmes avantages qu’avant, mais le flux d’action des règles est dorénavant beaucoup plus souple, attendu que chaque règle peut mettre en œuvre un nombre illimité d’actions (au lieu d’une seule auparavant) de genres différents.

Auparavant, nous avions :

Passe 0 (paragraphe par paragraphe)
— Règles du désambiguïsateur
— Règles du préprocesseur
— Règles d’analyse
Passe 1
— Règles du désambiguïsateur
— Règles du préprocesseur
— Règles d’analyse
Passe 2
— Règles du désambiguïsateur
— Règles du préprocesseur
— Règles d’analyse
etc.

Chaque règle ne pouvait faire qu’une seule action : signaler une erreur, transformer un morceau du texte ou appliquer une mesure de désambiguïsation.



À présent, nous avons :

Passe 0 (paragraphe par paragraphe)
Flux de règles multi-actions diverses

Passe 1 (phrase par phrase)
Flux de règles multi-actions diverses

L’expression régulière qui sert de déclencheur d’une règle permet de lancer plusieurs actions différentes. Autrement dit, chaque règle peut signaler plusieurs erreurs, transformer le texte sur plusieurs zones et appliquer plusieurs tests de désambiguïsation. Il n’y a plus de limite au nombre d’actions et à leur type, et chaque action dispose de ses propres conditions d’application.



L’utilité : plus de souplesse, plus de possibilités, et, peut-être, je l’espère, un gain de performances.

Le moteur reste malgré tout multi-passes, même si deux passes suffisent présentement.

À part ça, tous les bugs dont j’ai parlé précédemment ont été corrigés. Le correcteur fonctionne dorénavant sans avoir besoin de Hunspell. C’est du pur Python. Pour ceux qui s’inquiètent des performances après le remplacement d’une bibliothèque en C++ par du code en Python, sachez que Grammalecte est à présent environ 5 % plus rapide que la version 0.4.10 (qui était elle-même plus rapide que les versions précédentes).
Tous les voyants sont maintenant au vert. Je suis juste en retard sur la désimbrication de Grammalecte de LibreOffice. Ça devrait être fini assez rapidement.
Quand j’aurai peaufiné certains détails, avant la fin septembre, je publierai une nouvelle version du correcteur.

Alors commencera le port pour Firefox.
le 02 septembre 2015 à 05:59
Voilà, Grammalecte est à présent détaché de Hunspell et de LibreOffice. Oh, c’est encore un paquet Python assez rudimentaire, il faudrait encore ajouter quelques fonctions, mais on va pouvoir bâtir autour de ça une application autonome, un serveur, faire des tests unitaires… et n’importe quelle application Python pourra faire appel à l’API du paquet. Dans ce paquet, il y a le correcteur grammatical, le dictionnaire binaire indexable (ibdawg) et le conjugueur. On peut donc vérifier l’existence d’un mot, connaître les étiquettes apposées dessus, vérifier un texte (paragraphe par paragraphe), et obtenir la conjugaison de n’importe quel verbe à n’importe quel temps, sous n’importe quelle forme.

L’extension pour Writer inclut ce paquet et l’interroge sans cesse pour son fonctionnement. En somme, ce n’est plus qu’une glu et une interface entre Writer et Grammalecte.

L’API n’est sans doute pas encore définitive. Il y a encore des détails à régler. Pour l’instant, je ne suis pas certain que ça fonctionne avec d’autres langues, même s’il devrait être possible d’en inclure d’autres.

Donc, encore une semaine ou deux de rodage et de détails à peaufiner, et sortira une nouvelle version. La liste de mots à intégrer est encore en cours de revue. Il y a encore quelques retardataires.

Ensuite, je passerai à la conception de l’extension pour Firefox.
le 11 septembre 2015 à 18:22

On va pouvoir bâtir autour de ça une application autonome, un serveur, faire des tests unitaires…


Super, et bravo ! J'avoue ne presque jamais utiliser Grammalecte, car LibreOffice est trop lent à démarrer. Mais si je peux bientôt utiliser Grammalecte en ligne de commande ou en mode serveur, je pourrai finalement créer un plugin pour Vim.
le 11 septembre 2015 à 23:14
J’ai encore pris un peu de retard, car j’ai passé un temps considérable à mettre en place des tests unitaires pour éviter les régressions. À vrai dire, le terme “unitaire” est ici un peu abusif, attendu que j’ai surtout mis en œuvre des vérifications sur les résultats que Grammalecte doit rendre au final. Ce n’est donc pas unitaire au sens strict du terme, mais il est toujours possible d’améliorer ce point. L’essentiel, c’est que Grammalecte entreprend à présent une masse importante de tests (encore appelée à grossir) à chaque modification des règles. C’est un énorme progrès.
J’ai aussi supprimé bon nombre de faux positifs et ajouté des règles de contrôle ou amélioré certaines d’entre elles.

Mais le point important, c’est que Grammalecte fonctionne à présent en mode autonome. Et j’ai conçu une petite application pour tester le correcteur dans une simple console. Plus besoin de lancer LO. :)
s11.postimg.org…

Comme il y a eu un nombre énorme de changements, voici une version bêta. Merci de la tester.
www.dicollecte.org…

C’est toujours une extension pour LO, mais ceux qui veulent utiliser la console le peuvent. Allez dans le sous-dossier “pythonpath” et récupérez le dossier “grammalecte” et le fichier “parser.py”. C’est tout.

“parser.py” permet de tester le texte que vous entrez à la main.
“parser.py -f filename” pour analyser un fichier texte (UTF-8 requis).
“parser.py -ff filename” pour analyser un fichier texte (UTF-8 requis) et produire un fichier résultat.

C’est encore rudimentaire et peu testé. Navré. En théorie, je devrais me consacrer à présent à améliorer ça et à produire le serveur, mais comme ce n’est pas l’ordre promis par la campagne de financement et que je n’ai pas besoin de plus pour avancer, je vais à présent me consacrer à l’extension pour Firefox.
Rassurez-vous, je vais quand même améliorer les tests unitaires et parfaire l’outil, mais ce n’est pas la priorité pour l’instant.

En ce qui concerne les contreparties, le dictionnaire “Classique” (et seulement lui pour l’instant) contient désormais les mots demandés par les contributeurs.
La liste de ces mots est consultable ici : www.dicollecte.org…
Merci de me signaler les éventuelles erreurs et les oublis.

Bon nombre de ces mots (beaucoup des noms communs et quelques-uns des noms propres) sont éligibles pour être intégrés dans le dictionnaire commun. Ils y seront donc transférés dans quelque temps, au fur et à mesure, quand j’aurai le temps de faire les vérifications nécessaires. Voici par exemple certains des noms propres qui sont éligibles : Clothilde, Andrei, Joakim, Léopoldine, Euphrasie, Mouhammad, Fantine, Florestan, Florie, Terence, Hypnos, Djurdjura.

À noter que certains mots proposés étaient déjà présents dans le dictionnaire. En voici la liste : fada, Arthur, Marilou, jardin, vélo, grammatologie, Léopold, Héloïse, héraldique, Terry, Marcia, Narcisse, Lionel, Théo, Florence, plussoyer, Freud, schmilblick, Richard, Val d'Isère, Fernando, Grenoble, Buenos Aires, bépo, nuoc mam (sous la forme nuoc-mâm), yiddish, apostolicité, adamantin, Occitanie, occitant (mais il n’y a pas de “t” final), Gascogne, gascon-ne-s, OK, gouterreau (mais ça s’écrit avec deux “t”), email (sous la forme e-mail), escagasser, esquicher, esclaffer, emboucaner, µmole (sous la forme µmol), Min (le symbole des minutes s’écrit min).

Certains des mots proposés n’ont pas été ajoutés au dictionnaire et certains ne le seront probablement pas (la décision est en suspens). En voici la liste : Southern blot, Northern blot, Zea Invent, Apex Agri, Agro Bio, The Document Foundation, Apache Software Foundation, Free Software Foundation, Golden Show, Lovely Rita, Mix Bizarre, Scred TV, Las Gastios, Hero Corp, Texas Instruments, Standard de Liège, Creative Commons, Madame&Services.
La raison, c’est que le dictionnaire ne peut accepter que des mots entiers (pas d’espace et pas de caractères spéciaux comme “&”). Il faudrait donc ajouter ces mots séparément. Mais certains d’entre eux sont susceptibles de créer des confusions (Creative, Foundation, The, etc.). Parfois, ces mots existent déjà dans le dictionnaire (Rita, apache, software, document, bizarre, mix, golden, show, etc.).

N’hésitez pas à rapporter les bugs et les faux positifs. Merci.
www.dicollecte.org…
le 04 octobre 2015 à 20:33
Voilà quelque temps que j’ai commencé à travailler sur la conversion du moteur de Grammalecte en JavaScript.

L’univers JavaScript est un gigantesque bordel (cube-drone.com…). JavaScript lui-même est un langage très en retard sur bien des points, notamment parce que sa librairie interne est notoirement incomplète, sa syntaxe rudimentaire. (Il n’y même pas encore de commande d’import !). Vous trouverez sur le web des tas de billets expliquant pourquoi JavaScript pue (sametmax.com… whydoesitsuck.com… www.boronine.com…). La nouvelle norme ES6 va remédier à bien des soucis, mais elle est encore en cours d’implémentation (car elle n’est finalisée que depuis juin 2015 seulement) et ça va prendre du temps avant que ça arrive partout. Même Mozilla, qui est en avance sur tout le monde sur ce chapitre, est loin d’avoir terminé d’implémenter ES6.
kangax.github.io…
Cela dit, même avec ES6, JavaScript est encore loin d’être un langage hyper plaisant. Bref…

Je me suis donc demandé si j’allais adopter le plus petit dénominateur commun (ES5), suivre tranquillement la nouvelle norme (ES6) à mesure qu’elle serait reconnue par les grands acteurs, utiliser un autre langage comme CoffeeScript, TypeScript, Haxe, etc. et compiler Grammalecte vers le JavaScript (faire confiance à un outil tiers), ou bien utiliser un transpileur comme Babel ou Traceur qui produisent du JavaScript pour tous les moteurs (faire confiance à un outil tiers)…

Après avoir ruminé un peu la question, j’ai résolu de n’adopter aucune de ces solutions. Je vais suivre la norme ES6 de très près, sans me soucier de la compatibilité avec les divers moteurs JavaScript. Le moteur de référence sera celui de Mozilla (SpiderMonkey), à partir de la version 44 de Firefox qui sortira en janvier (80% d’ES6 implémentés). Tout ce que Mozilla implémentera sera la nouvelle référence. Tant pis pour les autres, qu’ils se hâtent de suivre.

Donc, pour répondre à certains contributeurs qui m’avaient demandé si je comptais utiliser ES6, la réponse est oui. Parmi les fonctionnalités d’ES6 utilisées, il y a/aura : les classes, les tableaux typés, Map, Set, les fonctions fléchées, for … of, la déstructuration, les paramètres par défaut, les paramètres du reste, les gabarits de chaînes de caractères, et même les array comprehensions (ES7), et sûrement d’autres choses (l’import quand ça existera).

Le principal problème concerne les expressions régulières, le moteur de JavaScript étant déficient sur ce chapitre, nettement en retrait par rapport à celui de Python. Il manque les assertions “lookbehind”, un support commode de l’unicode et surtout il n’y a rien pour récupérer les index de position des groupes, ce qui est problématique. Il faudra donc que j’implémente moi-même tout ceci et j’ignore encore quel impact ça aura sur les performances.

Je n’en suis encore qu’au début. Je vais essayer de publier une bêta au moment de la sortie de Firefox 44, fin janvier 2016.
le 18 octobre 2015 à 12:41
Un petit message d’encouragement pour vous féliciter pour le travail accompli jusqu’ici et vous dire mon impatience à voir la suite.

Je m’en vais tester de ce pas ce qui fonctionne déjà :)
le 23 novembre 2015 à 10:28
Bonjour,
où en sont les travaux ? Je profite pour vous féliciter du travail accomplit, je l’utilise quotidiennement !
le 07 février 2016 à 19:24
Bonjour,

Grosso modo, en ce moment, je bosse quasi exclusivement sur l’extension pour Firefox, plus précisément sur le moteur interne du correcteur grammatical en JavaScript. Et je passe surtout mon temps à corriger des bugs. Je suis dans la phase chiante du projet. C’est loin d’être palpitant en ce moment. Il n’y pas grand-chose à dire sur ça.

J’avance à une vitesse modeste, je dirais, pas aussi vite que je l’avais espéré parce que les bugs et les micro-problématiques sont plus nombreux que prévu. Et ce n’est pas toujours évident de dénicher d’où viennent les problèmes. Toutes sortes de subtilités me font trébucher parce que je ne suis pas aussi habitué à JavaScript qu’à Python. Je trouve que le débogage est plus difficile avec JavaScript. Le typage fort de Python rend les choses plus claires. Par exemple, JavaScript a tendance à vous balancer des “undefined” silencieusement qui se baladent dans le script et on ne trouve pas toujours d’où ça sort, là où Python vous renverrait juste un message d’erreur.

Bref. Rien d’alarmant. Je ne suis pas particulièrement bloqué par quoi que ce soit. J’avance seulement un peu plus lentement que ce que j’avais estimé au premier abord.

J’ose espérer pouvoir présenter les premiers résultats pour Firefox 45. Mais je demeure prudent, car quand je me suis déjà planté sur une prévision, je n’aime pas en faire d’autres.
le 08 février 2016 à 02:10
Bonjour,

Peut-être qu’un logiciel de mesure de la qualité du code source pourrait vous aider à éviter certains écueils avec JavaScript. SonarQube¹ m’a bien aidé quand j’ai dû maintenir du code écrit en Flex (ActionScript) en n’en ayant jamais écrit. Il dispose d’une extension pour JavaScript² qui est vraisemblablement compatible avec ECMAScript 6. Un exemple éclairant est fourni avec le code de jQuery³. Les règles sont personnalisables pour plus de flexibilité.

J’espère vous avoir aidé.

¹ www.sonarqube.org…
² docs.sonarqube.org…
³ nemo.sonarqube.org…
le 08 février 2016 à 09:42
Il est temps de faire le point.

Commençons par le plus important : la première bêta pour Firefox paraîtra le week-end prochain.
La version minimale de Firefox sera la 45.

Le débogage a été assez horrible. En janvier, mes tests me rapportaient environ 250 erreurs, et il me fallait souvent un temps considérable pour en corriger une seule. Heureusement parfois, ça en corrigeait des dizaines d’un coup, mais parfois ça m’en rajoutait aussi des dizaines. Bref… le cauchemar. C’est pour cette raison qu’en janvier, je n’osais plus faire de prédiction sur le temps nécessaire pour corriger tout ça.

Le moteur en JavaScript passe à présent tous les tests que passe le moteur en Python. Il est plus lent que celui en Python, mais tout semble fonctionnel. Il est plus lent parce que le moteur d’expressions régulières de JavaScript est particulièrement déficient et qu’il faut compenser toutes ses déficiences.
Par exemple, les méta-caractères \b \B sont inutiles et \w doit être amélioré. Les plages de caractères retenues pour compenser \w sont celles-ci : à-ö, À-Ö, ø-ÿ, Ø-ß, A-ʯ. Ça changera peut-être. Quand je chercherai à optimiser, je verrai s’il y a moyen de gagner du temps là-dessus.
L’un des plus gros problèmes concernait les positionnements des sous-groupes des expressions régulières. JavaScript est incapable de fournir la position des sous-groupes capturés. C’est pourtant indispensable, attendu que ça sert pour tout dans Grammalecte (positionner les erreurs, réécrire le texte, désambiguïser). Au début, je pensais calculer la position des sous-groupes au fur et à mesure, mais c’est bien trop long à faire de manière fiable. Donc, en fait, ceci se fait à présent au moment d’écrire l’expression régulière dans la liste les règles. Il faut spécifier ce que j’appelle des codes de positionnement de groupes qui permettent à JavaScript de savoir où ils sont ou bien comment trouver où ils sont, ce qui est bien plus rapide.
Enfin, il faut aussi compenser l’inexistence des assertions “negative lookbefore”. Ce qui ne pose pas de problème particulier.

Comme je l’ai dit, j’ai écrit avec la syntaxe ES6 de JavaScript. J’ai utilisé en vrac : let, const, les classes, les générateurs, Map, Set, les fonctions fléchées, for … of, la déstructuration, les paramètres par défaut, les paramètres du reste, les gabarits de chaînes de caractères, les array comprehensions (ES7), quasiment tout ce qui se fait en ES6 probablement.
Il y a quelques jours, j’ai vu passer un lien sur Twitter concernant les performances d’ES6. kpdecker.github.io…
Ça donne quand même à réfléchir, et ça montre qu’il y a sans doute de la marge pour l’optimisation du code.

Mais pour l’instant, je ne m’occupe pas de ça (ce serait mettre la charrue avant les bœufs; de toute façon, ça devrait aller en s’améliorant, ES6 étant encore récent). Je travaille sur les fonctionnalités, notamment l’interface, et il y a encore pas mal de choses à faire.
le 05 mars 2016 à 12:02

Notification par e-mail    6