GDL
GDL est un clone libre d'IDL, logiciel propriétaire largement utilisé en astronomie et dans d'autres domaines (géophysique, télédétection, médecine). Il s'agit d'un langage interprété à la syntaxe simple, typé dynamiquement, permettant d'écrire des fonctions complexes. Par rapport aux langages compilés classiques, il présente l'avantage de laisser la main sur les données à tout moment dans l'interpréteur de commande (CLI) et de les afficher aisément.
Pour les calculs, ce langage interprété fait appel à des bibliothèques écrites en C et C++, ce qui n'est pas pénalisant niveau temps de calcul lorsque l'on sait s'en servir ! (cf. le paragraphe Astuces ci-dessous). Ce langage sait gérer des objets à plusieurs dimensions (vecteurs, images, cubes, ...) et des structures. À travers des commandes concises, il permet un affichage simple de courbes, surfaces et images, avec une grande richesse de paramétrage. C'est un langage idéal pour écrire des prototypes et des pipelines complexes, tester des idées de traitement sur des données, ...
Cf les définitions sur Wikipedia :
GDL a une interface avec python, des routines écrites en python peuvent être appelées depuis GDL. Réciproquement, on peut appeler des codes en syntaxe GDL depuis python (nous avons eu très peu de retours sur ces usages).
De nombreux tests de régression sont faits de routine par rapport aux formats. Il ne faut pas hésiter à remonter les problèmes, notamment pour les très gros fichiers (> 4Go) et les petits/grands indiens.
- Tout format ASCII (dont CSV lisible par tout tableur) en entrée et en sortie
- Le format FITS est écrit et lu (via Astron ; format fréquent en astronomie)
- Le format XDR est écrit et lu (via une bibliothèque externe, à la licence empêchant son intégration dans GDL)
- Le format netCDF est réputé parfaitement supporté
- Le format HDF est partiellement supporté (dans la pratique, assez largement)
- Le format PDS est assez largement supporté
- Le format HEALPix est supporté
- Certains formats binaires, avec des aléas sous certaines plates-formes (de plus en plus rare)
- Existence de bibliothèques pour d'autres formats (images, formats métier...).
Plusieurs personnes, chercheurs, ITA et étudiants (master et thèse), utilisent GDL de manière régulière ou sporadique à l'Observatoire de Paris/Meudon. Je (AC) suis en contact avec des utilisateurs au CEA, dans des laboratoires du Max-Planck, à la Nasa, dans des universités américaines, anglaises, en Inde, en Pologne, au Vénézuéla ... GDL est utilisée au ESC (Japon). Les nouveaux venus qui ne connaissent pas IDL sont plutôt satisfaits car la syntaxe est simple, les performances raisonnables, la stabilité aussi. Depuis 2009, des articles à "referee" sont explicitement basés sur des calculs avec GDL, après inter-validation avec IDL.
Les utilisateurs avertis d'IDL sont plus gênés car :
- ils ne retrouvent pas certaines de leurs fonctions et procédures intrinsèques préférées d'IDL, même si le taux de couverture a significativement augmenté (cf http://aramis.obspm.fr/~coulais/IDL_et_GDL/Matrice...),
- ils connaissent un grand nombre de mots-clefs dont certains ne sont pas encore disponibles dans GDL (les développeurs de GDL ne sachant parfois même pas que tel ou tel mot-clef historique et non documenté d'IDL --car décrété obsolescent-- existait !),
- ils espèrent utiliser des codes IDL directement sans toucher au code source mais se heurtent à des difficultés en cascade, le plus souvent à cause de mots-clés manquants.
- Nous dépendons de la qualité de logiciels extérieurs, notamment PLplot, GDL, FFTw, Eigen3, IM ou GM. Certains sont parfois mal packagés pour certaines cibles, ou connaissent des régressions temporaires. Notre suite de test permet de tester et nos problèmes et parfois des problèmes externes, notamment pour IM.
- Les Widgets d'IDL ne sont pas que très partiellement implémentées : toute aide sera la bienvenue.
- Certains formats sont mal relus, en particulier des fichiers binaires écrits avec IDL sur certaines plates-formes en voie d'obsolescence (e.g. VMS). Tout retour sur ces problèmes permettrait de voir si des solutions méritent d'être développées. Il ne suffit plus de dire que "ça ne marche pas", nous avons besoin de retour concret (version GDL, OS et dépendances (ldd), fichiers et code de test) pour traquer les dernières déficiences. La plupart des cas soumis ont été rapidement résolus.
- La plupart des fonctions graphiques (plot, contour, surface, TV, ...) sont disponibles, mais certaines limitations existent (certains mots-clés manquent, absence de polices spéciales pour les titres, ...). Ceci est basé sur la bibliothèque Plplot, globalement satisfaisante dans GDL par rapport à la rapidité d'affichage dans IDL (sauf sous Debian où un écart significatif persiste (parfois +50%), les écarts sont désormais négligeables (environ 10%). À noter que le support de l'affichage des NaN et +-Inf a été inclus dans GDL depuis la 0.9pre4.
- Depuis rc4, la sortie Postscript n'est plus limitée au N&B, mais il reste des problèmes dans le positionnement et la qualité des sorties Postscript.
- Certains programmes fonctionnant en IDL ne tournent pas immédiatement sous GDL. On peut distinguer plusieurs cas :
- (1) une fonctionnalité intrinsèque manquante dans GDL
- (2) une bibliothèque externe manquante
- (3) des bogues dans GDL ou
- (4) des problèmes de syntaxe du côté de GDL.
Dans le cas 1, il faudra voir s'il existe un moyen simple de contourner le problème, ou d'implémenter le code manquant (en *.pro ou en C++, cf cas Bessel). Sinon, faire une demande aux développeurs. Dans le cas 2, bien vérifier ce qui est dans les chemins. On a eu des retours de personnes n'ayant pas compris comment ajouter Astron ou Mpfit dans le chemin des bibliothèques vues par GDL. Oui, l'installation complète de GDL avec Save/Restore, la cartographie, FFTw et ImageMagick (pour les entrées-sorties dans divers formats graphiques) peut être longue ! Dans les cas (3) et (4), un rapport de bogue sera bénéfique à tout le monde, car la version actuelle est plutôt bien stabilisée pour l'usage quotidien des principaux utilisateurs connus et des développeurs.
- On peut utiliser le flag !GDL (DEFSYSV, '!gdl', exist=flag) pour tester si on est en IDL ou en GDL, ce qui permet de contourner aisément les éventuels problèmes restants en traitant les 2 cas (cf cet usage dans testsuite/test_besel.pro dans le CVS).
- Certaines versions ou évolutions de bibliothèques externes (readline, plplot, GSL, FFTw, ...) peuvent poser problème (à la compilation ou durant l'usage de GDL). Ainsi, les dernières versions de PLplot (5.6.x et 5.8) semblent poser problème avec GDL 0.9 pre 4/5/6. La version historique 5.5.3 disponible pré-packagée sous Debian ne pose pas de problème... Sous OSX, la readline fournie par Apple, ancienne et limitée, doit impérativement être mise à jour pour compiler GDL (ce qui est désormais disponible nativement en OSX 10.6.x).
- ImageMagick (IM), utilisée pour la lecture et l'écriture des formats d'images (JPG, PNG ...) est de qualité inégale. GraphicsMagick, un fork moins ambitieux, s'est révélé plus stable.