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 : known-bugs (bugs connus)

Retours de la phase ALPHA (terminée) :

• txm_0.8.0alpha

Retours de la phase BETA : merci de répartir vos retours dans les sections thématiques ci-dessous ou dans de nouvelles sections.

AL 2019-02-11 (Ubuntu 16.04)

• TXM ne demande pas où il faut créer le répertoire utilisateur TXM et récupère tous les corpus de l'ancienne version. Ça peut être lourd, surtout en période de test.
  • MD corrigé : TXM demande maintenant quels corpus restaurer au premier lancement ticket #2509
• Installation du TreeTagger : le modèle fro.par est installé sans que l'utilisateur le demande.
  • MD corrigé

BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)

• TXM 0.8.0b3 ne se désinstalle pas avec la logithèque. On peut faire une désinstallation avec “sudo apt-get remove txm-0.8.0b3”. Chaque ancienne version de TXM semble cependant laisser un répertoire sous usr/lib, je ne sais pas si c'est normal.
  • MD reporté pour 0.8.1 c'est normal, dans l'état les setups alpha, beta et stable n'ont pas la même nom de version et ne se connaissent pas entre eux: #2529
  • BP : mais ici je voulais aborder la question de la désinstallation propre, demandée par l'utilisateur, et non celle de la désinstallation gérée automatiquement par l'installation d'une nouvelle version (qui est importante aussi bien sûr).
    • MD reporté pour 0.8.1 #2550
• Quelques messages d'erreur quelques minutes (~5 mn ?) après le 1er lancement et la récupération des corpus (ici minimisée, limitée à l'installation des corpus GRAAL et VOEUX).

  !ENTRY org.eclipse.core.resources 2 2 2019-03-05 11:55:42.691
  !MESSAGE Save operation warnings.
  !SUBENTRY 1 org.eclipse.core.resources 2 234 2019-03-05 11:55:42.691
  !MESSAGE The project description file (.project) for 'GRAAL' was missing.  This file contains important information about the project.  A new project description file has been created, but some information about the project may have been lost.
  !SUBENTRY 1 org.eclipse.core.resources 2 234 2019-03-05 11:55:42.692
  !MESSAGE The project description file (.project) for 'VOEUX' was missing.  This file contains important information about the project.  A new project description file has been created, but some information about the project may have been lost.
  

  • MD corrigé

FB 2019-03-06

• pour la langue française du moins, la segmentation ne se fait plus au niveau de l'apostrophe (par exemple, “c'est” est un seul mot) problème Treetagger ? Problème segmentation ?
  • SLH corrigé : c'est lié au problème déjà mentionné “La langue d'annotation sélectionnée par défaut est “FR”” alors qu'elle devrait être “fr”
    → positionner la langue d'annotation à “fr” dans le formulaire d'import

SLH 2019-03-24 (Ubuntu 18.04)

• fenêtre logithèque :
  • logo de TXM ?
  • license : propriétaire ?
  • taille : 0 octet ?
  • MD je donne ma langue au chat #2551

MD 2019-03-19

• Windows : Les chemins de lancement de TXM ne sont pas bons.
  • MD corrigé dans le setup b4

SLH 2019-03-24 (Ubuntu 18.04)

• TXM-0.8.0 n’apparaît pas dans la recherche du Dash → obligé de le lancer depuis un terminal
• l'icone de TXM 0.8.0 dans le lanceur est la même que celle de TXM 0.7.9 → on ne peut pas lancer TXM 0.7.9 et TXM 0.8.0 en même temps depuis le lanceur
• MD reporté #2552

BP 2019-04-02, BP 2019-04-05 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• Le lancement de TXM me paraît très long : ~8 minutes. Il y a une quinzaine de corpus mais une majorité de petits corpus, de moins de qq centaines de milliers de mots. J'ai supprimé le corpus BFM016DD qui était plus gros (4 millions de mots, avec une dizaine de partitions ou sous-corpus), il me semble que le seul corpus conséquent qui reste est AFVOIXOFFSUJ, 3 millions de mots mais 12 000 (petits) textes.
  • MD corrigé

MD - 2019-03-08

La non-récupération des corpus du précédent TXM 0.8.0 créé des corpus cassés

• MD corrigé

JCD - 2019-03-02

Les corpus récupérés ne sont pas affichés

• MD corrigé la vue corpus n'était pas bien rafraîchie et le travail de récupération n'était pas bloquant

AL 2019-02-13

• La commande Affichage/Changer la langue ne fonctionne pas (l'interface reste toujours en français). Pour forcer le lancement en anglais MD propose le patch suivant dans le fichier ~/TXM-0.8.0/.txm/TXM.ini, ajouter avant la ligne '-vmargs'

  -nl
  en
  

  • MD corrigé
• Lorsque l'OS est en russe, TXM se lance en russe. L'affichage du cyrillique dans le menu et dans les noms de certains onglets est incorrect (UTF-8 lu comme iso-latin ?)
  • MD en cours au moins pour la Beta les messages russes sont retirés. Ils pourront être réintégrés lors d'une mise à jour ou nouvelle version de TXM.
    • AL 2019-03-01. Le russe est disparu du menu de sélection de langue, mais l'interface reste en cyrillique cassé après installation sur un windows russe (confirmé sur deux machines). Ça donne une très mauvaise impression aux utilisateurs…
      • MD reporté #2553
• Lorsque l'interface est en anglais, certaines commandes restent en français :
  • menu Corpus : toutes les commandes sauf “re-import corpus”
  • menu Tools : toutes les commandes
  • menu View : Réinitialiser affichage
  • idem pour les commandes dans le menu contextuel
    • MD bugs connus reporté à plus tard http://forge.cbp.ens-lyon.fr/redmine/issues/2554

SLH 2019-03-24 (Ubuntu 18.04)

• interface en EN :
  • le démarrage EN annonce la date et la version, “Starting TXM 0.8.0.1928 (23 March 2019, 16h27)…”, alors que le démarrage FR ne donne pas la date : “Démarrage de TXM 0.8.0.1928…”
    • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2555
  • l'onglet de la vue Fichier garde son nom FR : “Fichier” → “File”
  • la majorité des entrées du menu principal restent en FR
    • dont “Fichier > Vérifier les packages R”
    • “File > New?”, le '?' est en trop, à moins que ce soit des '…' qui ont été remplacés à tort par un '?'
    • “File > Open in Browser?”, le '?' est en trop ou un bug
    • “File > Changer le répertoire de travail”, doit être traduit, et n'aurait pas du être remplacé par une Préférence ?
    • la majorité des entrées du menu contextuel restent en FR
    • MD reporté voir ci-dessus
• interface en FR :
  • le menu contextuel de la console est en EN
    • MD corrigé
• menu contextuel “Export > Corpus in binary format?”, le '?' est en trop ou un bug
  • MD corrigé

• FB - 2019-03-06
  • Ok pour cocher pour les garder tous par défaut mais je ne vois pas à quoi correspond “à la demande (mode de fonctionnement par défaut)”
  • SLH s'il s'agit de la persistence des résultats, la terminologie actuelle de TXM est la suivante :
    • en général les commandes prennent en entrée une requête CQL pour produire un résultat
    • la persistence porte sur les résultats [obtenus] plutôt que sur les requêtes [en entrée] (parce qu'il n'y a pas que les requêtes qui sont à l'origine de résultats mais également plein d'autres paramètres par ailleurs - comme des seuils, etc.)
    • par défaut un résultat n'est pas sauvegardé pour les sessions suivantes (non persisté)
      • donc il faut demander explicitement de le sauvegarder/persister si on veut qu'il perdure entre les sessions de TXM (→ “à la demande (mode de fonctionnement par défaut)”)
    • l'enregistrement entre sessions de TXM et la gestion de requêtes CQL utilisées pour un corpus font l'objet d'un composant qui n'est pas encore publié
  • MD documenté http://forge.cbp.ens-lyon.fr/redmine/issues/2543

• FR - 2019-03-11
  • Au démarrage de TXM, la date affichée par la console n'est pas à jour.
    • MD corrigé La data a été retirée. TXM affichait la date d'installation de TXM.

AL 2019-02-11

• Le fonctionnement de la barre de statut a évolué depuis 0.7.9, l'affichage varie selon les objets sélectionnés. Voici l'état actuel et quelques suggestions d'harmonisation :
  • pour un corpus, ça affiche le nom du corpus (c'était le nombre de mots avant). L'info est moins utile que le nombre de mots, mais OK.
    • BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605) : je viens de le constater aussi ; je m'aperçois que je me servais bien de ce nombre de mots mais bon ce n'est pas prioritaire.
      • MD corrigé tous les résultats n'ont pas encore leur message #2530
  • pour une description, toujours le nom de l'objet. Suggestion : ajouter “Description :”
  • pour un sous-corpus : le nom du sous-corpus. Suggestion : ajouter le nom du corpus parent
  • pour une partition : nom de la partition + nombre de parties
  • pour une concordance : nom du corpus ou sous corpus + requête, suggestion : ajouter “Concordance :”
  • pour un lexique : nom du corpus + propriété, suggestion : ajouter “Lexique :”
  • pour un index : “Index:” + requête, suggestion : ajouter le nom du corpus
  • pour une progression : nom du corpus: + requête en doubles crochets. Suggestion : ajouter “Progression:”, enlever les crochets en trop…
    • MD en cours résolution au moins après la Beta

FR 2019-03-11

• On ne peut plus accéder aux fonctions de calcul en cliquant dessus le nom des corpus : la seule possibilité consiste à utiliser la barre d'outils.
  • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2556

BP 2019-04-15 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205)

