vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:35:19+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1365Heuristique multi-systèmes 1.9, marquer les k-mers ambigus entre plusieurs sy...2016-11-29T14:35:19+01:00Vidjil TeamHeuristique multi-systèmes 1.9, marquer les k-mers ambigus entre plusieurs systèmes
***
@magiraud
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1363Dd-Ja2016-11-29T14:35:17+01:00Vidjil TeamDd-Ja1 réarrangements de Necker (pool 94, leur patient B1) est un Dd2 - Dd3 - Ja29
J'imagine qu'on le détecte en Dd2-Dd3.
A voir si on traite (on ne va pas traiter tous les cas les plus rares ?)
***
Avec l'automate d'Aho-Corasick (ou tout aut...1 réarrangements de Necker (pool 94, leur patient B1) est un Dd2 - Dd3 - Ja29
J'imagine qu'on le détecte en Dd2-Dd3.
A voir si on traite (on ne va pas traiter tous les cas les plus rares ?)
***
Avec l'automate d'Aho-Corasick (ou tout autre index qui indexe tous les germlines en même temps), les réarrrangements atypiques peuvent être gérés simplement : théoriquement on a les affectations des différents gènes qui se suivent. En pratique il y a aussi des faux positifs qu'il faut savoir éliminer.
***
À terme, ajouter un réarrangement bizarre ne nous demandera que quelques lignes depuis germlines.data, et de bien viser les "follows", le mieux on visera le moins on aura de faux positifs.
Et on a besoin de transformer "follows" pour qu'il prenne une liste :
TRD > Dd2-Jd > Dd2-Dd3
TRD > Dd2-Ja > Dd2-Dd3
Dd2-Dd3 ne doit être testé qu'après Dd2-Jd et Dd2-Ja.
***
On n'avait pas des problèmes en VdJa (demander Yann/Aurélie) ? Ja 29 ?
***
Ben si… https://www.producteev.com/workspace/t/553fc9bab0fa09cf47000017
***
Normalement c'est bon.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1362Upload de plusieurs fichiers via des formulaires web2018-03-21T19:04:38+01:00Vidjil TeamUpload de plusieurs fichiers via des formulaires webTâche spécialisée depuis la tâche originale déplacée dans #2891.
Tâche spécialisée depuis la tâche originale déplacée dans #2891.
Web 2018.01Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1361Événements pour un patient : utilité, modèle2021-11-19T11:06:56+01:00Vidjil TeamÉvénements pour un patient : utilité, modèleOn souhaiterait pouvoir ajouter des événements (date + texte) à chaque patient.
Ces événements seraient indiqués par des marqueurs sur le graphe (et sur les rapports .html / .pdf)
Arguments pour : une greffe est une info importante, on ...On souhaiterait pouvoir ajouter des événements (date + texte) à chaque patient.
Ces événements seraient indiqués par des marqueurs sur le graphe (et sur les rapports .html / .pdf)
Arguments pour : une greffe est une info importante, on doit le voir au premier coup d'oeil
Arguments contre : cela fait un peu trop dossier patient... va-t-on aussi indiquer un changement de traitement ou autre ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1360changer les systèmes sélectionnés devrait aussi mettre à jour le total des cl...2017-07-05T09:15:56+02:00Vidjil Teamchanger les systèmes sélectionnés devrait aussi mettre à jour le total des clonesEn multi-système, si on change l'affichage TRG / IGH / ... (boite en haut à gauche), le % de clones de la somme devrait se mettre à jour.
***
C'est toujours le cas (pas poussé ?)
***
merci !
***
@CyanaelEn multi-système, si on change l'affichage TRG / IGH / ... (boite en haut à gauche), le % de clones de la somme devrait se mettre à jour.
***
C'est toujours le cas (pas poussé ?)
***
merci !
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1359export html: transformation en .pdf par le serveur2022-06-20T10:10:27+02:00Vidjil Teamexport html: transformation en .pdf par le serveurPriorité basse, à voir même si c'est utile
***
@nobodyPriorité basse, à voir même si c'est utile
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1358cette page html est auto-contenue (css)2016-11-29T14:35:13+01:00Vidjil Teamcette page html est auto-contenue (css)
***
#1356
***
#1356https://gitlab.inria.fr/vidjil/vidjil/-/issues/1357export ouvre un nouvel onglet, page html avec le rapport2016-11-29T14:35:13+01:00Vidjil Teamexport ouvre un nouvel onglet, page html avec le rapport
***
#1356
***
#1356https://gitlab.inria.fr/vidjil/vidjil/-/issues/1356export html: Transformer l'export pdf en export html2016-11-29T14:35:13+01:00Vidjil Teamexport html: Transformer l'export pdf en export htmlOn passe donc tout en html.
Au bout, on supprimera pdf.js ? (il y a encore le graphe .pdf pour l'article)
***
Merci Marc, on va dire que globalement c'est bon, on crée des nouvelles tâches pour les bugs restants.
***
#1357, #1358
***
@DuezOn passe donc tout en html.
Au bout, on supprimera pdf.js ? (il y a encore le graphe .pdf pour l'article)
***
Merci Marc, on va dire que globalement c'est bon, on crée des nouvelles tâches pour les bugs restants.
***
#1357, #1358
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1355Axes lors de la normalisation2017-04-03T16:41:11+02:00Vidjil TeamAxes lors de la normalisationJ'ai toujours du mal à comprendre les axes de la normalisation par data.
http://rbx.vidjil.org/browser/?data=demo/external-data-test.vidjil&analysis=demo/external-data-test.analysis
Choisir qPCR (il n'y a en qu'un), normalize to 0.01 (o...J'ai toujours du mal à comprendre les axes de la normalisation par data.
http://rbx.vidjil.org/browser/?data=demo/external-data-test.vidjil&analysis=demo/external-data-test.analysis
Choisir qPCR (il n'y a en qu'un), normalize to 0.01 (ou 1, ou n'importe quoi)... le calcul est bien fait mais l'axe de gauche monte très haut (alors que les données ne vont "que" jusqu'à 1000% ou environ)
***
e34f85b, merci Marc !
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1354Upload de plus de 2G impossible2021-02-04T16:53:22+01:00Vidjil TeamUpload de plus de 2G impossibleDans les logs nginx :
2014/12/15 17:35:29 [error] 4101#0: *7459 client intended to send too large body: 2598841529 bytes
***
Option client_max_body_size dans le fichier de conf de l'hôte à changer mais cela ne résoud pas le problème pui...Dans les logs nginx :
2014/12/15 17:35:29 [error] 4101#0: *7459 client intended to send too large body: 2598841529 bytes
***
Option client_max_body_size dans le fichier de conf de l'hôte à changer mais cela ne résoud pas le problème puisqu'une autre erreur émerge : « upstream prematurely closed connection while reading response header from upstream ». Ô joie !
***
Erreur qui est synchro avec ces erreurs de web2py dans /var/log/uwsgi/uwsgi.log) :
Mon Dec 15 17:44:59 2014 - HARAKIRI !!! worker 2 status !!!
Mon Dec 15 17:44:59 2014 - HARAKIRI [core 0] 134.206.10.234 - POST /vidjil/file/upload since 1418661838
Mon Dec 15 17:44:59 2014 - HARAKIRI !!! end of worker 2 status !!!
Mon Dec 15 17:45:01 2014 - *** HARAKIRI ON WORKER 2 (pid: 16537, try: 2) ***
Mon Dec 15 17:45:01 2014 - HARAKIRI !!! worker 2 status !!!
Mon Dec 15 17:45:01 2014 - HARAKIRI [core 0] 134.206.10.234 - POST /vidjil/file/upload since 1418661838
Mon Dec 15 17:45:01 2014 - HARAKIRI !!! end of worker 2 status !!!
***
Bon, bon… alors augmenter le délai dans l'option harakiri de /etc/uwsgi/web2py.ini aide évidemment. Plus de tels messages d'erreurs. Mais… nginx sort maintenant un « upstream timed out (110: Connection timed out) while reading response header from upstream ». Ouiiin :(
***
Après l'ajout, dans /etc/nginx/sites-available/web2py de la section suivante :
location /vidjil/file/upload {
proxy_read_timeout 600;
}
l'upload ne fonctionne toujours pas sur mon fameux fichier… plus de message d'erreur dans les logs par contre (enfin si il reste toujours des « client intended to send too large body: 2598841526 bytes » erratiques, mais c'est tout)… J'abandonne pour ce soir :(
***
Juste par curiosité, on a vraiment un fichier de séquences de plus de 2G ?
***
Non, non je ne me prends pas la tête pour le plaisir, il y a un vrai fichier de plus de 2G (jeux de données des jumeaux). Et les problèmes de timeout je les rencontre sur des fichiers de 2G mais seulement parce que la connexion est très bonne. Avec une moins bonne connexion ils arriveraient sur des fichiers bien moins gros.
***
ok
***
Le location /vidjil/file/upload da,s /etc/nginx/sites-available/web2py a été enlevé (ça ne semblait pas résoudre le problème et en causait d'autres). En revanche il a fallu ajouter des client_max_body_size à d'autres endroits de la config pour que ce soit pris en compte par nginx (y compris dans le fichier de conf principal de nginx).
Le problème restant correspond à un database is locked, voir la tâche correspondante pour éviter les duplications.
***
Mikaël, toujours d'actualité ? Marc a pas mal changé l'uploader depuis
***
Non plus d'actualité : Jack a pu uploader des fichiers de 3G et j'ai pu aussi le faire.
***
Hmm… j'ai peut-être parlé un peu vite. L'upload était quasiment fini je pensais que c'était gagné mais en fait non. Pas de ticket web2py mais des erreurs dans les logs nginx : upstream prematurely closed connection while reading response header from upstream, client: 134.206.10.234, server: dev.vidjil.org, request: "POST /vidjil/file/upload HTTP/1.1", upstream: "uwsgi://unix:///tmp/web2py-dev.socket:" (ce qui est déjà l'erreur que j'avais il y a 3 mois).
Deux essais, deux échecs (depuis le labo).
***
Marche sous Chrome pas sous FF. C'est ce que disait Marc et c'est vérifié : « 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) »
***
On va faire simple : 8695d4b
Priorité toujours basse, donc, et ce n'est plus un bug, une limitation.
Attendons que les browsers se soient améliorés...
***
Remonté, on a de nombreux échecs. Ce n'est pas qu'un problème de navigateur. uwsgi se fait de nombreux harakiri à cause de l'upload :
sudo grep 'HARAKIRI.*upload' /var/log/uwsgi/uwsgi.log
(et ce sont ses seules causes d'harakiri récentes)
***
C'est très ballot parce que les fichiers semblent uploadés complètement. Le problème vient *après* (ce n'est donc pas un problème du navigateur, probablement pas du serveur web). Les fichiers sont dans /mnt/upload/tmp tels que transférés par le navigateur web. D'ailleurs ils ne semblent pas automatiquement effacés si l'upload foire !
D'ailleurs le problème survient après que l'indicateur d'upload indique « server check ». Que fait ce server check ?
***
C'est juste dans database.js, le fichier est tout chargé, mais il se passe quelque chose côté serveur. Quoi ?
***
Marc m'a dit que le server check s'occupe de copier le fichier au bon endroit (mais c'est fait côté web2py on n'a pas la main dessus). Les logs d'uwsgi montrent ceci :
INFO:vidjil: 134.206.239.24/team/LIFL file 17 (1): upload finished (6.44 GB)
Wed Mar 25 18:04:17 2015 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /vidjil/file/upload (ip 134.206.239.24) !!!
Wed Mar 25 18:04:17 2015 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during POST /vidjil/file/upload (134.206.239.24)
IOError: write error
***
Ce ne serait pas cela ?
http://lists.unbit.it/pipermail/uwsgi/2011-August/002520.html
> Normally it is nothing you should care about.
> If a client disconnect from the webserver, uwsgi will knows it only after
> data sending. This trigger a sigpipe that uwsgi reports for diagnostic
> purpose. You can disable it with --ignore-sigpipe
***
https://www.pythonanywhere.com/forums/topic/721/
Même genre de discussion
***
The server log comes from your uWSGI workers, which are the ones actually talking to the outside world, and asking your code to respond to requests. They are saying that they sometimes get disconnected from the client half-way through sending a response, and then that causes an error that appears in your error log. This isn't a problem that you can fix, but also it is probably not one you need to worry about. Sometimes, clients disconnect, that is something that happens every day. uWSGI is just a bit over-enthusiastic about logging this. There is an option to switch off SIGPIPE logging in uWSGI which we will investigate.
Ce qui serait normal que le client "déconnecte" au bout d'un gros fichier...
***
(je passe à autre chose, rdv tout à l'heure)
***
Après que le serveur indique “upload failed”, il y a toujours des écritures disques (beaucoup) :
8257 be/4 www-data 51.48 M/s 51.44 M/s 0.00 % 90.90 % uwsgi --ini web2py-dev.ini
ça tendrait donc à laisser penser qu'il y a un timeout
***
Et de façon intéressante (bis) le fichier semble bien pris en compte par le serveur (en ayant changé certains trucs dans le fichier de config) : il indique sa taille mais upload failed (cf.dev.vidjil.org avec l'utilisateur test@vidjil.org)
***
Le ignore-sigpipe permet certes de retirer le message d'erreur du log mais ne retire pas les autres…
INFO:vidjil: 134.206.234.249/team/LIFL file 20 (1): upload finished (6.44 GB)
Thu Mar 26 18:36:47 2015 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during POST /vidjil/file/upload (134.206.234.249)
IOError: write error
***
On a eu plusieurs 6GB uploadés depuis... est-ce que cela est toujours d'actualité ?
***
Non, ce n'est plus d'actualité.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1353algo: minor release 2014.122016-11-29T14:35:09+01:00Vidjil Teamalgo: minor release 2014.12Maintenance release, quasi rien, experimental -i.
On release quand même.
***
@magiraud @mikael-sMaintenance release, quasi rien, experimental -i.
On release quand même.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1352export html: diagnostic2016-11-29T14:35:08+01:00Vidjil Teamexport html: diagnosticPourrait-on ajouter des infos quand on seul point ? On doit réfléchir à ce qu'on voudrait pour le pdf du diagnostic, si possible avant la rencontre à Necker.
- Pie montrant la répartition par système ?
- Scatterplots ?
***
C'est bien sca...Pourrait-on ajouter des infos quand on seul point ? On doit réfléchir à ce qu'on voudrait pour le pdf du diagnostic, si possible avant la rencontre à Necker.
- Pie montrant la répartition par système ?
- Scatterplots ?
***
C'est bien scatterplot*s* au pluriel, on pense au diagnostic multi-système
***
Excellent, cela commence à être très beau !
Pour le rapport diag, on s'attendrait à voir aussi un div float-left avec les read statistics
***
Sur le rapport diagnostic, pour chaque clone, on n'a pas à voir les % de chaque timepoint, ni la mini-icône avec l'évolution
(Et la remarque ci-dessous vaut-toujours.)
***
merci
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1351Chargement d'analysis avec champ "data"2018-02-23T10:04:51+01:00Vidjil TeamChargement d'analysis avec champ "data"(priorité haute, envoi mail à Nikos)
(voir les fichiers browser/demo/* sur rbx)
Même sans résoudre la tache API analysis, l'URL suivante devrait fonctionner :
http://rbx.vidjil.org/browser/?data=demo/external-data-test.vidjil&analysis...(priorité haute, envoi mail à Nikos)
(voir les fichiers browser/demo/* sur rbx)
Même sans résoudre la tache API analysis, l'URL suivante devrait fonctionner :
http://rbx.vidjil.org/browser/?data=demo/external-data-test.vidjil&analysis=demo/external-data-test.analysis
La seule différence entre le external-data-test.analysis et le LIL-L3 analysis est ce bloc :
"data": {
"qPCR" : [0.95, 0.00003, 0.002, 0.1, 0.95],
"dataTest2" : [ 5, 400, 0.1, 0.02, 1]
},
Et on obtient, dans model.js :
undefined is not an object (evaluating 'this.data[key] = this.analysis.data[key]')
Me suis-je trompé dans le format, ai-je oublié quelque chose ?
***
merci
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1350API: le analysis=xxxx ne fonctionne pas2016-11-29T14:35:07+01:00Vidjil TeamAPI: le analysis=xxxx ne fonctionne pas(haute priorité, pour envoi à Nikos)
J'aimerais faire fonctionner l'URL suivante
http://rbx.vidjil.org/browser/?data=demo/LIL-L3.vidjil&analysis=demo/external-data-test.analysis
En fait, le paramètre analysis est bien récupéré dans ma...(haute priorité, pour envoi à Nikos)
J'aimerais faire fonctionner l'URL suivante
http://rbx.vidjil.org/browser/?data=demo/LIL-L3.vidjil&analysis=demo/external-data-test.analysis
En fait, le paramètre analysis est bien récupéré dans main.js, d'où loadAnalysisUrl()
est appelé. Mais cela ne marche pas
1) model.js : loadDataUrl() appelle aussi un loadAnalysisUrl(), écrasant le choix du paramètre
2) même en enlevant cet appel, cela ne marche pas (appelé trop tôt ?)
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1349Point non montré2016-11-29T14:35:06+01:00Vidjil TeamPoint non montréSur ce patient en IGH http://rbx.vidjil.org/browser/index.html?patient=66&config=2 on ne voit qu'un point. Or deux ont tourné. Le fichier .data contient les deux points. Vidjil et le fuse semblent avoir tourné sans encombre (/mnt/result/...Sur ce patient en IGH http://rbx.vidjil.org/browser/index.html?patient=66&config=2 on ne voit qu'un point. Or deux ont tourné. Le fichier .data contient les deux points. Vidjil et le fuse semblent avoir tourné sans encombre (/mnt/result/tmp/out-000713//000713.vidjil.log et /mnt/result/tmp/out-000713//000713.fuse.log).
***
je vois deux points chez moi :)
***
effectivement… :-/
Rassure-moi, t'as touché un truc Marc ?
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1348Warnings pour les normalisations2018-02-16T17:49:32+01:00Vidjil TeamWarnings pour les normalisationsWarning sur certains points :
1) pour les deux méthodes, quand le standard diffère de + d’un log de son expected value
« Before normalization, the size of the normalizing clone (NAME) was Xxx%. This size was very far from his expected v...Warning sur certains points :
1) pour les deux méthodes, quand le standard diffère de + d’un log de son expected value
« Before normalization, the size of the normalizing clone (NAME) was Xxx%. This size was very far from his expected value of Xxx%. »
2) et pour "to-100%", warning si la quantité non-100% aurait été bcp plus grande (disons un log, > 1000%) « Before normalization, the size of the dominant clone (NAME) was Xxx%. A constant normalization would have yield a size of Xxxx%. »
Dans les deux cas, icône warning à côté du time point + tooltip/balloon help pour le message de warning (comme pour les too few segmented)
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1347L'onglet "users" ne fonctionne plus sur rbx2016-11-29T14:35:04+01:00Vidjil TeamL'onglet "users" ne fonctionne plus sur rbx→ donner à Nikos tous les droits (y compris run Vidjil)
***
C'est toujours le cas, j'imagine que c'est juste que ce n'est pas encore pushé...
Proposition :
- pour fermer une tâche qui mentionne rbx, on va dire qu'il faut que cela f...→ donner à Nikos tous les droits (y compris run Vidjil)
***
C'est toujours le cas, j'imagine que c'est juste que ce n'est pas encore pushé...
Proposition :
- pour fermer une tâche qui mentionne rbx, on va dire qu'il faut que cela fonctionne... sur rbx :-)
- en contrepartie, on ne mentionne rbx que si c'est vraiment bloquant en production (comme ici)
***
merci, parfait
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1346Antonin : retravailler et faire marcher le graphe2021-07-09T19:53:23+02:00Vidjil TeamAntonin : retravailler et faire marcher le grapheMoins important que l'implémentation de dbscan.
Et difficile, pour avoir un graphe vraiment convaincant.
***
http://www.fil.univ-lille1.fr/~decomite/ue/ResumesStages/2014/resumes/carette/resume.php
***
Gianni Cazzaniga demande si on peu...Moins important que l'implémentation de dbscan.
Et difficile, pour avoir un graphe vraiment convaincant.
***
http://www.fil.univ-lille1.fr/~decomite/ue/ResumesStages/2014/resumes/carette/resume.php
***
Gianni Cazzaniga demande si on peut faire "hierarchical tree"
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1345Python 3 pour web2py / web3py2022-06-29T18:49:19+02:00Vidjil TeamPython 3 pour web2py / web3pyweb2py → non pour l'instant, et apparament il ne sont pas prêt de le faire
Il reste `fuse.py` et le reste → mais on en inclut aussi depuis le server, donc attention
Bref bof pour l'instant.
***
web2py, toujours pas de nouvelles là-des...web2py → non pour l'instant, et apparament il ne sont pas prêt de le faire
Il reste `fuse.py` et le reste → mais on en inclut aussi depuis le server, donc attention
Bref bof pour l'instant.
***
web2py, toujours pas de nouvelles là-dessus : https://groups.google.com/forum/#!topic/web2py/UKcWKU66qnA
(pour info, Algomus passe en python3, après 2 ans de tergiversations)