Ceci est une ancienne révision du document !
Cette page contient les discussions et les retours de bugs de TXM 0.8.0.
Vous pouvez ajouter vos discussions et retours à la fin de cette page.
Pour information, la liste des bugs non résolus, c'est-à-dire que cette version ne cherche pas à résoudre, se trouve ici : kown-bugs (bugs connus)
SLH (07/06/2018) :
pas possible de conserver dans le lanceur à la fois l'icone de TXM 0.8.0 et TXM 0.7.9 (le lanceur - icone - d'un TXM 0.8.0 correspond à celui - celle du TXM 0.7.9)
GL (11/12/2018) :
Les corpus de 0.7.9 ne sont apparemment pas compatibles avec le format 0.8 :
Installing sample corpus…
VOEUX.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file)
graal.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file)
Done.
2 corpus loaded.
TXM is ready.
SLH (07/06/2018) :
'Fichier > Charger > un corpus (.txm)…' → 'Fichier > Charger > un corpus binaire (.txm)…' [pour être homogène avec 'Fichier > Charger > un corpus répertoire de corpus binaires…']
'Fichier > Importer' : mettre un séparateur devant 'CQP' [qui se distingue du reste]
'Fichier > Importer > CNR+CSV' → 'Fichier > Importer > Cordial+CSV' [pour être homogène avec Alceste, Hyperbase, etc.]
'Fichier > Nouveau fichier' → 'Fichier > Nouveau…'
'Fichier > Changer la langue' → 'Affichage > Changer la langue'
toolbar des perspectives :
nommer Corpus ou C le bouton de la perspective Corpus [comme le bouton de la pers. R se nomme R]
mettre un flyover “ouvrir la perspective Corpus' sur le bouton de la perspective Corpus
mettre un flyover “ouvrir la perspective R' sur le bouton de la perspective R
toolbar :
flyover 'Créé [sic] un nouveau fichier' → 'Éditer un nouveau fichier'
flyover 'Ouvrir un fichier ()' → 'Ouvrir un fichier'
VL (02-07)
Dans le menu, serait-il possible d'harmoniser les langues utilisées ?
“Internal view” pourrait devenir “Vue interne” ; [SJ: fait]
“Sub-corpus” pourrait devenir “Créer un sous-corpus” ou “Sous-corpus”;
“Create partition” pourrait devenir “Créer une partition” ou “Partition”;
“Rename” pourrait devenir “Renommer”
BP : Quand je redémarre TXM, les deux concordances que je voulais supprimer sont bien parties, mais aussi un corpus avec ! Finalement un peu plus tard (après autres redémarrages ?) le corpus disparu semble revenu. Ai-je mal vu ?? [SJ: fixé]
SJ : bug de pack des colonnes difficilement identifiable (semblant lié à la taille du pivot ?), ex. : 1) faire une cooc sur VOEUX avec la requête “fa.*” avec structure sur “p” 2) envoyer “souhaite” vers les concordances ⇒ la colonne du pivot est énormément large
SJ : par ailleurs la colonne ref plante parfois, premières lignes vides
SJ :
auto compute ou pas des résultats ? généralisé sur tous les widgets ou seulement quelques-uns ?
[SLH, 12/07] : je pense que la remarque de BP est qu'il y a des paramètres (widgets ?) qui changent beaucoup la nature de certains calculs, que du coup un certain nombre de paramètres complémentaires doivent être réglés avant de recalculer, et donc que l'auto compute ne doit pas être déclenché pour ces paramètres. Mais ça ne me semble pas remettre en cause l'auto-compute.
tri multiple par défaut ou pas ?
a faire : tri par défaut : Indice décroissant
MD: OK c'est déjà le cas
VL (02/07) :
En cas de présence d'un guillemet anglais, lorsqu'un clic sur « envoyer vers concordance/index/progression » est opéré, rien ne se passe (fenêtre de requête vide). [MD: OK corrigé]
Si on tente de forcer la requête [word="\""], message d'erreur
SJ:
la réouverture après rechargement ne fonctionne pas [SJ: fixé]
BP: SPÉCIFICITÉS sur table lexicale, marges = index :
il me semble qu'avant quand on triait sur le score de spécif on commençait par un tri décroissant pour voir d'abord les mots les plus spécifiques (S+), là on commence par voir les S-, ce serait mieux si on pouvait commencer par les S+ comme avant ? [SJ: fixé]
BP : titre de la spécificité calculée sur un sous-corpus “TLNONAME:word” [MD : OK j'ai laissé juste la propriété utilisée]
SJ:
Graphique de spécifs: la réouverture après rechargement ne fonctionne pas [SJ: fixé]
VL (02-07)
- proposition de changer le terme « parameters » en paramètre [SJ: fixé]
SLH (05/06/2018) :
la toolbar est cool
la possibilité de régler en temps réel les paramètres montre qu'une Vmax à 100 par défaut est probablement mieux
dans la zone des paramètres, il n'est pas nécessaire de suffixer les noms de paramètres par ' :', le changement de couleur et de widget suffit à montrer la différence entre le label et le champ de saisie
le bouton Apply pour chaque property [du corpus] c'est sûrement too much → un seul bouton Apply ou Save bien situé
il faut en plus à côté un bouton Cancel, équivalent au re-clic sur 'edit properties' qui ferme la zone
peut-être aussi modifier le bouton 'edit properties' avec une flèche vers le bas quand c'est pour ouvrir, puis avec une flèche vers le haut quand c'est pour fermer la zone (comme dans les boutons équivalents du portail)
SJ: je propose d'utiliser le même bouton que pour les annotations
le changement du nom du corpus c'est très cool → faudra mettre le ticket à ~100%
dans la toolbar, il faudrait donner un aspect [bouton] à Compute et à 'edit properties', comme c'est le cas pour Parameters
'edit properties' → 'corpus properties' ou 'properties'
dans le titre du
HTML résultat de la commande : 'Détails du corpus CQP VOEUX' → 'Propriétés générales[internes ?] du corpus CQP VOEUX'
BP:
- Suppression d'une requête OK (mais le graphique ne se met pas à jour automatiquement, il faut par exemple faire “entrée” dans le champ d'une autre requête) [SJ: fixé]
SJ:
- ajouter un test pour ne pas ajouter 2 fois la même requête dans le QueryWidget (cela fait planter le graphique). Le test est fait dans la ligne de requête principale mais pas dans le QueryWidget [SJ: fixé. Mais un message d'erreur “The query already exists.” dans la console n'est pas suffisant à mon sens. Mettre une dialog box ?]
[SLH, 12/07] :
oui, un boite de dialogue modale me semble appropriée dans ce cas, le message d'erreur pourrait être plutôt : “That query is already represented by a curve in the graphic. Please use another Query.” [SJ: fixé. Messages actuels : EN: “The query {x} is already represented by a curve in the graphic. Please use another query.”, FR: “La requête {x} est déjà présente dans le graphique.”]
SLH (08/06/2018) :
n'est pas le même que celui du label dynamique (en bas à droite dans ma figure) :
02decive, 8.13, 189
139216 / 451747
117 / 561
versus
[lemma="king"] (119 / 961)
Or il y a des éléments du label fixe qui seraient intéressants dans le label dynamique (surtout la réf car elle aide à savoir où on est tout en bougeant le point).
Ce serait pas mieux de mettre les mêmes infos dans les deux ? (voir en déplacer : eg la requête dans le fixe)
Une autre idée : documenter un peu les infos.
Par exemple :
ref: 02decive, 8.13, 189
position: 139216 / 451747
order: 117 / 561
On pourrait aussi justifier le label en profitant d'une police à casse fixe :
ref: 02decive, 8.13, 189
position: 139216 / 451747
order: 117 / 561
idée : créer un raccourcis RETURN équivalent au double-clic sur un point (ouverture de concordance). En effet, souvent on se déplace sur une courbe avec les flèches et le RETURN serait plus rapide pour ouvrir une concordance à partir du point où on se trouve. En fait c'est peut-être l'occasion de designer un premier scénario basé entièrement sur des raccourcis pour naviguer entre ces outils (en plus des interactions avec la souris et souris+clavier) ; [SJ: fait, voir:
http://forge.cbp.ens-lyon.fr/redmine/issues/2470]
le retour au texte double ne fonctionne pas bien. Un scénario habituel est d'analyser deux courbes en même temps → du coup on ouvre deux concordances en même temps et on a envie d'avoir deux retours au texte en même temps. Or les éditeurs d'édition se mélangent entre les deux concordances à partir d'un moment
SJ (14.11.2018): après tests je ne crois pas avoir de problème, est-il possible d'avoir des précisions ? testé: 2 courbes sur “faire” et “lui” ⇒ double clic sur un point de “faire”, déplacement dans les courbes avec les flèches ⇒ ouvre une 2e concordance quand on arrive sur la courbe “lui” ⇒ déplacement avec les flèches ⇒ met bien à jour l'une ou l'autre des concordances (NOTE: les comportements semblent un peu différents entre Win et Linux, notamment toujours sur ces questions de focus de composant UI)
autre idée : pouvoir ouvrir une édition à la place d'une concordance (par exemple avec un Alt-clic en complément du Double-clic) → pour naviguer dans l'édition à partir de la courbe plutôt que dans la concordance, c'est-à-dire privilégier d'emblée une lecture au contexte large.
variante : maintenir l'édition et pouvoir y naviguer quand on ferme la concordance qui a ouvert l'édition.
AL (2018-06-06)
Installation sous Ubuntu 16.04 : OK
2 répertoires sont créés : TXM_0.8.0 et TXM-0.8.0, mais c'est peut-être normal [MD: nope c'est corrigé, on utilise ”-” OK]
Messages de la console :
Warning: NLS unused message: common_structuralUnit in: org.txm.core.messages.messages
Warning: NLS missing message: common_strucutralUnit in: org.txm.core.messages.messages
Démarrage de TXM 0.8.0 (2018-06-05 13h38)...
Création de l'espace de travail utilisateur de TXM.
Chargement des sous-corpus et des partitions...Terminé.
Moteur statistique lancé.Connecté.
Prêt.
Chargement des sous-corpus et des partitions...Terminé.
Prêt.
Tentative de récupération des corpus 0.7.9 :
Bugs constatés :
menu Aide, dernière entrée intitulée ”%command.label.141” [MD : la chaîne était absente et l'entrée de menu mal placée OK]
corpus GRAAL et VOEUX : message “corpus not ready”, disparaît au 2e lancement
Tentative d'import XTZ :
Sauvegarde des paramètres d'importation...
Error: org/txm/importer/xtz/xtzLoader.groovy not found.
Extraction of ressource failed from /usr/lib/TXM-0.8.0/plugins/org.txm.groovy.core_1.0.0.201806051338.jar with path org/txm/importer/xtz/xtzLoader.groovy
Error: can't find import script in plugin resources: /home/.../TXM_0.8.0/scripts/import/xtzLoader.groovy
VL (02-07)
Concernant mon utilisation de TXM, j'ai tendance à procéder par “sauts de puce” et à accumuler de très nombreuses vues (concordanciers, index, etc.) durant une session (même courte). J'ai l'habitude de “sauvegarder” (en les exportant) uniquement les vues qui méritent un retour lors d'une session ultérieure. D'une session à l'autre, une persistance de toutes les vues représenterait pour moi un coût important :
en clics pour tout fermer et avoir un confort de travail dans ma nouvelle session ;
et en attention, puisqu'il s'agit de ne pas supprimer la vue qui m'intéresserait même si elle est noyée dans une liste de 40 vues.
Je n'ai pas pu faire le test avec des vues renommées (en raison du bug lié au renommage), mais je crois qu'il ne faudrait pas négliger le coût cognitif qui serait celui de l'utilisateur pour retrouver les éléments pertinents perdus dans une très (très) longue liste.
Est-ce qu'une sauvegarde par type de résultats serait éventuellement techniquement possible ?
Exemple : la sauvegarde d'une matrice lexicale apporte un grand confort et une sécurité intéressante pour l'utilisateur, qui a certainement passé du temps à la modifier (fusion des lignes, suppression, etc.).
A l'opposé, convoquer un concordancier nécessite un très faible investissement de l'utilisateur (sauf en cas de requête très - très- sophistiquée): on pourrait donc discuter de l'apport de la sauvegarde automatique de cette vue d'une session à l'autre…
[SLH 12/07] :
On peut inverser le scénario en effet : punaiser explicitement les résultats que l'on souhaite conserver, et ne pas recharger (oublier) les résultats non punaisés au prochain lancement
éventuellement proposer une nouvelle commande “Nettoyer les résultats [non punaisés]” appliquée à la hiérarchie d'un objet désigné dans la vue Corpus ou à toute la vue, pour clarifier la vue Corpus de tout ce qui n'a pas été punaisé
éventuellement proposer une nouvelle commande “Exporter les résultats” appliquée à la hiérarchie d'un objet désigné dans la vue Corpus, pour créer autant de fichiers d'export que d'objets punaisés
question subsidiaire : peut on imaginer d'exporter (ou sauvegarder) un résultat, ou une hiérarchie de résultats, au sens où on pourrait le reconstruire/recalculer dans TXM comme s'il avait été punaisé ? Est-ce que ça permettrait d'échanger des résultats de sessions de travail entre utilisateurs de TXM sur un même corpus, sous-corpus, partition, etc.
SJ: c'est techniquement possible mais on a actuellement une limitation qui est la récupération automatique du résultat parent, pour les corpus l'ID est/sera le CQP ID donc c'est bon mais pour les sous-corpus et partition c'est plus compliqué car le nom peut ne pas être le même sur 2 machines différentes
propositions:
ajouter une commande “greffer” un résultat qui tente d'importer un result sur le noeud où elle est appelée (et si elle “foire”, elle “foire” avec les messages qui vont bien)
utiliser un sha/md5/etc pour vérifier que le parent est compatible/unique (d'une manière générale ça peut aussi être intéressant pour comparer/authentifier différentes versions d'un corpus mais sur quoi faire la signature ?)
MD: la parenté des résultats est assuré par le noeud de préférence mais pas par le CQPID. La nouvelle commande cloner le résultat et ses descendants, correspond à la commande clone le résultat + greffer les descendants au clone
Oui on peut créer une liste de commandes à punaiser par défaut (nouvelle préférence ?) : sous-corpus, partition, table lexicale
SJ: je suis pour. Note dev: Etat actuel avant les vacances : “Store this result” via le context menu permet de définir un result en persistable. Préférence globale “Auto save results” qui passe tous les results en persistable dès qu'ils sont créés. Tous les résultats sont persistés, peu importe si l'option est cochée ou non ou si le user a forcé un store result ou non. Les results sont donc tous persistés et les results non persistés (et fichiers) sont effacés au shutdown de la toolbox. Choix actuel avec Matt pour récupération en cas de crash.
Cette section a été créée par SLH le 09/10/2018 pour la version TXM 0.8.0.1180 (de status alpha 2).
Attention : les installeurs de TXM 0.8.0 alpha 2 sont régulièrement mis à jour en fonction des retours. Pour connaître la version précise du TXM téléchargé et évalué, il faut regarder le numéro indiqué dans la console au démarrage.
Par exemple :
Démarrage de TXM 0.8.0.1180...Terminé.
Prêt.
Si le numéro mineur du TXM que vous évaluez est différent de 1180, merci de le préciser au début de chaque retour.
SJ (18/10/2018, Win64) :
BP (19/10/2018, TXM 0.8.0.1196) : Dans l'application d'installation d'ubuntu, le numéro de version indiqué est 0.7.9. Et après l'installation, je n'ai plus mon TXM 0.7.9 (l'icône a disparu du lanceur et quand je fais une recherche sur “txm” dans l'outil de recherche de programmes d'ubuntu, je n'ai que quatre 0.8.0 (alpha2 ou pas, Debug ou pas). Dans mon HOME j'ai trois répertoires : TXM, TXM-0.8.0, TXM-0.8.0a2. [MD OK j'ai écrasé TXM 0.7.9 lors de l'installation, c'est corrigé depuis]
BP (19/10/2018, TXM 0.8.0.1196) : il y a un certain nombre de messages d'erreur au premier lancement, dont concernant R
Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo.png'
Warning: image not found in 'org.txm.rcp' -> 'icons/logo/TXM logo 64x64.png'
Démarrage de TXM 0.8.0.1196...
Création de l'espace de travail utilisateur de TXM.
Terminé.
..........Rserve not started with /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. Trying with commons R installation paths (will works if Rserve, textometry and FactoMineR are installed).
....................Impossible de démarrer RServe.
org.txm.statsengine.r.core.exceptions.RWorkspaceException: ** Le chemin du programme du serveur statistique a été renseigné mais sa recherche a échoué dans : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R.
at org.txm.statsengine.r.core.RWorkspace.initRserve(RWorkspace.java:352)
at org.txm.statsengine.r.core.RWorkspace.startExec(RWorkspace.java:483)
at org.txm.statsengine.r.core.RStatsEngine.start(RStatsEngine.java:63)
at org.txm.core.engines.EnginesManager.startEngines(EnginesManager.java:98)
at org.txm.Toolbox.startEnginesManagers(Toolbox.java:531)
at org.txm.Toolbox.initialize(Toolbox.java:260)
at org.txm.rcp.ApplicationWorkbenchAdvisor$8$1.run(ApplicationWorkbenchAdvisor.java:1095)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
Prêt.
Installing sample corpus...
VOEUX.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file)
graal.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file)
Terminé.
2 corpus loaded.
TXM est prêt.
BP (19/10/2018, TXM 0.8.0.1196) : au second lancement et après redémarrage complet de la machine, les messages d'erreurs sont réduits mas il y a toujours le pb concernant R
Démarrage de TXM 0.8.0.1196...
Terminé.
..........Rserve not started with /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R. Trying with commons R installation paths (will works if Rserve, textometry and FactoMineR are installed).
....................Impossible de démarrer RServe.
org.txm.statsengine.r.core.exceptions.RWorkspaceException: ** Le chemin du programme du serveur statistique a été renseigné mais sa recherche a échoué dans : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R.
at org.txm.statsengine.r.core.RWorkspace.initRserve(RWorkspace.java:352)
at org.txm.statsengine.r.core.RWorkspace.startExec(RWorkspace.java:483)
at org.txm.statsengine.r.core.RStatsEngine.start(RStatsEngine.java:63)
at org.txm.core.engines.EnginesManager.startEngines(EnginesManager.java:98)
at org.txm.Toolbox.startEnginesManagers(Toolbox.java:531)
at org.txm.Toolbox.initialize(Toolbox.java:260)
at org.txm.rcp.ApplicationWorkbenchAdvisor$8$1.run(ApplicationWorkbenchAdvisor.java:1095)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
Prêt.
en tout cas il y a bien un fichier R au bout du chemin indiqué sur mon DD : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R
et c'est aussi le chemin réglé dans les préférences : /usr/lib/TXM-0.8.0a2/plugins/org.txm.statsengine.r.core.linux_1.0.0.1188/res/linux64/bin/R
BP (19/10/2018, TXM 0.8.0.1196) : on ne peut pas charger de binaires réalisés avec la 0.7.9, enfin on a un message d'erreur (ci-après), mais le corpus semble quand même disponible (information, édition, concordance, etc.).<code>
AFNOTICES-V2-2018-10-02.txm binary corpus is not a TXM 0.8.0 corpus (no .settings nor .project file)
</code> [MD OK j'ai ajouté un message qui confirme le format lu au chargement du corpus]
SLH (09/10/2018) : de façon générale, dans le menu contextuel des objets de la vue Corpus
AL (09/10/2018)
il n'y a plus de commande “supprimer”. Comment faire pour supprimer un corpus, un sous-corpus ou une partition ? Pour les résultats on peut décocher “Conserver” et relancer TXM, mais ce n'est pas très pratique
le bouton “conserver” est-il utile sur les corpus, sous-corpus et partitions ?
le renommage d'un corpus fonctionne et persiste - OK
BP (19/10/2018, TXM 0.8.0.1196) :
j'ai renommé un corpus, j'ai renommé et sauvegardé certains résultats, tout cela semble bien fonctionner.
je pense que le comportement “pas sauvé par défaut” est bien, et la notation étoilée pour signaler les résultats caduques.
BP (19/10/2018, TXM 0.8.0.1196) : les boutons pour naviguer dans les pages ne semblent pas actifs.
BP (19/10/2018, TXM 0.8.0.1196) : le nom de la commande est en anglais (idem pour : Sous-corpus, Partition, les commandes sous TreeTagger [MD : OK]
SLH (09/10/2018) :
Supprimer le bouton Compute ? [SJ: finalement il faut le laisser pour le mode non électrique, à cause du spinner VMAX]
l'appel successif de Propriétés sur un même corpus multiplie les résultats (icones enfant, dans la vue Corpus) : est-ce vraiment utile ? (comportement différent d'avant 0.8.0)
BP (19/10/2018, TXM 0.8.0.1196) (feature ?) : Il me semble que la commande s'appelait avant “Description”. Il faudra réfléchir à unifier la terminologie et à l'accorder avec l'icône (I → informations ?). Dans l'affichage des résultats, le titre est “détails” d'un corpus et “Dimensions” d'une partition.
SLH (09/10/2018) :
supprimer le bouton Compute (peut il avoir un rôle ?)<del>
* <del>MD: pour l'instant il est grisé et la toolbar est visible [SJ: j'ai supprimé le bouton mais la zone de toolbar reste visible (Win64), ticket :
https://forge.cbp.ens-lyon.fr/redmine/issues/2478 ]
BP (19/10/2018, TXM 0.8.0.1196) :
Si je veux saisir une Fmin (ou Fmax ou Vmax ou Résultats par page), je ne peux pas saisir deux chiffres d'affilée (la saisie du 2e chiffre part dans un autre champ en bas à droite de la fenêtre). Cela semble lié au mode électrique (le résultat est recalculé dès l'entrée du premier chiffre). [SJ: fixé]]
quand je double-clique sur un résultat précédent, son onglet ne revient pas sur le dessus dans l'affichage à droite.
MD: j'ai une ouverture très lente de la concordance qui peut donner l'impression que la concordance ne se re-ouvre pas [MD: OK le ralentissement était du à l'affichage du détail de la concordance dans la barre de status (message trop long)]
SLH (09/10/2018) :
l'appel de Spécificités ou de Table lexicale ne fonctionne pas, avec l'erreur :
<code>LexicalTable.canCompute(): can not compute with no unit property.
TXMResult.compute(): LexicalTable: can not compute, missing or wrong parameters or error with parent computing, computing aborted.
TXMResult.compute(): Specificities: failed to compute parent result.
TXMEditor.compute(): SpecificitiesEditor: computing failed.</code>
→ dans ce cas un objet TL sans label est créé dans la vue Corpus, est-ce nécessaire ?
SJ: malentendu ici, on a oublié de préciser quelque chose dans le mail, on génère maintenant des résultats vides pour les LT, Specifs, etc. l'utilisateur doit ensuite choisir la propriété avant que le calcul ne puisse être lancé
manque l'appel de la CAH
AL (09/10/2018) :
L'appel direct des commandes LT et Specif provoque l'erreur dans la console, mais si je double-clique sur l'objet et sélectionne une propriété, ça marche
MD corrigé en attente de test
SJ: malentendu ici, on a oublié de préciser quelque chose dans le mail, on génère maintenant des résultats vides pour les LT, Specifs, etc. l'utilisateur doit ensuite choisir la propriété avant que le calcul ne puisse être lancé
La commande Specificités est accessible à partir du menu contextuel, mais il n'y a pas d'icone correspondante dans la barre de menu
SLH (09/10/2018) :
la version du package FactoMineR provoque une erreur :
→
org.txm.statsengine.r.core.exceptions.RException: ** Erreur R : "Error : Ceci est R 3.2.3, le package ‘FactoMineR’ nécessite >= 3.3.0
"
lors de l'évaluation de : library(FactoMineR)
at org.txm.statsengine.r.core.RWorkspace.safeEval(RWorkspace.java:1424)
at org.txm.statsengine.r.core.RWorkspace.voidEval(RWorkspace.java:1559)
at org.txm.ca.core.statsengine.r.functions.FactoMineRCA.loadLibrary(FactoMineRCA.java:455)
at org.txm.ca.core.statsengine.r.functions.FactoMineRCA.<init>(FactoMineRCA.java:108)
at org.txm.ca.core.functions.CA._compute(CA.java:178)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1906)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1960)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1960)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1960)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1960)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1866)
at org.txm.core.results.TXMResult.compute(TXMResult.java:1825)
...
impossible de choisir les axes
le déplacement et l'extension de la sélection de lignes d'infos lignes ne fonctionne plus
pourquoi la police par défaut des labels de points dans les plans sont dans la police Abyssinica SIL ?
le raccourcis Ctrl-S sur l'icone résultat AFC ne fonctionne pas
à la ré-ouverture, le label textuel associé à l'icone a disparu
SLH (09/10/2018) :
AL (09/10/2018) :
SJ (18/10/2018) :
-- Building 'default' edition of 1 texts...
.Error: could not create /home/alavrent/TXM-0.8.0a2/corpora/IMMONDEPRK/txm/IMMONDEPRK/ImMondePrK.xml 'default' edition: javax.xml.stream.XMLStreamException: No element was found to write: java.lang.ArrayIndexOutOfBoundsException: -1
-- Building 'default' XSL edition with step 'html'...
Exception in thread "Thread-112" groovy.lang.MissingPropertyException: No such property: ApplyXsl2 for class: org.txm.scripts.importer.xtz.XTZPager
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:67)
at org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.getProperty(GetEffectivePogoPropertySite.java:87)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:310)
at org.txm.scripts.importer.xtz.XTZPager.doPostEditionXSLStep(XTZPager.groovy:312)
at org.txm.scripts.importer.xtz.XTZPager.process(XTZPager.groovy:54)
at org.txm.importer.xtz.ImportModule$2.run(ImportModule.java:164)
--- Copying subdirectories [xsl, css, dtd]
..
Terminé.
Retours issus de la réunion à Besançon du X/X/2018.
(calcul automatique des résultats à chaque changement de paramètre)
(calcul automatique des résultats enfants si on modifie un résultat parent, ex. : modifier une table lexicale va recalculer automatiquement une spécif et/ou une AFC qui est en dessous)
l'astérisque n'est vraiment pas intuitive (on croit que ce sont les résultats qui vont être conservés alors que c'est l'inverse) ⇒ repartir sur une bullet/puce lorsque l'on clique sur “Conserver”
TXM étant aussi un logiciel d'exploration, il y a plus d'“essais” que de choses à conserver ainsi la pref d'auto-sauvegarde ne devrait sans doute pas être activée par défaut
VL,
MB sont très intéressées par l'utilisation des annotations dans un futur très proche
SLH (31/10) : j'ai fourni par mail à VL toutes les infos disponibles sur les différents outils d'annotation à ce stade. Il faut voir comment organiser des retours éventuels :
[extrait du mail]
*Annotation URS en plein texte*
L'annotation URS de DEMOCRAT est en cours de validation par des utilisateurs, surtout des stagiaires de master, depuis début 2017.
L'extension Analec (qui doit être renommée 'Annotation URS') est suffisamment mûre pour être disponible pour TXM 0.7.9 depuis début 2018.
Sa documentation est désormais intégrée au manuel TXM :
http://textometrie.ens-lyon.fr/html/doc/manual/0.7.9/fr/manual53.xhtml#toc285
[ou http://textometrie.ens-lyon.fr/files/documentation/Manuel%20de%20TXM%200.7%20FR.pdf pour le manuel PDF]
Elle explique comment installer l'extension Analec et comment annoter en unités URS.
Elle est très perfectible, donc n'hésitez pas à faire des propositions.
Elle n'intègre pas encore la description de tous les outils d'exploitation des annotations URS disponibles, mais un certain nombre de recettes de validation les présentent déjà, comme celle-ci :
https://groupes.renater.fr/wiki/txm-info/public/spec_exploitation_annotation/spec_urs_mesures2#recette_33
Il y a également une section de proto-documentation dans une autre page du wiki du projet :
https://groupes.renater.fr/wiki/txm-users/public/umr_lattice/democrat/public/manuel_utilisation_extension_analec#exploiter_des_annotations_analec_avec_des_macros
Il y aura une dernière campagne de développement/consolidation de l'extension URS, dont le contenu est pratiquement établi ici :
http://forge.cbp.ens-lyon.fr/redmine/projects/txm/issues?query_id=64
[on devrait notamment aider à exploiter ces annotations avec les outils habituels de TXM]
*Annotation par Concordances*
L'annotation de séquences de mots par le biais de Concordances est disponible depuis TXM 0.7.9.
Documentée dans le manuel de TXM depuis 0.7.9 :
http://textometrie.ens-lyon.fr/html/doc/manual/0.7.9/fr/manual50.xhtml
Il y aura une troisième fonctionnalité d'annotation par Concordances dans TXM 0.8.0 :
- annotation/correction de propriétés de mots par le biais de Concordances
L'ALPHA 3 de TXM 0.8.0 permet de tester la correction de pos et de lemmes, ou de toutes autres propriétés de mots, par concordances dans les textes.
La démo a été faite sur Windows
mode électrique = la fin de saisie d'un champ (voir le scénario de décision de fin de saisie) déclenche le recalcul ou la maj du résultat
Discussion:
mode MD : les paramètres sont électriques après avoir lancé le calcul une première fois
ajouter des paramètres électriques groupés/complexes (ex : réglage du contexte de la cooc)
voir la notion d'arguments de résultats (changement de la requête) VS paramètres de résultats (affichage de chart) VS modifications de résultats (suppression lignes)
évolution du bouton (|>) pour qu'il drive le mode électrique : (|>) électrique → (||) non-électrique → (|>) électrique
ajouter une préférence pour activer ou pas le (ou la tentative pour être + précis) calcul d'un résultat à l'ouverture dans son éditeur
Recalcul automatique alpha3 =
tous les paramètres d'un résultat sont modifiables
le résultat est recalculé entièrement seulement pour certains paramètres
tous les descendants d'un résultats sont alors recalculés
si un enfants modifie le paramètre de son parent, alors ses frères (et descendants) seront recalculés (AFC, Spécificités, CAH)
justifications :
Recalcul automatique MD =
tous les paramètres d'un résultat sont modifiables
le résultat est recalculé entièrement seulement pour certains paramètres
tous les descendants d'un résultat sont alors recalculés
les résultats intermédiaires ne sont pas affichés (ne sont donc pas re-paramétrable et n'ont qu'un seul descendant)
un enfant ne modifie pas de paramètre de son parent sauf si il est enfant unique et que son parent n'est pas visible (ex : AFC crée depuis une partition, la LT n'est pas affichée)
justifications :
Recalcul automatique SLH =
Recalcul automatique BP =
dès qu'un résultat a des enfants les paramètres ne sont pas modifiables
un enfant ne modifie pas de paramètre de son parent
pour faire une variante d'un calcul, on le clone sans ses descendants
justifications :
les calculs propagés ne sont a priori pas toujours bien définis (typiquement dans le cas du changement de la propriété d'analyse lorsqu'on travaille sur une sélection, par ex. passage de graphies en lemmes ou réciproquement). Du coup ce n'est pas clair : quelquefois on ne fait rien ? ou on fait quelque chose d'incomplet, d'approximatif ? comment l'utilisateur pourra-t-il comprendre ce qui s'est passé ? si on fait quelque chose de simplifié, n'aurait-il pas mieux valu que l'utilisateur le fasse lui-même (pas compliqué et meilleure perception du traitement) ?
le recalcul automatique met à jour des résultats intermédiaires dont la pertinence n'est pas vérifiée par l'utilisateur : l'utilisateur ne perçoit pas forcément la portée de sa modification, or il est important de bien maîtriser toute la chaîne de traitements pour interpréter le résultat, cf. ex. du choix de conception d'Hyperbase qui obligeait l'utilisateur à calculer et afficher les contextes des mots dont on allait ensuite repérer les cooccurrents (fonction Thème).
de même avec cette portée très puissante, il y a vraiment le risque d'écraser des résultats précédents, des intermédiaires, qu'on voulait garder (ex. retouche de l'AFC ⇒ on perd la table lexicale qu'on avait retravaillée en fusion/suppression de lignes, sans forcément s'en rendre compte…). Et on n'a pas de de fonction annuler (défaire, retour arrière, contrôle-z).
le clonage d'un résultat pour le modifier est de toutes façons utile à prévoir (cas de figure où on veut tester plusieurs variantes en parallèle pour les comparer).
le principe de cohérence qui voudrait appliquer une rétropropagation voudrait remplacer le chemin suivi par un autre chemin, analogue mais réajusté. Cependant, c'est un chemin artificiel. Ce qui a du sens c'est le “vrai” chemin, qui correspond à des étapes choisies, comprises et parcourues. A l'utilisateur de décider s'il veut recommencer autrement (et construire lui-même un autre chemin). Une question est alors plutôt la manière de rendre compte au niveau de l'interface du chemin suivi (par ex., faut-il marquer le lien entre des clones et comment ?).
Solution :
Que faire des modifications manuelles de résultat (ex: suppression de lignes dans la concordance et table lexicale) ?
Solution :
oublier les modifications à la fin de la session (Alpha 3)
sauver/charger automatique entièrement le résultat (pas que les paramètres
export/import à la demande (cas table lexicale)
ajouter une propriété interne aux objets pour coder la suppression (= les manipulations sont enregistrées)
Toolbar des éditeurs
augmenter le contraste des boutons : surtout Windows, par exemple le bouton “paramètres” de la toolbar des TXMEditors quand le bouton est activé
déplacer le bouton “Play” à la fin des boutons de la toolbar des éditeurs
auto-documentation de l'interface
prioritaire : vérifier que tous les flyover soient corrects
éventuellement : renseigner les titres de boutons et ajouter une préférence pour activer l'affichage des titre de boutons dans les toolbars des TXMEditors (ex : le bouton compute (|>) → Calculer (|>))
améliorer l'ergonomie du widget PropertiesSelector (le label “editer” sur le bouton prête à confusion)
prioritaire : “Editer” → ”…”
prioritaire : “Propriétés :” → “Propriétés”
éventuellement : scénarisation en widget extension de combo (pour gérer l'ordre de la sélection) : lorsque l'on clique sur la flèche v, une pop-up est ouverte (comme dans le portail)
connaître les paramètres d'un résultat :
confusion sur le role des boutons “Tri” et “Search” des concordances
amélioration des éditions
améliorer la relation entre la vue Corpus et les éditeurs
La synoptique du Graal est cassée ?
La saisie d'un caractère au clavier dans les spinners déclenchent un compute<del/> [SJ: fixé]
* <del>résolution : il y a des différences de comportement entre les OS à gérer
la liste des propriétés de corpus est modifiée (la propriété word a été retirée) par un des éditeurs
la maj de la courbe et de la légende de la progression ne fonctionne pas si on retire une requête [SJ: fixé]
la sélection d'une requête de l'historique du widget de requête ne déclenche pas de recalcul (mode électrique)
le bouton “tri” de la concordance ferme la zone des paramètres [SJ: fixé]
les boutons de navigation dans les pages de la concordance ferment la zone des paramètres [SJ: fixé]
déplacer la préférence “toujours conserver les nouveaux résultats” dans la page Utilisateur (plutôt que Avancées) [SJ: fait]
A faire
Paramètres électriques
préférence de 2 modes de lancement de calcul : “électrique” et “manuel” → manuel par défaut
séparer les paramètres électrisables des autres paramètres (arguments)
les paramètres électrisables sont souvent des paramètres d'affichage mais ce n'est pas une condition suffisante (ex: fmin)
Problématiques de chaque mode :
Électrique
décision de la fin de saisie (entrée, perte/prise focus, etc.)
changement d'ordres de grandeur (ex: cooc avec contexte de structure)
voir les paramètres qui ont été utilisé avec une vue / tooltip éditeur / commande propriétés / …
Manuel
rendre compte que les paramètres ont été modifiés
avec enable/disable du bouton compute
“*” dans l'onglet de l'éditeur
Cas particulier des sous-corpus et partition qui sont toujours old-style
Recalcul automatique en cascade
préférence de 2 modes de recalcul des résultat enfants : “automatique” et “manuel”
commande manuel “Recalculer les résultats”
Problématiques de chaque mode :
automatique
les résultats sont maj sans que l'utilisateur vérifie les données utilisée (il faut le faire après coup)
maîtriser les temps de calcul
difficultés pour mesurer l'impacte sur les résultats frères
manuel
Question subsidiaire : que faire des résultats sauvés après une maj de corpus ? → problématique de validation des données
Paramètres déportés
solution :
si oui → certains résultats
si non → lorsque l'on créé une AFC, afficher une LT et AFC vides dans la vue corpus et ouvrir l'éditeur de la LT pour la configurer
Problématiques de chaque mode :
scénarios :
modifier la propriété LT depuis AFC/Spécifs
modifier fmin de LT depuis AFC/Spécifs
modifier vmax de LT depuis AFC/Spécifs
passer en illustratif un point de AFC depuis la spécifs
Supprimer/merger lignes/colonnes depuis AFC/Spécifs
Supprimer/merger parties de la partition depuis AFC/Spécifs
cas particuliers des résultats modifiés manuellement :
LT avec des lignes supprimées/mergées
concordance avec des lignes supprimées
corpus mis à jour en sauvant les annotations de la concordance
Persistance des résultats
Préférences 2 modes de persistance : “tout nouveau résultat” / “manuelle” → MANUELLE PAR DÉFAUT
“tout nouveau résultat”
“manuel”
Les modifications manuel de résultat ne sont pas conservées (au démarrage, au recalcul du résultat)
Scénarios :
Dans TXM 0.5, modifier la requête CQL créé une nouvelle concordance, à partir de TXM XX, la concordance est éditée sur place
Stylage des objets de la vue corpus
États :
persisté : rien par défaut
non-persisté : italique
éditeur ouvert&premier plan : gras
non-rechargé : rien par défaut
dirty : étoile
voir la possibilité dans les préférences les stylages disponibles : rien / gras / italic / grisé / étoile / punaise / bullet
BP (29/10/2018, TXM 0.8.0.1216) : tout semble bien se passer ;
sous le HOME je n'ai pas un répertoire TXM-0.8.0a3 mais un répertoire TXM-0.8.0 (qui a écrasé au moins en partie le répertoire du même nom précédent) (il me reste aussi un répertoire TXM-0.8.0a2).
pas de message d'erreur pour l'installation de R (comme j'avais eu en 0.8.0 alpha 2), et de fait j'ai pu calculer des cooccurrences.
AL (30/10/2018, TXM RCP 0.8.0.1216)
En fait on ne voit pas le “Terminé” si la ligne de points est longue.
cependant l'annotation par TreeTagger ne fonctionne pas car 'd'après la console) le modèle de langue cherché est “FR.par”, or dans l'aide à l'installation de TreeTagger on demandait de nommer ce modèle “fr.par”.
Error: No Modelfile available for lang /usr/lib/treetagger/models/FR.par. Continue import process
par ailleurs le contenu par défaut de la description de l'import est “The source directory contains the sources files.” au lieu du nom de l'utilisateur, de la date, etc. comme dans d'autres imports ; et une fois l'import effectué, dans la description du corpus, on a la mention initiale “Build the alceste import module” (comme si le contenu du champ n'avait pas été utilisé de toutes façons ?) → cela gagnerait à être ajusté à l'occasion.
la tokenisation ne semble pas utiliser les caractères d'élision ? : dans le paramètre d'import, j'ai l'apostrophe simple ”'” qui est déclarée comme caractère d'élision, dans mes sources si je cherche ce caractère qui est dans les paramètres d'import, il correspond bien aux apostrophes du texte initial ; mais dans mon corpus TXM si je cherche .+'.+ je n'ai aucun résultat, alors que si je cherche .+'.+ je trouve “c'est”, “qu'il”, “j'ai”, “l'Europe”, “aujourd'hui”, “l'ensemble” etc.
* GL (2018-12-11, TXM 0.8.0.2018 10191541?)
Outside-text-to-edit: TEIheader
Milestones elements: <pb/>
Si on tente un import avec un répertoire qui contient déjà un import.xml, en modifiant certains paramètres, par exemple le nom, il me semble que l'import échoue. Exemple de message obtenu :
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Error: import not correctly ended. See console messages.
Done.
TXMResult.compute(): Project: computing failed.
(on aimerait bien savoir où se trouvent les 'console messages' !)
En faisant un nouveau test, après avoir éliminé le fichier import.xml, l'import se termine normalement.
SJ (2018-11-23)
plantage si l'index n'a qu'une seule ligne de résultat et que l'on choisit “Total toutes les occurrences recenses par l'index”.
faire un index de partition sur VOEUX et “lui”, créer une table lexicale avec l'option “Total toutes les occurrences recenses par l'index” ⇒ plantage R
Au passage je trouve les textes des 2 options pas très explicites
premier problème de compute en cascade ⇒ que faire des résultats enfant d'un index de partition lorsque la requête est changée ?
changer la propriété d'une table lexicale créée depuis un index sur partition ne fait rien. La table est toujours recréée depuis l'Index parent. Modifier l'Index modifie la table ⇒ à discuter, quel doit être le comportement ?
discuter des liens entre ces 2 types de résultats. Problème notamment de l'index qui peut avoir 2 propriétés alors que la table lexicale non.
supprimer la commande “Table lexicale” sur Index qui ne vient pas d'une partition au lieu de proposer la dialog box qui va inexorablement pointer vers une erreur [SJ: OK]
AL (2018-10-30, TXM 0.8.0.201810191541)
BP (05/11/2018, TXM 0.8.0.1216)
Si je modifie la propriété d'affichage du pivot cela modifie aussi, et de la même manière, la propriété de tri du pivot. Je n'arrive pas à dissocier les deux, à mettre une autre propriété de tri. [MD OK fixed]
AL (2018-10-30, TXM 0.8.0.201810191541)
Impossible de charger correctement le corpus VOEUX donné dans le lien de la recette (probablement, parce que le fichier est nommé “voeux-bin”, cela provoque la création de deux répertoires binaires, le corpus n'est pas utilisable)
Si j'utilise le corpus VOEUX livré avec TXM, impossible d'enregistrer les modifications, car le corpus n'a pas été créé avec le module XTZ. Il faut reformuler la recette !
Tentative d'annotation sur un corpus importé avec XTZ (ALEXISRAM)
requête [cattex-pos=“ADJ.*”] [cattex-pos=“NOM”]
pour les 6 premières occurrences, je remplace la valeur par “TEST”
j'enregistre la concordance
la requête [cattex-pos=“TEST”] donne 12 résultats. L'étiquette a donc été modifiée pour les 2 mots du motif. Est-ce le comportement normal ?
erreur d'encodage de caractères dans la liste déroulante des types d'annotation (”?” au lieu de “é”)
BP (05/11/2018, TXM 0.8.0.1216)
Je trouve intéressante la présentation unifiée de l'annotation dans la concordance (le même crayon donne accès à l'annotation sur les mots ou sur les séquences de mots).
Quand on fait une sélection multiple de lignes (controle + clic gauche), à chaque nouveau clic l'affichage se repositionne au début de la concordance.
Quand j'annote les mots,
j'ai édité le nom de la catégorie (dans l'idée d'ajouter une propriété que j'ai appelée “meteo”), mais quand j'ai appliqué mon annotation elle s'est enregistrée dans frlemma. Il me semblait qu'on pouvait ajouter de nouvelles propriétés (et pas simplement rectifier les valeurs de propriétés existantes), je me trompe ?
je suis toujours en difficulté pour corriger à la fois la POS et le lemme sur une sélection, car le bouton “OK” qui valide la correction porte sur une seule propriété, et après cette première validation la sélection est perdue pour pouvoir faire la seconde. (Mais je n'avais pas encore lu la recette qui indiquait de cliquer tout de suite sur le 2e OK.)
après avoir enregistré mes modifications (par deux corrections successives), quand je recherche les occurrences avec les valeurs de propriété que j'avais modifiées, seule la propriété frlemma semble avoir été modifiée (les modifications sur frpos semblent perdues), et cela seulement sur la première occurrence corrigée (et pas pour les 6 autres lignes que j'avais sélectionnées en même temps).
après avoir relu la recette, je recommence ma correction en cliquant cette fois-ci sur le OK de la 2e ligne (qui est dans mon cas frlemma). Je n'observe de modifications que sur les valeurs de frlemma, que ce soit dans l'affichage ou en recherchant les occurrences après sauvegarde des annotations. La modification de frlemma est bien prise en compte pour les 6 occurrences.
Quand j'annote des séquences de mots (qui ne sont pas dans la recette, donc c'est peut-être hors-sujet pour ces retours),
j'ai pu poser et interroger des annotations simples de type catégorie, ainsi que des annotations typées (catégorie/valeur) (au début je croyais que le 2e type ne fonctionnait pas car j'interrogeais sur <span_meteo=“favorable”>[]+</span> au lieu de <meteo_ref=“favorable”>[]+</meteo>)
je me demande si ce ne serait pas plus simple de ne proposer qu'un seul type d'annotation de séquences, qui soit typé ? (Mais il esttrès possible qu'il y ait des considérations qui m'échappent, il faudrait savoir pourquoi on propose ces deux types).