Bravo pour ton travail Olivier!
Bravo pour la dépêche très détaillée!
En plus, tu as devancé ma question sur la comparaison avec LanguageTools :)
C'est rigolo, il y a un gros parallèle entre ce que tu fais et ce que je fais (http://linuxfr.org/redaction/news/modernisez-votre-code-java-en-un-clic-avec-autorefactor-v1-0-0, hum dépêche à compléter).
J'ai la chance de pouvoir travailler sur un langage informatique d'où une syntaxe très bien définie (je ne parle pas du C++ ;) ). Je peux m'appuyer sur Eclipse JDT pour les analyses lexicales, syntaxiques et sémantiques (analyse des types, des variables, etc.).
Malheureusement, la langue naturelle n'est pas aussi logique, et le processus classique des compilateurs ne fonctionnent pas ou difficilement.
Je te tire mon chapeau pour oser t'attaquer à ce problème très difficile.
Ton analyse en plusieurs passe qui transforme le texte est une idée très intéressante pour palier aux multiples formes que permet un langage naturel. Merci d'en avoir expliqué le concept.
Comme tu l'as fait remarquer, j'y vois hélas un inconvénient majeur: c'est lorsqu'il s'agit de rapporter les erreurs sur du texte modifié.
Les compilateurs transforment plusieurs fois le code source en interne pour finalement parvenir à générer du code. GCC a au moins 3 représentations internes: GIMPLE => GENERIC => RTL .
Pour pouvoir correctement rapporter les erreurs a n'importe quel moment de la phase de compilation, il est impératif de pouvoir toujours revenir vers le texte initial en gardant des marqueurs ou des informations de localisation sur le texte source original. C'est aussi ce qui est fait dans le code généré pour pouvoir se référer au code source original lors de séances de débogage (Voir DWARF ou les source maps en javascript).
C'est comme ça que le problème est résolu dans les compilateurs. Je ne sais pas si c'est applicable a ton cas ou bien si cela ferait exploser la consommation mémoire, mais bon je me suis dit que ça pourrait être utile d'en parler.
Sur l'utilisation des expressions rationnelles, je sais a quel point cela peut être difficile. J'ai commencé comme ça avant de créer sur AutoRefactor a cause de la difficulté a les utiliser correctement et a les maintenir. Elles sont souvent imprécises (la plupart de l'espace pris par une regexp c'est uniquement pour la gestion des espaces), complètement ignorante de la sémantique de ce qu'elles traitent (pas d'informations de type!) et redondantes (Comment reconnaître a == b et b == a? Réponse: 2 regexps avec duplication de code. grmbl!.
Je pense que tu dois passer beaucoup de temps a les mettre au point. Tu as beaucoup de courage.
La ou je te plains, c'est que tu n'as pas de tests unitaires :(
J'ai commence par un truc sale pour faire les tests: un booléen dans le code du plugin qui exécute les tests sur des exemples de code: Je lançais Eclipse sur le projet avec les exemples. Si la variable booléenne test valait vrai, alors le plugin parcourait le projet pour trouver les exemples avec le code d'entree et le code en sortie, il appliquait les transformations et vérifiait que le résultat final était obtenu. Il affichait alors une fenêtre avec les résultats.
S’était bien, mais lorsque j'ai pu automatiser les tests avec JUnit dans le processus de production (build en anglais), et bien ma productivité a été décuplée et j'ai pu ajouter beaucoup plus de regles avec une grande confiance sur l’absence de régressions.
Je t'encourage a faire ça en premier, c'est une investissement qui vaut vraiment le coup. Le temps passé dessus est récupéré plusieurs fois au fil du temps.
Finalement, je vois que tu as créé un outil que l'on retrouve dans le développement: un formatteur. De même dans l'Analyse statique de programmes, on retrouve le problème des faux positifs.
Comme je l'ai déjà dit, les parallèles sont rigolos :)
Encore une fois bravo pour ton courage et ta motivation!
# Bravo!
Posté par djano . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 4.
Bravo pour ton travail Olivier!
Bravo pour la dépêche très détaillée!
En plus, tu as devancé ma question sur la comparaison avec LanguageTools :)
C'est rigolo, il y a un gros parallèle entre ce que tu fais et ce que je fais (http://linuxfr.org/redaction/news/modernisez-votre-code-java-en-un-clic-avec-autorefactor-v1-0-0, hum dépêche à compléter).
J'ai la chance de pouvoir travailler sur un langage informatique d'où une syntaxe très bien définie (je ne parle pas du C++ ;) ). Je peux m'appuyer sur Eclipse JDT pour les analyses lexicales, syntaxiques et sémantiques (analyse des types, des variables, etc.).
Malheureusement, la langue naturelle n'est pas aussi logique, et le processus classique des compilateurs ne fonctionnent pas ou difficilement.
Je te tire mon chapeau pour oser t'attaquer à ce problème très difficile.
Ton analyse en plusieurs passe qui transforme le texte est une idée très intéressante pour palier aux multiples formes que permet un langage naturel. Merci d'en avoir expliqué le concept.
Comme tu l'as fait remarquer, j'y vois hélas un inconvénient majeur: c'est lorsqu'il s'agit de rapporter les erreurs sur du texte modifié.
Les compilateurs transforment plusieurs fois le code source en interne pour finalement parvenir à générer du code. GCC a au moins 3 représentations internes: GIMPLE => GENERIC => RTL .
Pour pouvoir correctement rapporter les erreurs a n'importe quel moment de la phase de compilation, il est impératif de pouvoir toujours revenir vers le texte initial en gardant des marqueurs ou des informations de localisation sur le texte source original. C'est aussi ce qui est fait dans le code généré pour pouvoir se référer au code source original lors de séances de débogage (Voir DWARF ou les source maps en javascript).
C'est comme ça que le problème est résolu dans les compilateurs. Je ne sais pas si c'est applicable a ton cas ou bien si cela ferait exploser la consommation mémoire, mais bon je me suis dit que ça pourrait être utile d'en parler.
Sur l'utilisation des expressions rationnelles, je sais a quel point cela peut être difficile. J'ai commencé comme ça avant de créer sur AutoRefactor a cause de la difficulté a les utiliser correctement et a les maintenir. Elles sont souvent imprécises (la plupart de l'espace pris par une regexp c'est uniquement pour la gestion des espaces), complètement ignorante de la sémantique de ce qu'elles traitent (pas d'informations de type!) et redondantes (Comment reconnaître
a == betb == a? Réponse: 2 regexps avec duplication de code. grmbl!.Je pense que tu dois passer beaucoup de temps a les mettre au point. Tu as beaucoup de courage.
La ou je te plains, c'est que tu n'as pas de tests unitaires :(
J'ai commence par un truc sale pour faire les tests: un booléen dans le code du plugin qui exécute les tests sur des exemples de code: Je lançais Eclipse sur le projet avec les exemples. Si la variable booléenne
testvalaitvrai, alors le plugin parcourait le projet pour trouver les exemples avec le code d'entree et le code en sortie, il appliquait les transformations et vérifiait que le résultat final était obtenu. Il affichait alors une fenêtre avec les résultats.S’était bien, mais lorsque j'ai pu automatiser les tests avec JUnit dans le processus de production (build en anglais), et bien ma productivité a été décuplée et j'ai pu ajouter beaucoup plus de regles avec une grande confiance sur l’absence de régressions.
Je t'encourage a faire ça en premier, c'est une investissement qui vaut vraiment le coup. Le temps passé dessus est récupéré plusieurs fois au fil du temps.
Finalement, je vois que tu as créé un outil que l'on retrouve dans le développement: un formatteur. De même dans l'Analyse statique de programmes, on retrouve le problème des faux positifs.
Comme je l'ai déjà dit, les parallèles sont rigolos :)
Encore une fois bravo pour ton courage et ta motivation!