Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile).
Le problème c'est qu'un debuggeur est très pratique pour certains type de bug, mais pas tous. Si je prend un cas que j'ai eu jeudi dernier. Je code un algo en C car la quantité de calcul est monstrueuse et j'ai besoin que ce soit relativement rapide.
Avant de faire l'implémentation en C, j'en ai fait une sous Octave qui m'a permis de le coder de manière très rapide et bien plus sure. La version sous Octave à été beaucoup plus simple à debugger, et je sais maintenant que le résultat qu'elle me sort est correcte même si elle y passe des heures sur de petites données d'entrée.
La version en C me sortait un résultat différent, donc il y a un bug. Pour débugger, j'ai sortit plusieur logs des différents calculs intermédiaires fait par la version en Octave. Dans ces log j'ai des matrices gigantesques, donc impossible de faire un gdb et de lui demander de m'afficher les matrice et de comparer à la main.
J'ai recompiler plusieurs version du programme en C, dans lequel je sort aussi des logs, pour trouver ou ce situe le problème et voir à quel endroit il y a une différence.
GDB est très utile quand tu as un bug bien localisé, c'est-à-dire, un bug ou tu peut mettre un point d'arret très près de l'enroit ou ce produit le bug, ou une surveillance sur une donnée quand tu sait qu'elle va prendre une valeur interdite. Mais dans mon cas, et je suis souvent confronter à ce genre de problème, ce n'est pas un segfault ou autre, le programme est parfaitement correct, c'est juste qu'il traite de grosse quantitées de donnée et ne fait pas le bon calcul sur certaines d'entre elles.
Il faut bien comprendre qu'il n'y a pas une seule bonne manière de debugger.
Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Et comme d'habitude, la réponse classique est à côté de la plaque ;-) Si tu veux nous vendre Lisaac avec comme argument «il ne fait que de la compilation globale parce que c'est meilleur pour les optims» il faut bien t'attendre à avoir des remarques sur le «que»...
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant... Et pour prouver que je suis de bonne foi, il y a eu une news qui m'avait même fait tester Lisaac. Je l'avais installer, porter si je me souvien bien, deux codes de calculs et donner les résultats en commentaire de mes petits benchs.
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
Pour ce qui est de ce journal, je parlais de javascript, mais j'avais surtout en tête, l'impression qui ressort de l'ensemble des journaux et news sur Lisaac. Quasiment à chaque fois on à vraiment l'impression que seul Lisaac est un bon langage et que le reste est de la merde à vous lire.
C'est ça que je n'apprécie pas...
[^] # Re: Surprise
Posté par beagf . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile).
Le problème c'est qu'un debuggeur est très pratique pour certains type de bug, mais pas tous. Si je prend un cas que j'ai eu jeudi dernier. Je code un algo en C car la quantité de calcul est monstrueuse et j'ai besoin que ce soit relativement rapide.
Avant de faire l'implémentation en C, j'en ai fait une sous Octave qui m'a permis de le coder de manière très rapide et bien plus sure. La version sous Octave à été beaucoup plus simple à debugger, et je sais maintenant que le résultat qu'elle me sort est correcte même si elle y passe des heures sur de petites données d'entrée.
La version en C me sortait un résultat différent, donc il y a un bug. Pour débugger, j'ai sortit plusieur logs des différents calculs intermédiaires fait par la version en Octave. Dans ces log j'ai des matrices gigantesques, donc impossible de faire un gdb et de lui demander de m'afficher les matrice et de comparer à la main.
J'ai recompiler plusieurs version du programme en C, dans lequel je sort aussi des logs, pour trouver ou ce situe le problème et voir à quel endroit il y a une différence.
GDB est très utile quand tu as un bug bien localisé, c'est-à-dire, un bug ou tu peut mettre un point d'arret très près de l'enroit ou ce produit le bug, ou une surveillance sur une donnée quand tu sait qu'elle va prendre une valeur interdite. Mais dans mon cas, et je suis souvent confronter à ce genre de problème, ce n'est pas un segfault ou autre, le programme est parfaitement correct, c'est juste qu'il traite de grosse quantitées de donnée et ne fait pas le bon calcul sur certaines d'entre elles.
Il faut bien comprendre qu'il n'y a pas une seule bonne manière de debugger.
Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Et comme d'habitude, la réponse classique est à côté de la plaque ;-) Si tu veux nous vendre Lisaac avec comme argument «il ne fait que de la compilation globale parce que c'est meilleur pour les optims» il faut bien t'attendre à avoir des remarques sur le «que»...
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant... Et pour prouver que je suis de bonne foi, il y a eu une news qui m'avait même fait tester Lisaac. Je l'avais installer, porter si je me souvien bien, deux codes de calculs et donner les résultats en commentaire de mes petits benchs.
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
Pour ce qui est de ce journal, je parlais de javascript, mais j'avais surtout en tête, l'impression qui ressort de l'ensemble des journaux et news sur Lisaac. Quasiment à chaque fois on à vraiment l'impression que seul Lisaac est un bon langage et que le reste est de la merde à vous lire.
C'est ça que je n'apprécie pas...