• Quand je sélectionne un cube de partition, en bas de la fenêtre s'affiche par exemple “10 built part(s)” (en interface FR). Ce que je veux signaler c'est que le nombre est instable : en début de session j'ai eu 9, puis après qq clics 8, puis je crois après un calcul de PROPRIÉTÉS 9, puis après un autre calcul (INDEX) 10, puis à chaque nouvel INDEX ou PROPRIÉTÉS le nombre semble s'incrémenter (11, 12…)
  • MD corrigé

SLH 2019-03-24 (Ubuntu 18.04)

• la commande “Fichier > Charger corpus binaire…” n'affiche pas de message quand elle a terminé. Elle affiche seulement indéfiniment : Chargement du corpus binaire au format 0.7.9 HOBBES8.txm…
  • SJ: fixé par MD

  • Chargement du corpus binaire au format 0.7.9 GRAAL.txm...
    GRAAL corpus chargé(s).

SLH 2019-04-16 (TXM 0.8.0.2018, Ubuntu 16.04)

• commande interne de rechargement des corpus binaires par répertoires :
  • chaines non externalisées (?) :

    • Restoring corpora

    • A corpus with the same CQP MainCorpus identifier DEMOCRATLYON3 already exists. Aborting loading of /home/sheiden/TXM/corpora/DEMOCRATLYON3_TEMP.

    • A corpus named GRAAL already exists, loading of /home/sheiden/TXM/corpora/GRAAL canceled.

    • Warning no corpus element defined in the /home/sheiden/TXM-0.8.0/corpora/P1S8S/import.xml file.

  • message difficile à interpréter pour l'utilisateur, utile ?

    • Informations de l'espace de travail (selfElement null)

JCD - 2019-03-02

Faut il vraiment que le menu « propriétés « présent la position vide. Pourquoi ne pas mettre un epropriété par défaut, par exemple « word » qui est probablement la plus utilisée ?

• MD corrigé

AL 2019-02-11

• La date de création de tous les corpus est me 31/12/2018, l'heure semble être celle du système au moment de la création ou chargement du corpus
  • MD corrigé, pour les corpus TXM 0.7.9 chargés dans TXM 0.8.0, la date de création sera effectivement la date du chargement du corpus
• Pour un nouveau corpus la date de dernière modif est bonne, mais elle re-passe au 31/12/2018 après redémarrage de TXM
  • MD corrigé

BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• J'ai installé TXM 0.8.0 beta 4 sans récupérer aucun corpus. J'ai refait l'import de mon corpus ELYSEE depuis ses sources. Quand je demande ses propriétés (mais je pense avoir fait d'autres commandes et redémarré depuis l'import), j'obtiens une erreur sur les dates malgré la correction faite par Matthieu (cf. retours d'Alexei ci-dessus) :

  Date de création : 31 décembre 2018, 14h46
  Dernière modification : 31 décembre 2018, 14h48.
  

  • MD corrigé
  • Par ailleurs la “Description” qui est donnée ne reprend pas celle que j'avais entrée dans le formulaire d'import, voici celle qui s'affiche :

    Build the Alceste import module
    

  • MD corrigé

SJ 2019-03-15

• Le champ V Max est mal branché au ComputeListener (la touche Entrée ne fonctionne pas + en mode électrique le clic sur les flèches du Spinner recalcule automatiquement le résultat mais ne devrait pas)
  • SJ corrigé

• AL 2019-04-16 (TXM 0.8.0.201904161055)
  • Lorsqu'on arrive à la dernière page du dernier texte d'un corpus et qu'on clique sur “page suivante”, TXM affiche la 1ère page du dernier texte. Idem, si on clique sur “page précédente” à la 1ère page du 1er texte, TXM affiche la dernière page de ce 1er texte.

AL (2019-02-11)

• La navigation par page ne fonctionne pas (c'est toujours la 1ère page qui s'affiche)
  • MD corrigé
• Un astérisque est toujours affiché à côté de l'objet dans le volet corpus (avant et après la conservation), il disparaît si on ferme l'onglet)
  • MD corrigé l'astérisque était lié au bug précédent
• L'icone “roue dentée” ne correspond plus au nouveau nom de la fonction
  • MD corrigé nouvelle icone (loupe sur un tableau)

FB (2019-02-18)

• La vue requête provoque une erreur pour une version ubuntu 18.04 (mais la conservation des requêtes est ok via le changement dans les préférences)
  • MD vue retirée la vue n'est pas encore prête et doit être repensée pour mieux s'intégrer avec le reste des outils de TXM

BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• Quand je modifie une requête et que je relance le calcul de l'index, l'affichage du résultat n'est pas repositionné pour démarrer à la première ligne.
  • MD corrigé
