<div>Hi, </div><div> </div><div>For me Eigen 3.0.4 work perfectly. </div><div>cmake </div><div>make buildtests </div><div> </div><div>I have gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5). </div> <div> Perhaps a strange config on your linux distribution error... </div><div> </div><div>But I think that support GCC/Visual is a must to have for research code. </div><div>IPOL do not plan to have "company quality code" ... </div><div>I want to say that we don't have to support all the compiler but the most used one. </div><div>IPOL goal is to provide a usable code that respect an article under some basis condition (the basic tools that are used for software development). </div><div>I'm agree the more we support the better it is... but it's not the target. </div><div> </div><div>Regards, </div><div>Pierre </div> <div class="gmail_quote">Le 16 décembre 2011 13:44, Nicolas Limare <<a href="mailto:nicolas.limare@cmla.ens-cachan.fr">nicolas.limare@cmla.ens-cachan.fr</a>> a écrit : <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Suggestion de chapitre dans la thèse: mettre en forme cette > discussion sur la fiabilité d'une librairie, Eigen. </div>Je suis en train de rédiger un long commentaire des guidelines, en argumentant chacune des instructions, avec des parties issues des discussions que les guidelines ont suscitées. Je compte y ajouter un chapitre sur un projet d'extension des guidelines, qui permettrait le test automatique de la qualité du code. Cette discussion pourrait peut-être y trouver sa place. Je comptais initialement faire aussi un chapitre sur "introduction à la gualité logicielle", mais en fait le sujet est très vaste, trop vaste (j'ai plusieurs livres, donc certains de 1000 pages, sur le sujet), et très difficile à organiser, donc j'ai un peu abandonné. <div class="im"> > Ce problème de la "contamination par d'autres codes" non fiables > semble crucial. Je suppose qu'il y a une biblio là dessus qui > pourrait être ajoutée. </div>Étonamment, je n'ai pas de références en tête à ce sujet, et je ne sais pas où en trouver. Par contre il y a une large bibliographie, plutôt sous forme de livres, sur la très vaste question du contrôle qualité des logiciels, mais ce n'est pas tout à fait la même chose. Au passage, note que si les guidelines sont strictement respectées, les problèmes comme celui posé par Eigen pour le code SURF/orsa ne peuvent plus se poser, car un tel code serait refusé, ne respectant manifestement pas le standard. Je suis d'ailleurs étonné que le reviewer qui a signalé le problème avec Eigen ne conclue pas au refus du code en l'état. <div class="HOEnZb"><div class="h5"> -- Nicolas LIMARE - CMLA - ENS Cachan <a href="http://www.cmla.ens-cachan.fr/~limare/" target="_blank">http://www.cmla.ens-cachan.fr/~limare/</a> IPOL - image processing on line <a href="http://www.ipol.im/" target="_blank">http://www.ipol.im/</a> </div></div> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7rPTIACgkQvviFAPpCP080UgCdHbnHEWcFaMufdY8fvbb4eymi nCgAoIMMLbhvYAmkpW/O5U9qXA7YUtHs =mmW+ -----END PGP SIGNATURE----- _______________________________________________ discuss mailing list <a href="mailto:discuss@list.ipol.im">discuss@list.ipol.im</a> <a href="http://tools.ipol.im/mailman/listinfo/discuss" target="_blank">http://tools.ipol.im/mailman/listinfo/discuss</a> </blockquote></div> -- <div>Regards/Cordialement,</div><div>Pierre M</div>