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) :

1. 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) :

1. '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…']
2. 'Fichier > Importer' : mettre un séparateur devant 'CQP' [qui se distingue du reste]
3. 'Fichier > Importer > CNR+CSV' → 'Fichier > Importer > Cordial+CSV' [pour être homogène avec Alceste, Hyperbase, etc.]
4. 'Fichier > Nouveau fichier' → 'Fichier > Nouveau…'
5. 'Fichier > Changer la langue' → 'Affichage > Changer la langue'
6. toolbar des perspectives :
   1. nommer Corpus ou C le bouton de la perspective Corpus [comme le bouton de la pers. R se nomme R]
   2. mettre un flyover “ouvrir la perspective Corpus' sur le bouton de la perspective Corpus
      • MD: ok j'ai renommer la perspective en “ouvrir la perspective Corpus”, ce qui affiche le bon tooltip
   3. mettre un flyover “ouvrir la perspective R' sur le bouton de la perspective R
      • MD: ok j'ai renommer la perspective en “ouvrir la perspective R”, ce qui affiche le bon tooltip
7. toolbar :
   1. flyover 'Créé [sic] un nouveau fichier' → 'Éditer un nouveau fichier'
   2. flyover 'Ouvrir un fichier ()' → 'Ouvrir un fichier'
      • SJ: je pense que les parenthèses sont dûes à un mnemonic vide mais je ne trouve pas la définition
      • MD: il restait un paramètre de commande vide qui provoquait l'affichage des parenthèses ”()”

VL (02-07) Dans le menu, serait-il possible d'harmoniser les langues utilisées ?

1. “Internal view” pourrait devenir “Vue interne” ; [SJ: fait]
2. “Sub-corpus” pourrait devenir “Créer un sous-corpus” ou “Sous-corpus”;
3. “Create partition” pourrait devenir “Créer une partition” ou “Partition”;
4. “Rename” pourrait devenir “Renommer”

• [SLH, 12/07] : nous sommes en train de finaliser le nouveau workflow de finalisation/correction/traduction des chaines de l'interface utilisateur

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

• BP : la sauvegarde n'a pas fonctionné
  • MD : j'ai fait des corrections + vérifications
    • SJ: toujours buggé pour l'annotation par Mots, la sauvegarde ne fonctionne pas + les messages de l'UI ne sont pas en UTF-8, donc probs d'accents, etc.

SJ :

1. 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.
     • il faudrait préciser commande par commande, paramètre par paramètre si auto-compute ou pas ?
2. tri multiple par défaut ou pas ?
   • MD: L'interface n'est pas prête pour ça, mais on peut peut-être le faire juste quand on tri sur l'indice :
     • Indice puis Cofréquence puis Fréquence ?
3. a faire : tri par défaut : Indice décroissant
   1. MD: OK c'est déjà le cas

SLH (07/06/2018) :

1. commande Lexique : - on change la propriété → le nom de la colonne change mais le contenu et la fréquence restent 'word' [SJ: fixé temporairement, voir http://forge.cbp.ens-lyon.fr/redmine/issues/2398]
   • SJ : on ne peut pas réouvrir un lexique par double-clic [en attente de voir si on refont ou pas les 2 classes Lexicon/Index] [SJ: fixé par MD mais la refonte du lexique n'est pas complètement terminée, voir ticket]

VL (02/07) :

1. 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é]
2. Si on tente de forcer la requête [word="\""], message d'erreur

SJ:

1. 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:

1. 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) :

1. la toolbar est cool
2. la possibilité de régler en temps réel les paramètres montre qu'une Vmax à 100 par défaut est probablement mieux
3. 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
   • MD: j'ai retiré les ”:” des principaux paramètres
4. le bouton Apply pour chaque property [du corpus] c'est sûrement too much → un seul bouton Apply ou Save bien situé
5. il faut en plus à côté un bouton Cancel, équivalent au re-clic sur 'edit properties' qui ferme la zone
6. 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)
   1. SJ: je propose d'utiliser le même bouton que pour les annotations
7. le changement du nom du corpus c'est très cool → faudra mettre le ticket à ~100%
8. dans la toolbar, il faudrait donner un aspect [bouton] à Compute et à 'edit properties', comme c'est le cas pour Parameters
9. 'edit properties' → 'corpus properties' ou 'properties'
10. 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, 31/07] mise à jour du message français, calque de la version anglaise :
      • FR: “La requête {x} est déjà représentée dans le graphique par une courbe. Veuillez utiliser une autre requête.” [SJ: fixé]