• Je suis en train d'utiliser l'index, et je décide de changer de stratégie de recherche en utilisant la macro SetMatchingStrategy. Après avoir fait tourner la macro, le bouton flèche verte qui permet de relancer le calcul (sur la même requête pour voir l'effet du changement de stratégie) n'est plus actif. Je ne réussis à le réactiver qu'en changeant de requête.
  • MD corrigé on a retiré la désactivation du bouton
• L'historique des requêtes inclut une sélection de lignes copiées d'un résultat d'index ! J'ai fait plusieurs opérations de la sorte -sélection puis copie dans un index- mais une seule d'entre elles a intégré le menu.
  • MD pas réussi à reproduire

BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• Ce retour concerne plus généralement le champ Requête CQP (j'observe le même bug en concordance par exemple) : Si je lance la requête

  "[A-Z].+"

  alors celle-ci s'exécute correctement, mais dans le champ requête la requête perd ses guillemets ; elle les perd aussi dans l'historique des requêtes. Du coup, lorsqu'on veut relancer la requête, cela génère une erreur CQP.
  • MD corrigé #2531

BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• Je reviens sur un index déjà calculé (avec des descendants : table lexicale, spécifs, graphe de spécif) et je décide de changer la requête en en sélectionnant une autre dans l'historique. Mais le bouton flèche verte pour lancer le calcul est désactivé, et je n'arrive pas à le réactiver (en changeant de requête, en entrant une nouvelle requête, etc.)
  • MD corrigé voir plus haut

SLH 2019-02-11

• quand je lance une concordance, le champ CQL initial contient la chaine ””. Est il possible d'avoir un champ vide à la place ? (comme avant, et comme pour la commande Index)
  • SJ: corrigé

BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)

• Quand je double-clique sur une ligne pour revenir au contexte large dans l'Edition, l'occurrence concernée n'est pas mise en évidence par le surligné rose. En revanche à partir du 2e clic (quand je sélectionne une autre ligne qui appelle une autre page de l'édition), le surlignage se fait.
  • MD corrigé
• Je parcours toutes les lignes de la première page de concordance. Puis je passe à la page suivante, et je suis surprise parce que je suis positionnée à la fin de la page (comme quand j'ai quitté la page 1), je m'attendrais à voir affiché le début de la 2e page pour continuer la lecture des lignes 98, 99, 100 aux lignes 101, 102, 103 etc.
  • MD corrigé le bouton page suivante remonte l'ascenseur en début de page

FR 2019-03-15

• Le scroll synchronisé des 2 tableaux de concordances ne fonctionne pas lorsque l'on scroll en utilisant l'ascenseur
  • MD corrigé

BP 2019-03-19

• on ne peut pas supprimer une ligne de concordance lors que l'on annote
  • MD corrigé

BP 2019-03-21 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• J'ai fait un retour au texte en double-cliquant sur une ligne de la concordance. Si ensuite j'édite la requête CQL et je relance le calcul avec la flèche verte à droite du champ requête de la concordance, alors rien ne bouge dans le résultat de la concordance (le calcul pour la nouvelle requête ne se fait pas) alors que l'édition associée se repositionne au début du texte (pour le texte en cours).
  • MD en cours http://forge.cbp.ens-lyon.fr/redmine/issues/2557
  • MD en cours http://forge.cbp.ens-lyon.fr/redmine/issues/2558
• Lorsque je fais évoluer la requête de la concordance, il est arrivé que l'édition de retour au texte associée conserve (certains ?) surlignages d'une recherche antérieure (mais pas de toutes les recherches antérieures). Je ne suis pas très précise car je n'ai pas réussi à cerner plus précisément le cas de figure dans lequel cela se produit.
  • MD lié au bug précédent
• Lorsqu'on exporte une sélection de lignes par copier/coller, on n'a plus l'information de la référence (1ère colonne - d'où viennent l'occurrence et ses contextes), c'est assez embêtant quand même… (difficile de s'en passer donc on la remet à la main)
  • SJ: reporté, voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2522

SLH 2019-03-24 (Ubuntu 18.04) :

• quand on avance d'une page de concordance, la colonne Référence reprend sa largeur d'origine, même si on l'a redimensionnée, alors que l'offset de la scrollbar horizontale de la colonne Référence est elle bien conservé → il ne faut pas redimensionner d'office la colonne des Références à chaque changement de page
  • MD corrigé sauf à l'ouverture des concordances conservées

BP 2019-04-05 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• Lors du retour au texte, la requête cherche toujours les 2 mots dans les deux ordres possibles, même si on n'a cherché les cooccurrents que d'un côté.
  • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2559

AL 2019-02-11

• Les crochets sont dupliqués dans la requête qui s'affiche dans le volet corpus [[frpos="VER:impf"]]
  • SJ: les premiers crochets sont utilisés en tant que marqueur de liste, ce n'est pas à proprement parlé un bug mais peut-être qu'il faudrait changer le pattern pour l'affichage ? 2 exemples avec 3 requêtes ci-dessous
    • [[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]]
    • [[word="est"], [word="pour"], [word="une"]]
      • SH: proposition : {…} (usage peu fréquent dans les textes)
        →
        • {[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]}
        • {[word="est"], [word="pour"], [word="une"]}
        • question : dans le cas soulevé par Alexis, c'est à dire un singleton, est il nécessaire de formuler sous la forme d'une liste (d'un seul élément) ?
      • MD : et '[frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]' ?
        • SJ: fix de MD au 22-02-2019: les crochets ont été supprimés et une virgule sépare les requêtes, 2 exemples avec 3 requêtes :
          • [frpos="PRO:PER"], [frpos="PRO:REL"], [frpos="VER:pper"]
          • "est", "pour", "une"

SJ 2019-02-12

• le graphique en mode densité est à nouveau buggé
  • SJ: fixé temporairement : forçage du mode R quand on passe en “Densité” et forçage du mode JFC quand on repasse en “Cumulatif”. Il faut implémenter le graphe “Densité” en mode JFC, voir ticket dédié]
• changer une requête dans la zone multiple ne passe pas l'éditeur en dirty, le bouton “compute” reste donc disabled et la seule solution pour mettre à jour et d'appuyer sur entrée
  • MD corrigé

SLH 2019-02-11

• dans la Progression, clic gauche ou double-clic gauche n'importe où dans la fenêtre (éditeur) provoque une stacktrace comme la suivante :

  !ENTRY org.eclipse.ui 4 0 2019-02-11 17:44:27.791 
  !MESSAGE Unhandled event loop exception 
  !STACK 0 
  java.lang.IndexOutOfBoundsException: Index: 104, Size: 81 
      at java.util.ArrayList.rangeCheck(ArrayList.java:657) 
      at java.util.ArrayList.get(ArrayList.java:433) 
      at org.jfree.data.xy.XYSeries.getRawDataItem(XYSeries.java:634) 
      at org.jfree.data.xy.XYSeries.getX(XYSeries.java:645)
  

  • MD corrigé

SLH 2019-02-11

• dans la Progression, la suppression de deux requêtes (pour éclaircir le graphique par exemple) décale les couleurs des courbes encore affichées (on commence toujours par bleu, rouge, etc.)
  

C'est dommage car ça gêne la lecture → si possible, ne pas changer l'allocation des couleurs des courbes qui restent présentes, et récupérer les couleurs des courbes retirées au fur et à mesure de l'ajout de nouvelles requêtes/courbes

• SJ: reporté, peut-être pour la 0.8.1, voir ticket ticket #2504

SLH 2019-02-11

• dans la Progression, le clic sur le bouton “Open Chart Properties” des paramètres de rendu ne fait qu'afficher ceci dans la console (pas de propriétés accessibles) :
  

OpenJFCChartPropertiesEditor.execute(): Can not open chart properties interface for the current chart engine.

• MD message rectifié

SLH 2019-02-11

• dans la Progression, le clic sur le bouton “Show/Hide title” des paramètres de rendu ne fait qu'afficher ceci dans la console (le titre est toujours là) :
  

java.lang.ClassCastException: org.jfree.chart.JFreeChart cannot be cast to java.io.File 
    at org.txm.chartsengine.r.core.RChartCreator.updateChart(RChartCreator.java:32) 

• SJ: corrigé pour les moteurs JFC et R

BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)

•  Dans la zone de paramètres, dans la partie de réglage de l'“unité structurelle et propriété”, le champ pour afficher la valeur de la propriété est de largeur quasi nulle : on voit ce qu'on peut choisir quand on affiche sur la flèche, mais une fois le choix fait on ne voit plus le nom de la propriété qui a été choisie.
  • SJ: non reproductible sous Windows 7 et Ubuntu 14 ; reproductible sous VM Ubuntu 18.10, en cours de correction
    • MD corrigé

SLH 2019-03-24 (Ubuntu 18.04)

• la Progression en densité de 3 mots dans VOEUX provoque une stacktrace (la progression s'affiche correctement) :

Progression de <[[word="France"], [word="pays"], [word="Europe"], [word="monde"]]> dans le corpus VOEUX...
Sauvegarde du graphique dans le fichier : /home/sheiden/TXM-0.8.0/results/progression_density6712310819957726674.svg.

!ENTRY org.eclipse.ui 4 0 2019-03-23 17:35:58.671
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.NullPointerException
    at java.awt.Container.addImpl(Container.java:1095)
    at java.awt.Container.add(Container.java:419)
    at org.txm.chartsengine.rcp.swt.SwingChartComposite.loadChart(SwingChartComposite.java:877)
    at org.txm.chartsengine.rcp.swt.ChartComposite.loadChart(ChartComposite.java:91)
    at org.txm.chartsengine.rcp.editors.ChartEditor$2.run(ChartEditor.java:460)
    at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233)
    at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144)
    at org.eclipse.swt.widgets.Display.syncExec(Display.java:5535)
    at org.txm.chartsengine.rcp.editors.ChartEditor.loadChart(ChartEditor.java:457)
    at org.txm.chartsengine.rcp.editors.ChartEditor.updateEditorFromResult(ChartEditor.java:302)
    at org.txm.rcp.editors.TXMEditor.refresh(TXMEditor.java:1059)
    at org.txm.rcp.editors.TXMEditor$4$2.run(TXMEditor.java:930)
    at org.eclipse.ui.internal.PendingSyncExec.run(PendingSyncExec.java:58)
    at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:168)
    at org.eclipse.ui.internal.UISynchronizer.lambda$0(UISynchronizer.java:150)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4577)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4186)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
    at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
    at org.txm.rcp.Application.start(Application.java:240)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
