vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2018-10-17T16:04:31+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3567should_results_from_vidjil() pourrait utiliser le .vidjil ou bien le .tsv2018-10-17T16:04:31+02:00Mathieu Giraudshould_results_from_vidjil() pourrait utiliser le .vidjil ou bien le .tsvActuellement, should_results_from_vidjil, utilisé par ~"dev\-tests\-curated\-vdj", prend ses infos dans le header fasta qui est faiblement structuré #3566.
Lui faire prendre les infos dans le .vidjil ?Actuellement, should_results_from_vidjil, utilisé par ~"dev\-tests\-curated\-vdj", prend ses infos dans le header fasta qui est faiblement structuré #3566.
Lui faire prendre les infos dans le .vidjil ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3450Modulariser .gitlab-ci.yml2021-02-23T11:54:48+01:00Mathieu GiraudModulariser .gitlab-ci.ymlDepuis #1491 :
> le `.gitlab-ci.yml` actuel est un gros mélange...
Vu https://gitlab.com/gitlab-org/gitlab-ce/issues/42861#note_99630939, on va pouvoir bientôt modulariser `.gitlab-ci.yml`, ce qui a la fois améliorera la situation act...Depuis #1491 :
> le `.gitlab-ci.yml` actuel est un gros mélange...
Vu https://gitlab.com/gitlab-org/gitlab-ce/issues/42861#note_99630939, on va pouvoir bientôt modulariser `.gitlab-ci.yml`, ce qui a la fois améliorera la situation actuelle (qu'on est susceptibles de garder encore un certain temps) et aussi préparera une éventuelle séparation #1491.
À faire dans la feature sera disponible dans ~"dev\-gitlab".https://gitlab.inria.fr/vidjil/vidjil/-/issues/3437d3.js : conserver, changer ?2019-01-10T15:21:24+01:00Mathieu Giraudd3.js : conserver, changer ?Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait êtr...Conservera-t-on a terme d3.js ? Très puissant, mais maitrise-t-on ce qu'il se passe ?
chart.js va être testé par @flothoni pour ~"app\-stats" stats#233, on pourra ainsi se faire une idée.
(Notons que même le ~"client\-grid" pourrait être fait en chart.js, http://www.chartjs.org/samples/latest/scriptable/bubble.html). Mais chart.js ne permet pas d'export svg.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3319Renommer les modes de DP pour être plus systématique et précis2018-06-28T10:53:27+02:00Mathieu GiraudRenommer les modes de DP pour être plus systématique et précisVoir #3315, #3317.
Soit on garde les appellations « Global » / …, en spécifiant Left/Right dès que nécessaire (Local LeftGlobal-RightSemiGlobal),
Soit on est plus explicite (et ce n'est pas que du ~bikeshedding, mais aussi une manière d...Voir #3315, #3317.
Soit on garde les appellations « Global » / …, en spécifiant Left/Right dès que nécessaire (Local LeftGlobal-RightSemiGlobal),
Soit on est plus explicite (et ce n'est pas que du ~bikeshedding, mais aussi une manière de ~"dev\-refactor" le code pour que ce soit plus clair) :
- Global: `startX = Complete, endX = Complete, startY = Complete, endY = Complete`
- Local:`startX = Partial, endX = Partial, startY = Partial, endY = Partial`
- SemiGlobal: `startX = Complete, endX = Complete, startY = Partial, endY = Partial`
- (actuellement LocalEndWithSomeDeletions) LeftLocal-RightGlobalEndWithSomeDeletions: `startX = Partial, endX = Partial, startY = Partial, endY = CompleteWithSomeDeletions`
- et #3318: `startX = Complete, endX = Partial, startY = Partial, endY = CompleteWithSomeDeletions`
(on pourrait trouver un nom plus sémantique, du genre `ReadAgainstGermline`)
Bref `{start, end}{X,Y} = (Complete / CompleteWithDeletionsEnd / Partial)` qui permettrait de faire n’importe quel alignement sur ces 3^4 modes.
En l’écrivant, je me dis que c’est la bonne solution : avoir ce qu’il faut de générique, ce qui aidera aussi à la lisibilité de `dynprog.cpp`, quitte à maintenir les alias `Global` / `Local` / `SemiGlobal` (et `ReadAgainstGermline`) pour les situations les plus courantes.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3254fuse.py, et champs à merger comme diversity2019-01-10T15:21:22+01:00Mathieu Giraudfuse.py, et champs à merger comme diversityVoir ce qui a été fait dans !176 : est-ce que cela ne peut pas être transformé en quelque chose d'encore plus générique pour fusionner une liste de champs quelconques ?
cc @flothoniVoir ce qui a été fait dans !176 : est-ce que cela ne peut pas être transformé en quelque chose d'encore plus générique pour fusionner une liste de champs quelconques ?
cc @flothonihttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3206Repasser sur les tests .should en bénéficiant des nouvelles syntaxes2020-08-21T12:21:35+02:00Mathieu GiraudRepasser sur les tests .should en bénéficiant des nouvelles syntaxesEn particulier
- Viser un mode par défaut exact, ne mettre `r` et `b` que quand souhaité
- Enlever `z`
- Quand c'est possible, limiter les commandes enchaînées/pipées et voir si on ne peut pas utiliser `l` ou autre
- Rendre les tests...En particulier
- Viser un mode par défaut exact, ne mettre `r` et `b` que quand souhaité
- Enlever `z`
- Quand c'est possible, limiter les commandes enchaînées/pipées et voir si on ne peut pas utiliser `l` ou autre
- Rendre les tests plus lisibles en mettant les commandes successives sur plusieurs lignes
- Utiliser `j` (et enlever `format-json`)
En profiter pour se demander si on aimerait tester d'autres choses (y compris des fonctionnalités non encore implémentées dans `should`).https://gitlab.inria.fr/vidjil/vidjil/-/issues/3184Factoriser js/form_builder.js et views/partial/file/form.html2018-04-17T14:55:19+02:00Mathieu GiraudFactoriser js/form_builder.js et views/partial/file/form.htmlOn peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'...On peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'autre sens ?
Si c'est trop complexe, pas de soucis, on laisse ainsi.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3084germline_id, *.g et vidjil-algo2020-11-19T08:41:57+01:00Mathieu Giraudgermline_id, *.g et vidjil-algoSuite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire év...Suite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire évoluer les germlines, travailler sur `split-from-imgt`, faire les tests qui vont avec sans casser l'algo. Quand on est content, on met à jour `germline_id` et on travaille sur l'algo.
Problème : on trouve aussi ces numéros de versions dans les `*.g` (mais qui sont aussi, quelque part, des choses plutôt algo).
Voir #1491.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3064Stats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur ...2018-02-27T14:29:40+01:00Mathieu GiraudStats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur 'set'A-t-on besoin de trois controlleurs différents ?
cc @RyanHerbA-t-on besoin de trois controlleurs différents ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2968Classes pour les méthodes de segmentation2022-02-01T10:30:14+01:00Mathieu GiraudClasses pour les méthodes de segmentationDiscuté avec @mikael-s il y a déjà un certain temps : "segment.cpp a plein de `if`, on commence a ne plus y voir grand chose."Discuté avec @mikael-s il y a déjà un certain temps : "segment.cpp a plein de `if`, on commence a ne plus y voir grand chose."Algo 2022.04Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2959Groupe public géré par web2py2018-01-08T09:54:07+01:00Mathieu GiraudGroupe public géré par web2pyNous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le...Nous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le faire de notre côté.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2892clone.shortName n'est pas utilisé2017-11-24T17:01:42+01:00Mathieu Giraudclone.shortName n'est pas utilisé`client.getCode` possède un test `this.length > 100` qui ne fait rien, et donc `.shortName` n'est pas utilisé. Cette ligne date de la nuit des temps (681f539f).
`getShortName()`, bien plus récent, n'utilise pas du tout `.shortName` (mai...`client.getCode` possède un test `this.length > 100` qui ne fait rien, et donc `.shortName` n'est pas utilisé. Cette ligne date de la nuit des temps (681f539f).
`getShortName()`, bien plus récent, n'utilise pas du tout `.shortName` (mais est appelé à chaque `updateElem` de ~"client-cloneList", c'est sûrement trop souvent). Il devrait stocker son résultat dedans.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2810Multiple scatterplot : créer une seule fois sp22020-10-13T17:40:36+02:00Mathieu GiraudMultiple scatterplot : créer une seule fois sp2On devrait avoir une seule création de `sp2` (comme c'est le cas `graph` d'ailleurs).
Mais en faisant #2698, je n'y suis pas arrivé et j'ai laissé tomber. C'est maintenant dans !114.On devrait avoir une seule création de `sp2` (comme c'est le cas `graph` d'ailleurs).
Mais en faisant #2698, je n'y suis pas arrivé et j'ai laissé tomber. C'est maintenant dans !114.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2747Organiser les sample_sets par projet pour accélérer les requêtes2020-09-23T17:32:47+02:00Ryan HerbertOrganiser les sample_sets par projet pour accélérer les requêtesActuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la no...Actuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la notion de hierarchie de groupes, on se retrouve avec des requêtes plutôt complexes pour déterminer si l'utilisateur a accès à un élément.
> Il faut chercher si l'utilisateur appartient à un groupe qui a la permission `access` ou à un groupe dont le parent a la permission `access`
Donc lister les sets d'un type particulier auxquels un utilisateur a accès revient au code suivant:
``` python
def vidjil_accessible_query(self, name, table, user_id=None):
"""
Returns a query with all accessible records for user_id or
the current logged in user
this method does not work on GAE because uses JOIN and IN
This is an adaptation of accessible_query that better fits
the current auth system with group associations
:param: name: The name of the query (eg. 'read')
:param: table: The table for accessibility
:param: user_id: ID of the user
Example:
Use as::
db(auth.vidjil_accessible_query('read', db.mytable, 1)).select(db.mytable.ALL)
"""
if not user_id:
user_id = self.user_id
db = self.db
if isinstance(table, str) and table in self.db.tables():
table = self.db[table]
elif isinstance(table, (Set, Query)):
# experimental: build a chained query for all tables
if isinstance(table, Set):
cquery = table.query
else:
cquery = table
tablenames = db._adapter.tables(cquery)
for tablename in tablenames:
cquery &= self.vidjil_accessible_query(name, tablename,
user_id=user_id)
return cquery
if not isinstance(table, str) and\
self.has_permission(name, table, 0, user_id):
return table.id > 0
membership = self.table_membership()
permission = self.table_permission()
perm_groups = self.get_permission_groups(name, user_id)
query = (table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)) |
table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == db.group_assoc.second_group_id) &
(db.group_assoc.first_group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)))
if self.settings.everybody_group_id:
query |= table.id.belongs(
db(permission.group_id == self.settings.everybody_group_id)
(permission.name == name)
(permission.table_name == table)
._select(permission.record_id))
return query
```
Ce qui produit la requête SQL suivante:
```sql
SELECT `patient`.`id`, `patient`.`first_name`, `patient`.`last_name`, `patient`.`birth`, `patient`.`info`, `patient`.`id_label`, `patient`.`creator`, `patient`.`sample_set_id` FROM `patient`
WHERE (
(`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`
WHERE (
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
))
)
OR (`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`, `group_assoc`
WHERE (
(
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `group_assoc`.`second_group_id`)
) AND (`group_assoc`.`first_group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
)
)
));
```
On a donc une requête composée de deux sous-requêtes chacune contenant un `IN` aussi long que le nombre de groupes auxquels l'utilisateur appartient, l'une avec un `join` et l'autre avec deux `join` (ici les joins sont implicites).
Et les autres primitives du model `VidjilAuth` sont composées de plusieurs `joins` et souvent plusieurs requêtes.
Avec une organisation par projet (avec une nouvelle table, et une clef étrangère dans la table `sample_set`) on pourrait se débarrasser complètement de la permission `access`, et par la même occasion on laisse tomber cette anbiguïté qu'on a avec les groupes de projets/hôpitaux et les groupes de rôles/permissions.
La requête "patient" deviendrait:
```python
def get_project_sets(type, project_id):
return db(
(db.sample_set.project_id == project_id) &
(db.sample_set.sample_type == type) &
(db[type].sample_set_id == db.sample_set.id)
).select(db[type].*)
```
Avec auparavant avoir vérifié que l'utilisateur ait accès à un groupe/rôle apparetenant au projet (2 joins sur relativement peu de données). Ce qui nous donne un total de 4 joins sur deux requêtes par rapport à un total de 3 joins répartis sur 3 requêtes, et on perd les `IN`
Il y a plusieurs autres endroits où des gains de jointures ou de requêtes seraient aussi envisageables (`get_permission(...)`, `can_view_sample_set(...)`, ...).
Ainsi que des endroits où les requêtes seraient plus complexes ?
J'aurais tendance à vouloir limiter les associations de samples à des sets du même projet car celà simplifierai certaines requêtes, comme l'autocompletiondes tags, et ainsi que celle des samples_sets à l'ajout d'un sample.
Ca éliminerait également l'impacte des grosses requêtes auxquelles nous les admins soumettons la BDD. Et donc on n'occuperait plus un (voire plus) de processus uwsgi pendant des durées prolongées (par exemple, plus d'une minute pour un compare patient).
Cette moification demanderait beaucoup de travail, donc ça ne serait pas pour tout de suite, mais je pense que celà réduirait le nombre de timeouts subis par nos utilisateurs. Celà demanderait peut-être plus d'analyse, de tests et de benchmarks.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2700Réduire les différences entre MODE_BAR et MODE_GRID2018-10-03T23:57:38+02:00Mathieu GiraudRéduire les différences entre MODE_BAR et MODE_GRIDY a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compt...Y a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compte en essayant de faire #2699, voir !91)
- dans `scatterplot.js`, similarités de codes entre `computeBarTab` utilise `axisX.posBarLabel
Dans `scatterplot.js`, au moment de faire le bar plot, on doit certes avoir une gestion différenciée de l'axe Y. Mais j'ai l'impression que tout ce qui touche l'axe X devrait être identique/générique (et #2394 serait alors naturel). Que ce soit en `BAR` ou en `GRID`, que ce soit en valeurs génériques ou numériques, on peut avoir (ou pas) des valeurs `?`, on a envie d'avoir du `nice_{floor,ceil}` #2699, on peut vouloir (ou pas) zoomer #2431.
cc @RyanHerbWeb 2018.01https://gitlab.inria.fr/vidjil/vidjil/-/issues/2585haml2023-03-01T16:42:41+01:00Mathieu Giraudhaml@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2440Segmenteur, gènes VDJ: refactorer encore, highlights2017-11-29T15:11:37+01:00Mathieu GiraudSegmenteur, gènes VDJ: refactorer encore, highlightsÉvoqué avec @aurelBZH : ce serait bien que `toString` de `genseq` utilise les highlights. Cela permettrait de faire des choses sur les "autres séquences", et surtout de ne pas avoir de code en double.
Une solution est de couper `toStrin...Évoqué avec @aurelBZH : ce serait bien que `toString` de `genseq` utilise les highlights. Cela permettrait de faire des choses sur les "autres séquences", et surtout de ne pas avoir de code en double.
Une solution est de couper `toString` de `Sequence` en deux, pour sépararer la partie préparation des highlights de la partie affichage.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2438Eviter les initialisations multiples2017-11-14T17:42:00+01:00Ghost UserEviter les initialisations multiplesJe remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler...Je remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler ce souci permettrait certainement de gagner en performance, ou du moins de limiter les appels 'superflus'.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2388Code similaire dans list.div_elem et segmenter.div_elem2020-10-14T11:29:53+02:00Ghost UserCode similaire dans list.div_elem et segmenter.div_elemLes éléments identiques ont été factorisés et rassemblés avec la création de `clone.div_elem` (!21).
Il reste cependant quelques éléments communs mais qui n'ont pas pu être déplacés tout de suite, car ils sont traités de manières diff...Les éléments identiques ont été factorisés et rassemblés avec la création de `clone.div_elem` (!21).
Il reste cependant quelques éléments communs mais qui n'ont pas pu être déplacés tout de suite, car ils sont traités de manières différentes. C'est par exemple le cas de `nameBox`, qui a a priori la même utilité et la même place dans les deux cas mais qui n'est pas construit et mis à jour de la même façon.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2368axis: mettre toutes les valeurs de available_axis dans GenericAxis()2018-08-08T20:49:02+02:00Mathieu Giraudaxis: mettre toutes les valeurs de available_axis dans GenericAxis()Suite à la discussion de hier, et en particulier les problèmes sur le `init`, je me demande
si on ne pourrait pas mettre tout ce qu’on a besoin pour chaque axe dans `GenericAxis()`,
peut-être sous la forme d’un dictionnaire comme il y a ...Suite à la discussion de hier, et en particulier les problèmes sur le `init`, je me demande
si on ne pourrait pas mettre tout ce qu’on a besoin pour chaque axe dans `GenericAxis()`,
peut-être sous la forme d’un dictionnaire comme il y a des choses optionnelles.
On aurait quelque chose du genre :
```
avalaible_axis = [
...,
new PercentCustomAxis("sequenceLength", this.m,
{
doc: "ratio of the number of reads of each clone to the total number of reads in the selected locus",
label: "size",
fct : function(clone){return clone.getSizeZero()},
min : function(){return self.m.min_size},
max : 1,
log : true
}),
...
]
```
Ou, si on souhaite garder un dictionnaire, `"sequenceLength": new PercentCustomAxis( ... )`
Si on n'a plus de dictionnaire pour `available_axis`, une conséquence pourrait être, dans `scatterPlot.js`, de se passer complètement de `splitX` et `splitY` (sauf dans `changeSplitMethod`) et de remplacer
- `this.available_axis[this.splitX]` par quelque chose du type`this.axisX.data`
- `this.splitX` en `this.axisX.key`
Les appels à `available_axis` ne seraient alors que dans la construction du menu "plot" (et aussi dans`updateMenu`)
(et peut-être aider #2367).
cc @RyanHerb