vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-04-05T09:51:21+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2847Problème avec align quand on change de patient : `this.sequence` dans Segmen...2018-04-05T09:51:21+02:00Thonier FlorianProblème avec align quand on change de patient : `this.sequence` dans Segmenter n'est pas mise à jourUne remarque de ~"LIL-Lille" : de temps en temps, la fonction alignement ne fonctionne pas. Je présume qu'il doit s'agir d'un problème dnas l'accès au fichier CGI, ou bien d'un timeout dependant de leur réseau. Il faudrait avoir un log q...Une remarque de ~"LIL-Lille" : de temps en temps, la fonction alignement ne fonctionne pas. Je présume qu'il doit s'agir d'un problème dnas l'accès au fichier CGI, ou bien d'un timeout dependant de leur réseau. Il faudrait avoir un log qui correspond dans ce cas.
Sinon, rechercher l'origine de l'erreur, mais a priori completement aléatoire.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2999Release 2018.01 -> 2018.022018-04-05T12:16:02+02:00Mathieu GiraudRelease 2018.01 -> 2018.02Comment faire la release 2018.01 ?
- soit aller au bout de #2255 (peut-être pas si complexe). Je vais y rejeter un coup d'oeil
- soit faire un truc complètement manuel et/ou réverter des choses
- soit, intermédiaire, utiliser #2255 / !97...Comment faire la release 2018.01 ?
- soit aller au bout de #2255 (peut-être pas si complexe). Je vais y rejeter un coup d'oeil
- soit faire un truc complètement manuel et/ou réverter des choses
- soit, intermédiaire, utiliser #2255 / !97 et rajouter à la main s'il manque des choses. Cela va peut-être dans le bon sens (en tout cas la simplification de #2255 / !97, quand cela fonctionnera, est indéniable...)
Repasser dans tous les cas sur la fin de #2630.
Au passage, on devrait avoir un test de release ? #2720Algo 2017.11Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3077Erreur serveur en visualisant des résultats sur la branche feature-w/multi_up...2018-04-05T17:26:31+02:00Mikaël SalsonErreur serveur en visualisant des résultats sur la branche feature-w/multi_uploadL'accès à ces données : https://dev.vidjil.org/browser/index.html?set=42&config=3 produit une [erreur serveur](https://dev.vidjil.org/admin/default/ticket/vidjil/134.206.27.223.2018-03-06.19-11-26.f7e19838-ecf0-4300-a717-4295f8f075e8) si...L'accès à ces données : https://dev.vidjil.org/browser/index.html?set=42&config=3 produit une [erreur serveur](https://dev.vidjil.org/admin/default/ticket/vidjil/134.206.27.223.2018-03-06.19-11-26.f7e19838-ecf0-4300-a717-4295f8f075e8) si dev est sur la branche `feature-w/multi_upload` mais pas si elle est sur la branche `dev` :
```
AttributeError: 'NoneType' object has no attribute 'group_id'
```Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3138Les utilisateurs ne peuvent pas supprimer ou éditer les nouveaux sample sets ...2018-04-05T19:00:00+02:00Mikaël SalsonLes utilisateurs ne peuvent pas supprimer ou éditer les nouveaux sample sets créésConstaté sur les comptes 48 ou 70 qui ont utilisé la nouvelle fonctionnalité.Constaté sur les comptes 48 ou 70 qui ont utilisé la nouvelle fonctionnalité.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3140Les flèches < > sur un sample set amènent à un autre sample set complètement ...2018-04-06T07:07:21+02:00Mikaël SalsonLes flèches < > sur un sample set amènent à un autre sample set complètement randomUn problème peut-être similaire à #3138 ?
En attendant une correction je vais virer à la main les flèches…Un problème peut-être similaire à #3138 ?
En attendant une correction je vais virer à la main les flèches…https://gitlab.inria.fr/vidjil/vidjil/-/issues/3144Bloquer la tabulation sur le specific set des add sample2018-04-06T11:00:46+02:00Thonier FlorianBloquer la tabulation sur le specific set des add sampleJ'ai testé hier le multiupload, et je me suis aperçu d'un bug lorsque l'on utilise la tabulation pour remplir les différents champs on tombe sur un os pour le champ `specific set`.
Dans le cas pratique si on tabule dans cette zone, on ...J'ai testé hier le multiupload, et je me suis aperçu d'un bug lorsque l'on utilise la tabulation pour remplir les différents champs on tombe sur un os pour le champ `specific set`.
Dans le cas pratique si on tabule dans cette zone, on valide le choix d'auto-complétion sur lequel on est et on en ouvre un nouveau. Du coup on ne peux jamais en sortir.
Je ne sais pas si le comportement est souhaitable. Valider l’auto-complétion par la tabulation est un comportement proche de ce qui est connu sur Linux, par contre on ne peut jamais quitter la boucle.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3035split-from-imgt.py : germlines J gappées2018-04-06T12:03:40+02:00Mathieu Giraudsplit-from-imgt.py : germlines J gappéesDepuis #3008 :
> Discuté ensemble : c'est similaire à #2187, il faudrait mettre des séquences gappées. Voir `gap_j` dans `split-from-imgt.py`.Depuis #3008 :
> Discuté ensemble : c'est similaire à #2187, il faudrait mettre des séquences gappées. Voir `gap_j` dans `split-from-imgt.py`.Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/967Antonin : refaire marcher dbscan en javascript2018-04-09T14:45:43+02:00Vidjil TeamAntonin : refaire marcher dbscan en javascript- repenser dbscan / distance, de quoi a-t-on besoin
- pour l'instant caché dans index.html
***
merci pour le merge !
et oui, réouvert car il faudra voir ce qu'on intègre, mais ce n'est plus très urgent
***
- ne passe pas pour l'instant ...- repenser dbscan / distance, de quoi a-t-on besoin
- pour l'instant caché dans index.html
***
merci pour le merge !
et oui, réouvert car il faudra voir ce qu'on intègre, mais ce n'est plus très urgent
***
- ne passe pas pour l'instant à fuse.py
***
Sur certaines données (14-08-Necker), le script bloque dans dbscan.js...
Est-ce possible de le désactiver pour l'instant ? merci.
Script : file:///.../vidjil/browser/js/dbscan.js:121
***
désactivé pour le moment
***
merci, repasse donc en basse priorité
***
Au programme du prochain Vidjil Day
***
Uniquement la fonctionnalité dbscan (et donc matrice de distance à récupérer).
Pas besoin pour l'instant du graphe à visualiser
***
Plutôt en février...
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1492Translocations, régions aval/amont2018-04-10T12:27:08+02:00Vidjil TeamTranslocations, régions aval/amontFaut-il rentrer des gènes entiers où il pourrait y avoir des translocations ? et/ou autre structure d'index pour stocker cela ?
(Voir tâche "BCL2 / JH")
Même sans parler de translocation, c'est très tentant de mettre quelque part le lo...Faut-il rentrer des gènes entiers où il pourrait y avoir des translocations ? et/ou autre structure d'index pour stocker cela ?
(Voir tâche "BCL2 / JH")
Même sans parler de translocation, c'est très tentant de mettre quelque part le locus IGH complet.... ou au moins les régions aval/amont des gènes D... ou bien, dans une autre germline, les régions aval/amont, **sans** les gènes D & co, bref des choses qui normalement ne sont pas là.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1604Le calcul de la e-valeur devrait prendre en compte le -t2018-04-10T12:28:09+02:00Vidjil TeamLe calcul de la e-valeur devrait prendre en compte le -tSi on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers...Si on ne garde que x nucléotides pour les germlines V ou J, le calcul de la e-valeur ne doit se faire que sur une longueur inférieure ou égale à x, même si la séquence est beaucoup plus longue : il est impossible d'avoir plus de x k-mers V (et même x - s + 1) par exemple.
***
ok
***
Tout doit se faire dans kmerstore.h
- en entrée, les insert() reçoivent et utilisent keep_only : à stocker
- en sortie, getProbabilityAtLeastOrAbove()
***
68fef14. Quitte à prendre en compte le -t, autant être plus générique : si on n'a inséré que des choses de 200 ou moins, le calcul devrait prendre en compte ces 200.
Pour faire le changement souhaité, il faut maintenant faire quelque chose du type :
int n_max = atMostMaxSizeIndexing(length) - getS() + 1;
dans getProbabilityAtLeastOrAbove()
Mais j'ai maintenant des doutes : veut-on remplacer vraiment n par n_max dans toute cette fonction ? Est-ce que le index_load n'a pas déjà pris cela en compte ?
Bref, je te laisse voir :-)
***
Dans une séquence de longueur 200, même si on n'a inséré que des séquences de longueur 100 :
- la proba d'avoir exactement 18 k-mers est toujours la même ?
- et celle d'avoir 150 k-mers ? Elle est faible... mais pas nulle (et d'ailleurs, on trouvera des séquences chimériques avec cela). Est-ce que le but est de mettre cela à zéro ?
ou bien est-ce que cela doit être fait finalement dans affectanalyser.cpp:160 ? Qu'est-ce que cela signifie ?
***
La proba d'avoir 18 k-mers par hasard est plus élevée dans une séquence de longueur 200 que de longueur 100. De manière générale, il existe au moins une valeur t pour laquelle t k-mers dans 100nt est significatif mais pas t dans 200nt.
***
ok pour la longueur de la séquence observée, mais est-ce que cela dépend de la longueur de la séquence insérée ? (Cette dépendence ne serait-elle pas déjà dans le index_load ?)
En tout cas, si tu penses avoir la formule, vas-y :-)
***
Je pense que je ne comprends pas ce que tu veux dire :)
Par exemple pour l'instant on calcule la probabilité à gauche sur toute la longueur jusqu'à first_pos_max. Ce qui est très bien puisque cela évite de prendre en compte le N (dans lequel on ne s'attend pas à avoir de k-mers). Là c'est la même chose : on ne veut pas prendre en compte le début du V puisqu'on ne s'attend pas à avoir de k-mers dedans.
Autrement dit, entre un read qui contient 100nt de V et un read qui contient 300nt du même V, on ne devrait pas avoir une e-valeur différente (avec -t 100).
***
Après réflexion collective, un segment de 200, même avec -t 100, contient aussi un certain nb de kmers "aléatoires" dans les 100 premiers nt, qui fait que le calcul de la e-valeur serait tout de même bon (à peu près).
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2921JS : `==` ou `===` en comparant par rapport à `undefined` ou `0`2018-04-10T12:35:15+02:00Mikaël SalsonJS : `==` ou `===` en comparant par rapport à `undefined` ou `0`Dans #2272 @RyanHerb avait [mis un fichier](https://gitlab.inria.fr/vidjil/vidjil/uploads/468a35081d3d30d32b8ccb1af57e1e72/code_analysis.txt) montrant que `jshint` râlait pour des `==` à la place de `===`. Par exemple :
```
clone.js: li...Dans #2272 @RyanHerb avait [mis un fichier](https://gitlab.inria.fr/vidjil/vidjil/uploads/468a35081d3d30d32b8ccb1af57e1e72/code_analysis.txt) montrant que `jshint` râlait pour des `==` à la place de `===`. Par exemple :
```
clone.js: line 46, col 27, Use '===' to compare with 'undefined'.
clone.js: line 68, col 35, Use '===' to compare with '0'.
clone.js: line 81, col 33, Use '!==' to compare with 'undefined'.
clone.js: line 100, col 18, Use '===' to compare with '0'.
```
@RyanHerb avait d'ailleurs fait des modifications dans ce sens : cc7595e2.
Mais maintenant cela ne semble pas poser de problème à `jshint` : https://gitlab.inria.fr/vidjil/vidjil/merge_requests/139#note_65732
Quelle est la bonne pratique à suivre ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2504Germlines : Les informations de germlines.js ne sont pas prises en compte pou...2018-04-10T12:49:36+02:00Mikaël SalsonGermlines : Les informations de germlines.js ne sont pas prises en compte pour la couleur et shortcut de l'allèleSur la branche `feature-c/germline-segmenter` on a perdu l'information de locus pour chaque clone (couleur et shortcut consistant en une seule lettre).
Probablement dû à une modification autour de germline/germlineList.Sur la branche `feature-c/germline-segmenter` on a perdu l'information de locus pour chaque clone (couleur et shortcut consistant en une seule lettre).
Probablement dû à une modification autour de germline/germlineList.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3118should: matcher sur plusieurs lignes2018-04-11T16:34:25+02:00Mathieu Giraudshould: matcher sur plusieurs lignes@mikael-s : "Une option pour matcher quelque chose sur plusieurs lignes."
Cela n'empêchera pas le `format-json` dans des cas complexes, mais permettrait effectivement de simplifier certaines commandes `LAUNCH`.@mikael-s : "Une option pour matcher quelque chose sur plusieurs lignes."
Cela n'empêchera pas le `format-json` dans des cas complexes, mais permettrait effectivement de simplifier certaines commandes `LAUNCH`.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3115should : --var2018-04-11T16:34:46+02:00Mathieu Giraudshould : --varDepuis https://gitlab.inria.fr/vidjil/vidjil/issues/3105#note_81394 :
> > Si tu parles des constantes définies au début, il suffit de définir ces variables dans un autre fichier qu'il faudra inclure au début du script.
> Oui. Ou dans l...Depuis https://gitlab.inria.fr/vidjil/vidjil/issues/3105#note_81394 :
> > Si tu parles des constantes définies au début, il suffit de définir ces variables dans un autre fichier qu'il faudra inclure au début du script.
> Oui. Ou dans l'autre sens : on veut avoir un `should-to-tap` générique, sans aucune référence dure à vidjil ou à un autre fichier. On peut par contre lui passer en paramètre (ou en fichier) certaines variables.
On pourrait passer à `should` des arguments type `--var VIDJIL_DIR=../../bla --var FOO=bar`https://gitlab.inria.fr/vidjil/vidjil/-/issues/3119should: chercher seulement dans une partie du fichier2018-04-11T17:52:04+02:00Mathieu Giraudshould: chercher seulement dans une partie du fichier@mikael-s : "Parfois on cherche quelque chose à un endroit, mais on met `3` parce que cela apparaît aussi dans d'autres endroits".
Pas facile à spécifier ? Ou des opérateurs `after`/`before` couplés à un multi-line #3118 ?
Ou même sans...@mikael-s : "Parfois on cherche quelque chose à un endroit, mais on met `3` parce que cela apparaît aussi dans d'autres endroits".
Pas facile à spécifier ? Ou des opérateurs `after`/`before` couplés à un multi-line #3118 ?
Ou même sans opérateurs, avec le multi-line : `Outputing clones .* IGHV2-23 .* End of clones` https://gitlab.inria.fr/vidjil/vidjil/-/issues/2317Avoir la requête originale quelque part dans le json de retour de CloneDB2018-04-12T15:36:59+02:00Mathieu GiraudAvoir la requête originale quelque part dans le json de retour de CloneDBAvoir la séquence de 40nt remise dans le json de retour permettrait de faire simplement #2315 / #2316.
cc @mikael-sAvoir la séquence de 40nt remise dans le json de retour permettrait de faire simplement #2315 / #2316.
cc @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1757should-to-tap.sh veut un sed GNU ?2018-04-12T19:07:17+02:00Vidjil Teamshould-to-tap.sh veut un sed GNU ?Les tests ne passaient plus sur mon système tout neuf (pourtant POSIX ?)
```
sed: illegal option -- r
usage: sed script [-Ealn] [-i extension] [file ...]
sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...Les tests ne passaient plus sur mon système tout neuf (pourtant POSIX ?)
```
sed: illegal option -- r
usage: sed script [-Ealn] [-i extension] [file ...]
sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
```
J'ai installé `gsed` (`port install gsed`), puis `ln -s /opt/local/bin/gsed /usr/local/bin/sed`, et cela refonctionne.
Documenter si c'est obligé.
***
C'est aussi accepté sur freeBSD mais en lisant le man, c'est effectivement non standard, le mieux serait de le remplacer. Mais par quoi ?
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1465should: avoir le temps de chaque test2018-04-12T19:07:33+02:00Vidjil Teamshould: avoir le temps de chaque testCe serait bien d'avoir sur la sortie standard le temps passé par chaque test.
Au passage : http://buildtimetrend.herokuapp.com/dashboard/vidjil/vidjil/index.html
***
Notons que https://travis-ci.org/vidjil/vidjil/builds/53916084
permet...Ce serait bien d'avoir sur la sortie standard le temps passé par chaque test.
Au passage : http://buildtimetrend.herokuapp.com/dashboard/vidjil/vidjil/index.html
***
Notons que https://travis-ci.org/vidjil/vidjil/builds/53916084
permet aussi de voir les temps, en gros. Le gros du paquet (414s) est dans les .should_get
***
Pas sûr de voir l'intérêt (en lançant les tests on voit déjà que les .should_get prennent la majorité du temps, non ?). C'est aussi quelque chose que fait Jenkins. Par exemple ici https://ci.inria.fr/bonsai/job/Vidjil%20%28all%20slaves%29/label=ubuntu-1204-amd64/314/console on voit que Valgrind met 5 minutes sur l'exécutable tests.
Les timestamps n'étaient pas activés pour les autres builds, je l'ai fait.
***
Je me suis mal exprimé : la question porte sur le temps de *chaque* should_get,
en mettant à jour should-to-tap.sh.
***
mais effectivement, avec la sortie Jenkins on a tout ce qu'on veut.
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1542La liste patient met, pour les admin, 5,5 secondes à être calculée2018-04-13T12:36:06+02:00Vidjil TeamLa liste patient met, pour les admin, 5,5 secondes à être calculéeDepuis ce matin 10:47:29 (mais pas à chaque fois), juste après les erreurs serveurs.
***
Ce n'est pas le cas sur dev.
***
La solution « ça fait 2 semaines qu'on n'a pas rebooté le serveur » n'est pas une solution ;-)
***
La requête...Depuis ce matin 10:47:29 (mais pas à chaque fois), juste après les erreurs serveurs.
***
Ce n'est pas le cas sur dev.
***
La solution « ça fait 2 semaines qu'on n'a pas rebooté le serveur » n'est pas une solution ;-)
***
La requête 2 (db.patient.id == db.sequence_file.patient_id) met 0,6 seconde sur le serveur contre 0,1 dans le shell ipython avec web2py chargé…
Quelle différence ? uwsgi ?
***
Même problème au niveau de la base de données. Cette page mettait plus d'une seconde à charger https://rbx.vidjil.org/vidjil/appadmin/select/db?query=db.patient.id%3E0 contre 0,3 s pour dev
Ça sent le problème côté uwsgi. Mais c'est difficile de faire des tests car modifier le fichier de config entraîne le relancement des process… (et après le relancement, sans modif, le temps de requête est redevenu normal).
Peut-être abaisser le max-requests, pour recharger uwsgi plus souvent ? ou vérifier la consommation mémoire de uwsgi ?
En tout cas ce n'est pas satisfaisant. Il ne devrait pas y avoir d'intervention humaine nécessaire.
***
On vient de passer à 5-7 secondes pour une raison inexpliquée. Du coup on a plein de timeouts. Pourtant rien ne tourne sur le serveur et le réseau est tranquille aussi.
***
Priorité baissée, ce n'est plus le cas. Mais ça serait bien d'identifier le problème qui a eu lieu…
***
Ryan, 28 juin:
> Je viens de pull une hotfix list patient pour améliorer la lenteur sur
prod-server. Faites-moi signe si vous voyez des anomalies :)
J'imagine que tu parles de 1ee80f0.
Bravo ! La patient list (pour nous) est passée de 5.5-6.5s à environ 3.5s.
***
Oui la vitesse n'est pas améliorée pour tout le monde. notament le probleme de lenteur venait du fait que je ne chargeais pas les permissions non présentes (donc quand un utilisateur n'avait pas les permissions anon ou admin sur un patient, une requete bdd était lancée)
***
Pour mémoire, une manière de logger toutes les requêtes effectuées sur Mysql : http://stackoverflow.com/a/20485975
***
Aurélie a assez souvent des timeout, en particulier avec la liste patient. En regardant dans les logs, sur les mois de septembre et octobre, la liste patient a mis 5,4s à se charger en moyenne pour elle (n=234, min=2.3, max=11.2, mediane=2.9), et plus de 9s pour 25% des tentatives.
ligne de commande pour avoir la liste des durées pour Aurélie sur sept. et oct :
`grep -P '2016-(09|10).*Aurélie.*patient.*list.*s\)\s*$' /var/vidjil/vidjil-debug.log | sed -r 's/^.*\(([0-9.]+)s\)\s*$/\1/'`
***
8177a7d et eb4ab24
On peut s'attendre à des améliorations importantes pour les utilisateurs ayant peu de patients, pas pour les admins. À voir ce que ça change pour Aurélie, une fois en prod.
***
Comme vu pendant l'audio du jeudi 10/11/2016, une solution de pagniation pourrait être envisagée. Les informations complémentaires pourraient être en 'lazy load' pour réduire la charge.
Et nous pourrions ne charger l'entièreté des données d'un utilisateur que lorsqu'un filtre ou un sort est appliqué.
***
Après quelques tests, en limitant chaque page à 50 patients, mes temps passent de ~1.1s (pour 1130 patients) à ~0.25s
***
@magiraud @RyanHerb @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2294API : La modification de l'URL est prise en compte même sans devel-mode2018-04-13T12:36:06+02:00Ghost UserAPI : La modification de l'URL est prise en compte même sans devel-model'ajout manuel de clone ou de plot dans l'url est disponible en mode normal et non pas uniquement en dev mod. D'autant plus que le dev mode ne semble pas etre détecté au chargement de la page.
@magiraud @mikael-sl'ajout manuel de clone ou de plot dans l'url est disponible en mode normal et non pas uniquement en dev mod. D'autant plus que le dev mode ne semble pas etre détecté au chargement de la page.
@magiraud @mikael-s