Pour répondre sur les assertions et ton problème d'erreur de signe. Tu peux trouver des erreurs d'équation en utilisant les propriétés mathématiques de ta fonction, par exemple, tu vérifies que l'opération reste transitive, reflexive, tu peux vérifier les éléments neutres, et autre propriété un peu poussé. Si tu codes une multiplication de matrice tu peux vérifier par exemple que ((A*B)*A)*B =A*((B*A)*B).
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
Le truc c'est que ça ne change rien au schmilblic. Pour les vérifs dont tu parle, il faut qu'il y en ais des propriétés testables et c'est pas toujours le cas.
Dans mon cas, c'est un algo itératif qui converge vers un optimum, l'opération en question était destinée à corriger certains comportements très particulier de l'algo dans des cas rares qui produisent une instabilité.
L'algo va quand même converger, mais sur certaines dimension il va osciller pendant plusieurs itérations avant de réussir à sortir de la configuration particulière.
Donc, les assertions qui vérifie que globalement on converge ne sont pas levées puisque l'on continue de converger. On converge beaucoup plus lentement mais on ne peut pas savoir que ça devrait être plus rapide.
Et on ne peut pas mettre d'assertions sur l'instabilité car ces un comportement qui ne peut être vérifié que sur un grand nombre d'itérations. Une instabilité sur deux ou trois itération c'est normal, sur plus d'une dizaine ça doit être corrigé. Et garder en mémoire les valeurs des dix dernière itération c'est tout simplement impossible.
Je ne vais pas rentrer dans les détails du système mais la vérification des propriétés n'est absolument pas une solution miracle, tout comme le debuggage à coup de log.
Il faut bien voir qu'il y a plein de manière de debugger et quelle sont toutes complémentaires. Dans mon cas, le programme en question c'est parfois plusieurs jours de calculs avec des problèmes qui ne se manifestent que sur de gros volumes de données et très difficiles à cibler, donc le debuggeur interactif, c'est pas vraiment gérable.
C'est des morceaux de code ou des vérifications complexes reviendrais à rajouter 4 fois plus de code que l'existant et qui donc contiendrais surement 4 fois plus de bugs.
Le coeur de l'algo fait en gros 400 lignes de C. C'est pas beaucoup mais ça reste très complexe à debugger. Tu rajoute à un peu plus d'une centaine de lignes de commentaires, et un peu moins de 200 lignes d'assertions.
Si je le transforme en Lisaac, du peu d'experience que j'ai dans ce langage, j'ai pas l'impression que le nombre de lignes de code va changer. C'est vraiment des math brutal, il y a rien du style allocation memoire ou autre. C'est juste des boucles, des if et des calculs.
La seule différence qu'il y aura ce sont les assertion qui deviennent des contrats, donc rien de plus facile pour debugger.
C'est même pire avec les contrats... Actuellement j'ai 6 types d'assertions différentes qui ne sont pas tous activés en même temps. Certains test sont peu couteux et peuvent rester en permanence, mais d'autre sont très couteux et ne sont activé que quand il y en as besoin, générallement sur des jeux de données petits ou avant le week-end.
A ma connaissance, ce genre de vérification sélective n'est pas simple à faire avec des contrats. C'est plus du tout ou rien.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
C'est bien beau tout ça, mais quand ? Ça à quand même l'air d'être pour dans longtemps. Ce n'est pas une critique mais ça veut dire que pour un gros projet c'es pas pour tout de suite, donc pour un gros projet Lisaac n'est pas adapté.
Je prend un autre exemple ou une compilation rapide est presque indispensable : un projet colaboratif ou la compilation commence à être longue.
Dans ce genre de projet, quand tu soumet un fonctionalité, la politesse veut que tu découpe ton gros patch en plusieurs petits patch progressif qui peuvent être testé un par un, et approuvé un par un. Pour la libdispatch par exemple, il y a eu un patch il y a peu découpé en 17 petits-patchs. Cela veut dire pour celui qui soumet 17 compilation pour vérifier à chaque fois que le patch marche bien donc beaucoup de temps s'il faut tout recompiler. Et autant de compilation pour tout ceux qui testent les patchs.
Sachant que génarallement il y a des remarques et des petites modifs à faire, c'est beaucoup de temps au final.
Et pourtant la libdispatch n'est pas un si gros projets que ça au final et des patch de ce genre son pas des cas rares.
Donc Lisaac a, à mon avis, un manque à ce niveau là. Encore une fois, ce n'est pas une critique du langage en lui-même, mais quand tu en parles, il faut accepter cette limitation et dire que ça changera, mais surtout admettre que au moins pour l'instant il n'est pas adapté.
[^] # Re: Surprise
Posté par beagf . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 4.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
Le truc c'est que ça ne change rien au schmilblic. Pour les vérifs dont tu parle, il faut qu'il y en ais des propriétés testables et c'est pas toujours le cas.
Dans mon cas, c'est un algo itératif qui converge vers un optimum, l'opération en question était destinée à corriger certains comportements très particulier de l'algo dans des cas rares qui produisent une instabilité.
L'algo va quand même converger, mais sur certaines dimension il va osciller pendant plusieurs itérations avant de réussir à sortir de la configuration particulière.
Donc, les assertions qui vérifie que globalement on converge ne sont pas levées puisque l'on continue de converger. On converge beaucoup plus lentement mais on ne peut pas savoir que ça devrait être plus rapide.
Et on ne peut pas mettre d'assertions sur l'instabilité car ces un comportement qui ne peut être vérifié que sur un grand nombre d'itérations. Une instabilité sur deux ou trois itération c'est normal, sur plus d'une dizaine ça doit être corrigé. Et garder en mémoire les valeurs des dix dernière itération c'est tout simplement impossible.
Je ne vais pas rentrer dans les détails du système mais la vérification des propriétés n'est absolument pas une solution miracle, tout comme le debuggage à coup de log.
Il faut bien voir qu'il y a plein de manière de debugger et quelle sont toutes complémentaires. Dans mon cas, le programme en question c'est parfois plusieurs jours de calculs avec des problèmes qui ne se manifestent que sur de gros volumes de données et très difficiles à cibler, donc le debuggeur interactif, c'est pas vraiment gérable.
C'est des morceaux de code ou des vérifications complexes reviendrais à rajouter 4 fois plus de code que l'existant et qui donc contiendrais surement 4 fois plus de bugs.
Le coeur de l'algo fait en gros 400 lignes de C. C'est pas beaucoup mais ça reste très complexe à debugger. Tu rajoute à un peu plus d'une centaine de lignes de commentaires, et un peu moins de 200 lignes d'assertions.
Si je le transforme en Lisaac, du peu d'experience que j'ai dans ce langage, j'ai pas l'impression que le nombre de lignes de code va changer. C'est vraiment des math brutal, il y a rien du style allocation memoire ou autre. C'est juste des boucles, des if et des calculs.
La seule différence qu'il y aura ce sont les assertion qui deviennent des contrats, donc rien de plus facile pour debugger.
C'est même pire avec les contrats... Actuellement j'ai 6 types d'assertions différentes qui ne sont pas tous activés en même temps. Certains test sont peu couteux et peuvent rester en permanence, mais d'autre sont très couteux et ne sont activé que quand il y en as besoin, générallement sur des jeux de données petits ou avant le week-end.
A ma connaissance, ce genre de vérification sélective n'est pas simple à faire avec des contrats. C'est plus du tout ou rien.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
C'est bien beau tout ça, mais quand ? Ça à quand même l'air d'être pour dans longtemps. Ce n'est pas une critique mais ça veut dire que pour un gros projet c'es pas pour tout de suite, donc pour un gros projet Lisaac n'est pas adapté.
Je prend un autre exemple ou une compilation rapide est presque indispensable : un projet colaboratif ou la compilation commence à être longue.
Dans ce genre de projet, quand tu soumet un fonctionalité, la politesse veut que tu découpe ton gros patch en plusieurs petits patch progressif qui peuvent être testé un par un, et approuvé un par un. Pour la libdispatch par exemple, il y a eu un patch il y a peu découpé en 17 petits-patchs. Cela veut dire pour celui qui soumet 17 compilation pour vérifier à chaque fois que le patch marche bien donc beaucoup de temps s'il faut tout recompiler. Et autant de compilation pour tout ceux qui testent les patchs.
Sachant que génarallement il y a des remarques et des petites modifs à faire, c'est beaucoup de temps au final.
Et pourtant la libdispatch n'est pas un si gros projets que ça au final et des patch de ce genre son pas des cas rares.
Donc Lisaac a, à mon avis, un manque à ce niveau là. Encore une fois, ce n'est pas une critique du langage en lui-même, mais quand tu en parles, il faut accepter cette limitation et dire que ça changera, mais surtout admettre que au moins pour l'instant il n'est pas adapté.