392, 153, 141, 139 position(s).

• SJ: non reproductible, reporté, voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2527

BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• Après fusion de lignes, la 1ère colonne est retriée, mais du coup se trouve en ordre alphabétique inverse : il faudrait peut-être plutôt trier 2 fois ?
  • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2560
• Quand on clone une table lexicale, cela perd les fusions de lignes qu'on avait effectuées avant clonage : bien le noter dans la doc car ce n'est pas forcément ce à quoi on s'attend.
  • MD corrigé un warning est maintenant affiché dans la console et voir aussi https://forge.cbp.ens-lyon.fr/redmine/issues/2545

BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• [plutôt une feature] Ce serait commode que le premier tri obtenu en cliquant sur une colonne de fréquences soit décroissant (dans la TL, mais aussi ailleurs quand ce n'est pas le tri initial : spécifs, cooc).
  • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2561

JCD 2019-03-20

• “que ce soit dans AFC ou CAH, lorsqu’on effectue un zoom sur le graphique, tous les points sont superposés au centre du graphique”
  • SJ: corrigé en repanssant à Java jre-8u151-macosx-x64 bug de Java > 1.8u151 faisant que Java ne reçoit pas les bons événements lors du défilement sur un touchpad Mac #2519

SLH 2019-02-11

• dans le tableau des lignes d'une AFC, les raccourcis flèche-haut et flèche-bas ne fonctionnent plus (mouvement de la sélection vers le haut ou le bas).
  • SJ: bug spécifique à Linux, en cours de correction

SJ:

• les préférences par défaut fmin/vmax de la page de pref AFC ne fonctionnent plus. Ce sont celles de la page de pref de la Table Lexicale qui sont utilisées.
• MD à discuter pour TXM 0.8.1 #2510

BP 2019-03-22 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• le menu pour choisir le plan à visualiser est figé (on n'arrive pas à l'ouvrir pour sélectionner le plan 1×3 par exemple).
  • SJ: corrigé

SLH 2019-03-24 (Ubuntu 18.04)

• le recalcul après relancement de TXM d'une AFC des colonnes conservée provoque une stacktrace (le plan d'AFC s'affiche correctement):

Création de la fenêtre de l'AFC
TXMEditor.createPartControl(): can not create the editor for result null.
Stacktrace:
[1]             org.txm.rcp.editors.TXMEditor.createPartControl  TXMEditor.java, 484
[2]           org.txm.ca.rcp.editors.CAEditor.      createPages  CAEditor.java, 173
[3]         org.txm.ca.rcp.handlers.ComputeCA.          execute  ComputeCA.java, 177
[4]  org.txm.rcp.handlers.BaseAbstractHandler.   executeCommand  BaseAbstractHandler.java, 240
[5]  org.txm.rcp.handlers.BaseAbstractHandler.   executeCommand  BaseAbstractHandler.java, 164
[6]   org.txm.rcp.views.corpora.CorporaView$3.      doubleClick  CorporaView.java, 361
[7]                   org.txm.rcp.Application.            start  Application.java, 240
java.lang.NullPointerException
    at org.txm.chartsengine.rcp.swt.AdvancedChartEditorToolBar.<init>(AdvancedChartEditorToolBar.java:53)
    at org.txm.chartsengine.rcp.editors.ChartEditor._createPartControl(ChartEditor.java:186)
    at org.txm.rcp.editors.TXMEditor.createPartControl(TXMEditor.java:430)
    at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:241)
    at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:211)
    at org.txm.ca.rcp.editors.CAEditor.createPages(CAEditor.java:173)
    at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:151)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor.createPartControl(CompatibilityEditor.java:99)
    at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:355)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    ...
    

• SJ: corrigé

SLH 2019-02-11

• l'onglet de l'éditeur de CAH n'est pas externalisé
  • MD corrigé

SLH 2019-02-11