SLH (08/06/2018) :

• actuellement dans la progression, le contenu du label fixe (en haut à gauche dans ma figure)

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
  • (La recette ne dit pas s'il faut fermer TXM 0.7.9 avant l'installation, il était fermé)
• 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.
  

  • MD: faute de frappe OK
• Tentative de récupération des corpus 0.7.9 :
  • Commande Fichier > Charger > un répertoire de corpus binaires : OK
• 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 

AL (2018-06-06)

• Import (menu accessible, mais ne fonctionne pas)
• Chargement : * <del>corpus binaire : OK
  • répertoire de corpus : OK
• Vue corpus
  • Renommage de corpus : OK, mais le titre de l'onglet “Description” ne change pas (même si on on appelle la commande sur un corpus après le renommage), après redémarrage de TXM le corpus reprend son nom d'origine, la modif de la description persiste
  • Modif Vmax OK, mais il semble y avoir une limite non explicitée sur le nombre de propriétés (20 ?) [SJ: devenu obsolète ? à checker]
    • SJ: actuellement le max semble être 100, est-ce normal ? [MD : OK c'était la valeur par défaut du widget, on peut monter à 1000 si 100 est la valeur par défaut]
• Progression
  • Ajout de requêtes : OK, modification des réglages : OK, sauf
    • ajout de structures : le graphique n'affiche plus rien, il faut modifier un autre réglage pour que tout se remette en place [SJ: fixé]

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.
      • nécessite discussions pour les noms de commandes et préférences et UI pin/coche/etc
      • nécessite discussions et devs pour la récup 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) :
  • au premier démarrage, l'installation des corpus d'exemple devrait se faire avec une progress bar modale car là TXM semble prêt alors qu'il ne l'est pas. L'interface est accessible alors que des processus cruciaux sont encore en cours d'exécution [SJ: ticket https://forge.cbp.ens-lyon.fr/redmine/issues/2429#change-7046]
  • manque un fichier :
    • !ENTRY org.eclipse.jface 4 0 2018-10-18 16:34:24.062 !MESSAGE /icons/functions/save.png !STACK 0 java.io.FileNotFoundException: /icons/functions/save.png [MD: OK les icones de org.txm.annoattion.kr.rcp n'étaient pas exportés]
  • bug de Theme toujours présent :

    • !ENTRY org.eclipse.e4.ui.css.swt.theme 4 0 2018-10-18 16:31:19.787
             !MESSAGE 
            !STACK 0
            java.net.MalformedURLException
        	at java.net.URL.<init>(URL.java:627)
       	at java.net.URL.<init>(URL.java:490)
      	at java.net.URL.<init>(URL.java:439)
      	at org.eclipse.e4.ui.css.core.impl.engine.AbstractCSSEngine.parseStyleSheet(AbstractCSSEngine.java:211)
      ...
              Caused by: java.lang.NullPointerException
      	at java.net.URL.<init>(URL.java:532)
      	... 29 more

• 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
  • mettre Conserver devant Renommer…
    • MD corrigé en attente de test [SJ: OK]
  • mettre un séparateur devant Préférences
    • MD corrigé en attente de test
      • SJ: OK testé mais je pense qu'il faudrait virer cette entrée de menu, d'autant plus qu'elle ne pointe même pas vers les prefs de la commande
• 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
    • MD corrigé en attente de test
      • SJ: OK testé. En revanche pour le menu global, l'entrée apparaît dans “Corpus” ⇒ bug ?
        • MD: non
        • SJ: c'est vraiment bizarre que pour supprimer un résultat on doive faire “Corpus\Supprimer” ?
  • le bouton “conserver” est-il utile sur les corpus, sous-corpus et partitions ?
    • MD corrigé en attente de test [SJ: OK]
  • 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.
  • SJ: je confirme, bug sous Win aussi [SJ: fixé]
• 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)
    • MD corrigé en attente de test* [SJ: OK]

• 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 : l'idée est de généraliser cette commande à tous les objets de la vue Corpus tout en s'alignant sur la terminologie usuelle des explorateurs de répertoires et fichiers des systèmes d'exploitation. La terminologie devrait être “Propriétés [du corpus]|[de la partition]|…” pour tous les objets.

• 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 ]

• SLH (09/10/2018) :
  • mettre le bouton Compute à droite du bouton Paramètres → mettre le bouton Compute systématiquement à l'extrémité droite de toutes les fenêtres résultats ?

