La particularité de ce binding est qu'il a été généré automatiquement en introspectant le code C. C'est une étape importante dans le travail d'introspection de Glib, et qui devrait permettre de donner à de nombreux langages l'accès complet aux API GNOME.
NdM : Un binding permet de programmer dans un langage en se servant d'une bibliothèque écrite dans un autre langage. Les bibliothèques GNOME (GTK, gconf, libxml2, dbus, Cairo et Gstreamer pour les plus fondamentales) ont le grand avantage de couvrir à peu près tous les besoins d'une application et de le faire de façon cohérente. Elles sont aussi, comme la majorité du code dans une distribution, écrites en C, ce qui n'est pas un mal (bonne performance, code accessible à un maximum de monde). Mais le C, tout le monde n'aime pas, et c'est un langage relativement verbeux (le classement du shootout donne une première approximation).
Heureusement le C est également très portable ; en écrivant des bindings, on peut l'utiliser depuis à peu près n'importe quel langage. GTK+ en a par exemple une trentaine.
D'où un doux rêve : celui de faire pour toutes les bibliothèques qui utilisent la Glib ce qui a été fait pour GTK+. Vous programmez avec le langage que vous trouvez le plus sexy, et vous avez accès à la pile GNOME.
Entre en scène l'introspection GObject.
L'idée de l'introspection est d'extraire automatiquement l'information sur les types (enums, listes, structs...) et les objets (modèle OO genre Java) du programme, et de générer les bindings avec. Cette information est intégrée depuis longtemps dans GType, comme vous pouvez le vérifier depuis certaines démos de GTK (comme gtk+/tests/testfilechooser) qui permettent de manipuler directement les propriétés d'un objet. En vérifiant que cette information couvre bien l'intégralité d'une API, on peut générer de la glue dans un autre langage.
Le premier binding libpoppler->Python démontre la faisabilité du concept, même si il reste expérimental.
Au moment où l'on débat de savoir s'il faut élire une unique machine virtuelle pour tout écrire, l'introspection GObject propose une approche pluraliste qui bénéficie à tous et attire des développeurs de tous horizons.
Aller plus loin
- L'annonce du binding sur le blog de Johan Dahlin (0 clic)
- shootout: concision de différents langages (1 clic)
- Bindings gtk (1 clic)
- Le blog de Jonathan Blandford (0 clic)
# du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 8.
Sans vouloir encore et toujours la ramener à Mono, mais ils génèrent leurs bindings pour GTK+, Gnome et autre GStreamer en utilisant depuis le début un outil qui répond aux même objectifs : créer automatiquement les bindings.
L'utilitaire en question, c'est GAPI : http://www.mono-project.com/GAPI(...)
L'approche est différente puisque ce sont les en-tête .h qui sont parsés et non un système d'introspection. Le résultat est le même (bien qu'on puisse récupérer un peu plus d'info dans le .h, comme le nom des arguments) et n'est plus du tout expérimental dans Mono.
De plus l'utilitaire génère une description au format XML des API, un 2ème utilitaire permet de "patcher" au besoin (parcque ce n'est jamais parfait, ou pour modifier le design pour qu'il colle un peu plus au langage cible) et enfin un autre utilitaire qui génère le binding à partir du document XML. Vous l'aurez compris il est tout à fait possible de réutiliser ces outils pour générer des bindings dans un autre langage.
(Ah oui au fait : avec IronPython on a déjà accès à tous les bindings Gnome automatiquement ;) )
[^] # Re: du déjà vu
Posté par Pinaraf . Évalué à 1.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: du déjà vu
Posté par Pinaraf . Évalué à 6.
cannot open assembly /usr/lib/gtk-sharp-2.0/gapi-parser.exe
Malgré mon installation foireuse, tu peux voir que pour générer les bindings via GAPI il faut mono.
gapi2-parser - The parser is a C source and header parser that produces an XML document describing the API. (d'après le lien que t'as donné dans ton premier commentaire)
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # Re: du déjà vu
Posté par Prosper . Évalué à -1.
Qui etrangement , travaillent tous ou presque chez redhat , qui lui favorise gcj . De toutes facons quand on voit comment gcj se traine fasse a Mono dans les benchs , on peut se dire que Novell a fait le bon choix.
[^] # Re: du déjà vu
Posté par Pinaraf . Évalué à 2.
Je suppose que tu voulais dire gij et pas gcj hein ? (gij c'est l'équivalent de la commande mono il me semble, alors que gcj serait plutôt un gcc puis exécution du résultat)
Mais bon, les benchmarks restent des trucs non fiables...
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 3.
gij c'est l'équivalent de la commande mono il me semble
non pas du tout.
gij c l'équivalent de mint dans le projet mono.
[^] # Re: du déjà vu
Posté par Cook Captain . Évalué à 3.
Voici un bench un peu plus sérieux que le shootup...
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 4.
C'est pas parcque c'est plus "sérieux" en apparence que ca a plus de valeur : ca reste un bench et ca a les mêmes limitations que les autres : à savoir que ce ne sont généralement pas des cas concrêts et quand les résultats obtenus sont du même ordre d'idée, il est bien difficile de faire une conclusion utile.
[^] # pas de gcj4 dans ces benchs
Posté par free2.org . Évalué à 4.
[^] # Re: du déjà vu
Posté par k. stephane . Évalué à 10.
Ce qui signifie que l'on n'a pas besoin des sources de la librairie à analyser, on n'utilise que des appels GObject.
Glade fonctionne d'ailleurs comme ça. Il fouille les objets de Gtk+ pour en extraire les propriétés et les signaux et ensuite permettre leur modification via sa GUI. C'est bien plus que simplement trouver les méthodes et les champs publics. GObject, c'est JavaBeans aux stéroïdes.
De plus GObject permet aux bindings d'étendre les types GObject et aussi de passer des fonctions dans leur langage aux signaux. Ça va très loin. La création de bindings automatique n'est q'une utilisation de cette introspection, Glade en est une autre et qui sait, un IDE pour GObject...?
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 0.
Chacun ses dépendances mais ca change rien aux objectifs et aux résultats obtenus : avec GAPI t'obtient les méthodes, les signaux, l'arbre d'héritage, etc.
Bref comme je l'ai dis seule l'approche est différente, mais il y en a un qui est éprouvé.
[^] # Re: du déjà vu
Posté par Tobu . Évalué à 7.
L'intérêt de l'introspection est que ç'est quelque chose de complètement automatique qui se fonde sur le code compilé qui lui est 100% sûr et sans ambiguité. Le module http://cvs.gnome.org/viewcvs/gobject-introspection/(...) dans le CVS de gnome qui a été utilisé pour poppler génère un XML directement à partir des binaires, des applications comme glade et la démo gtk+/tests/testfilechooser obtiennent ces infos en linkant contre gtk.
Ça paraissait une chose évidente à faire depuis le concept de GType qu'a la glib, mais il a fallu réviser les API pour que GObject ou GType soit utilisé partout (travail de Mathias Clasen - http://bugzilla.gnome.org/show_bug.cgi?id=139486(...) ), et écrire le compilateur binaires->xml (gobject-introspection dans le CVS).
Une possibilité encore à explorer (et absolument pas déjà vue, dites-moi si je me trompe ;) ) est d'utiliser la version runtime de l'introspection pour générer les bindings au vol: des langages comme python supportent bien l'ajout de méthodes aux objets pendant l'exécution, ce qui permet d'utiliser libmachin sans même avoir à installer une libmachin-python.
[^] # Re: du déjà vu
Posté par Vivi (site web personnel) . Évalué à 6.
non, il y a plus d'informations dans les données d'introspection (metadata). C'est justement parce que le parsing des .h n'est pas toujours suffisant que cette approche est utilisée.
On trouve ainsi : le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la gestion mémoire pour les fonctions renvoyant un pointeur, des liens entre un argument de type tableau (un pointeur) et un autre argument entier contenant la longueur du tableau, etc. Il y a aussi les "properties" des gobjects et ginterfaces dans les metadata, on ne trouve pas ça dans les .h.
Enfin ces données sont dans un fichier binaire compact et il y a une lib pour y accéder, ce qui permet aux langages dit "dynamiques" de générer les bindings à la volée (au runtime).
Donc bref c'est pas tout à fait pareil. De plus Mono n'a non plus rien inventé, ça fait trés longtemps que plusieurs bindings utilisait des fichiers de description de l'API (les .def avec une syntaxe en sexp).
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
ce qui permet aux langages dit "dynamiques" de générer les bindings à la volée
C'est un peut douteux dans la méthode tout de même :) Je vois mal comment déployer ce genre d'application qui vont découvrir à la volée un nouvel API :)
De plus Mono n'a non plus rien inventé
Houlà non je parle juste de ce que je connais. MS fait ca depuis très longtemps avec ses composants COM ou ActiveX.
[^] # Re: du déjà vu
Posté par Vivi (site web personnel) . Évalué à 6.
ben ... relis mon post, je donne 3 ou 4 exemples d'informations qui ne sont pas dans le .h.
C'est un peu douteux dans la méthode tout de même :)
non pas du tout, il s'agit simplement d'étendre le mécanisme de binding retardé des langages dynamique aux bibliothèques C. En python quand tu exécute un mon_objet.une_methode(un_parametre) la méthode est recherchée au dernier moment dans le dico de l'objet ; ici il s'agit de remplacer automatiquement la recherche dans le dico python par une recherche dans les données d'introspection de GTK+ suivi d'une conversion des paramètres, appel de la fonction C et conversion (dans l'autre sens) du résultat. Ça va "découvrir" l'API à la volée comme pour n'importe quel module python.
Les bindings pyorbit du bazar CORBA fonctionnent déjà comme ça d'ailleurs.
C'est le même principe sauf que la conversion de donnée utilisera les structures glib et les conventions d'appel de fonction C au lieu des équivalents CORBA.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
J'ai bien compris, je voulais l'utilité de ces informations dans un binding.
Ça va "découvrir" l'API à la volée comme pour n'importe quel module python.
Et si la méthode n'est pas là ? Non je trouve ca franchement douteux :) hors de question de déployer un truc comme ca !
Je vois franchement pas ce que cela apporte de faire la "découverte" au dernier moment de ce genre d'info...
[^] # Re: du déjà vu
Posté par Vivi (site web personnel) . Évalué à 2.
ben ça sert à générer du code correct pour le binding.
Et si la méthode n'est pas là ?
comme tous les langages dynamiques: ça se vautre comme une grosse bouse en disant « méthode truc_chose_bidule n'existe pas »
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 3.
Visiblement Mono n'a pas besoin de ces informations, pas plus que le développeur qui n'a que les .h n'en a besoin... je veux bien croire qu'il y est un intérêt mais justement je te demande concrêtement ce qui fait que telle info est super vitale pour faire un binding et qui n'est pas présent dans un .h
comme tous les langages dynamiques
D'où le fait que je trouve cela "douteux". On a beau dire mais autant faire en statiques les vérifications qui peuvent l'être, et laisser s'exprimer la puissance dynamique du langage là où c'est vraiment utile (typiquement on manipule des informations dynamique). J'ai jamais compris cette obstination à vouloir faire en dynamique quelque chose qui peut l'être en statique : ca n'apporte strictement rien, à part une perte de vitesse et de robustesse. C'est pour ca que je trouve que c'est plus une "curiosité" qu'un réel intérêt d'avoir ce binding dynamique.
[^] # Re: du déjà vu
Posté par Vivi (site web personnel) . Évalué à 2.
il y a trés probablement des infos qui sont rentrées "à la main". C'est comme ça que ça marche pour les bindings utilisant les .def .
pour ce qui est des exemples concrets :
le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la gestion mémoire pour les fonctions renvoyant un pointeur, des liens entre un argument de type tableau (un pointeur) et un autre argument entier contenant la longueur du tableau, etc.
D'où le fait que je trouve cela "douteux".
Tu gagne en flexibilité (pas la peine de recompiler les bindings pour chaque nouvelle version de GTK+) et tu ne perds pas beaucoup en robustesse (vu que le langage est dynamique à la base).
Note aussi que ça devrait permettre de diminuer la taille du code des bindings. Avec une grosse API comme GTK+, ça devient problématique.
En fait c'est à peu près les mêmes compromis que pour le choix entre bibliothèque statique (.a) et bibliothèque partagée (.so) en C.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
Il y en a certaines oui, mais généralement pour rendre certaines parties plus "friendly" au programmeur, c'est pas du tout une opération indispensable. J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.
le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la [...]
Euh là tu ne fais que reformuler ce que t'as déjà dis :)
Je te demande de me montrer un exemple concrêt de méthode ou de je ne sais quoi qui est dans un .h, qui est destiné à être bindé, et qui ne peut l'être sans ces infos accessibles uniquement par introspection. Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème, il n'y a aucune raison qu'un autre langage ne puisse pas le faire à partir de ces seuls en-tête. J'avoue que je suis très sceptique sur la réelle utilité de cette nouvelle approche.
Tu gagne en flexibilité (pas la peine de recompiler les bindings pour chaque nouvelle version de GTK+) et tu ne perds pas beaucoup en robustesse
Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :) Par contre ce qu'on pert en robustesse... Evidemment tu me dis que le langage ne l'ai pas à la base et que donc on peut se permettre toutes les fantaisies. Là en l'occurence c'est pour "éviter" de relancer le script de génération des bindings. Hem.
[^] # Re: du déjà vu
Posté par Frédéric RISS . Évalué à 2.
Ta phrase est juste, tu parles bien de compiler. Par contre pour programmer, le profile d'une fonction ne suffit pas, il faut la description du comportement (par exemple de quel type sont les éléments d'une liste, exemple que tu sembles vouloir ignorer). La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais comment fait le programmeur C qui utilises ces fameuses listes ? Je te demande un exemple concrêt de méthode ou classe où les en-têtes ne suffisent pas, avec ces fameuses listes si tu veux.
La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.
Donc le programmeur C n'a pas le choix : il fait de l'introspection en natif avec son cerveau c'est ca ?
[^] # Re: du déjà vu
Posté par Alex G. . Évalué à 1.
exactement, il fait le cast qu'il faut car il sait que c'est comme ça (dû à la doc, à la logique du machin, comme son nom...). C'est hyper courant en c, en java etc... de faire ça. Sans t'offenser, si tu ne comprends pas tu dois pas programmer beaucoup en c !
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: du déjà vu
Posté par Vivi (site web personnel) . Évalué à 6.
On verra. Le coup du binding généré automatiquement c'est un peu le cas extrême, moi non plus je suis moyen convaincu. Par exemple en ocaml, on continuera à écrire des trucs à la main, c'est sûr.
Mais ça va quand même beaucoup accélérer la création des bindings.
Euh là tu ne fais que reformuler ce que t'as déjà dis :)
c'est toujours vrai :)
un exemple :
GList *gtk_truc_bidule_chose (machin *arg1, guint arg2);
est-ce que :
- arg1 peut être NULL ?
- arg1 est une simple struct passée par pointeur ?
- arg1 est un tableau de longueur arg2 ?
- arg1 est un tableau terminé par un NULL (et arg2 n'a rien à voir) ?
et :
- qu'est-ce qu'il y a dans la GList ? (des char*, des objets ?)
- comment gère-t-on la mémoire de la GList ? (il y a 3 possibilités: rien à libérer, libérer la GList, libérer la GList + tous les éléments).
Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème
justement, le programmeur C ne peut pas se baser uniquement sur les prototypes pour écrire du code correct, il a besoin de la doc. Le C n'est pas sûr mais tous les autres langages le sont. L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage (comme si la lib était écrite nativement dans le langage).
Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :)
plus besoin de compilateur C, de l'environnement de compilation de GTK+ (les .h), ni de celui du langage ...
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 2.
Justement, là on doit se baser uniquement sur les .h. Ce que tu sembles indiquer c'est qu'il y a une sémantique supplémentaire ajoutée par les dev des libs Gnome et qui ne peut être récupéré que dynamiquement. Je comprends mieux.
Cela dis je me demande si il n'y a pas des "conventions" d'utilisation qui font que ce sont les même règles qui s'appliquent partout, auquel cas il est facile d'indiquer au parser d'en-tête quelles infos supplémentaires il faut déduire dans quels cas. J'aimerai un exemple concrêt autre que gtk_truc_bidule_chose, histoire de voir comment sont gérer ces cas par les parser d'en-tête justement.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: du déjà vu
Posté par François-Xavier Houard . Évalué à 1.
#define ArrayOf(Type, X, Y) Type X, int Y
void fun(ArrayOf(wxFrame,arg2));
ça permet de conserver les mêmes en-têtes pour compiler et pour parser (afin dé générer le binding)
Nottez que le plus difficile a sans aucun doute été la gestion mémoire. Si un tel mécanisme devait être conserver pour GTK, un effort tout particulier devrait être consacré à préciser la manière de récupérer les "objets". C'est particulièrement vrai avec les languages disposant d'un garbage collector.
Moralité: ça peut le faire, mais faut penser, en même temps qu'on écrit des libs, à écrire un en-tête amélioré.
# Tites fautes
Posté par Sixel . Évalué à 1.
"Toute_s_ les APIs"
Dans l'article :
(debut) "... tou_s_ les besoins d'une application..."
(tout à la fin) "... des développeurs de tou_s_ horizon_s_."
Mes 0.02 euros
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Tites fautes
Posté par Damien (site web personnel) . Évalué à 10.
# Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 10.
Finalement, gnome ne fait que suivre la voie de KDE:
http://dot.kde.org/1032279318/#1032280045(...)
A noter que la news KDE est datee de 2002. Et oui, 3 ans deja que KDE genere une partie de ses bindings de la meme facon.
Et vous savez pourquoi c'est beaucoup plus facile avec KDE ? Le langage ! En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin. Les pointeurs ou les template ont un type precis (pas comme les void * qui sont utilises par exemple dans les listes gnome), la syntaxe est plutot simple (vous avez deja vu le nombre de declarations necessaire a faire l'equivalent d'un class Toto: public QObject en gnome ?).
Bon, on va encore s'offusquer de ma prise de position extreme pro-KDE mais depuis que j'ai decouvert le logiciel libre, je suis persuade que Gnome a fait une grosse erreur en choisissant un toolkit en C et que KDE a fait un bon choix en choisissant du C++.
Ceci n'est qu'un exemple de plus.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Anonyme . Évalué à 1.
quant aux trains de retard, je prefere être patient et avoir quelque chose qui me convient ^^
[^] # Re: Gnome, toujours trois trains de retard
Posté par gnumdk (site web personnel) . Évalué à 3.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 9.
Mais quand je dois faire des objets avec de l'heritage et des methodes virtuelles, ben je choisis un langage objet. C'est etonnant hein ? De meme que si je devais faire de la programmation fonctionnelle, je me tournerai plutot vers un langage fonctionnel.
En toute honnetete, je ne comprends pas comment tu peux a la fois aimer le C et aimer programmer en C avec Gnome. La programmation sous Gnome n'a pour moi rien a voir avec la programmation en C (que j'aime beaucoup, je le reappelle). Quand tu fais des classes, des objets, des methodes virtuelles et de l'heritage et que tu dis que tu programmes en C, tu te mens a toi-meme.
Le C sous Gnome, c'est un mensonge. Tu fais du C++ mais en fait c'est pas du C++. T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 2.
Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage, alors qu'appeler un API C++ n'est pas donné à tous les langages de haut niveau. Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 2.
Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.
Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.
Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).
Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.
Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.
En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
- on programme avec KDE dans un langage moderne
- on a une generation de binding automatisee
> Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.
Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :
[^] # Re: Gnome, toujours trois trains de retard
Posté par Anonyme . Évalué à 4.
L'interet de gnome est de pouvoir programmer sous environnement graphique dans le language qu'il te plait, y compris pour les vieux fan du C, qui ont le droit d'utiliser leur langage preféré ailleur que dans un shell ^^ mais aussi d'offrir un ensemble d'API de developpement pour tout les langages (car il n'y a pas que des fans du C ^^)
je pourrais critiquer le choix du c++ par kde comme un vieil unixien integriste du C POSIX (que je ne suis pas... si bon un peu ?) mais je prefère me dire que c'est bien qu'il y en ait pour tous les gouts ^^.
[^] # Re: Gnome, toujours trois trains de retard
Posté par zeSixty4Douille . Évalué à 1.
l'avantage du c pour le binding, c'est la simplicite du "language linker", cela permet aussi d'avoir un meilleur controle a l'edition de liens.
Le choix du cpp n'empeche pas Qt et KDE de faire des bindings tres rapidement, donc cela ne justifie pas le choix de gnome. L'autre paradoxe qui me fait aimer KDE par rapport a gnome, c'est la 'quasi' compatibilite binaire entre les versions 3.1, 3.2, 3.3, 3.4, malgres les options de compilation qu'utilisent les distros et le partage des composantes entre les appli.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Anonyme . Évalué à 1.
Je précise quand même que dans mon cas, je vois le C comme de l'assembleur de haut niveau portable ^^ simple à debugger et à optimiser (et limite simple a compiler de tête)
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 0.
De plus créer un binding sur KDE est très (trop) limité : le langage C++ utilisé n'est pas forcement facile à utiliser dans tous les langages de haut niveau, et très peu de langage de haut niveau implémente toutes les fonctionnalités de C++ : il en ressort des difficultés à créer le binding, voir parfois une impossibilité dans certains langage. D'où le choix pour Gnome de C qui a l'avantage d'être un dénominateur commun à tous les langages : ils sont tous capables d'utiliser le C (ou presque). Je parle même pas d'un hybride C++ qui nécessite un précompilo si tu vois ce que je veux dire.
En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
Ben en C aussi dis donc.
Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place dans les libs compatible "Gnome" (à la glib quoi) permettent l'introspection, ce que ne permettent absoluement pas les libs KDE.
Voilà pour ce qui était de la réplique pro-Gnome ;)
[^] # Re: Gnome, toujours trois trains de retard
Posté par Pinaraf . Évalué à 5.
Là tu te plantes !
En effet, le (décrié) moc de Qt c'est Meta Object Compiler. Et il permet de connaître les signaux, slots, propriétés.. d'un objet très facilement. Par exemple Qt-Designer fonctionne ainsi.
Cf http://doc.trolltech.com/3.3/qmetaobject.html(...)
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 1.
Enfin ca confirme ce que je pensais : bien que proposant également l'introspection, visiblement les "bindeurs" KDE n'en ont pas eu besoin pour faire de la génération automatique, les .h leurs suffisent. Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Raphael Junqueira . Évalué à 3.
> génération automatique, les .h leurs suffisent.
Ca n'est pas totalement vrai.
Cela est vrai pour les bindings des langages "statiques" (ex: C) par contre pour les langages "dynamiques" (du genre python, ruby, etc...) le binding exploite a fond les capacites de moc
> Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.
Il est plus facile de partir de bcp d'informations (ie. typage assew fort dans les headers c++) et de "degrader" que le contraire (probleme du fameux "void*" du c)
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 2.
Parce que comme l'objet ne fait pas partie de la syntaxe C, il est emule a coup de macros et de struct, qui sont beaucoup plus difficile a parser.
Qui plus est, un certain nombre d'information sont tout simplement perdue dans la syntaxe C. Je pense aux signaux Gtk qui acceptent un argument de type void *
cf
http://www.gtk.org/tutorial/sec-theoryofsignalsandcallbacks.html(...)
Tu noteras la presence de gpointer callback_data qui est impossible a interpreter pour un outil de binding automatique.
Au contraire, les signaux et slots Qt sont types et peuvent donc etre pris en compte dans une generation automatique.
De meme, les listes Gtk ne sont pas typees. Elles prennent aussi un gpointer pour la partie data donc tu ne sais pas de quoi est faite la liste. En C++, les listes sont faites avec des templates ou le type est explicitement visible.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Raphael Junqueira . Évalué à 3.
> parcque justement il était facile à "binder". . KDE n'a pas
> forcement la primeur en la manière.
Cela existe en effet depuis des annees. Mais si tu lit bien le commentaire auquel tu repons il ne parle que de "la primeur de KDE" par rapport a gnome. De plus l'interet du binding KDE est la facon dont tout est automatise et genere de telle maniere a que ce soit le plus integre dans la philosophie du langage cible (et c'est le meme script te genere le binding pour tous les langages)
> De plus créer un binding sur KDE est très (trop) limité : D'où le
> choix pour Gnome de C qui a l'avantage d'être un dénominateur
> commun à tous les langages : ils sont tous capables d'utiliser le C (ou
> presque). Je parle même pas d'un hybride C++ qui nécessite un
> précompilo si tu vois ce que je veux dire.
Je ne voit pas comment tu peux dire ca. Tu devrais jeter un oeil au bindings KDE avant de parler. Mis a part le binding c (ex: qtc) qui est un peu horrible a regarder (car tu dois comme gnome faire de l'object sans object) les autres sont complets.
Le langage C++ au lieu de poser des problemes, comme tu pense le penser, permet (par son defaut d'etre assez verbeux au niveau des headers) de belles choses.
> En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
> Ben en C aussi dis donc.
tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
> Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place
> dans les libs compatible "Gnome" (à la glib quoi) permettent
> l'introspection, ce que ne permettent absoluement pas les libs KDE.
Mais bien sur. Et la marmotte ...
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 2.
Il pose pas des problèmes pour récupérer les infos, le langage C++ étant par nature objet il est sans doute plus facile de récupérer certaines infos, mais je parle de la réalisation du binding en soit : en gros faut faire un wrapper C++ intermédiaire qui soit plus friendly car très peu de langage comprennent "nativement" le C++, contrairement au C avec lequel la plupart des langages sont capable d'intéragir. Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité, et il faut refaire cette couche pour tous les langages... C'est en ce sens que le binding d'API C++ est "lourd" à mon sens.
tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
Ce que je voulais dire c'est que pour faire le binding "tel quel", les .h suffisent, aussi bien en c++ qu'en C. Après je viens enfin de comprendre l'intérêt de l'introspection dans certaines situation, notamment pour améliorer considérablement la sémantique du binding et rendre le tout plus friendly au langage de haut niveau. J'aurai tout de même aimé retrouver cette info dans la news, car c'est vraiment là que réside l'intérêt de l'approche à mon sens.
Mais bien sur. Et la marmotte ...
Oué je me suis planté je sais.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 3.
De fait, il y a une couche intermediaire en C qui est generee (il me semble).
> Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité,
Comment tu peux parler d'efficacite d'une couche intermediaire alors que utilise un langage ou tout le framework objet est genere par macro et ne peux donc pas etre optimise par le compilateur. En C++, tu donnes beaucoup d'info sur tes structures au compilateur, qui peut donc les optimiser en consequence. Avec un wrapper objet en C comme on a en Gtk/Gobject, le compilateur ne peut pas faire ce type d'optimisation parce qu'il ne sait pas ce que c'est qu'un objet.
> il faut refaire cette couche pour tous les langages
Ben non, c'est la meme partout. C'est elle justement qui fournit le coeur de binding. Elle fournit tous les services dont le binding va avoir besoin (introspection, typage dynamique pour certains langages, ...) en C.
> les .h suffisent, aussi bien en c++ qu'en C.
Justement, non. Une partie des informations sur un objet en Gtk est contenu dans les structures qui sont definies dans le .c, pas dans le .h
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 1.
Justement, non.
Ah si. Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h. J'ai moi même tenter quelques bindings à la mano directement et y'a tout ce qu'il faut. Après c'est une question de style et d'intégration, on a envie qu'un tableau s'appelle un tableau (et non un pointeur + une taille), on peut avoir envie de typer leur contenu, etc, mais ce n'est pas indispensable au fonctionnement d'un binding (même si indispensable à faire un bon binding).
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 5.
>>
Tu peux essayer de tourner la phrase pour que ce que je dise paraisse debile mais je maintiens.
Tu as plusieurs niveaux:
- Gtk (avant gobject), avec un framework objet emule en C, et eventuellement un binding genere a la main. Le compilateur ne peut pas optimiser correctement les parties objet du code car il ne connait pas l'objet. Les bindings attaquent directement les .h de gtk (bien que ce point soit a verifier, je ne serait pas surpris qu'il y aie des couches intermediaires, par exemple pour gerer le comptage de reference et autres joyeusetes des langages de script).
- KDE, avec un framework en C++, que le compilateur peut optimiser correctement. Ce framework genere ensuite une _interface_ en C, qui utilise en interne du C++ (qui est donc optimisee correctement par le compilateur), mais qui ajoute au moins un appel de fonction par methode. Pour info, le cout d'un appel de fonction de nos jours et negligeable, plus particulierement dans un gui ou c'est l'utilisateur qui declenche les evenements.
- Gnome + Gobject : le framework objet s'est complexifie, mais est toujours en C (donc toujours aussi difficile a optimiser) mais en plus, on genere une couche intermediaire qui sert a interfacer le binding. Bref, on cumule deux inconvenients en terme de performance, mais on gagne en qualite des bindings et en quantite de travail.
Il serait interessant de valider ce que j'affirme avec des benchs. Je serai infiniment surpris si l'appel d'une methode virtuelle en gobject etait plus rapide qu'en C++. J'essaye d'imaginer le nombre d'etape intermediaire par lequel le code C passe pour simuler une methode virtuelle.
> Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h
Ok, je prends deux fonctions au hasard:
cf http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Fun(...)
- g_strstr() renvoie un gchar * deja alloue a ne pas liberer.
- g_strdup_printf() renvoie un char * qui doit etre libere.
Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions. Tu es oblige d'inclure une phase manuelle basee sur la documentation que tu auras lu.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 1.
mais bon franchement on s'en balance des différences de perfs entre C++ et C objet, même si elles existent, le principal problème viendra de toute façon du binding dans le langage de haut niveau, ce binding constituera la plus lente des couches intermédiaires, avec tous les problèmes de perf lié au marshaling.
Tout ce que je constate c'est qu'au final le C est nécessaire, et KDE devrait proposer des API sous cette forme, même s'ils veulent par derrière utiliser un API C++. Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions.
Le binding s'en fou, il expose les api tel quel, au programmeur d'appeler le gfree dans son langage de haut niveau si besoin est. Bref, pour faire un binding de base "idiot" les .h suffisent et c'est tout à fait automatique et fonctionnel. Par contre si on veut cacher certains aspects techniques (gestion mémoire) pour simplifier la vie du programmeur ou faciliter l'intégration dans un langage de haut niveau, là oui il faut plus d'info. Mais ca c'est ce que j'ai déjà dis.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Vivi (site web personnel) . Évalué à 2.
N'importe quoi. Personne ne fait ça. Ça n'a pratiquement aucun d'intérêt un tel binding qui te fait perdre les garanties de sûreté du langage. C'est déjà quasi-impossible de faire en sorte que le programmeur C gère correctement sa mémoire, alors un programmeur habitué à un autre langage ...
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 4.
On parle de faire un binding, et toi tu nous dis que pour faire un truc completement merdique, c'est facile. C'est super interessant comme info.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 2.
Le but du binding, c'est de proposer le confort du langage cible, avec les fonctionnalites du projet original. Ca demande beaucoup de travail affinage pour que toutes les problematiques de binding, de gestion de memoire et autres restent transparentes.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 3.
> quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.
Ben non. La derivation a deja ete faite en C++ (donc deja optimisee). Ensuite, la classe est visible dans ton langage cible. Si ce langage supporte la derivation, la derivation sera faite dans ce langage cible. La couche c ne sert vraiment qu'a transferer des appels.
Cela dit, tu as probablement raison que le plus lent, dans tout ca, c'est le langage cible. Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.
> le C est nécessaire, et KDE devrait proposer des API sous cette forme,
Ben non, on est pas maso. Si tu veux faire des applis C graphiques, va voir Gnome, tu seras plus heureux. Les devs de KDE ont des criteres de qualite pour la facilite de developpement que le C ne remplit pas, et encore moins du C wrappant du C++. Ca a ete fait a une epoque et c'etait immonde.
Je pense qu'il est possible de voir l'avantage de programmer dans un langage objet lorsque tu manipules des concepts objets a tour de bras. Quitte a faire un binding aussi debile, je preferai le faire pour le brainfuck (http://www.muppetlabs.com/~breadbox/bf/).(...) Au moins, je sais pourquoi je le fais.
> Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
Pourquoi est-ce que j'ai l'impression de me repeter 23 fois ? Ton argument est completement ecule. D'une part, il semble avoir ete exprime ici clairement que le C est loin de faciliter la vie des binder non plus pour d'autres raisons. D'autres part, KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE.
Donc KDE facilite la vie des binders sur deux plans, et ce depuis 2002:
- la generation des api KDE dans un langage intermediaire est automatisee et maintenue a chaque version de KDE : pas besoin aux binders de maintenir cette partie la
- ils doivent uniquement s'occuper de la semantique du langage qu'ils binde, sachant que smoke prevoit deja toutes les caracteristiques des langages de scripts actuels : introspection et typage dynamique notamment.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 2.
Vois pas le rapport : tu auras toujours le problème du marshaling, en mode compilé aussi.
Oué bon laisse tomber. Je te dis qu'il faudrait proposer une couche externe en C pour faciliter la vie des binders, toi tu me réponds : "on est pas maso" ou "c'est immonde", et 10 lignes plus bas tu me dis "KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE." avant d'avoir bien sûr précisé " le C est loin de faciliter la vie des binder non plus pour d'autres raisons." Pourtant si KDE génère ca automatiquement c bien justement pour faciliter la vie des binders qui préfèrent appeler du code C !
Enfin heuresement j'ai eu les réponses à toutes mes questions à travers ces différentes contradictions ;)
Reste qu'il y a toujours un problème à régler : il faut toujours maintenir pleins de bindings, pour chaque langage cible.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . Évalué à 2.
Sinon, de fait, KDE propose une couche en C automatiquement generee, qui ne demande pas de maintenance. Le developpeur du binding n'a plus qu'a integrer cette couche dans un moteur et hop, ca marche (ca doit etre un poil plus complique quand meme) donc il n'a lui aussi pas de maintenance (theoriquement) a effectuer.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . Évalué à 2.
Enfin dans tous les cas il y a toujours le problème de maintenir les bindings dans tous les langages, quelque soit la méthode il n'y en a aucune de parfaite (enfin jusqu'à présent).
[^] # Re: Gnome, toujours trois trains de retard
Posté par ckyl . Évalué à 9.
Evidement puisqu'en C++ tu as 99% du code dans les .h....
# Déjà vu, episode 2
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
On peut programmer ses objets/composants dans le langage que l'on veut, du moment qu'il y a le binding adéquate dans XPconnect (la couche applicative qui permet l'interconnection entre tous les composants XPCOM). Chaque composant peuvent implementer une ou plusieurs interfaces (déclarées en IDL)
Actuellement, on peut développer des composants XPCOM, en C++, Javascript, Python, Ruby, perl.
[^] # Re: Déjà vu, episode 2
Posté par Vivi (site web personnel) . Évalué à 5.
(ça vient du README de la fameuse lib d'introspection)
# Employer Volubile au lieu de verbeux, c'est plus Français et plus exact
Posté par Stéphane Téletchéa (site web personnel) . Évalué à 0.
[^] # Re: Employer Volubile au lieu de verbeux, c'est plus Français et plus ex
Posté par Philip Marlowe . Évalué à 3.
Verbeux : indique l'utilisation de trop de mots pour s'exprimer.
On peut trouver une nuance de plaisir dans la volubilité. La verbosité par contre est une plaie pour l'auditeur ou le lecteur, du moins quand il ne manque pas de goût. Comme exemple, la séquence initiale de Pulp Fiction montre des personnages volubiles. Beaucoup de films italiens jouent sur le fait de montrer un peuple volubile. Des exemples de verbosité ? Les oeuvres de Bernard-Henri Lévy (toutes catégories confondues), les interventions télévisées ou radiophoniques de Francis Lalanne. D'une manière imagée on peut dire que quelque chose est verbeux lorsque les mots cachent les idées ou leur absence.
Donc je trouve au contraire que le choix de verbeux comme adjectif est pertinent.
[^] # Re: Employer Volubile au lieu de verbeux, c'est plus Français et plus ex
Posté par Barnabé . Évalué à 4.
# Contre les bindings automatiques
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
En effet, ils integrent la lib dans le langage avec son esprit, alors que je prefère que l'API soit adaptée au langage.
Des choses comme par exemple ce que renvoit une methode set_* (l'objet ? le parametre ? rien ?), ou meme les convention de nom des methodes, dépendent du langage.
Il est possible bien sur de partiellement automatiser ces conversions mais je ne l'ai vu jusqu'à présent dans aucun système de génération de bindings.
Il est parfaitement imaginable d'automatiquement creer dans le binding ruby la methode foo= quand la methode s'appelle set_foo et prend un seul parametre ou foo? pour is_foo. Par contre, certains choix qui me plaisent dans le binding ruby-gnome2 n'auraient je pense pas été mis dans un generateur. Par exemple avec la libglade, my_glade_object.get_widget('foo') qui peut s'ecrire my_glade_object['foo'].
De plus il semble inutile d'avoir certaines methodes, par exemples celles liées à la gestion mémoire dans un langage ou c'est fait de manière transparente habituellement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.