• faire une CAH ou une AFC avec la propriété 'id' provoque la stacktrace ci-dessous → retirer la propriété 'id' de la liste des propriétés.
  • MD corrigé
  • SJ: je pense qu'il faut une fois pour toute stocker la liste des propriétés CQP de type “interne” et qui ne doivent pas forcément être affichées pour l'utilisateur lambda. L'état actuel est : ça dépend des commandes et tout est codé en dur avec des tests sur String un peu éparpillés dans les différentes commandes.
    • SH : il existe déjà une infrastructure pour gérer le comportement d'une commande par rapport à des propriétés de structures (et non de mots) : les métadonnées de textes pour la commande ”Liste des textes” implémentée seulement dans le portail
      • le paramétrage du comportement se fait directement dans le fichier import.xml, pas d'UI à ce stade
        • les éléments XML concernés doivent être documentés dans le manuel d'administrateur de portail
      • il y a différents types de comportements propres à la commande : afficher ou pas, ordre d'affichage entre propriétés, types de tris, etc.
      • on pourrait faire évoluer cela en :
        • prenant en charge des propriétés de mots, en plus de propriétés de textes, pour certaines commandes
        • créant une interface pour simplifier le paramétrage au sein, ou accessible depuis, le formulaire d'import d'un corpus
        • les paramètres de comportements de commandes seraient gérés comme des propriétés de corpus
  • SJ: mais en fait je ne comprends pas pourquoi supprimer la propriété “id” ? “base”, etc. OK mais “id” ?
    • SH : dans le contexte de la CAH, tout ce que dit mon retour est que ça bugge si on utilise la propriété “id” (ça n'a pas forcément de sens non plus). J'imagine que ne pas donner accès à cette propriété est une façon d'éviter de provoquer le bug. On peut aussi laisser l'utilisateur se planter (pas un bug du coup).
    • SJ: je viens de comprendre qu'il n'y a pas d'intérêt à faire une Table sur 'id'. En revanche je ne sais pas pourquoi la table plantait. Ca devrait créer une tableau avec les “id” et des 1, 0, 0, 0 etc. / 0, 1, 0, 0 etc. Ca relance aussi la question des tests manquants sur des tables de contingences n'étant pas une matrice valide pour la CA et la CAH, lignes ne contenant pas 3 valeurs non nulles, etc. (indépendamment du nombre de colonnes/lignes)
      • MD discussions en cours choix probablement après la 0.8.0

JCD 2019-02-13

• faire une CAH en Mac OS X 10.10 ou 10.12, bloque le calcul (le moniteur indique que TXM ne répond pas). Le job affiche “Calcul de 2 clusters etc.” la console :

Calcul de la CAH...
Sauvegarde du graphique dans le fichier : ...

• SJ: bug reproduit 1 fois sous Mojave. Je n'arrive pas à le reproduire de nouveau. Il y a un deadlock, la première hypothèse étant un eval R qui ne retourne pas car la dernière ligne du log et l'envoi de la commande de AHC à R.
  • SJ: normalement corrigé, à retester en profondeur

FB 2018-03-07

• une erreur lors de la classification qui fonctionne dans l'ancienne version mais me renvoie vide dans la nouvelle : SVG file /home/flora/TXM-0.8.0/results/ahc165681592925985331.svg is empty.

Stacktrace: [ 1] org.txm.chartsengine.svgbatik.rcp.swt.SVGComposite. loadSVGDocument SVGComposite.java, 59 […]

• SJ: voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2521

BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• Si on lance un calcul de spécificités directement sur une partition, les paramètres par défaut (qu'on ne voit pas si on ne va pas les chercher) ne sont plus les mêmes qu'en 0.7.9, avant on avait juste Fmin > 1, maintenant on a aussi un Vmax=200. Or cela a un gros impact et sur les valeurs d'indice, et sur les mots présents dans le tableau des résultats, si l'utilisateur ne se méfie pas cela peut être assez trompeur. J'imagine que le seuil de Vmax a dû être fixé pour tenir compte du fait que les corpus actuels peuvent être vraiment très (trop) gros pour lancer le calcul par défaut sur tous les mots (Fmin > 1 voire Fmin > 0). Ce qui pourrait être envisagé (en le documentant ?), ce serait de calculer les spécifs pour tous les mots mais de créer une ligne #RESTE# regroupant les plus basses fréquences si le calcul est jugé trop lourd : ainsi, les tailles des parties sont calculées en prenant bien en compte tous les mots, et la plupart des mots que l'utilisateur peut vouloir chercher sont présents dans le tableau.
  • SJ : c'est un effet de bord, comme pour l'AFC, les préférences par défaut sont celles de la commande Table Lexicale. Il faudrait sans doute dissocier ces prefs pour les commandes directs qui ne passent pas par la table lexicale et la masque (voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2510)
  • BP 2019-04-03 : en attendant, que penseriez-vous de régler les préférences de la table lexicale à Fmin = 1 et Vmax = 9999999…, autrement dit pas de filtrage en pratique ? Le risque c'est de planter TXM pour les (très) gros corpus, mais dans ce cas les utilisateurs chercheront une solution et iront régler la préférence de façon pertinente pour leur cas et en connaissance de cause ? Et il me semble que cet effet négatif serait moins important/fréquent que celui de la mauvaise interprétation d'un calcul de spécificité où l'ensemble de référence est très différent de celui qu'on croit.
  • BP 2019-04-04 : même quand on passe par une table lexicale, cette application des préférences Fmin=2 & Vmax=200 reste gênante sinon “dangereuse”. Je crée un index sur partition, je le transforme en table lexicale avec l'option marges = tous les mots recensés par l'index, et cela me crée une table lexicale avec seulement les 200 mots les plus fréquents, donc seulement une partie de mon index. Ce n'était pas le cas en 0.7.9 (la préférence pour une Fmin à 2 n'intervenait pas à ce stade). Et comme la table n'est pas triée de la même façon (alphabétiquement au lieu de hiérarchiquement), le fait que des lignes aient été “perdues” n'apparaît pas de façon évidente.
  • BP 2019-04-04 : l'enjeu, c'est d'éviter que même les spécificités “de base” soient “compliquées” à obtenir (c'est le genre de calcul que les autres logiciels offrent en un clic), ou massivement “fausses” (l'utilisateur ne comprend pas ou ne voit pas les seuils, qui ne sont généralement pas bons avec les valeurs par défaut 2 / 200). Du coup pour moi c'est un point qui serait assez urgent (cela ne sera peut-être pas possible pour la 0.8.0, mais ce serait alors pour une des premières mises à jour). Un simple (?) changement des paramètres par défaut pourrait déjà régler l'essentiel il me semble.
  • SJ 2019-04-08 : je suis en train de m'orienter vers ceci, dans les cas des commandes “raccourcies” (celles non appelées sur la Table Lexicale) :
    • on laisse fmin=2/vmax=200 pour la commande table lexicale, donc aussi pour la CA et CAH
    • on force fmin=1/vmax=9999999 pour la commande Spécificités
    • pour la commande Table Lexicale depuis Index de partition, on transmet le fmin et vmax de l'index à la table lexicale

BP 2019-04-04 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• Bug concernant le diagramme en bâtons de spécificités lorsque plusieurs lignes sont sélectionnées : la légende ne fait pas correspondre les bons mots (lignes) aux bons bâtons. En fait, dans la légende qui s'affiche à droite, c'est comme si l'ordre (vertical) des mots et l'ordre des couleurs étaient inversés l'un par rapport à l'autre, je crois que par exemple si on lit les couleurs de haut en bas et les mots de bas en haut on retrouve les bonnes correspondances couleur-mot (première couleur = dernier mot, 2e couleur = avant-dernier mot, etc.). Cependant, cela ne se produit pas systématiquement, mais je n'ai pas identifié ce qui pourrait être différent dans les situations où cela arrive vs où cela n'arrive pas.
  • MD reporté http://forge.cbp.ens-lyon.fr/redmine/issues/2562
  • BP 2019-04-12, BP 2019-04-15 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205) Il me semble que je peux préciser le diagnostic :
    • les bâtons sont triés selon l'ordre alphabétique des unités sélectionnées (tri alphabétique de la première colonne), ou l'ordre inverse, en tout cas l'ordre des bâtons est stable quel que soit l'ordre d'affichage des lignes dans le tableau ;
    • la légende est ordonnée selon l'ordre des lignes affichées dans le tableau au moment du lancement de la commande (par ex. selon un tri hiérarchique sur un indice de spécif. pour une colonne)
    • (Rq. au passage : si l'on a fait une sélection de lignes et que l'on change l'ordre des lignes, la sélection ne suit pas le mouvement des lignes, elle reste fixe pendant que les lignes bougent.)
    • Rq. principale : j'espère que ce diagnostic plus précis pourra aider à corriger le bug rapidement car il est important (il peut vraiment conduire à de grosses erreurs d'analyse).
    • MD corrigé