• 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.
    • SJ: non reproductible sous Windows
• 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)]

• BP (19/10/2018, TXM 0.8.0.1196) :
  • Quand on lance (crée) une nouvelle concordance (un nouvel onglet), on a un message d'erreur, qui pourrait être lié au mode électrique.<code> oncordance.canCompute(): Query is not set or empty. TXMResult.compute(): Concordance: can not compute, missing or wrong parameters or error with parent computing, computing aborted. TXMEditor.compute(): ConcordanceEditor: computing failed. </code>
    • SJ: il s'agit seulement du log, on devrait passer ce message en warning
  • Si on a 8 lignes de concordance, l'affichage de la pagination indique 1-9 / 8 ; si on a 139 lignes, la page 1 affiche 1-100 / 139, et la page 2 101-140 / 139.
    • MD OK on a du le corriger entre temps<del/> * Si j'édite les annotations des mots et que je veuille modifier à la fois le lemme et la pos pour une même sélection de lignes, je n'arrive pas à appliquer les deux modifications en même temps, et je n'arrive pas non plus à garder la sélection de lignes pour les opérer successivement. * Dans le menu contextuel, plutôt que “Options d'affichage des contextes” (ce qui était déjà le cas avant) cela me paraîtrait plus clair d'avoir “Taille des contextes”. ===== Commande Cooccurrence ===== * <del>SJ (18/10/2018) :
  • la commande ne fonctionne pas. Par ailleurs il y a 2 appels à compute() successifs. [SJ: fixé dans l'alpha3]

• SJ (25/10/2018) :
  • la commande ne fonctionne pas depuis un sous-corpus, Specificities.getPartShortNames() essaie de récupérer les noms depuis une partition parente [MD OK j'ai simplifié le code interne qui était trop compliqué à gérer]

• SLH (09/10/2018) :
  • il y a un sélecteur de moteur (menu avec 'CQP' par défaut) devant la saisie de la requête, mais concordances, cooccurrences, etc. n'en ont pas → le retirer temporairement de l'index ou le mettre à toutes les commandes
    • MD corrigé en attente de test [SJ: OK]
• AL (09/10/2018) :
  • L'appel de la commande devrait placer le curseur dans le champ de saisie de requête, comme c'était le cas dans les versions précédentes
    • MD corrigé en attente de test [SJ: OK]
• BP (19/10/2018, TXM 0.8.0.1196) :
  • comme dans le Lexique, on ne peut pas saisir deux chiffres dans les seuils, le calcul se relance dès la saisie du premier et le second par dans un autre champ (requête). [SJ: fixé]

• BP (19/10/2018, TXM 0.8.0.1196) : simple OK, avancée OK.

• 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
    • MD corrigé en attente de test [SJ: OK]
• 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
    • MD corrigé en attente de test [SJ: OK]

• BP (19/10/2018, TXM 0.8.0.1196) :
  • simple OK
  • assistée : instable ?
    • la fenêtre de construction disparaît quand je crée la 4e partie qui aurait sans doute du s'afficher sur une 2e ligne. Le cube de partition apparaît dans la vue Corpus : la partition semble disponible mais seulement avec les 2 premières parties.
    • j'essaye de reproduire le bug, je recommence la création de la même partition en lui donnant un nom différent. Tout se passe bien jusqu'à la création de la 5e et dernière partie, je crois que c'est au moment où j'affecte les valeurs dans la partie que la fenêtre explose. La partition est créée mais ne compte que 4 parties.

• SLH (09/10/2018) :
  • manque l'appel de Propriétés
    • SJ: nouvelle commande ? que doit-elle faire ?
      • SLH : la même chose que pour Partition, dans un premier temps, en affichant également les marges des index. [SJ: ticket : http://forge.cbp.ens-lyon.fr/redmine/issues/2479]
  • manque l'appel de Spécificités
    • MD corrigé en attente de test [SJ: OK]
  • manque l'appel de l'AFC
    • MD corrigé en attente de test [SJ: OK]
  • manque l'appel de la CAH
    • MD corrigé en attente de test [SJ: OK]

• SLH (09/10/2018) :
  • manque l'appel de Propriétés → même traitement que pour Partition [SJ: ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2485]
  • manque l'appel de CAH
    • MD corrigé en attente de test [SJ: OK]

• 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)
    	...

    • SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ?
  • impossible de choisir les axes
    • SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ?
  • le déplacement et l'extension de la sélection de lignes d'infos lignes ne fonctionne plus
    • SJ (18/10/2018) : tout fonctionne sous Win chez moi, Matt tu peux investiguer sous Linux ?
  • pourquoi la police par défaut des labels de points dans les plans sont dans la police Abyssinica SIL ?
    • SJ: à creuser, pouvez vous me donner le nom d'une police UTF-8 embeded dans Linux ?
  • le raccourcis Ctrl-S sur l'icone résultat AFC ne fonctionne pas
    • SJ: non reproductible ici
      • SJ: en fait il s'agit peut-être d'un bug général ⇒ si la vue corpus n'a pas le focus, le raccourci CTRL+S ne fonctionne sur aucun des résultats
  • à la ré-ouverture, le label textuel associé à l'icone a disparu
    • SJ: précision: à la réouverture de session ⇒ bug de lazy name [SJ: fixé, il y avait également le même bug dans la Table Lexicale]

• SLH (09/10/2018) :
  • ajouter Return sur point sélectionné comme raccourci clavier de double-clic sur un point (ouverture de concordance) [SJ: fait]
• AL (09/10/2018) :
  • L'appel direct de la commande sur un corpus provoque l'erreur “can not compute with no query”
    • SJ: il s'agit seulement du log, on devrait passer ce message en warning
  • Les labels de progression sont en crochets (doubles crochets si la requête CQL en a déjà.
    • SJ: tu parles bien de crochets ou bien de guillemets ? on a un léger souci en ce moment sur la restauration des requêtes, les requêtes basiques du type : faire - sont sauvées de manière interne en : “faire” et à la restauration on a donc les guillemets
• SJ (18/10/2018) :
  • passer en mode densité ne fonctionne pas [SJ: fait, force le passage en mode R]

• AL (09/10/2018) :
  • Testé le corpus IMMONDEPRK : Tout se passe bien jusqu'à l'étape de production de l'édition

-- 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é.

• MD corrigé en attente de test
• L'import écrase sans avertissement un ancien corpus avec le même d'origine s'il a été renommé.
• MD OK

Retours issus de la réunion à Besançon du X/X/2018.

(calcul automatique des résultats à chaque changement de paramètre)

• rendre toutes les commandes électriques semble une bonne chose du point de vue des utilisateurs
  • voir ensuite si on peut maintenir cela techniquement
• remarques :
  • si on décide de rendre des commandes électriques et d'autres non électriques, on pourrait mettre un Bouton Toggle sur chaque commande pour activer ou non le mode électrique ou non + pref globale par commande
    • SLH (31/10) : ça ne me semble pas bon parce que ça voudrait dire que certaines commandes ne fonctionnent pas bien en électrique, par design. Auquel cas autant ne pas faire d'électrique du tout. Par contre, on peut faire un paramètre global unique “Activer le mode électrique [oui/non]”, ce qui serait utile par exemple comme paramètre de corpus pour le grands corpus qui supporteraient mal les commandes électriques
  • même si on rend toutes les commandes électriques, ce bouton et les prefs globales par commandes pourraient être utiles ?
    • SLH (31/10) : je ne comprends pas la remarque. Ça correspond à mettre toutes les commandes électriques par défaut et permettre d'en débrancher à la demande, ce qui revient au cas de départ
  • on pourrait aussi utiliser un code couleur pour électriques/non électriques
  • changer code couleur des commandes électriques ou non (titre onglet ou background color ? ou autre ?)
  • la cooccurrence semble une commande pouvant être longue à paramétrer donc peut-être que le mode électrique n'est pas adapté ?
    • si on reste en électrique et à propos de la remarque de BP :
      • faire une pref d'hampan pour word, ex. tailles des contextes à 10
        • SLH (31/10) : une valeur par défaut comme préférence globale ?
      • faire une pref d'hampan pour structure, ex. tailles des contextes à 1
      • changer la taille lorsque l'on passe de word à structure et vice versa
        • SLH (31/10) : cela veut dire qu'il y a de la dépendance entre paramètres dans leur saisie. Y-a-t'il des précédents dans TXM ?
  • attention : mettre une pop up au changement d'unité structurelle de la Table Lexicale si elle a été modifiée (lignes supprimées, fusionnées, etc.) pour prévenir l'utilisateur qu'il va perdre ses changements ou bien lui proposer d'exporter la table
    • SLH (31/10) : changement de propriété de mot plutôt ?
      • c'est valable pour tout changement de nature d'une table issue de Table lexicale, Index de partition etc. après édition de cette table
      • la proposition d'export ou de sauvegarde rejoint la problématique du recalcul d'une table lexicale éditée

(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)

• le maintien de la cohérence de la branche de résultats semble très utile, recalcul ascendant, descendant et des noeuds frères
  • à confirmer après la prise en main de l'alpha

• 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”
  • SLH (31/10) : dans ce cas comment différencier les résultats temporaires non sauvegardés (sans marque) des résultats persistents de sessions précédentes (sans marques)
• 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
  • SLH (31/10) : ça devrait déjà être le cas dans l'ALPHA 3

• 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

• scénarios électriques exprimés:
  • BP : certain paramètres ne sont pas électriques
    • il faut discuter de ces paramètres
  • SJ : tous les paramètres sont électriques
• solution
  • ajouter une préférence pour activer/désactiver le “mode tout électrique” (mode SJ) des paramètres de résultats
    • par défaut : désactiver ? (à cause des gros corpus ? à discuter ?)
  • recenser tous les paramètres non-électriques (BP)
  • finaliser le scénario

Discussion:

• mode MD : les paramètres sont électriques après avoir lancé le calcul une première fois
  • BP : c'est plus souvent pertinent qu'au début (on est plus souvent dans un scénario de retouche et ajustement) mais ce n'est quand même pas toujours le cas.
• 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 :
  • MD (à reformuler) la propagation est totale, il n'y a pas de désynchronisation entre les résultats

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 :
  • MD (à reformuler) on limite la propagation

Recalcul automatique SLH =

• reprend le mode Alpha3 ou MD et ajoute :
  • on peut geler un résultat et sa descendance à la demande
  • un parent ne peut pas modifier un descendant gelé
  • pour faire une variante d'un calcul gelé, on le clone sans ses descendants

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 :

• ajouter une préférence pour activer/choisir le “mode de calcul en dépendance”
• choisir le mode par défaut

• Mode de conservation des résultats :
  • mode Bezak : ne pas conserver par défaut, mettre en évidence les résultats conservés avec un bullet vert
  • mode SLH (Alpha3) : ne pas conserver par défaut, mettre en évidence les résultats non sauvés avec une astérisque
    • le mode BP est celui des Bisontins ou de Serge, à savoir par défaut un résultat est caduque. Mais l'idée ensuite (celle de Serge) c'est d'éviter d'alourdir typographiquement les résultats conservés ; par contre l'astérisque n'est pas forcément bien comprise par tous. Chercher un autre mode typographique (italique, grisé,…?) qui signale la caducité du résultat de façon plus intuitive tout en alourdissant le moins possible l'affichage.
  • mode CG : conserver par défaut, ne mettre aucune mise en évidence (devient inutile) et retirer le choix “conserver” du menu contextuel de la vue Corpus (devient inutile, car on peut supprimer)

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 :
  • prioritaire : Ajouter une commande “Propriétés” à tous les résultats (affiche dans un éditeur les paramètres dans une page HTML + 2 boutons Exporter/Importer)
  • éventuellement : Ajouter une vue “Propriétés” qui permet de voir, exporter et importer des paramètres
• confusion sur le role des boutons “Tri” et “Search” des concordances
  • retirer le bouton “Tri” et détecter dans le compute de la concordance si il faut recalculer toute la concordance ou pas
    • note MD: dans TXM 0.7.9 la concordance est systématiquement recalculée entièrement, mais on peut à présent détecter si il suffit de maj les lignes ou si il faut maj la sélection de la concordance
• amélioration des éditions
  • remonter le bouton de choix des éditions de la commande Édition dans la zone des paramètres
• améliorer la relation entre la vue Corpus et les éditeurs
  • lorsque qu'un éditeur TXMEditor est activé,
    • faire le focus (déplacer le viewport) sur le résultat dans la vue Corpus
    • mettre en évidence en “gras” dans la vue Corpus

• 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
  • scénario de décision de fin de saisie de valeur (voir la saisie des valeurs de propriétés URS) :
    • au clavier la touche Entrée valide la valeur [SJ: fait]
    • prise de focus par un autre champ de l'éditeur [SJ: non fait. A faire ?]
• 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)
  • SJ: + l'éditeur passe en dirty dès qu'on clique sur la flèche de la combo box
• 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

• établir la liste des patterns par commande (et en fonction de l'état du résultat ?) :
  • titre des onglets d'éditeurs du résultat
  • tooltips des onglets d'éditeurs du résultat
  • message de la barre de statut lors du clic sur un résultat dans la vue corpus
  • labels des résultats dans la vue corpus
  • vérifier les préférences par défaut des commandes

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
  • problème de cohérence pour la persistence des résultats
  • problème de cohérence pour le cas de 2 AFC calculées sur un état différent d'une LT

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 :

• A) oui ou non ?
• B) préférences afficher les paramètres déportés : “oui” / “non”

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 :

• oui
  • pas de validation de la modification du parent
• non
  • ouverture d'une LT alors qu'une AFC a été demandée

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”
  • pas de commande conserver
  • pas de stylage
• “manuel”
  • commande conserver dans la vue corpus
  • marqué ce qui n'est pas conservé : italic par défaut (on limite ainsi les différences d'affichage entre les 2 modes)

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)
  • Ce serait bien de savoir comment désinstaller les alpha précédentes proprement (la Logithèque n'y arrive pas), j'ai donc 3 TXM en parallèle.

• BP (29/10/2018, TXM 0.8.0.1216) :
  • sans avoir rien installé, je lance un import (Alceste) : l'import semble bien fonctionner (cf. retours ci-après sur l'import Alceste), mais avec un warning comme quoi le modèle de langue TT manquait.
  • j'installe l'extension d'installation des modèles de langue EN et FR. Puis proposition de redémarrage que je valide.
  • je supprime le corpus précédemment créé, je relance l'import : cette fois l'import bloque dès le départ en indiquant qu'il n'y a pas Treetagger.
  • j'installe l'extension d'installation de Tree Tagger. Puis proposition de redémarrage que je valide.
  • je retente l'import de mon corpus, j'obtiens les messages suivants :

    Démarrage de TXM 0.8.0.1216...
    Terminé.
    .Prêt.
    Updating TreeTagger binaries path...Done.
    Updating TreeTagger models path...Done.
    Using parameters from already imported corpus: null
    Sauvegarde des paramètres d'importation...
    
    Error: path to TreeTagger is wrong: /home/bpincemi/plugins/org.txm.treetagger.core.linux_1.0.0.201810191105/res/linux/bin
    Error: TreeTagger annotation engine is not ready please check TXM > Advance > TAL > TreeTagger preferences. Aborting
    Terminé.
    TXMResult.compute(): Project: computing failed.
    

  • Je vais voir les préférences, les chemins indiqués sont les suivants :

    Chemin du dossier d'installation : /home/bpincemi/plugins/org.txm.treetagger.core.linux_1.0.0.201810191105/res/linux
    Chemin du dossier de modèles linguistiques : /home/bpincemi/plugins/org.txm.treetagger.core.models_1.0.0.201810191105/res/models
    

    or effectivement je n'ai pas de répertoire plugins sous home/bpincemi.
  • MD OK le chemin était mal réglé et les fichiers modèles n'étaient pas exporté dans le plugin
