Je commence par ça sinon vraiment personne ne va me lire…

• La visu des éléments AEJ de Vinciane plante (Windows et Linux). Les tests 2D tournent mais “clignotent” bizarrement. Les tests 3D plantent lors de l'ouverture de la fenêtre (pareil chez Luc qui utilise les libdelui). J'ai essayé de debuguer rapidement mais sans succès. J'ai envoyé un mail à Vinciane. Peut-être utilise-t-elle un vizwin.conf spécifique où une option par défaut serait désactivée?
• Le test abrawal.testsBattery.frequenciesAnalysisBlade18ER (Philippe) produit des fréquences qui varient d'un run à l'autre. On obtient par exemple des résultats différents si on lance avec le script battery.py ou avec la GUI. Voulant vérifier les valeurs obtenues sous linux, je me suis rendu compte que le script matlab utilisé faisait un syntax error sur une nouvelle fonctionnalité (utilisation d'un tilde pour ignorer un argument retourné par une fonction)! C'est un peu bête de ne pas le signaler (ou d'utiliser une telle fonctionnalité qui supprime la compatibilité avec d'anciennes version). Finalement, j'ai mis à jour matlab (2012a).
• Beaucoup de tests ne nettoient pas correctement le workspace lors de la batterie. En fin de batterie le workspace dans bin devrait être vide. Plus grave, des fichiers se trouvent dans le répertoire bin hors de tout workspace. Si chaque test ne reste pas dans son workspace, on ne pourra plus lancer la batterie en parallèle en toute sécurité. Essayez donc de corriger ces problèmes.

Mon TFiste travaille sur un PC Ubuntu 12.04LTS. J'ai donc décidé de compiler le code sur cet OS. A ma grande surprise, je n'ai rien dû recompiler au niveau des libs. J'ai eu, par contre, un petit problème avec le nouveau compilateur intel (C++ v13.1 du “composer XE 2003 update 2” équipé des MKL 11.0) et le gcc 4.6.

• Certaines fonctions de <mkl_service.h> ont été renommées et les anciens noms (utilisés par gaston et sa version 10.1) ne sont plus utilisables. J'ai donc dû bidouiller le source pour que ça marche. On utilise maintenant les nouveaux noms et si ceux-ci ne sont pas dispo (sur gaston), on crée des macros.
• MKL 11.0 ne possède plus de lib “solver” dédiée. J'imagine que le DSS est maintenant dans la lib principale nommée mkl_intel. J'ai donc modifié CMake/FindMKL.cmake pour rechercher cette lib séparement des autres. Si elle n'est pas trouvée, c'est qu'on utilise une nouvelle version des MKL et on ne linke plus avec.

J'utilise la toute dernière version du compilateur Intel puisqu'il est gratuit en utilisation non-commerciale.

• Problème: certaines fonctions friend dans nos namespaces ne sont pas reconnues lors de la compilation. Par exemple la fonction Gen4::operator«(std::ostream &out, const Vec &v) de gen4::Vec (fichier gen4vec.cpp) génère le message: error: namespace “Gen4” has no member “operator«”. On a simultanément un message pour Gen4::operator«(std::ostream &out, const Vec3 &v). En ajoutant une déclaration supplémentaire dans le .h pour la première fonction, on se débarrasse… des deux erreurs!!! Ca commence à sentir le moisi. Continuons dans l'étrange: après avoir trouvé ce premier remède, je décide alors de supprimer cette déclaration un peu moche un peu inutile et d'encapsuler les définitions des deux fonctions problématiques dans une définition de namespace (namespace Gen4 { et };), dans le .cpp. Youpi, le fichier compile… mais la compilation plante plus tard dans gen4metric.cpp sur Gen4::operator«(std::ostream &out, const Metric &v) (??) Cette erreur n'apparait pas si la déclaration magique ajoutée précédemment est présente! Bref, je me demande si c'est pas un bug dans le compilateur. J'ai donc ajouté quelques déclarations de fonctions friend qui plantaient jusqu'à ce que j'arrive à compiler tout le code. C'est pas terrible mais ça marche…

Avec ces modifs, le code peut être compilé avec le compilateur Intel.

Problème beaucoup plus drôle avec gcc: le code compile sans problème de A à Z mais il plante au runtime lors de l'utilisation des objets Partition (un peu après le Sloan). En debug, grâce à l'Intel Debugger (idb), je me suis rendu compte que la commande new Partition() créait un objet de type inconnu qui n'a rien a voir avec notre Partition. Je suspecte les nouvelles extensions “parallèles” du C++11, nouveauté du gcc 4.6. Autre possibilité, un objet nommé Partition dans une lib annexe de VTK hors de tout namespace (c'est moins probable vu que l'interface graphique n'intervient pas à ce niveau dans le code. J'ai donc décidé de renommer l'objet Partition en mtPartition. A terme, il sera utile de créer un namespace (mt ou mtf par exemple) pour protéger tous nos objets. Pour l'instant, on s'en sort avec un nouveau nom pour une seule classe.

Voilà: portage gcc 4.6 effectué!

Donc, en conclusion, pour ceux qui voudraient utiliser du Linux sur une nouvelle machine (ou dans une vbox), cet OS est pas mal. Quelques apt-get install et Metafor tourne.

— Romain BOMAN 2013/03/01 12:27