SJ:

• la suppression du texte de la barre de statut ne se fait plus au bout de X secondes, ça reste par exemple sur “Calcul de 2 clusters of columns…”
  • le plus simple serait de linker le contenu de la barre avec la Task name du JobJandler de TXMEditor.compute()
    • MD corrigé la status line est vidée à la fin du job
  • SH: le message “Calcul de 2 clusters of columns…” est du franglais, il devrait être :
    • EN: “Calculus of 2 clusters of columns…”
    • FR: “Calcul de 2 classes de colonnes…”
    • MD corrigé

SJ:

• la version beta3 et les version antérieures souffrent de problèmes liés au focus des composants qui se comporte différemment selon les systèmes d'exploitation. Le passage à Eclipse 4.7 a par ailleurs changé de nouveau les comportements avec la mise à jour de SWT
• Bugs répertoriés induits par les problèmes de focus :
  • Windows :
    • Menus contextuels ⇒ OK
    • Raccourcis clavier ⇒ OK sauf CA et Eigenvalues (note dev : le Context RCP ChartEditor se désactive à cause du MultiEditorPart, on peut voir par ailleurs que le menu contextuel sur la CA ou l'Eigenvalues ne contient pas les raccourcis)
    • Activation de l'Editeur au clic dans le graphique ⇒ OK
    • Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau “Colonnes” ou “Lignes” ⇒ OK
    • BUG Win 7: lancer une commande “non graphique” alors qu'un onglet avec graphique est déjà ouvert et actif repasse directement l'onglet avec graphique devant la nouvelle commande SJ: corrigé
  • Linux :
    • Menus contextuels ⇒ OK
    • Raccourcis clavier ⇒ KO mais marche parfois (note dev : pourtant le Context RCP ChartEditor est bien activé même quand cela ne fonctionne pas. Attention : en plus les autres raccourcis, ex. F2 (rename) ne fonctionnent pas toujours non plus et cela semble se produire plus souvent lorsqu'on a un onglet de graphique ouvert)
    • Activation de l'Editeur au clic dans le graphique ⇒ OK
    • Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau “Colonnes” ou “Lignes” ⇒ KO
      • note dev : je pense que les Listener clavier AWT et SWT sont exécutés en même temps. L'appui d'une flèche via AWT sélectionne la igne du tableau SWT et scroll jusqu'à elle ce qui doit bloquer la navigation par flèche dans le tableau
      • note dev 2 : cela ne fonctionne que si la CA perd le focus
    • BUGS Ubuntu 18.10:
      • lancer une commande “non graphique” alors qu'un onglet avec graphique est déjà ouvert et actif passe TXM en “arrière-plan”/grisé
      • quand on change d'onglets entre deux onglets de graphique, TXM passe en grisé et il faut recliquer une fois sur le titre de l'onglet pour l'activer
      • le composant AWT ne perd jamais le focus au clic à l'extérieur du composant ce qui provoque divers bugs (Un fix pourrait être implémenté dans ChartEditor.onPartDeactivated() ?)
  • Mac :
    • Menus contextuels ⇒ OK
    • Raccourcis clavier ⇒ OK si l'éditeur est actif (sauf CA et Eigenvalues)
    • Activation de l'Editeur au clic dans le graphique ⇒ OK
    • BUGS Mac OS X Mojave 10.14 :
      • le composant de l'AFC n'a jamais le focus donc la sélection de points dans le graphique au clavier ne fonctionnent pas
      • quand on change d'onglets entre deux onglets de graphique, le focus reste dans le composant du premier onglet
      • le composant AWT ne perd jamais le focus au clic à l'extérieur du composant ce qui provoque divers bugs (Un fix pourrait être implémenté dans ChartEditor.onPartDeactivated() ?)
    • Mise en évidence de points dans le nuage de points de l'AFC depuis la sélection au clavier des lignes du tableau “Colonnes” ou “Lignes” ⇒ OK

SJ: voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/1127

BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)

• Pour l'export des graphiques, il n'y a plus de préférence à régler ? Il faudra penser à indiquer dans le manuel comment le choix du format se fait (par le menu déroulant indiquant les types de fichiers en bas à droite de la boite de dialogue de sauvegarde, si j'ai bien compris).
  • SJ : la préférence est dans “TXM\Avancé\Moteur de Graphiques\Format d'export par défaut”
  • BP : OK, je l'ai bien trouvée et utilisée ; mais, pour faciliter la transition, si on permettait aussi le réglage à l'ancien endroit (TXM > Utilisateur > Export) ?

SJ:

• l'ouverture direct de fichier SVG à partir d'un fichier .svg ne fonctionne plus
  • SJ: corrigé

FB 2019-03-06

• qu'est ce que cet import ?
  • MD désolé c'est un renommage [SH: documenté dans la prochaine version du manuel de TXM (0.8 : télécharger le fichier ODT courant du manuel 0.8 en cours de rédaction)]

AL 2019-02-11

• Le nom du corpus est défini au moment du choix du dossier. C'est bien, mais c'est dommage qu'il ne soit plus modifiable (ni même affiché sauf dans la console) par la suite !
  • MD reporté changer le nom est un peu délicat. En attendant, j'ai ajouté le nom du corpus dans l'onglet de la fenêtre d'import. http://forge.cbp.ens-lyon.fr/redmine/issues/2563
• Les préférences (plans textuels, langue, etc.) des sources 0.7.9 (stockées dans import.xml) ne sont pas reprises, elle ne semblent pas non plus persister d'une session à l'autre sous 0.8. C'est très inconfortable si le corpus a beaucoup de réglages spécifiques.
  • MD corrigé à confirmer
  • AL correction confirmée TXM 0.8.0.201904161055
• La langue d'annotation sélectionnée par défaut est “FR”, or les fichiers .par disponibles après installation du TreeTagger sont “en.par”, “fr.par” et “fro.par”. Sous Linux, ça provoque une erreur, puisque TXM cherche le fichier “FR.par”
  • MD corrigé
• L'import échoue à l'étape cwb-makeall en cas de “présence d'absence de valeurs propriétés” (retour détaillé fait à MD par mail)
  • MD corrigé l'étape de tokenisation n'était pas faite
  • AL correction confirmée TXM 0.8.0.201904161055
• Après l'erreur cwb-makeall le corpus s'affiche tout de même dans la liste, et il n'y a pas de moyen de savoir s'il est fonctionnel ou non (0.7.9 affichait “corpus not ready” dans ce cas)
  • MD corrigé après un échec d'import les corpus ne devraient pas s'afficher

SJ 2019-02-19

• la fonction “Deviner” la langue ne fonctionne plus :

  Error: no C:\Users\s\TXM_0.8.0_dev\treetagger-models\??.par model file found for the ?? lang.
  Error while importing corpus during 'annotate' step, reason=TreeTagger annotation failed.
  End of Groovy import script: 573 msec (573 ms)
  Erreur: l'import ne s'est pas terminé correctement. Voir les messages précédent.
  

  • MD corrigé ticket #2511

FR 2019-03-20

• échec de l'import du corpus Hobbes8.1 dans TXM 0.8.0beta4 Windows :

  ApplyXsl2 with the C:\Users\Utente\TXM-0.8.0\hobbes-v8.1-li-noi-src\xsl\2-front\convert-pb-facs-eebo-id-to-filename.xsl stylesheet.
  Debug mode enabled.
  -- Applying C:\Users\Utente\TXM-0.8.0\hobbes-v8.1-li-noi-src\xsl\2-front\convert-pb-facs-eebo-id-to-filename.xsl XSL to 3 files with parameters: {output-directory=file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/src/} on directory C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC result written in C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC
  003 .copying inputfile to: C:\Users\Utente\TXM-0.8.0\corpora\HOBBESV81LINOISRC\txm\HOBBESV81LINOISRC\tmp\01elements.xml
  Error 
    I/O error reported by XML parser processing
    file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/txm/HOBBESV81LINOISRC/01elements.xml: Byte non valido 2 della sequenza UTF-8 a 3 byte.
  net.sf.saxon.trans.XPathException: I/O error reported by XML parser processing file:/C:/Users/Utente/TXM-0.8.0/corpora/HOBBESV81LINOISRC/txm/HOBBESV81LINOISRC/01elements.xml: Byte non valido 2 della sequenza UTF-8 a 3 byte.

  • MD corrigé

SLH 2019-03-24 (Ubuntu 18.04)

• l'import XML-TEI Zero+CSV ne lit pas les paramètres d'import dans le fichier import.xml de sources 0.7.9 : il faut qu'il le fasse. Il faut au minimum aider à décoder les valeurs de paramètres.
  • MD corrigé
  • AL correction confirmée TXM 0.8.0.201904161055

AL 2019-04-03 (Ubuntu 16.04, TXM 0.8.0.201903221605)

• les éditions supplémentaires créées par des scripts XSLT ne sont pas accessibles à la fin de l'import (il faut patcher à la main les fichiers de préférences)
• si on remplace un ancien corpus par un nouveau et que les noms des éditions changent, les anciennes préférences persistent
• impossible de définir les éditions par défaut sans patcher le fichier de préférences du projet
• MD en cours http://forge.cbp.ens-lyon.fr/redmine/issues/2564
• AL correction confirmée TXM 0.8.0.201904161055, mais un petit problème tout de même :
  • si les éditions XSL ne remplacent pas default et qu'elle est produite en mode groovy, l'édition existe, mais n'est pas déclarée

AL 2019-04-04 (Ubuntu 16.04, TXM 0.8.0.201903221605)

• l'étape XSLT “1-split-merge” ne fonctionne pas, message d'erreur :

Démarrage du script d'import Groovy xtzLoader.groovy.
-- Split-Merge XSL Step with /home/alavrent/xml/davydovachron-fr-txm080/xsl/1-split-merge
groovy.lang.MissingMethodException: No signature of method: static org.txm.importer.ApplyXsl2.processImportSources() is applicable for argument types: (File, [Ljava.io.File;, HashMap, Boolean) values: [/home/alavrent/xml/davydovachron-fr-txm080/xsl/1-split-merge/txm-merge-and-split-davydova.xsl, ...]
Possible solutions: processImportSources(java.io.File, [Ljava.io.File;, java.util.HashMap), processImportSources(java.io.File, java.io.File, java.io.File, java.util.HashMap, boolean), processImportSources(java.io.File, java.io.File, java.io.File), processImportSources(java.io.File, java.io.File, java.io.File, java.util.HashMap)
	at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1528)
	at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1514)
	at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:52)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:152)
	at org.txm.scripts.importer.xtz.XTZImporter.doSplitMergeXSLStep(XTZImporter.groovy:188)