• BP (05/11/2018, TXM 0.8.0.1216) : pour pouvoir poursuivre la dernière fois, j'avais changé les chemins dans le réglage des préférences pour pointer vers le Treetagger que j'utilisais avec les versions précédentes. Mais quand je redémarre TXM quelques jours après, ces réglages ont été perdus et au relancement de mon import (car mon corpus a disparu) je retrouve un message analogue à celui ci-dessus. Je quitte TXM pour essayer de voir si je ne me suis pas trompée de programme et si je retrouve mon TXM 0.8.0a3 ailleurs. J'essaye le TXM 0.8.0 qui semble bien être l'alpha de juin. Je relance donc TXM 0.8.0a3, et l'import Alceste, et cette fois-ci j'obtiens des messages encore différents :

  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.1216...
  Création de l'espace de travail utilisateur de TXM.
  Terminé.
  .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.
  Updating TreeTagger binaries path...Done.
  Updating TreeTagger models path...Done.
  New import corpus project.
  Sauvegarde des paramètres d'importation...
  
  org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources.
  	at org.eclipse.core.internal.resources.Resource.move(Resource.java:1514)
  	at org.eclipse.core.internal.resources.Resource.move(Resource.java:1475)
  	at org.txm.objects.Project._compute(Project.java:282)
  	at org.txm.core.results.TXMResult.compute(TXMResult.java:1925)
  	at org.txm.core.results.TXMResult.compute(TXMResult.java:1844)
  	at org.txm.rcp.handlers.scripts.ExecuteImportScript$2.run(ExecuteImportScript.java:162)
  	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
  Contains: Resource already exists on disk: '/home/bpincemi/TXM-0.8.0/corpora/ELYSEE181105'.
  TXMResult.compute(): Exception occurs during computing: org.eclipse.core.internal.resources.ResourceException: Problems encountered while moving resources.
  Terminé.
  

  • MD, il s'agit d'un autre bug, à creuser
    • MD OK ça devrait aller mieux

