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.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
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".
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
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.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
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".
"La première sécurité est la liberté"