...
	at org.txm.rcp.handlers.scripts.ExecuteImportScript$2.run(ExecuteImportScript.java:146)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

• corpus de test pour reproduire le bug : webdavs://sharedocs.huma-num.fr/dav.php/@Shares/(948) Cactus/(3788) Cactus/Projets/JournauxFrancophones/Corpus/sources/davydovachron-fr-txm080.zip
• avec TXM 0.7.9 l'étape split-merge se déroule sans erreur sur ce corpus, modulo le bug connu de persistance de fichiers output standard (http://forge.cbp.ens-lyon.fr/redmine/issues/2284)
  • MD corrigé
  • AL correction confirmée TXM 0.8.0.201904161055

FB 2019-03-06

• impossible d'importer un corpus en trs. Soit il se passe rien soit :

  Démarrage du script d'import Groovy transcriberLoader.groovy.
  org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
  file:/home/flora/TXM-0.8.0/scripts/groovy/user/org/txm/scripts/importer/transcriber/compiler.groovy: 134: The current scope already contains a variable of the name project
  

  • MD corrigé

BP 2019-04-02 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• dans le formulaire d'import, il y a une section pour régler le découpage en pages, son rôle n'est pas clair car le manuel utilisateur semble dire qu'on découpe plutôt selon les pages du traitement de texte.
• les étiquettes frpos du modèle TT FR habituel ont été passées en minuscules. Par ailleurs, j'ai l'impression que les lemmes eux aussi ont été “minisculisés” car la requête suivante ne donne aucun résultat :

  [frlemma = "[A-Z].+"]

  alors que la requête

"[A-Z].+"

[frpos = "nam"]

• MD corrigé

BP 2019-03-05 (Ubuntu 16.04, TXM 0.8.0.1826, 0.8.0.201902271548)

• L'import Alceste fonctionne, cependant la console ne donne pas de message indiquant que l'import est terminé, dans mon cas les dernières lignes affichées sont celles-ci :

  End of cwb-makeall logging process.
  -- EDITION - Building edition
  Paginating 714 texts
  %%% .........|.........|.........|.........|.........|.........|.........|.........|.........|.........|
  

  • MD corrigé

BP 2019-04-12 (Ubuntu 16.04, TXM 0.8.0.2009, 0.8.0.201904121205)

• Je ne sais pas si c'est spécifique à l'import Alceste, mais après j'ai constaté qu'après un tel import la commande Propriétés ne semble pas trouver le fichier de description HTML associé au corpus :