• BP (05/11/2018, TXM 0.8.0.1216) :
  • installation OK ; lancement depuis un index OK.
  • les commandes de la barre des paramètres de rendu semblent indisponibles : soit on n'a pas de modification, soit on semble avoir un recalcul du nuage (autre positionnement des mots) mais sans changement du paramètre de rendu sollicité. [SJ: j'ai désactivé la barre de rendu pour le WordCloud. Plus tard on pourrait augmenter RWorkspace pour changer la font, mode de rendu, etc.]

• BP (29/10/2018, TXM 0.8.0.1216) :
  • l'import Alceste aboutit : je n'ai pas de message disant que l'import est fini mais je récupère un corpus sur lequel je peux appliquer des commandes : description, concordance, édition. Voici le contenu de la console (j'ai tronqué les lignes de points) :

    Sauvegarde des paramètres d'importation...
    
    -- IMPORTER - Reading source files
    Some attributes were duplicated: [id2]
    707 texts found in /home/bpincemi/area/data/2018/projet/textometrie/3corpus/politique/elysee/181029src/elysee/export.txt
    Tokenizing files (707)
    ..............................
    Tagging sentences of 707 files
    ..............................
    Building xml-tei-txm (707 files)
    ..............................
    -- ANNOTATE - Running NLP tools
    Error: No Modelfile available for lang /usr/lib/treetagger/models/FR.par. Continue import process 
    -- COMPILING - Building Search Engine indexes
    process 707 files
    ..............................
    [p:[n], s:[n], lb:[n], txmcorpus:[lang], text:[id, titre, president, id2, quand, qui, annee, base, project]]
    pAttrs : [id, lbn, pn, sn, n]
    sAttrs : [p:+n, s:+n, lb:+n, txmcorpus:+lang, text:+id+titre+president+id2+quand+qui+annee+base+project]
    -- EDITION - Building edition
    Paginating texts: 
    .............................Terminé.
    

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.

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Pour les répertoires de sources créés sous TXM 0.7.9 et avant, certains paramètres stockés dans import.xml ne sont pas reconnus (e.g. les plans textuels)
  • La langue par défaut pour l'annotation TreeTagger est “FR” or nous avons toujours recommandé de nommer les modèles avec des minuscules. En revanche, la liste déroulante propose les noms de fichiers modèles disponibles
  • Lors de l'import la console ne défile pas à l'écran, il faut scroller manuellement pour suivre l'évolution
  • L'étape d'annotation par le TreeTagger n'est pas affichée dans la console (en mode Severe et Warning, en tout cas)
  • La durée de l'import n'est pas affichée, c'était très pratique pour les tests de l'import
  • Les éditions XSL multiples sont créées mais restent indisponibles (problème du nouveau système de préférences ?)
  • Pour certains corpus la création d'édition par défaut échoue

    -- Building 'default' edition of  1 texts...
     .Fail to build 'default' edition for text: /home/alavrent/TXM-0.8.0/corpora/QJOYESKA/txm/QJOYESKA/QJoyesKa.xml
    

  • en revanche, si une édition “default” XSL est construite correctement
  • dans le corpus binaire, fichier .settings/TextualPlans.prefs, l'usage de camelCase est incorrect :
    • MileStones → Milestones (1 seul mot en anglais)
    • OutSide → Outside
    • NB: dans la tei, il n'y a jamais de majuscule à la 1ère lettre. Pourquoi pas faire pareil?

