vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:36:31+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1452Config 'debug kmers' sur le serveur2016-11-29T14:36:31+01:00Vidjil TeamConfig 'debug kmers' sur le serveurLorsque les tâches '-X' et '.affects dans le browser' auront été faites, faire une config "debug k-mers" avec des bonnes options pour débugguer les k-mers directement dans le browser+serveur.
***
Config 'debug-100-k10', avec -!KAX 100 -1...Lorsque les tâches '-X' et '.affects dans le browser' auront été faites, faire une config "debug k-mers" avec des bonnes options pour débugguer les k-mers directement dans le browser+serveur.
***
Config 'debug-100-k10', avec -!KAX 100 -1 -k 10
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1449Afficher les .affects dans le browser2016-11-29T14:36:28+01:00Vidjil TeamAfficher les .affects dans le browserVu ce que Marc a mis en place pour le CDR3, cela devrait être facile d'afficher des .affects sur les séquences , type :
+H+H _ _ _ +K _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ +h+h+h+h+h
Est-ce que le truc fonctionnerait ...Vu ce que Marc a mis en place pour le CDR3, cela devrait être facile d'afficher des .affects sur les séquences , type :
+H+H _ _ _ +K _ _ _ _ _ _+H+H+H+H+H+H+H+H+H+H+H _ _ _ _ _ _ _ +h+h+h+h+h
Est-ce que le truc fonctionnerait si on met plusieurs features "H" dans une même séquence ?
***
- côté cpp:
- Lorsque l'option '-K' est mise, mettre aussi les .affects dans le json .vidjil ... (en debug, typiquement avec -X 100)
- et sinon, on pourrait aussi le faire par défaut pour les séquences FineSegmentées... ou avec option ?
- côté .js : à voir
***
On discute de cela jeudi matin
***
- côté .js : c'est bon. 35cd4fe8
Il suffit de mettre dans le .vidjil un { start:"0", stop:"xxx", seq:" ") avec la séquence des affects (un seul caractère, pas deux, tant pis pour le +/-).
***
C'est parfait ainsi. Un bon jeu d'options est ainsi -!KAX 100 -1 -k 10, comme dans la config 'debug-100-k10' sur rbx.
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1437Spécificité / P-value / E-value d'une recombinaison2019-09-16T16:58:45+02:00Vidjil TeamSpécificité / P-value / E-value d'une recombinaisonPrend en compte nb de délétions, mutations V/J, N... Normalement cela devrait se voir dans les scores de FineSegmentation.
Détecter ces probabilités depuis nos jeux de données (mais cela suppose d'avoir des segmentations VDJ de référe...Prend en compte nb de délétions, mutations V/J, N... Normalement cela devrait se voir dans les scores de FineSegmentation.
Détecter ces probabilités depuis nos jeux de données (mais cela suppose d'avoir des segmentations VDJ de référence...)
Lien avec génération aléatoire.
Faire cela dans notre coin ? Mettre quelqu'un dans la boucle ? (Laurent ?)
***
De manière empirique, pas nécessairement besoin de segmentations VDJ de réf. Ne peut-on pas le faire directement depuis les fenêtres ? On sait où est censé se terminer le V et commencer le J. Et donc on peut retrouver si on trouve une fenêtre à distance 0 ou 1.
Et si on va sur la génération aléatoire, le problème est la probabilité qu'on affecte à des délétions, insertions (et cela dépend des chaînes et des récepteurs, la dTd et la bouffeuse de nucléotides ne sont pas aussi actives partout). Ou alors on part de nos données, mais là pour le coup on a besoin de segmentations VDJ de références.
***
On en parle donc un jour avec Laurent. Voir quand.
***
On a donc maintenant une e-valeur d'une découpe left/right, mais la question reste toujours ouverte pour une recomb VDJ, à partir d'exemples, d'estimer les paramètres. On en avait aussi parlé avec Nikos.
***
(copié depuis tâche "Taille de fenêtre en multi-système") Si on a un V/J collé avec 0 zone de N, ce sera très limite même avec une fenêtre de taille 100 :-) On doit mettre un gros warning dessus, et permettre de revenir sur les reads.
***
Remonté, car l'heuristique peut regrouper des choses curieuses si la fenêtre n'est pas spécifique. (mais bon, contrôle par le coverage ?). Devient légèrement différent : quelle est la P/E-valeur d'une fenêtre ?
- compter les N (après Fine Segmenter)
- un bidule dans le FineSegmenter qui compte en plus les mutations de la fenêtre
- ... ou bien un truc magique à base de k-mers (y compris des D) ?
(Voir par exemple notable/0481)
***
euh... on maintenant a un warning si faible e-valeur ?
toujours d'actualité ?
***
Cela a été fait très sérieusement par Thierry Mora et Aleksandra Walczak
-> Quantifying lymphocyte receptor diversity
http://arxiv.org/abs/1604.00487
***
Et il y a un article qui utilise cela pour calculer la p-value de clones identifiés au diag : http://www.nature.com.sci-hub.cc/bmt/journal/vaop/ncurrent/full/bmt2016148a.html « Reliability of immune receptor rearrangements as genetic markers for minimal residual disease monitoring »
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1434Focus2016-11-29T14:36:16+01:00Vidjil TeamFocusLorsqu'un certain nombre de clones sont sélectionnés, on pourrait avoir un bouton "focus" qui ne garde que les clones sélectionnés.
On pourrait ainsi plus facilement, sélectionner un paquet de clones (par exemple même V/J), puis change...Lorsqu'un certain nombre de clones sont sélectionnés, on pourrait avoir un bouton "focus" qui ne garde que les clones sélectionnés.
On pourrait ainsi plus facilement, sélectionner un paquet de clones (par exemple même V/J), puis changer complètement les axes pour faire autre chose :
- sélection pour mieux grouper
- ou tout simplement des stats dans tous les sens : Quelle est la distribution des CDR3 de ce paquet de clones ?
J'ai l'impression que cela pourrait être fait assez (très ?) facilement avec le .isFiltered des clones.
Comme c'est le même mécanisme que "search", peut-être mettre ce bouton à côté de search, et trouver un moyen que quand on est focus, on le sait (est-ce que le X de search annulerait aussi le focus ?)
***
09de66e ... 52fc4b7
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1422axis: mécanisme générique2016-11-29T14:36:06+01:00Vidjil Teamaxis: mécanisme génériqueEn ajoutant l'axe SequenceLength dans axis.js (b2b2260), j'ai furieusement copié Nlength.
J'ai l'impression qu'il y avait un mécanisme générique de prévu ("custom"), mais il n'a pas l'air utilisé. En tout cas cela vaudrait le coup, surt...En ajoutant l'axe SequenceLength dans axis.js (b2b2260), j'ai furieusement copié Nlength.
J'ai l'impression qu'il y avait un mécanisme générique de prévu ("custom"), mais il n'a pas l'air utilisé. En tout cas cela vaudrait le coup, surtout si on rajoute d'autres axes.
***
merci Marc
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1419Icône "x" pour déselectionner un clone dans le segmenter2016-11-29T14:36:04+01:00Vidjil TeamIcône "x" pour déselectionner un clone dans le segmenterActuellement, cliquer sur un clone dans le segmenter le déselectionne. C'est un peu trop rapide (surtout si on a beaucoup de clones sélectionnés, on le fait par erreur, ce n'est pas facile de le retrouver). Cela pourrait être plus explic...Actuellement, cliquer sur un clone dans le segmenter le déselectionne. C'est un peu trop rapide (surtout si on a beaucoup de clones sélectionnés, on le fait par erreur, ce n'est pas facile de le retrouver). Cela pourrait être plus explicite, par exemple avec une icône type "x" à côté du nom du clone, ou un clic droit (mais on n'utilise pas de clic droit ailleurs, cohérence ?)
De plus, cela libère le clic simple pour faire d'autres choses si besoin.
***
e4b0308
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1417Segmenter : pouvoir faire "undo" sur l'align2016-11-29T14:36:03+01:00Vidjil TeamSegmenter : pouvoir faire "undo" sur l'align(Yann, 10 février)
Quand on clique sur "align", on n'est pas toujours content du résultat. On aimerait pouvoir annuler cela, le plus simple étant de recliquer sur "align"
***
678f755
***
@Duez(Yann, 10 février)
Quand on clique sur "align", on n'est pas toujours content du résultat. On aimerait pouvoir annuler cela, le plus simple étant de recliquer sur "align"
***
678f755
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1415Regrouper TRD et TRD+, ou les comptabiliser ensemble ?2016-11-29T14:36:01+01:00Vidjil TeamRegrouper TRD et TRD+, ou les comptabiliser ensemble ?(Yann, 10 février)
Dans certains cas, on souhaite regrouper IGH/IGH+, TRD/TRD+/VdJa, et IGK/IGK+.
Pour des questions d'axes, cela parait difficile de tout regrouper, surtout que de temps en temps on aime voir ce qui est complet et ce qui...(Yann, 10 février)
Dans certains cas, on souhaite regrouper IGH/IGH+, TRD/TRD+/VdJa, et IGK/IGK+.
Pour des questions d'axes, cela parait difficile de tout regrouper, surtout que de temps en temps on aime voir ce qui est complet et ce qui ne l'est pas.
Après discussion, on voit que ce qui est important est surtout de pouvoir calculer le pourcentage de chaque clone par rapport au total TRD/TRD+/VdJa. Ce pourcentage pourrait être affiché sous la forme
"30.0% (37.3% of TRD/TRD+/VaJa, 43.32% of TRD)", que ce soit dans les rapports ou dans l'export .csv ou fasta.
À discuter Marc/Mikaël/Mathieu avant de lancer l'implémentation.
***
7c3305b
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1414export csv: mettre les pourcentages par système2016-11-29T14:36:00+01:00Vidjil Teamexport csv: mettre les pourcentages par système(Yann, 10 février)
Dans le .csv, on souhaiterait avoir les mêmes infos que dans les rapports
***
(et dans le fasta aussi...)
***
e8d2913. Pourcentages en vrac dans une colonne, mais au moins ils sont là.
***
@Duez(Yann, 10 février)
Dans le .csv, on souhaiterait avoir les mêmes infos que dans les rapports
***
(et dans le fasta aussi...)
***
e8d2913. Pourcentages en vrac dans une colonne, mais au moins ils sont là.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1406Deux fuse servers sur une même machine2016-11-29T14:35:53+01:00Vidjil TeamDeux fuse servers sur une même machineMettons que nous ayions deux instances de Vidjil qui tournent sur une même machie (au hasard une version de prod et une version de test). Chaque instance doit avoir son propre fuse_server. Or, le code du fuse_server précise le port en du...Mettons que nous ayions deux instances de Vidjil qui tournent sur une même machie (au hasard une version de prod et une version de test). Chaque instance doit avoir son propre fuse_server. Or, le code du fuse_server précise le port en dur. Du coup impossible d'avoir deux instances parallèles (même problème si le port est occupé). Le serveur pourrait chercher un port libre, l'utiliser et stocker le port utilisé dans un fichier. Ou, plus simple, lire le port à utiliser depuis un fichier de conf.
***
Est-ce que ce fichier de conf pourrait être simplement modules/defs.py ?
Facile à récupérer pour model/task.py, plus délicat pour fuse_server.py, mais pas impossible (defs.py est du python standard, pas web2py)
***
Dans l'idée oui. Mais je suis toujours un peu gêné par le fait qu'un fichier de conf soit versionné (après il y a des choses qui sont poussées et qui ne devraient pas l'être ;-) ). Ça serait bien que defs.py lise les infos depuis un fichier de conf.
***
Mmm... il y a bien le module configParser de python qui lit les fichiers à la .ini... mais on ne fait que repousser le problème (au prix d'une complexificaiton) : on devra donner un fichier .ini d'exemple, avec des commentaires pour qu'il soit lisible, et lui devra être versionné.
Donc n'avoir que defs.py me paraît être une bonne solution; et c'est normalement le seul fichier dans lequel on met tout ce qui doit bouger. Après, le fichier versionné peut s'appeler quelque chose comme "defs-example.py", et une copie (ou pas) est effectuée sur le serveur, et on dit dans les instructions d'install comment s'en servir.
http://stackoverflow.com/questions/6009/how-do-you-deal-with-configuration-files-in-source-control
Il y aurait aussi des solutions basées sur git, mais bof... http://stackoverflow.com/a/1396886/4475279
***
63d6df4
***
1612a0b : defs.py.sample
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1405C++11 : Jenkins et ses slaves, Travis2017-09-08T19:06:57+02:00Vidjil TeamC++11 : Jenkins et ses slaves, TravisPour l'instant tous les dév C++11 sont sur la branche c++11.
Avant de passer sur master, il faudra que nos systèmes d'intégration continue prennent tout cela...
... et ce n'est pas si facile: par exemple, sur Travis, le gcc par défaut ...Pour l'instant tous les dév C++11 sont sur la branche c++11.
Avant de passer sur master, il faudra que nos systèmes d'intégration continue prennent tout cela...
... et ce n'est pas si facile: par exemple, sur Travis, le gcc par défaut est 4.6
Voir http://gearchicken.com/wordpress/?p=105
***
(copié depuis tâche C++11)
Mikaël : CentOS 6 (maintenue jusqu'en 2017) embarque gcc 4.4 qui a un support limité de C++11 (pas de lambda fonctions par exemple) : https://gcc.gnu.org/gcc-4.4/cxx0x_status.html
Mathieu: Oui... et on trouvera plein d'autres systèmes stables sans bon support C++11. Je propose qu'on ne revienne pas sur la décision : on va basculer sur C++11. Par contre, il faut trouver un moyen correct d'avoir notre intégration continue.
Trois solutions :
- on arrive à installer un gcc correct sur CentOS 6 : http://www.necessaryandsufficient.net/2014/07/c11-on-centos/
- on met plutôt un slave CentOS 7
- on enlève CentOS des slaves !
***
Comment détecter s'il faut passer l'option -std=c++0x ou -std=c++11 au compilateur et le mettre automatiquement dans le Makefile ? Sur les différents slaves on n'aura pas forcément les mêmes versions des compilateurs (et ce n'est pas nécessairement souhaitable). Alors on pourrait, dans la config de Jenkins, mettre une option à la main. Mais ce n'est pas super portable et ça nécessite que l'utilisateur sache s'il doit passer l'option c++0x ou c++11 ce qui n'est pas gagné d'avance…
***
Bien sûr les autotools font ça :)
***
Travis: bbb0de1, 3ca2a73
***
Mmm... si tu veux faire du autotoools (autoconf suffit ?), vas-y sur une autre tâche...
Notons que, sur un système très (trop) récent, il n'y a besoin d'aucun flag, héhé.
***
Sans mettre une option à la main, on ne peut pas tout simplement définir la variable d'environnement CXXFLAGS à la main sur chaque slave une fois pour toute ? Oui c'est manuel, mais de toute façon l'installation d'un bon gcc est aussi manuelle...
***
Sur quel système récent il n'y a pas besoin de flag ? Pour gcc 9.2 (dernière version stable), il faut toujours le flag. La version par défaut est c++98.
La variable d'environnement solutionnerait le problème pour les slaves mais pas pour les utilisateurs extérieurs utilisant le programme (savoir compiler un programme ne veut pas dire savoir quelle option passer à gcc).
L'utilisation d'autotools était une boutade. Mais c'est vrai que si on peut utiliser autoconf seul ça pourrait être intéressant : ce n'est pas la seule dépendance qu'on a (zlib, c++11, unzip, wget, tar).
Pour la gestion du flag C++11, une piste peut être de tester la version de gcc dans le Makefile : http://stackoverflow.com/a/5188472/1192742
***
Le module json n'a pas seulement besoin de C++11 mais d'un gcc >= 4.8 (mars 2013). L'inconvénient c'est que c'est très récent, l'avantage c'est que l'option de compilation est forcément -std=c++11
***
Remonté. Bloquant pour parser C+11.
***
(aïe, Travis est sur gcc 4.6.3 pour l'instant)
***
non, c'est bon, sur la branche c++11-new Travis est bien sur 4.8.1
***
Ubuntu 12.04 : c'est bon !
En s'inspirant de http://askubuntu.com/questions/271388/how-to-install-gcc-4-8
```
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.8 g++-4.8
### sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50 ### pas fait !
```
puis
make CXX=g++-4.8
(ou make CXX=g++-4.8 CXXFLAGS="-std=c++11" si on a enlevé d19e410)
Les tests should passent (après enlevage de compilation, les flags ne passent pas dans make test)
***
Les derniers développements de Marc (parser, puis matrice distance) ont lieu sur c++11-new. Il faut merger à un moment.
Proposition :
- la release 2015.06 sera la dernière non - c++11
- en contrepartie, on va diffuser ensuite des binaires
(- et... si on y tient, on pourrait toujours backporter des bugs sur 2015.06)
Implémentation :
- juste après la release 2015.06, on merge c++11-new.
- cela cassera certains slaves, on verra ce que l'on fait. Installer g++-4.8 dessus ou... supprimer des slaves. On supporte au moins les deux LTS Ubuntu en service, et on arrivera bien à supporter quelques autres.
***
« juste après la release 2015.06, on merge c++11-new. »
Non. Ne garder que des slaves ubuntu a peu d'intérêt. C'est la diversité qui apporte de l'intérêt et permet de débusquer des bugs. Ça nous est arrivés plusieurs fois d'avoir certains slaves qui plantent mais pas tous.
***
> Ne garder que des slaves ubuntu a peu d'intérêt
Tout a fait d'accord. On essaiera de mettre à jour d'autres slaves, le but est d'avoir de la diversté... Mon post d'avant n'était pas pour dire que c'était fini, juste que en y passant un peu de temps, on peut tout à fait installer g++-4.8 sur d'anciens trucs (j'ai pris la 12.04 exprès).
D'où la proposition de faire cela en *début* de mois, après la release, on a un mois, ou même plus, pour mettre à jour les slaves (on a déjà vécu avec "all slaves" qui ne foncitonne pas 2 semaines !)
Je propose la motion "on ne fera pas de release suivante tant qu'on a pas réussi à configurer des slaves sur au moins 3 distribs différentes (ubuntu, xxx, xxx)". Les 3 différentes ne seront pas nécessairement les slaves actuels, on verra.
***
Autant passer « un peu de temps » avant le merge qu'après alors. Avoir un build cassé pendant 2 semaines n'est pas une situation normale.
Il faut aussi que les distribs soient suffisamment différentes (si c'est pour avoir Ubuntu, Debian et Linux Mint, ça n'apporte pas grand chose). freebsd, centos/fedora et ubuntu/debian semble un bon compromis. Je tiens particulièrement à freebsd qui n'est pas (trop ?) GNU à l'inverse des autres. Cela permet de nous alerter quand on utilise des choses spécifiques à GNU.
Si on arrive à avoir un compilateur plus récent (gcc 4.9) sur une distrib, ça serait bien aussi.
***
Mon gcc est en fait... "Apple LLVM version 6.0 (clang-600.0.56)"
Un clang, si possible sans pomme, ce serait bien.
***
Oui ça existe aussi sous Linux, ça serait bien
***
ok. On résume :
> au moins 3 distribs suffisament différentes : freebsd, centos/fedora et ubuntu/debian
> g++-4.8
> idéalement un g++-4.9 et un clang quelque part
***
CentOS 6.3 : c'est bon, sur les deux slaves
```
wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++
scl enable devtoolset-2 bash # Open a shell running devtools
```
(au passage, /etc/yum.repos/epel* ne marchaient plus, j'ai du les enlever temporairement le temps de faire cela)
***
Il y a déjà un clang (non utilisé) sur freebsd, ça peut être un bon client…
***
les nouveaux gcc installés sont-ils les compilateurs par défaut sur les slaves ?
***
non, il ne vaut mieux pas vu qu'on n'est pas les seuls à utiliser les slaves. Il faut forcer :
- CentOS : "scl enable devtoolset-2 bash"
- Ubuntu : "make CXX=g++-4.8"
***
Avec la mise à jour de freebsd (9.2) on a gcc4.8 (pas par défaut) et clang 3.3, compatibles C++11.
Au passage la mise à jour m'a affiché ce message pour gcc (à voir si c'est utile) :
« To ensure binaries built with this toolchain find appropriate versions
of the necessary run-time libraries, you may want to link using
-Wl,-rpath=/usr/local/lib/gcc48
»
***
Comment gérer le fait d'avoir des commandes différentes à rentrer pour compiler sur certains slaves ?
***
vu ensemble: suite de tests directement dans Jenkins
***
meccano: installé g++-4.8 (en suivant doc/algo.org, pas par défaut)
Essayé de lancer avec "export CXX=g++-4.8", ne marche pas récursivement partout.
***
Bon, j'ai tout cassé avant de partir en we
On a eu une après-midi où tous les jobs Jenkins refonctionnaient :-)
***
freebsd :
```
cd /builds/workspace/Vidjil (all slaves)/label/freebsd
gmake CXX='clang++ -stdlib=libc++' MAKE=gmake
gmake CXX='g++48' MAKE=gmake (ou g++49, installé aussi)
```
ne toruve pas iostream, ou d'autres choses
***
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193528
Ajouter l'option -D_GLIBCXX_USE_C99 dans les CXXFLAGS
***
debian squeeze : ok
***
doc/algo.org reflète ce qu'on a actuellement.
à voir si on supprime / déplace vers un autre job Jenkins les 2 slaves qui ne fonctionnent pas...
***
« Je propose la motion "on ne fera pas de release suivante tant qu'on a pas réussi à configurer des slaves sur au moins 3 distribs différentes (ubuntu, xxx, xxx)". Les 3 différentes ne seront pas nécessairement les slaves actuels, on verra. »
On ne peut pas vraiment dire qu'on a 3 distribs différentes (ubuntu et debian sont très proches).
***
Certes... et c'était déjà le cas pour la release d'il y a trois mois...
***
Ok pour FreeBSD avec g++ (je n'arrive pas à compiler avec clang…).
Fedora upgradé à Fedora 19 → passe avec g++ mais utilisation de clang 3.3 (pour la diversité)
8 mois après et 36 messages plus tard, on a fini !
***
Bravo pour l'excellence de cette intégration continue :-)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1402algo/tools: align.cpp2016-11-29T14:35:49+01:00Vidjil Teamalgo/tools: align.cppEn cours de modif, pour tester dynprog
***
@magiraudEn cours de modif, pour tester dynprog
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1398Makefile et flags2016-11-29T14:35:46+01:00Vidjil TeamMakefile et flagsJe voulais passer -g -ggdb partout, il y a make debug pour cela, mais cela ne marche pas comme il faut.
Plus généralement, il faudrait revoir comment sont passés les flags entre algo et algo/core ? et vidjil ? $(OPTIM) ? Hum.
***
et algo...Je voulais passer -g -ggdb partout, il y a make debug pour cela, mais cela ne marche pas comme il faut.
Plus généralement, il faudrait revoir comment sont passés les flags entre algo et algo/core ? et vidjil ? $(OPTIM) ? Hum.
***
et algo/tools
***
344feb9, on n'efface plus CXXFLAGS et LDFLAGS définis par le système
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1394Filter/search dans le 'compare patients'2016-11-29T14:35:43+01:00Vidjil TeamFilter/search dans le 'compare patients'merci Marc
***
@Duezmerci Marc
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1393Compare patients : et si on comparait des configs différentes ?2016-11-29T14:35:42+01:00Vidjil TeamCompare patients : et si on comparait des configs différentes ?Y a t-il une raison profonde pour laquelle on ne pourrait pas comparer des points venant de configs différentes ? Quand ils ont le même -w, a priori les points sont fuse-ables. Et même s'ils n'ont pas le même -w, et bien ce serait joli d...Y a t-il une raison profonde pour laquelle on ne pourrait pas comparer des points venant de configs différentes ? Quand ils ont le même -w, a priori les points sont fuse-ables. Et même s'ils n'ont pas le même -w, et bien ce serait joli de les voir à côté.
En ce moment je teste une config particulière, avec des options expérimentale, mais j'aimerais bien voir la différence entre cela et la situation normale.
Un utilisateur peut aussi vouloir comparer la config normale (multi) et une config uniquement TRG.
Certes, pour le mode normal, on stocke les fichiers fusés par config.
Mais, en mode "compare", si j'ai bien compris on ne stocke rien.
***
9de9c73
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1387Par défaut, liste des patients triée par plus récent en haut2016-11-29T14:35:38+01:00Vidjil TeamPar défaut, liste des patients triée par plus récent en hautCela évitera à avoir à se servir de l'ascenseur dans la plupart des cas
***
merci
***
@DuezCela évitera à avoir à se servir de l'ascenseur dans la plupart des cas
***
merci
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1384export html multi-systèmes: voir aussi le % par rapport à chaque système2016-11-29T14:35:36+01:00Vidjil Teamexport html multi-systèmes: voir aussi le % par rapport à chaque systèmeAu lieu de voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80%
On pourrait voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80% (25.40% of IGK)
Cela est particulièrement utile pour le diagnostic, mais aussi pour les autres points.
S'il n'y a qu'un seul système ...Au lieu de voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80%
On pourrait voir :
>IGKV1-5*01 -1/2/-2 KDE 12.80% (25.40% of IGK)
Cela est particulièrement utile pour le diagnostic, mais aussi pour les autres points.
S'il n'y a qu'un seul système sélectionné, peut-être que ce n'est pas la peine
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1379export html: Faire que les séquences soient en format Fasta2016-11-29T14:35:32+01:00Vidjil Teamexport html: Faire que les séquences soient en format FastaCe serait bien que la partie texte prête à copier/coller soit au format Fasta :
>Clone 3 - 3% - IGKV4-V4...
TCGCACTTATACGACATCAGACATA
***
l'apparence n'a pas changé mais le résultat du copier/coller donne du fasta
***
merci !
***...Ce serait bien que la partie texte prête à copier/coller soit au format Fasta :
>Clone 3 - 3% - IGKV4-V4...
TCGCACTTATACGACATCAGACATA
***
l'apparence n'a pas changé mais le résultat du copier/coller donne du fasta
***
merci !
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1377Raccourci clavier : shift-P pour revenir à la liste des patients2016-11-29T14:35:30+01:00Vidjil TeamRaccourci clavier : shift-P pour revenir à la liste des patients
***
@Cyanael
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1376Le champ "search" des patients devrait aussi rechercher dans les infos2017-07-10T17:01:50+02:00Vidjil TeamLe champ "search" des patients devrait aussi rechercher dans les infos
***
@Duez
***
@Duez