Information HTML file doesn't exist.
Stacktrace: 
[1]    org.txm.properties.rcp.editors.PropertiesEditor.updateEditorFromResult  PropertiesEditor.java, 157
[2]                      org.txm.rcp.editors.TXMEditor.               refresh  TXMEditor.java, 1061
[3]                      org.txm.rcp.editors.TXMEditor.            openEditor  TXMEditor.java, 1016
[4]                      org.txm.rcp.editors.TXMEditor.            openEditor  TXMEditor.java, 983
[5]  org.txm.properties.rcp.handlers.ComputeProperties.               execute  ComputeProperties.java, 82
[6]                            org.txm.rcp.Application.                 start  Application.java, 242

• Suite : Après avoir redémarré, la commande Propriétés semble fonctionner normalement (sur le corpus et sur la partition que j'avais créée, alors qu'elle ne fonctionnait ni sur l'un ni sur l'autre). En revanche, une partition que j'ai créée dans la session du premier lancement a un comportement anormal : les fréquences de l'index de partition sont anormalement basses, mais moins basses dans la dernière partie. Pourtant les tailles des parties semblent bonnes. Après un redémarrage, j'ai recréé la même partition, et cette fois-ci l'index de partition se comporte normalement.

FB 2019-03-06

• sous Linux, plus de préférences (onglet vide) dans TXM > Utilisateurs > Annotation
  • SLH : la rubrique “TXM > Utilisateurs > Annotation” est même doublée (et vide)
    • MD corrigé
• l'annotation ne fonctionne que sur les propriétés déjà présentes, on ne peut pas en recréer ? ou import différent ??
  • SLH : on peut ajouter de nouvelles propriétés de mots à annoter, consulter le fichier ODT courant du manuel 0.8 en cours de rédaction (voir la section 12.3 Annotation de propriétés de mots par concordances page 183)
• l'annulation de l'enregistrement d'une annotation provoque la suppression du corpus
  • MD corrigé

FB - 2019-03-08

• l'annotation est possible pour tous types de corpus mais ne peut s'enregistrer que sur un XML-“XTZ” (MD oui, seul l'import XTZ permet de mettre à jour le corpus). L'enregistrement est assez long, ça peut faire peur.
  • MD la sauvegarde de l'annotation rejoue les étapes compiler et pager de l'import XTZ
• Mettre une information comme quoi l'enregistrement est terminé et à fonctionné.
  • MD corrigé
• Peut-on avoir l'annotation sur plusieurs mots mais tout en gardant l'idée d'une seule annotation pour un groupe de mots ?
  • MD oui avec l'un des 2 modes d'annotation des structures

FB - 2019-02-18

• Suite au changement d'une propriété de mot et à son enregistrement, le corpus a ainsi été rechargé mais il n'y a plus les sous corpus et partition créés
  • MD corrigé

FB - 2019-03-06

• la macro buildwordproptable ne fonctionne plus
  • SJ: reporté, voir ticket http://forge.cbp.ens-lyon.fr/redmine/issues/2523

BP 2019-03-19 (Ubuntu 16.04, TXM 0.8.0 beta 4, 0.8.0.1913, 0.8.0.201903181603)

• Je me mets dans le cas de figure où je souhaite corriger des erreurs d'étiquetage TreeTagger dans le corpus VOEUX. Je construis une concordance de “des”, je vois que toutes les occurrences ont frpos=“PRP:det” et frlemma=“du”. Or dans un certain nombre de cas, où la construction est directe (sans préposition, passer au singulier par exemple pour s'en apercevoir), il faudrait frpos=“DET:ART” et frlemma=“un”. Je souhaite donc effectuer cette correction pour une ou plusieurs lignes sélectionnées.
  • je n'arrive pas à modifier en même temps la correction sur les deux propriétés (j'ai essayé par exemple en cliquant sur le dernier bouton “OK”). Du coup c'est particulièrement lourd pour faire cette double modification car la sélection faite pour la première modification est perdue dès que celle-ci est appliquée, il faut donc retrouver et re-sélectionner les lignes à modifier pour appliquer la 2e correction.
  • ayant corrigé l'annotation sur une occurrence, je sauve l'annotation, et j'ai dans la console des messages qui semblent confirmer que tout s'est bien passé :

Concordance de <"des|un"> dans le corpus VOEUX...
1069 occurrence(s).
Affectation de la valeur DET:ART à la propriété frpos pour 1 occurrences.
Affectation de la valeur un à la propriété frlemma pour 1 occurrences.
Enregistrement de 2 annotations...
Annotations enregistrées.

• pourtant, si je re-calcule à nouveau la concordance pour voir si mon annotation a bien changé, je ne retrouve pas ma modification, les valeurs de frlemma et frpos sont toujours les anciennes.
• faut-il revoir le code ? les messages dans la console ? ou la documentation ?
• MD corrigé la sauvegarde ne se faisait pas
• MD pour plus tard : revoir le scénario multi propriétés #2533

AL 2019-04-03 (Ubuntu 16.04, TXM 0.8.0.201903221605)

• la sauvegarde des annotations peut prendre plusieurs minutes (par exemple s'il faut re-générer des éditions XSLT ou si le corpus est volumineux). Or l'objet corpus reste actif pendant le réimport, on peut appeler des commandes pendant ce temps, ce qui provoque des erreurs. Le réimport se poursuit normalement toutefois.
  • MD en partie corrigé la fenêtre du job de re-import s'affiche devant l'UI par défaut, ce qui gêne le lancement d'autres commandes (voir ticket)
• le dernier message de la console après réimport est ”– Fetching page word IDs…
  001 .”. Il faudrait afficher un message plus explicite annonçant la fin de l'opération.
  • MD corrigé

SLH 2019-03-24 (Ubuntu 18.04)

• l'ajout des extension TreeTagger Software et TreeTagger models provoque les messages suivants dans la console, qu'il faut retirer :

  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.754
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.treetagger.binaries.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  
  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.758
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.treetagger.models.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  
  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.758
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.wordcloud.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  
  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.763
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.tigersearch.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  
  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.763
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.backtomedia.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  
  !ENTRY org.eclipse.equinox.p2.discovery 4 0 2019-03-23 17:26:16.767
  !MESSAGE Unknown category 'null' referenced by connector 'org.txm.annotation.urs.feature.feature.group' declared in http://textometrie.ens-lyon.fr/dist/0.8.0/ext/stable
  

  • MD corrigé

BP 2019-04-04 (Ubuntu 16.04, TXM 0.8.0, 0.8.0.1928, 0.8.0.201903221605)

• La macro ne fonctionne plus, elle indique le message d'erreur suivant :

  ** Erreur lors de l'exécution du script : groovy.lang.MissingMethodException: No signature of method: org.txm.specificities.core.functions.Specificities.getFrequency() is applicable for argument types: () values: []
  Possible solutions: getFrequencies()
  Stacktrace: 
  [1]  org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run  ExecuteGroovyScript.java, 270
  groovy.lang.MissingMethodException: No signature of method: org.txm.specificities.core.functions.Specificities.getFrequency() is applicable for argument types: () values: []
  Possible solutions: getFrequencies()
  	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:120)
  	at org.txm.macro.stats.BasicVocabularyMacro.run(BasicVocabularyMacro.groovy:72)
  	at groovy.util.GroovyScriptEngine.run(GroovyScriptEngine.java:599)
  	at org.txm.rcp.handlers.scripts.ExecuteGroovyScript$1.run(ExecuteGroovyScript.java:259)
  	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
  

  • MD corrigé