est plus complexe.
V.5 Discussion
V.5.1 Langage principal pour l’architecture de la plate-forme
Une des questions importante est de d´etermin´e quel langage il vaut mieux utiliser
pour impl´ementer l’architecture globale de la plate-forme ALEA. Comme Merrysim a
´
et´e d´evelopp´e tr`es tˆot, avant que le choix de Python ne soit pris pour le projet ALEA, l’architecture principale a ´et´e r´ealis´ee en C++. Int´egrer un interpr´eteur Python `a une application C++ s’est r´ev´el´ee une tˆache difficile et pleine de subtilit´es. Le GIL de Python ne pouvant pas ˆetre test´e, il a fallu faire tr`es attention `a ne pas provoquer de dead-lock? avec les locks de l’application. Par ailleurs, l’interaction avec Qt a ´et´e elle-aussi difficile `a mettre au point du fait de ce mˆeme GIL et de la n´ecessit´e de manipuler les diff´erents verrous et s´emaphores correctement. Enfin, les fonctions d’ex´ecution de code
Python depuis un programme en C sont plus complexe que leurs ´equivalent Python et
n´ecessitent une analyse des instructions envoy´ees.
Tous ces probl`emes de synchronisation, mˆeme s’ils existent, sont bien moins pr´esent dans le cadre d’une application ´ecrite en Python enti`erement. Car alors le GIL n’est plus `
a prendre en charge et il ne reste plus qu’`a garantir des op´erations atomiques sur les
structures de donn´ees du programme. De plus, une application Python pourra facilement
b´en´eficier des modules ´ecrits en Python pour l’analyse de code Python. Ainsi, il devient
plus facile de proposer la compl´etion des termes, la pr´esentation de la signature de la
fonction. . . comme le propose l’application PyAlaMode par exemple.
Aussi, le fait d’utiliser Python pour l’interface graphique et l’architecture principale simplifie grandement le dialogue entre l’interpr´eteur embarqu´e et le thread Qt.
Ainsi, nous recommandons l’usage de Python pour l’architecture principale du
pro-gramme dans le cas de l’int´egration d’un interpr´eteur car la gestion des threads Python
depuis le C ou le C++ est une tˆache fastidieuse et difficile.
V.5.2 Techniques de programmation g´en´erique C++ et
exten-sions Python
´Ecrire du code g´en´erique C++ peut ˆetre fait principalement par deux moyens : le
po-lymorphisme ou les patrons. Nous allons voir les avantages et les inconv´enient de chacune
de ces deux m´ethodes.
G´en´ericit´e par polymorphisme?. La m´ethode la plus ancienne consiste `a utiliser la
d´erivation et une approche purement objet. Les algorithmes sont impl´ement´es sur une
classe de base que l’utilisateur devra d´eriver pour sp´ecifier les parties param´etrables. L’avantage de cette m´ethode est que la r´esolution de la g´en´ericit´e se fait `a l’ex´ecution et objet par objet. Ainsi, une liste impl´ement´ee par cette technique pourra stocker des objets
d´efinie lors de la cr´eation de la classe de liste. Par contre, cette r´esolution `a l’ex´ecution a un coˆut en temps d’ex´ecution et en place m´emoire des objets.
Du point de vue de la construction d’extensions Python, cette solution a un tr`es
gros avantage : la plupart des biblioth`eques proposent des syst`emes pour pouvoir ´etendre
la classe de base depuis Python car c’est une technique de programmation g´en´erique
commune `a C++ et Python.
G´en´ericit´e par patrons. Une technique beaucoup plus r´ecente pour la g´en´ericit´e est l’usage des patrons? de classe ou de fonction. C’est une technique qui a d’abord ´et´e po-pularis´ee par la STL1 puis qui a ´et´e plus r´ecemment utilis´ee intensivement par l’ensemble de biblioth`eques Boost (website Boost).
Le principal avantage de cette m´ethode est que la r´esolution de la g´en´ericit´e se fait `a la compilation. Ainsi il n’y a aucune perte de temps du `a cette g´en´ericit´e lors de l’ex´ecution. Aussi, la g´en´ericit´e propos´ee par cette m´ethode est bien plus pouss´ee et les possibilit´es de g´en´eration de code conditionnels permettent de cr´eer des biblioth`eques `a l’utilisation tr`es simple. Par contre, les temps de compilation et la taille de code g´en´er´e peuvent facilement ˆ
etre tr`es importants du fait des patrons. Par ailleurs, l’´edition des liens est rendue plus difficile et il y a des pr´ecautions particuli`ere `a prendre, notamment sous MS Windows2.
Du point de vue de la construction d’extensions Python, cette approche a un d´efaut
majeur : il n’existe pas d’´equivalent Python `a cette structure et il n’est mˆeme pas
pos-sible d’exporter un patron? en Python. Une solution consiste `a exporter divers instances
du patron. S’il y en a beaucoup, il y a d’abord un probl`eme de nommage en Python du
patron (surtout s’il s’agit de classes car pour les fonctions, Boost.Python peut ´ eventuelle-ment s’occuper de g´erer la surcharge). Ensuite, ´ecrire le code n´ecessaire pour exporter les instances peut devenir fastidieux. Il devient alors utile d’´ecrire un patron de la fonction
d’export Python (ou de classe) permettant d’exporter les patrons instanci´es. Toutefois,
une bonne d´efinition du patron de la fonction d’export qui marche quel que soit l’instance peut ˆetre assez complexe `a r´ealiser. La tˆache a ´et´e entreprise pour les types d´efinis par la STL, mais non seulement il reste des restrictions, mais il a fallu plusieurs semaines pour mettre au point les patrons de classe et de fonction utilis´ees dans ce cas. Enfin, s’il est en plus n´ecessaire de rendre le patron extensible depuis Python, il y a alors deux possibilit´es. La premi`ere consiste `a instancier le patron pour un objet Python, et il est recommand´e
d’utiliser la classe boost::python::object de la biblioth`eque Boost.Python plutˆot que
le PyObject* propos´e par l’API de Python. L’inconv´enient de cette m´ethode est qu’elle
n´ecessite probablement de r´eimpl´ementer le patron pour cet objet. Une autre technique
consiste `a cr´eer un proxy C++ encapsulant l’objet Python. Ainsi, tout le code de conver-sion Python vers C++ et vice-versa est restreint `a cette classe et il est tr`es probablement possible d’utiliser l’impl´ementation g´en´erique du patron de classe ou de fonction.
1Standard Template Library, biblioth`eque standard en C++ qui propose un ensemble de structures de donn´ees et des fonction d’entr´ee/sortie de haut niveau
2voir http://wiki.python.org/moin/boost.python/CrossExtensionModuleDependencies pour discussion
Cas d’utilisation de ces m´ethodes. La d´ecision d’utiliser l’une ou l’autre des m´
e-thodes d´ependra principalement de deux param`etres : le premier concerne le type de
g´en´ericit´e voulue, le second est le langage-cible principal.
Tout d’abord, s’il est n´ecessaire que la g´en´ericit´e soit r´esolue `a l’ex´ecution, alors seul le polymorphisme? permettra de r´esoudre le probl`eme. Par contre, s’il est n´ecessaire de g´en´erer un code conditionnellement `a des arguments, alors seul les patrons? pourront ˆetre utilis´es. Il faut toutefois noter qu’il est possible de m´elanger patron et polymorphisme si la g´en´ericit´e est r´esolue tantˆot `a l’ex´ecution, tantˆot `a la compilation.
Dans les nombreux cas o`u aucune de ces conditions n’est v´erifi´ee, il est possible d’uti-liser les patrons avec parcimonie, par exemple en ´evitant les objets `a exporter en Python.
De mˆeme, r´eduire le nombre de param`etre des patrons permettra de r´eduire le nombre
d’instances `a exporter en Python.
Sinon, il est utile de consid´erer la cible principale de tel ou tel algorithme ou objet. Ainsi, un algorithme ´ecrit pour ˆetre compatible avec la Boost Graph Library sera n´ eces-sairement ´ecrit en template. Par contre, il sera peut-ˆetre suffisant de l’exporter pour la classe de graphe impl´ement´ee dans Merrysim (ou une autre) pour pouvoir l’utiliser depuis Python. Inversement, si un algorithme est destin´e a ˆetre quasi-exclusivement utilis´e de-puis Python, il est pertinent d’´eviter les templates et de pr´ef´erer le polymorphisme?. Dans ce dernier cas, le surcoˆut li´e `a l’utilisation de Python rend de toute fa¸con n´egligeable la perte due au polymorphisme. Dans le cas d’un usage ´equilibr´e des deux cˆot´es, il devient
pertinent d’utiliser les patrons? mais de n’exporter qu’une instance utilisant une classe
pr´evue pour ˆetre d´eriv´ee en Python.
V.5.3 Une interface multi-public
Une des probl´ematique r´ecurrente dans les recherches `a l’interface de plusieurs do-maines est d’arriver `a ce que tous les chercheurs profitent des outils d´evelopp´es. Ainsi, notre probl`eme est de mettre `a disposition de tout le monde, informaticiens et biologistes, les outils que nous avons d´evelopp´es. Ainsi, nous avons choisi de pr´esenter une inter-face double : graphique et langagi`ere. L’interface graphique permet d’utiliser l’application plus rapidement, l’apprentissage ´etant plus facile, mais les possibilit´es d’actions sont plus restreintes que pour l’interface langagi`ere. L’interface langagi`ere est elle plus complexe `a maˆıtriser, mais elle permet d’agir beaucoup plus librement que l’interface graphique. Aussi,
pour permettre `a un maximum de personnes d’utiliser l’interface dans toute sa souplesse,
le langage choisi pour l’interface l’a ´et´e pour sa facilit´e d’apprentissage, au moins pour les structures de contrˆole simples.
Par rapport aux applications r´ealis´ees, Merryproj et Merrysim sont aujourd’hui utilis´es de mani`ere autonome par les biologistes du laboratoire de biologie cellulaire de Versailles.
L’utilisation de Merrysim peut aller de la saisie jusqu’`a la simulation. Pour le moment,
seules les m´ethodes d’analyses ne sont pas accessible sans formation relativement pouss´ee `