* GL (2018-12-11, TXM 0.8.0.2018 10191541?)

• Je conseillerais d'ajouter des valeurs de défaut pour les différents paramètres d'import (ou du moins d'ajouter des commentaires), ex :

      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.

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Double-clic sur l'icone fonctionne pour Index et concordance, mais pas pour Lexique [SJ: fixé par MD]
  • Export des données n'est plus disponible pour les corpus, sous-corpus et partitions : OK !
  • Renommage de corpus fonctionne et persiste : OK !
  • Au bout d'un certain nombre de manipulations (import, chargement de corpus, renommage, redémarrage), certains corpus sont dupliqués dans la vue corpus

• BP (05/11/2018, TXM 0.8.0.1216)
  • Le corpus que j'ai importé la fois précédente (cf. retours sur l'import -import Alceste) a disparu au redémarrage de TXM.
  • Après des opérations d'annotation, je redémarre TXM, et j'ai 6 fois le corpus GRAAL et 6 fois le corpus VOEUX. Le corpus sur lequel avait porté mes annotations n'est pas dupliqué.

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Modification du nom de corpus dans l'onglet de propriété fonctionne, mais ne persiste pas (modifications perdues si on ferme TXM). La mise à jour de la partie basse ne se fait que si on appuie d'abord sur le 1er, puis sur le 2e bouton Apply [MD: OK]

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Impossible d'avancer dans l'affichage : les bouton “Suivant”, “Dernier” ou saisie directe ne fonctionnent pas [SJ: fixé]

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Mode assisté : des requêtes sont générées à partir des métadonnées disponibles, mais les caractères spéciaux éventuels ne sont pas échappés, du coup la création de sous corpus peut échouer. E.g. pour l'auteur “Adgar (dit Guillaume)” de la BFM, la requête générée est

    /region[text,a]:: a.text_auteur="Adgar (dit Guillaume)"

    au lieu de

    /region[text,a]:: a.text_auteur="Adgar \(dit Guillaume\)"

  • Dans l'interface, j'aurais remplacé “certains critères” par “au moins un critère” et j'harmoniserais Maj ou min pour les deux options

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Pas d'anomalie détectée (testé partition en mode assisté pour le corpus BFM2016)

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Pas d'anomalie détectée

