vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-12-08T10:03:35+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2669Normalisation : renommer les variables A et B2017-12-08T10:03:35+01:00Mikaël SalsonNormalisation : renommer les variables A et BSuggéré par @RyanHerb : renommer les variables `model.normalization.A` et `model.normalization.B` utilisées pour la normalisation pour quelque chose de plus parlant.Suggéré par @RyanHerb : renommer les variables `model.normalization.A` et `model.normalization.B` utilisées pour la normalisation pour quelque chose de plus parlant.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2755Documenter l'utilisation de Docker2017-12-13T09:31:43+01:00Mathieu GiraudDocumenter l'utilisation de Docker`doc/server.org` pourrait contenir des infos sur l'installation Docker.
Il faudra d'ailleurs un jour qu'on fasse une journée tutorial Docker pour tous, puis qu'on communique sur cette installation.`doc/server.org` pourrait contenir des infos sur l'installation Docker.
Il faudra d'ailleurs un jour qu'on fasse une journée tutorial Docker pour tous, puis qu'on communique sur cette installation.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1985Requêtes incessantes à scheduler_task et scheduler_worker2017-12-19T09:46:45+01:00Vidjil TeamRequêtes incessantes à scheduler_task et scheduler_workerIl s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a pl...Il s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a plusieurs requêtes par seconde ayant un lien avec les workers et les schedulers alors qu'aucun process n'est queued ou assigned.
Il s'agit de requête du genre :
SELECT scheduler_task.id, scheduler_task.application_name, scheduler_task.task_name, scheduler_task.group_name, scheduler_task.status, scheduler_task.function_name, scheduler_task.uuid, scheduler_task.args, scheduler_task.vars, scheduler_task.enabled, scheduler_task.start_time, scheduler_task.next_run_time, scheduler_task.stop_time, scheduler_task.repeats, scheduler_task.retry_failed, scheduler_task.period, scheduler_task.prevent_drift, scheduler_task.timeout, scheduler_task.sync_output, scheduler_task.times_run, scheduler_task.times_failed, scheduler_task.last_run_time, scheduler_task.assigned_worker_name FROM scheduler_task WHERE ((scheduler_task.assigned_worker_name = 'rbx.vidjil.org#26682') AND (scheduler_task.status = 'ASSIGNED')) ORDER BY scheduler_task.next_run_time LIMIT 1 OFFSET 0
et
SELECT scheduler_worker.id, scheduler_worker.worker_name, scheduler_worker.first_heartbeat, scheduler_worker.last_heartbeat, scheduler_worker.status, scheduler_worker.is_ticker, scheduler_worker.group_names, scheduler_worker.worker_stats FROM scheduler_worker WHERE (scheduler_worker.worker_name = 'rbx.vidjil.org#9626')
Les (anciennes) requêtes sont loggées dans /var/log/mysql/mysql_general.log. J'ai désactivé le log pour ne pas saturer le disque. Pour réactiver, il faut aller dans /etc/mysql/my.cnf, chercher general, décommenter les deux lignes en lien avec general_log et redémarrer le serveur mysql.
***
Dev et test ont maintenant un Heartbeat de 10 secondes, rbx un Heartbeat de 3 secondes (inchangé), la charge de la bdd semble être réduite.
***
On est effectivement passés à environ 3,1 requêtes par seconde, ce qui semble cohérent.
D'après les valeurs que tu donnes, en l'espace de 30 secondes on va avoir 3 heartbeats de chaque worker de dev et de test (soit au total 3 heartbeats * 3 workers * 2 serveurs = 18 heartbeats) et on va en avoir 10 pour rbx ( * 3 workers, soit 30 heartbeats). On arrive à 48 heartbeats en 30 secondes, soit environ 1,6 par seconde. Chaque heartbeat semble générer 2 requêtes, ce qui donne 3,2 requêtes par seconde. On tombe pas loin de ce que j'ai mesuré.
On pourrait diminuer encore du côté de dev et test, mais au final ça ne changerait pas grand chose puisque maintenant c'est rbx qui fait le plus de heartbeats.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2961Choix du dernier set/run lors de l'import d'un nouvel échantillon2017-12-20T11:52:01+01:00Anne de SeptenvilleChoix du dernier set/run lors de l'import d'un nouvel échantillonJe ne sais pas si c'est voulu, mais lors de l'import d'un nouvel échantillon, l'affichage des derniers sets/runs utilisés sur simple clic dans la case a disparu.
Ce qui oblige à taper du texte et ajoute donc une étape à chaque nouvel éch...Je ne sais pas si c'est voulu, mais lors de l'import d'un nouvel échantillon, l'affichage des derniers sets/runs utilisés sur simple clic dans la case a disparu.
Ce qui oblige à taper du texte et ajoute donc une étape à chaque nouvel échantillon d'un même set/run.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2983Shorter / shifted w: Refaire passer les tests2018-01-16T21:25:11+01:00Mathieu GiraudShorter / shifted w: Refaire passer les tests@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/141#note_66041 :
> Le job should-vdj foire mais c'est à cause de !132, car j'ai voulu utiliser un même fichier de test, celui de #2910, dans les deux cas. Si je n'arrive pa...@mikael-s, https://gitlab.inria.fr/vidjil/vidjil/merge_requests/141#note_66041 :
> Le job should-vdj foire mais c'est à cause de !132, car j'ai voulu utiliser un même fichier de test, celui de #2910, dans les deux cas. Si je n'arrive pas à faire passer !132, je dupliquerais peut-être le fichier (ce qui serait dommage) ou lui dirais qu'il ne faut pas lancer les tests should-vdj dessus.Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2919TEST_TAP_EQUAL pour les tests unitaires2018-01-18T00:35:54+01:00Mathieu GiraudTEST_TAP_EQUAL pour les tests unitairesMême remarque que #2823 pour les tests unitaires ~cpp .
Moins important, nos tests sont tout de même bien stables et c'est facile de débugger si besoin.Même remarque que #2823 pour les tests unitaires ~cpp .
Moins important, nos tests sont tout de même bien stables et c'est facile de débugger si besoin.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2644Décaler automatiquement voire raccourcir la window quand il n'y a pas assez d...2018-01-18T00:35:54+01:00Mathieu GiraudDécaler automatiquement voire raccourcir la window quand il n'y a pas assez de place(Rendu compte lors de la minimisation #2643, mais s'applique aussi au cas général.)
N'est-il pas dommage que des séquences dont le point de jonction a été trouvé finissent en `TOO_SHORT_FOR_WINDOW` ? Dans ces cas-là, pourrait-on, au mom...(Rendu compte lors de la minimisation #2643, mais s'applique aussi au cas général.)
N'est-il pas dommage que des séquences dont le point de jonction a été trouvé finissent en `TOO_SHORT_FOR_WINDOW` ? Dans ces cas-là, pourrait-on, au moment du `getJunction()`, accepter de décaler un peu la fenêtre jusqu'au bord gauche/droit, voire la raccourcir ?
Ces reads ne serait pas groupées avec les autres... mais a priori ce serait peu problable de les mettre avec d'autres reads non liées, car toutes les fenêtres ainsi décalées viendraient de reads toutes trop courtes de la même façon.
Voir #1580 pour d'autres raisons de décalage.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2827Le 'spinner' de requête tourne en permanence2018-01-18T10:35:18+01:00Ryan HerbertLe 'spinner' de requête tourne en permanenceIl se peut que le Spinner qui indique qu'une requête est en cours reste affiché, alors qu'il n'y a plus de requête en coursIl se peut que le Spinner qui indique qu'une requête est en cours reste affiché, alors qu'il n'y a plus de requête en courshttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2992'align' doit être robuste en cas de non-réponse du serveur2018-01-18T10:51:41+01:00Mathieu Giraud'align' doit être robuste en cas de non-réponse du serveur@mikael-s : "normalement c'est déjà le cas"
Vérifier que c'est vrai même avec plusieurs requêtes à la suite / entrelacées...@mikael-s : "normalement c'est déjà le cas"
Vérifier que c'est vrai même avec plusieurs requêtes à la suite / entrelacées...https://gitlab.inria.fr/vidjil/vidjil/-/issues/2916Sortir des champs `warn` dans le C++2018-01-27T22:15:42+01:00Mathieu GiraudSortir des champs `warn` dans le C++Voir #2247.
Chaque clone peut avoir un `warn`, et un `warn` global peut être mis.
Pas de ~bikeshedding ici, voir #2247 pour cela.
Voir #2247.
Chaque clone peut avoir un `warn`, et un `warn` global peut être mis.
Pas de ~bikeshedding ici, voir #2247 pour cela.
Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2613make forcedep, bamopen.h, erreur fatale mais pas tant que cela2018-01-29T15:08:59+01:00Mathieu Giraudmake forcedep, bamopen.h, erreur fatale mais pas tant que cela`make valgrind_unit` sort à un moment `bam.h:10:31: fatal error: lib/unbam/bamopen.h: No such file or directory`
mais cela continue`make valgrind_unit` sort à un moment `bam.h:10:31: fatal error: lib/unbam/bamopen.h: No such file or directory`
mais cela continueAlgo 2017.07https://gitlab.inria.fr/vidjil/vidjil/-/issues/3011Short / shifted window : re-rendre cohérent le message sur stdout2018-01-29T20:08:49+01:00Mathieu GiraudShort / shifted window : re-rendre cohérent le message sur stdoutSuite à !141, le message historique sur stdout `found 11835 100-windows in 13152 reads` (provient au moins de 2013.07 !) est parfois inexact: ce ne sont pas que des 100-windows.
Ne mettre que le nombre de window non raccourcies ? (bof...Suite à !141, le message historique sur stdout `found 11835 100-windows in 13152 reads` (provient au moins de 2013.07 !) est parfois inexact: ce ne sont pas que des 100-windows.
Ne mettre que le nombre de window non raccourcies ? (bof).
Retirer "100-" ? Mettre une autre formulation ?Algo 2017.11Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2630Réduire fortement /Makefile2018-01-29T22:30:44+01:00Mathieu GiraudRéduire fortement /MakefileUne étape vers #1491 est de supprimer (ou de fortement réduire) `/Makefile`.
Toutes les règles doivent être directement dans les bons sous-dossiers... et le CI doit lancer d'où il le faut.
On aura peut-être #2255 gratuitement.Une étape vers #1491 est de supprimer (ou de fortement réduire) `/Makefile`.
Toutes les règles doivent être directement dans les bons sous-dossiers... et le CI doit lancer d'où il le faut.
On aura peut-être #2255 gratuitement.Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2989Réécrire les tests unitaires avec TEST_TAP_EQUAL2018-01-30T08:22:26+01:00Mathieu GiraudRéécrire les tests unitaires avec TEST_TAP_EQUALSuite à #2919.
Pas très urgent, cela sert surtout en cas de debug et/ou pour les nouveaux tests.Suite à #2919.
Pas très urgent, cela sert surtout en cas de debug et/ou pour les nouveaux tests.Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/3013Warnings compilation sur Jenkins et ailleurs2018-01-30T15:50:25+01:00Mathieu GiraudWarnings compilation sur Jenkins et ailleurs- Deux warnings Jenkins https://ci.inria.fr/bonsai/job/Vidjil-coverage/752/warnings24Result/ que je n'ai pas chez moi, viennent de #2989 ? C'est pour cela que le build est jaune ?
- Par contre, j'ai beaucoup de warnings (je pensais qu'o...- Deux warnings Jenkins https://ci.inria.fr/bonsai/job/Vidjil-coverage/752/warnings24Result/ que je n'ai pas chez moi, viennent de #2989 ? C'est pour cela que le build est jaune ?
- Par contre, j'ai beaucoup de warnings (je pensais qu'on en avait déjà discuté et que c'était que de mon côté, mais je ne retrouve pas l'issue) :
```
lib/json.hpp:1834:64: warning: unsequenced modification and access to 'range' [-Wunsequenced]
if (JSON_LIKELY(*range <= current and current <= *(++range)))
```Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2981Autocomplétion patient/run/set : utiliser la classe CSS du menu2018-01-30T16:15:49+01:00Mathieu GiraudAutocomplétion patient/run/set : utiliser la classe CSS du menuSuite à #2977, on aimerait, dans le menu d'autocomplétion :
1) utiliser les couleurs
2) afficher "**patient** Jacques Dupont (1980-01-01)" (et idem pour les runs et sets).
Le "**patient**" pourrait être rajouté par CSS et être plus pe...Suite à #2977, on aimerait, dans le menu d'autocomplétion :
1) utiliser les couleurs
2) afficher "**patient** Jacques Dupont (1980-01-01)" (et idem pour les runs et sets).
Le "**patient**" pourrait être rajouté par CSS et être plus petit / plus léger.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2895Autocomplétion patient/run/set2018-01-30T16:27:59+01:00Mathieu GiraudAutocomplétion patient/run/setDiscuté ensemble
- taper "bla" autocomplète sur tout
- retour visuel pour savoir le type de sample
- éventiellement taper `:p` ou une autre commande limite aux seuls patientsDiscuté ensemble
- taper "bla" autocomplète sur tout
- retour visuel pour savoir le type de sample
- éventiellement taper `:p` ou une autre commande limite aux seuls patientsRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2982Shorter / shifted w: documenter (algo.org, user.org)2018-01-31T09:21:21+01:00Mathieu GiraudShorter / shifted w: documenter (algo.org, user.org)Suite à #2913/!141.Suite à #2913/!141.Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/3018La sortie XML de Valgrind doit être dans un fichier différent pour chaque sho...2018-01-31T10:06:47+01:00Mikaël SalsonLa sortie XML de Valgrind doit être dans un fichier différent pour chaque should_getÀ l'heure actuelle le job `Vidjil-valgrind` écrase à chaque fois le même fichier ce qui fait que nous n'avons les résultats de Valgrind que pour le dernier test lancé !À l'heure actuelle le job `Vidjil-valgrind` écrase à chaque fois le même fichier ce qui fait que nous n'avons les résultats de Valgrind que pour le dernier test lancé !Algo 2017.11https://gitlab.inria.fr/vidjil/vidjil/-/issues/2720Tester `make release`2018-01-31T10:06:47+01:00Mathieu GiraudTester `make release`Après #2255 et #1491.
On pourra avoir une règle qui teste la release. On l'avait sur Jenkins.Après #2255 et #1491.
On pourra avoir une règle qui teste la release. On l'avait sur Jenkins.Algo 2017.11