vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-01-12T12:30:35+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1220samples.timestamp devrait correspondre à la date des prélèvements2017-01-12T12:30:35+01:00Vidjil Teamsamples.timestamp devrait correspondre à la date des prélèvementsLes dates de prélèvement de la DB ne sont pas utilisées (où cela devrait être ? dans le .data ? dans le fuse ? dans le save analysis ?). Bref, pour l'instant les options "sampling date" (et la nouvelle "days after...") ne servent à rien ...Les dates de prélèvement de la DB ne sont pas utilisées (où cela devrait être ? dans le .data ? dans le fuse ? dans le save analysis ?). Bref, pour l'instant les options "sampling date" (et la nouvelle "days after...") ne servent à rien :-)
J'ai mis "à la main" dans le .fused de UPNT715 les dates correctes pour qu'on voie ce que cela doit donner.
Pour mémoire (car si on relance fuse, écrase...) :
"timestamp": [
"2009-11-03 20:03:29",
"2009-12-14 20:03:24",
"2009-12-14 20:03:24",
"2010-01-25 20:04:00",
"2010-01-25 20:03:54",
"2010-02-10 20:03:52",
"2010-02-10 20:04:33",
"2010-03-12 20:04:27",
"2010-03-12 20:04:22",
"2010-01-06 20:05:05",
"2010-04-06 20:04:58",
"2009-11-03 20:04:57"
],
***
85dd6226d92 : de manière temporaire, dates enlevées pour ne pas mettre de la confusion pour nos clients
***
parfait. J'ai remis l'affichage de la date sur rbx.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1239align.cgi ne fonctionne plus en tant que CGI2016-11-29T14:33:37+01:00Vidjil Teamalign.cgi ne fonctionne plus en tant que CGIDepuis le commit 59a1bcf6 Fasta::add() affiche un message sur cout. Or le CGI ouvre un fichier FASTA et le constructeur fait appel à la fonction add, du coup on se retrouve avec un
<== /tmp/VidjilAlignxndSPK 54 bp in 3 sequenc...Depuis le commit 59a1bcf6 Fasta::add() affiche un message sur cout. Or le CGI ouvre un fichier FASTA et le constructeur fait appel à la fonction add, du coup on se retrouve avec un
<== /tmp/VidjilAlignxndSPK 54 bp in 3 sequences
au début de la sortie, ce qui fait foirer le parsing du Json.
Vire-t-on l'affichage du Fasta (perso j'ai rien contre…) ? Ou autre solution ?
(J'avais aussi introduit d'autre problèmes en refactorant, c'est corrigé par a6ca2f2..19c540a)
***
2cb2d70 et 027ac25.
Cela rend fasta.cpp un peu plus lourd, mais de l'extérieur cela ne se voit pas. J'aime bien cet affichage, cela permet de se rendre compte de ce qu'il se passe.
***
Dans mon précédent message je faisais référence à des commits que j'ai oublié de pousser (pour corriger d'autres aspects) : du coup les commits sont 239b954..469d433
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1243'color by system' ne fonctionne pas2016-11-29T14:33:40+01:00Vidjil Team'color by system' ne fonctionne pas>> 46c54dc0118c0d
***
@Duez>> 46c54dc0118c0d
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1254Échec de l'upload : database is locked2016-11-29T14:33:49+01:00Vidjil TeamÉchec de l'upload : database is lockedParfois l'upload de fichier échoue. Exemple de ticket : https://rbx.vidjil.org/admin/default/ticket/vidjil/134.206.10.234.2014-11-13.14-22-22.5d2d0491-a1a0-4820-b599-1f760db3cfe5
On a un database locked. Est-ce dû aux limitations de sqli...Parfois l'upload de fichier échoue. Exemple de ticket : https://rbx.vidjil.org/admin/default/ticket/vidjil/134.206.10.234.2014-11-13.14-22-22.5d2d0491-a1a0-4820-b599-1f760db3cfe5
On a un database locked. Est-ce dû aux limitations de sqlite ? Peut-il y avoir plusieurs connexions en parallèle sur la base de données ?
***
Sur les gros fichiers (ou uploads longs) on a des « database is locked » qui semblent récurrents.
***
Exemple : https://rbx.vidjil.org/admin/default/ticket/vidjil/134.206.10.234.2014-12-16.12-39-46.3b1604d2-4155-4688-8ec9-15f37b79081e
***
http://www.motobit.com/help/scptutl/pa98.htm
la plupart des browsers sont limités a 2gb en upload (sauf chrome !!!!)
une solution serait d'utiliser l' API file de hml5 qui permet de slice un upload (mais c'est incompatible avec ie 10)
***
Mikaël, est-ce toujours d'actualité ?
***
Oui. Testé de chez moi avec un fichier de 900Mo. 1ère tentative échec : https://rbx.vidjil.org/admin/default/ticket/vidjil/109.190.80.52.2015-02-07.16-57-12.8b53effd-52a6-4e2b-ab20-c33798bc1a84
2è tentative : ok
***
Florian, des US, a essayé d'uploader... on a un (plusieurs) ticket(s) "Database is locked" :
https://rbx.vidjil.org/admin/default/ticket/vidjil/171.66.219.134.2015-03-09.17-49-31.93642c4b-06b2-44f7-8d4b-0fc8506d6376
***
Et aussi un "database is locked" ce matin du CBP
***
je reboote rbx, cela faisait > 1 semaine.
***
et ce matin, encore plein d'erreurs... aïe...
***
Florian a eu des soucis encore cette nuit... + on a eu des "No space left on device" ???
***
Trois "database locked" aujourd'hui, pour deux usagers différents
***
Plusieurs "<class 'sqlite3.OperationalError'> database is locked" encore aujourd'hui
***
Pas de 'database is locked' depuis quelque temps. Magie du MySQL ?
Priorité baissée, et on fermera courant mai si pas de soucis.
***
Le serveur a aussi été moins chargé ces derniers temps.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1255Send to IMGT/IgBlast en multi-système2016-11-29T14:33:50+01:00Vidjil TeamSend to IMGT/IgBlast en multi-systèmeSelon le système de la séquence sélectionnée, on doit donner les bons paramètres pour que la segmentation avec IMGT/IgBlast se fasse sur le bon système (par défaut il semble l'envoyer en TRG)
***
Prendre le système de la plus séquence sé...Selon le système de la séquence sélectionnée, on doit donner les bons paramètres pour que la segmentation avec IMGT/IgBlast se fasse sur le bon système (par défaut il semble l'envoyer en TRG)
***
Prendre le système de la plus séquence sélectionnée la plus abondante (car si on a sélectionné des séquences de systèmes différents, cela ne va de toute façon pas marcher pour tout le monde)
***
Euh... Demo L3 → clone principal IGH → igBlast → le fait en TRB et non pas en IGH
***
>>ba13fdc55ebd097
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1256Bugs consécutifs à l'échec d'upload2016-11-29T14:33:51+01:00Vidjil TeamBugs consécutifs à l'échec d'uploadSuite à un échec d'upload il ne semble pas possible de modifier les métadonnées du fichier ou de réuploader un fichier.
***
@DuezSuite à un échec d'upload il ne semble pas possible de modifier les métadonnées du fichier ou de réuploader un fichier.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1263Browser ne charge pas en offline2017-07-10T17:01:50+02:00Vidjil TeamBrowser ne charge pas en offlineReferenceError: germline_data is not defined germline_builder.js:60
C'est bloquant pour les tests browser…
***
pas de probleme en offline chez moi germline_data se trouve dans germline/germline.data qui est un fichier javascript (contra...ReferenceError: germline_data is not defined germline_builder.js:60
C'est bloquant pour les tests browser…
***
pas de probleme en offline chez moi germline_data se trouve dans germline/germline.data qui est un fichier javascript (contrairement a ce que laisse penser son extension) accessible en offline.
j'ai vu sur les log de jenkins le message
>> phantomjs : cannot connect to X server
qui est apparemment du a une version obsolete de phantomjs
***
Il y a bien germline/germlines.data mais il est à la racine du git. Il n'est pas dans browser. Or le browser y accède via url: window.location.origin + "/germline/germlines.data". Il s'attend donc à ce qu'il soit dans browser. Il ne manque pas un lien symbolique ou quelque chose sur le git ?
Plus précisément si j'y accède via mon serveur apache (URL vidjil.local, qui correspond au répertoire ~/Recherche/vidjil/browser), ça ne marche pas. Si j'y accède via l'URL directe ça fonctionne : file:///home/mikael/Recherche/vidjil/browser/index.html
Là où c'est bloquant c'est pas pour les tests unitaires mais pour les tests fonctionnels (watir).
***
window.location.origin renvoie juste le domain name (rbx.vidjil.org)
et il y a un fallback pour récupérer le fichier autrement depuis qu'il est en javascript.
le probleme doit venir du repertoire germline/
recemment j'ai rajouté dans etc/nginx/sites-available/web2py :
location /germline {
root /path/to/vidjil/;
expires max;
error_page 405 = ;
}
la modif a été faite sur rbx et dans le fichier d'instal mais certainement pas sur le serveur de test
***
Oui mais la racine du site web est dans browser, alors que germline est au dessus de la racine, c'est difficilement accessible, non ?
***
>>8d43922dbe7a
le browser n'a plus besoin d'accéder a germline/ , le script buildGermlineBrowser.py met tout ce dont le browser a besoin (germline.data et les sequences) dans germline.js
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1265Erreur d'affectation en multi-système2016-11-29T14:33:59+01:00Vidjil TeamErreur d'affectation en multi-systèmeSur certains patients (par exemple Leu en multi-système virtuel), on a un clone en IGL. Il devrait être séquencé en TRG mais la séquence est chimérique : plein de V, puis des J puis à nouveau des V. Elle est classée en tant que too few J...Sur certains patients (par exemple Leu en multi-système virtuel), on a un clone en IGL. Il devrait être séquencé en TRG mais la séquence est chimérique : plein de V, puis des J puis à nouveau des V. Elle est classée en tant que too few J. Elle devrait être notée ambigue/chimérique : ce qui signifierait que le germline est bon, mais qu'on ne peut rien faire. Il n'y a donc pas à continuer à chercher une affectation avec un autre germline.
***
a9b4ecc et a8d2c87
***
> diff /mnt/result/tmp/out-00053[48]/*.vidjil.log
- ==> segmented 1452687 reads (58%)
+ ==> segmented 1421376 reads (56.8%)
La différence vient bien de AMBIGUOUS :
- UNSEG ambiguous -> 1950 193.4
+ UNSEG ambiguous -> 327571 189.4
Mais... il reste toujours du IGL (moins) :
- IGL -> 47730 194.1
+ IGL -> 17081 191.9
(et quelques pouillèmes d'autres systèmes)
***
Youpi. 41b4f07
Le problème ne venait pas que TOO_FEW_J/V. Mais aussi STRAND, DELTA_MIN/MAX...
> diff /mnt/result/tmp/out-0005[34]4//000*.vidjil.log
- ==> segmented 1452687 reads (58%)
+ ==> segmented 1400617 reads (55.9%)
TRG -> 320591 194.8
- IGH -> 1081421 319.8
- TRA -> 45 186.7
- TRB -> 1602 197.2
- TRD -> 991 196.9
- IGK -> 307 185.9
- IGL -> 47730 194.1
+ IGH -> 1078450 319.7 *** on en a perdu un peu, ok ***
+ TRA -> 39 185.2
+ TRB -> 217 193.0
+ TRD -> 914 193.3
+ IGK -> 220 185.7
+ IGL -> 186 172.3 *** youpi ****
Plus de IGL (ou à peine, en tout cas rien dans le top 100).
Vérifié les 10 premiers clones à la main, les résultats sont conservés.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1267Capture un peu trop large des raccourcis clavier2016-11-29T14:34:00+01:00Vidjil TeamCapture un peu trop large des raccourcis clavierLes raccourcis tels que Ctrl+C ou Ctrl+T (nouvel onglet) ne fonctionnent plus lorsqu'on est sur le browser (et peut-être d'autres).
***
Je confirme. Embêtant quand on souhaite copier des bouts de séquence :)
***
>>acda0b93b8a5d0
***
merc...Les raccourcis tels que Ctrl+C ou Ctrl+T (nouvel onglet) ne fonctionnent plus lorsqu'on est sur le browser (et peut-être d'autres).
***
Je confirme. Embêtant quand on souhaite copier des bouts de séquence :)
***
>>acda0b93b8a5d0
***
merci
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1268Listes de gauches montrées même vides2016-11-29T14:34:01+01:00Vidjil TeamListes de gauches montrées même videsLes listes correspondant aux données externes (et à ... ?) occupent un espace important en hauteur alors qu'elles sont vides. Bug sous FF 31.2.0, pas sous Chromium.
***
>>df71399faa
***
@DuezLes listes correspondant aux données externes (et à ... ?) occupent un espace important en hauteur alors qu'elles sont vides. Bug sous FF 31.2.0, pas sous Chromium.
***
>>df71399faa
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1273Raisons de non-segmentation : remettre à plat, documenter ?2019-11-21T12:10:16+01:00Vidjil TeamRaisons de non-segmentation : remettre à plat, documenter ?Les commits jusqu'à 41b4f07 peuvent nous faire demander si les raisons de non-segmentation sont bien rangées.
En particulier STRAND par rapport à AMBIGUOUS.
On pourra faire cela pour heuristique 1.9 ou 2.0.
***
Un read uniquement avec d...Les commits jusqu'à 41b4f07 peuvent nous faire demander si les raisons de non-segmentation sont bien rangées.
En particulier STRAND par rapport à AMBIGUOUS.
On pourra faire cela pour heuristique 1.9 ou 2.0.
***
Un read uniquement avec des J est classifié parfois en tant que #UNSEG ambiguous, ce qui n'est pas vraiment attendu, parfois en tant que too few V.
Exemple :
#UNSEG ambiguous
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+J+J+J+J+J+J+J+J+J+J+J _
Mais aussi :
#UNSEG too few V
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+J+J+J
***
Ce n'est pas trop flou, c'est clairement un bug. Peut-être lié avec l'autre potentiel de ce matin :)
***
>TRDD2*01-TRDJ1*01
CCTTCCTACACACCGATAAACTCATCTTTGGAAAAGGAACCCGTGTGACTGTGGAACCAA
#UNSEG ambiguous
_ _ _ _ _ _ _ _ _+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J+J
>TRDV3*01-TRDD3*01
ATCTCTCCAGTAAGGACTGAAGACAGTGCCACTTACTACTGTGCCTTTAGACTGGGGGATACG
#UNSEG ambiguous
+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V+V _ _ _ _ _ _ _ _ _ _ _ _ _
***
En fait c'est bien à cause de 41b4f07105.
Si on détecte 10 k-mers, passe en AMBIGUOUS. Ce n'est pas très informatif, et surtout ce n'est pas souhaité si on fait derrière des réarrangements incomplets.
***
a8df78e, on n'aura plus ce bug.
Mais il faudra toujours remettre un jour les raisons de non-segmentation à plat, strand / detect.
***
Beaucoup mieux depuis 1f1f16e.
Mais une remise à plat serait toujours la bienvenue.
Autant faire cela après germlines.data et Aho-Corasick...
***
Et documenter cela.
***
Fait depuis 2015-05 et 2015-06
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1274send to IMGT: ne marche plus2016-11-29T14:34:06+01:00Vidjil Teamsend to IMGT: ne marche plusrbx → Demo (L2, TRG ou L3, multi) → clone principal → IMGT
***
bug ajouté avec (probleme d'initialisation) >> 50d5a2fffd08e7a
corrigé avec >> ba13fdc55ebd09
***
@Duezrbx → Demo (L2, TRG ou L3, multi) → clone principal → IMGT
***
bug ajouté avec (probleme d'initialisation) >> 50d5a2fffd08e7a
corrigé avec >> ba13fdc55ebd09
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1275On ne peut plus visualiser la séquence de clones "?/?"2016-11-29T14:34:07+01:00Vidjil TeamOn ne peut plus visualiser la séquence de clones "?/?"J'imagine que maintenant c'est limité à ceux du système en cours (est-ce souhaitable ? c'était rigolo d'aligner des TRG avec des IGH).
En tous cas, pour les ?/? on doit pouvoir voir la séquence.
***
@DuezJ'imagine que maintenant c'est limité à ceux du système en cours (est-ce souhaitable ? c'était rigolo d'aligner des TRG avec des IGH).
En tous cas, pour les ?/? on doit pouvoir voir la séquence.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1282Le renommage de clone ne fonctionne plus2016-11-29T14:34:12+01:00Vidjil TeamLe renommage de clone ne fonctionne plusclonelist → on renomme → save (ou entrée) → rien ne change
***
@Duezclonelist → on renomme → save (ou entrée) → rien ne change
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1288color by abundance at selected time point à l'intérieur d'un cluster2016-11-29T14:34:16+01:00Vidjil Teamcolor by abundance at selected time point à l'intérieur d'un clusterLa coloration ne fonctionne pas pour les clones à l'intérieur d'un cluster (lorsque le cluster a été « déplié »)
***
>> 25bb43b0f61247
***
@DuezLa coloration ne fonctionne pas pour les clones à l'intérieur d'un cluster (lorsque le cluster a été « déplié »)
***
>> 25bb43b0f61247
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1289Impossible de « décacher » le menu de gauche2016-11-29T14:34:17+01:00Vidjil TeamImpossible de « décacher » le menu de gaucheSous FF ou Chromium, une fois le menu de gauche caché (en cliquant sur la barre du milieu), impossible de le remontrer : il apparaît pour disparaître aussitôt
***
>> 9afd899311eb371
***
@DuezSous FF ou Chromium, une fois le menu de gauche caché (en cliquant sur la barre du milieu), impossible de le remontrer : il apparaît pour disparaître aussitôt
***
>> 9afd899311eb371
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1297Ne pas faire apparaître les points qui n'ont pas fini de tourner2016-11-29T14:34:23+01:00Vidjil TeamNe pas faire apparaître les points qui n'ont pas fini de tournerLorsqu'un point est en train de tourner avec Vidjil, il apparaît dans le graph, ce qui semble le faire bugger (les courbes apparaissent puis disparaissent rapidement). Or ce point n'existe pas encore puisqu'on n'a pas les résultats.
***
...Lorsqu'un point est en train de tourner avec Vidjil, il apparaît dans le graph, ce qui semble le faire bugger (les courbes apparaissent puis disparaissent rapidement). Or ce point n'existe pas encore puisqu'on n'a pas les résultats.
***
7d9f4ce422
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1302Bouton de normalisation non cohérent avec l'affichage dans le graphique2017-05-11T17:25:19+02:00Vidjil TeamBouton de normalisation non cohérent avec l'affichage dans le graphiqueExemple avec le patient Leu où les courbes ne sont pas normalisées mais le radio button est sélectionné.
***
@DuezExemple avec le patient Leu où les courbes ne sont pas normalisées mais le radio button est sélectionné.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1305Sauvegarde impossible du fichier analysis2016-11-29T14:34:29+01:00Vidjil TeamSauvegarde impossible du fichier analysisPour le patient MAQ : impossible de sauvegarder l'analysis en étant connecté en admin ou en lille. Message : database : id patient file needed, id config needed, you do not have permission to save changes on this patient
***
b3f0afa, mer...Pour le patient MAQ : impossible de sauvegarder l'analysis en étant connecté en admin ou en lille. Message : database : id patient file needed, id config needed, you do not have permission to save changes on this patient
***
b3f0afa, merci Marc
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1306Alignement : la séquence majoritaire n'est plus la première affichée2016-11-29T14:34:30+01:00Vidjil TeamAlignement : la séquence majoritaire n'est plus la première affichéeComme la segmentation se fait en fonction de la première, c'est gênant (et en plus on la cherche en se demandant où elle est).
***
43e053a02
***
ok
***
@DuezComme la segmentation se fait en fonction de la première, c'est gênant (et en plus on la cherche en se demandant où elle est).
***
43e053a02
***
ok
***
@Duez