• 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.
    • proposition: si parent = index de partition ⇒ alors masquer les paramètres déportés

1. 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)
  • Fonctionnalités testées : Lexique, Index, Concordance, Progression, Références, Spécificités, AFC. Seuls les bugs sont signalés

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • Il y a apparemment une erreur dans le calcul du total des occurrences. Le total affiché est égal au nombre d'occ - 1; e.g. “1-59 / 58” [MD OK fixed]
• 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)
  • Ajout/suppression dynamique de requêtes OK
  • Mais si on clique sur le graphique, on ne peut plus taper dans le champ de la requête, il faut passer par l'assistant de requête pour réactiver la saisie
    • SJ: non reproductible sous Windows
      • MD: je confirme le bug, le focus à l'air d'être sur le champ requete (ou spinner, etc.) mais les événements de clavier ne sont pas transmis
        • MD: OK on a desactiver l'electrique sur les widget de type Spinner car la gestion des événements est trop différente entre les OS [SJ: fixé: changement de listener sur les Spinner ⇒ ModifyTextListener au lieu d'un SelectionListener]

• AL (2018-10-30, TXM 0.8.0.201810191541)
  • l'étiquette de “banalité” semble dupliquée avec un léger décalage
    • MD: fixed ?
      • SJ: faudrait faire des tests plus poussé sous Linux, je ferai un ticket un peu plus tard

• BP (2018-11-22, TXM 0.8.0.1216)
  • Ce n'est pas exactement la commande Spécificités, mais c'est peut-être un peu lié ? Je n'arrive pas à utiliser la macro PlotSpecif pour le calcul d'une spécificité à partir de ses quatre paramètres (y compris avec les valeurs par défaut), j'ai le message d'erreur suivant :

    NLS missing message: ExecuteScript_11 in: org.txm.rcp.messages.messages
    org/txm/macro/r/PlotSpecifMacro.groovy
    Error during script execution: groovy.lang.MissingMethodException: No signature of method: org.txm.statsengine.r.core.RWorkspace.plot() is applicable for argument types: (File, org.codehaus.groovy.runtime.GStringImpl) values: [/home/bpincemi/TXM-0.8.0/results/txm598229176872617115.svg, ...]
    Possible solutions: wait(), split(groovy.lang.Closure), dump(), grep(), find(), any()
    groovy.lang.MissingMethodException: No signature of method: org.txm.statsengine.r.core.RWorkspace.plot() is applicable for argument types: (File, org.codehaus.groovy.runtime.GStringImpl) values: [/home/bpincemi/TXM-0.8.0/results/txm598229176872617115.svg, ...]
    Possible solutions: wait(), split(groovy.lang.Closure), dump(), grep(), find(), any()
    	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:72)
    	at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:48)
    	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:136)
    	at org.txm.macro.r.PlotSpecifMacro.run(PlotSpecifMacro.groovy:73)
    	at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:599)
    	at org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run(ExecuteGroovyScript.java:244)
    	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
    

• 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).