Je me répond à moi même : dans le cas des tableaux il faut effectivement le préciser à la mano après coup. Si cette info peut être récupérée dynamiquement cela peut être utile puisque cela améliore nettement le binding (sans l'empêcher toutefois)
L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage
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.
Par contre pour programmer, le profile d'une fonction ne suffit pas,
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 ?
Bah z'ont bien utilisé le compilo C# de mono, je vois pas pourquoi ils ne pouvaient pas faire de même avec le compilo VB.NET de Mono, parcque en lisant la FAQ le langage semble rentrer dans les critères "techniques", j'ai même envi de dire plus que le langage C qui n'a quasiment aucun "should have".
Bah c'est pas si bête que ca, c pas bien compliqué en Java d'ajouter une ligne dans un fichier... Et si la classe qui "valide" tiens absolument à trouver cette info pour valider, je ne vois même pas d'autre solution... Elle ne te paraît peut être pas élégante mais elle a l'avantage d'être simple et rapide à mettre en oeuvre.
Houlà oui autant pour moi :) Désolé pour la connerie monstrueuse. J'avais oublié que le (décrié) meta-compilo-qui-fait-chier était puissant :)
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.
Euh je vois pas en quoi ces benchs sont plus sérieux : d'abord ils ne semblent pas contredire les autres bench, et au final ce ne sont que des benchs "mathématiques", un peu comme dans les autres bench quoi.
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.
il y a trés probablement des infos qui sont rentrées "à la main".
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.
oué enfin faut pas exagéré non plus, procédural et objet ne sont pas si fortement dissociés, les 2 sont complémentaires, c'est d'ailleur aussi un des succès de l'objet : sa transition avec le monde procédural est relativement "aisé" lorsqu'on compare à des méthodes beaucoup plus différentes comme la programmation déclarative.
Quelqu'un a-t-il commencé à apprendre la programmation par autre chose que du procédural impératif ?
Ben dans ma FAC ils ont (pas moi j'étais pas là au début) commencé par Scheme, pourtant on dit que l'on reste à nos premiers amours en matière de programmation, ben ils sont tous beaucoup plus productifs et heureux en codant en Java :)
La notion d'objet est facile à appréhender par le programmeur qui peut "mapper" sa vision sur le monde réel. Bref c'est relativement intuitif (même si cela ne conduit pas toujours au meilleur design). Pour l'impératif, celui-ci a l'avantage de donner un seul ordre à la fois, dans un ordre précis qui est celui dans lequel le programmeur écrit : c'est donc très simple à appréhender (même si ce n'est pas forcement intuitif) et à utiliser.
Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème. C'est aussi ce qui fait la puissance de ces langages : il force le développeur à indiquer l'algorithme au compilateur/interprêteur qui peut alors en déduire plus d'information, conduisant parfois (souvent pour OCaml) à des optimisations qu'un compilateur plus traditionnel ne pourrait se permettre.
Mais qu'est ce que cela change que Apple construise son matos ? Le consommateur laisé s'en balance royalement ! Il n'a pas à le savoir ! Pas plus que quand il achète un PC sous Windows que ce n'est pas MS qui l'a fabriqué ! Ces détails sont des problèmes de production, de sous-traitance, etc.
On peut très bien dire que les pièces qui constituent un PC ont été conçu pour fonctionner avec Windows (ce qui est souvent le cas malheuresement), et que donc le tout forme un appareil homogène.
Alors non non non et non, on applique les mêmes règles à Apple ou à personne, on va pas faire d'exception pour eux : on peut très bien installer une distri Linux sur un MAC, ou intaller un OS Mac sur un vieux mac : comme quoi techniquement les 2 sont dissociés, et c'est tout ce qui compte pour définir la vente liée et respecter le consommateur.
Ce que tu sembles oublier c'est que le langage C avait été choisi parcque justement il était facile à "binder". De plus si t'avais pris la peine de te renseigné, il existe depuis le départ des outils permettant de créer des bindings automatiquement à partir des .h. KDE n'a pas forcement la primeur en la manière.
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 ;)
ben ça sert à générer du code correct pour le binding.
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.
personnellement j'attribue au chargement et a la charge fixe de l'interpréteur les très mauvais score de python.
Autant le chargement on pourrait l'enlever, autant l'interprêteur, comme tu l'indiques, est "fixe". Il contribue donc au score de Python de manière "régulière".
comme cela déjà été dit plus haut la vitesse pure n'est pas forcement le principale critére de choix d'un langage sans quoi on coderait encore tous en AS
Tout est une histoire de compromis et de polyvalance. l'ASM et un langage inteprêté comme Python sont un peu les extrêmes. Je te laisses te faire tes propres conclusions.
le client peut être un utilisateur lambda dans le cas d'une application bureautique. Me dis pas que le client il est gland de mettre son système à jour de temps à autre.
Quand au mec en prod, il aura beau faire tous les tests, s'il ne tombe pas direct sur l'appelle de méthode qui lève la fameuse exception, il sera pas plus gland et pourtant peut être qu'au bout de quelques jour ca va lui péter à la tronche...
Franchement question robustesse/sécurité on a vu mieux que de laisser ce genre de "détail" au client...
relis mon post, je donne 3 ou 4 exemples d'informations qui ne sont pas dans le .h.
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...
Oué VS 2005 pompe des trucs sur Eclipse. Et ? Eclipse n'a pompé sur personne ? VS 2005 a quand même des trucs qui tuent, à commencer par ce foutu Class Designer qui en jette. (Dommage que ce ne soit pas de l'UML mais les raisons sont à mon sens louable, cela à l'avantage de proposer une autre approche sans concurrencer son partenenaire IBM avec Rational ;) )
Je veux ouvrir un projet web ASP.NET dans VS 2003 pour lire le source ?
Faudrait que j'essai tiens :) Mais effectivement je m'attend pas à des miracles, j'avoue que la premières fois que j'avais utilisé VS.NET je trouvais ca pas top top qu'il commence par me demander où je voulais mettre mon projet dans VS... Enfin c'est sans doute ce qu'il faut sacrifier pour avoir une intégration qu'il faut bien reconnaître est plutôt bien foutu : déploiement, déboggage.
C'est tellement con qu'ils sont revenus en arrière dans VS 2005 en intégrant Cassinni :)
Le serveur qu'on code en 10 lignes ? Oué c'est vrai que ca devait pas être bien dur à intégrer direct dans VS ;)
Oui, sauf que jamais personne ne fout en prod des jar sans les tester.
Mais celui qui développe la lib n'est pas forcement le même que celui qui l'utilise ! Tu peux pas à chaque fois que tu fait une nouvelle version de ta lib passer une annonce et dire : "attention je vais mettre une nouvelle version de ma lib dans les repositories, tous ceux qui l'utilisent sont invités à recompiler leur application ! " Ca va se finir que tout le monde va utiliser sa version de lib qui marche bien dans son coin, et on aura pleins de lib en double, triple, bien difficile de mettre tout ca à jour. Enfin si je regarde les appli que j'utilise en Java c'est malheuresement ce qui se profile : à part le point commun (JDK), tout le monde embarque ses libs.
qu'il n'y a aucune norme propre en matière de packaging d'applications .NET
Euh, la norme d'encapsulation est très bien défini, c'est les .exe et les .dll avec un espace reconnu et unique : le GAC. C'est même normalisé ca. Pour les fichiers de config, la norme veut que l'on mette un truc.exe.config à côté de truc.exe. Pour IIS c'est pareil, il n'y a pas trop le choix des emplacements je trouve. Mais bon c'est vrai que le dev peut faire sa propre sauce. Mais bon cela n'a aucun impact sur la sécurité ou la robustesse.
J'ai un peu de mal à bien cerner tout de même à quoi peuvent servir ces infos : à priori tout ce que l'on cherche à générer c'est une nouvelle "vue" d'un API, quelque chose de statique et non dynamique (sinon ce n'est pas viable), et à priori je vois pas trop ce qu'on peut offrir de plus comme informations au développeur que ce qu'il y a dans les .h... ou alors même en C on a pas accès à tous les éléments... Tu pourrais préciser l'utilité dans un binding ?
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.
Visual Studio... cette espèce de bouse incapable de gérer le refactoring ?
Désolé j'utilise la beta 2 de visual studio 2005 et j'ai le refactoring :)
Le machin qui oblige à lier ses projets web avec IIS
C'est le problème de l'intégration (déboggage, etc.). Si tu pars de ce principe y'a le même problème avec tomcat (de toute façon au final, sous vs comme sous eclipse tu finis par faire un script ant ou nant)
Bah si bien sûr que c'est ça. J'ai jamais dis le contraire :) J'ai juste montré qu'en Java tu n'as pas ce mécanisme, et que donc le runtime va essayer de charger la nouvelle lib et va se vautrer si jamais l'exception est levée.
Faut être trés con pour redistribuer une appli avec une nouvelle lib sans la recompiler ne serait-ce qu'une fois.
T'as pas compris ce que j'ai mis. La lib a été mise à jour "indépendament" de l'appli. L'appli n'a pas été mis à jour ! (ce qui cause d'ailleur le problème).
c comme si le mec avait fait apt-get update
ce qui a mis à jour la lib
mais pas l'appli (qui elle n'a pas changé)
Donc, dans ce cas c'est blanc bonnet et bonnet blanc. Soit tu as un pb dans le code de la librairie, soit dans le code de ton appli.
Arf. Sauf que c'était un bug que le programmeur avait peut être contourner, ou bien qui ne le genaît pas dans son cas d'utilisation, enfin bref tu ne peux absolument rien affirmer, et tu peux très bien faire planter une appli qui ne s'y attendais pas.
Quand tu attaques libgtk en C# tu as exactement les mêmes contraintes qu'en java. A savoir que tu es dans un environnement unsafe. Point.
Et ? quel est le rapport avec la choucroute ? Tu peux utiliser du code unsafe dans un autre cadre que du binding.
Je vois pas le rapport. entre les patchs, les maj et les exceptions conditionnelles.
Je réexplique une dernière fois :
Tu fais une lib A qui contient une méthode qui ne lève pas d'exception. Tu la distribues en version 1.0.
Machin utilises ta lib, son compilo ne gueule pas vu que y'a pas d'exception.
Tu as trouvé un bug dans ta lib, tu lève une exception dans un cas particulier, tu distribues une version 1.0.1
Machin met à jour son OS et par le même fait ta lib.
Et là l'horreur se produit, machin se bouffe une exception alors qu'il était persuadé d'avoir blindé son appli ! Le client est furax.
Le runtime aurait du s'en apercevoir dès le début en déclarant la lib "non utilisable parcque ne correspond pas à son utilisation". Malheuresement ce n'est pas possible car les exceptions ne font pas parti de la signature d'une méthode, et Java n'a aucune gestion des versions à ce niveau de granularité.
En C# tu n'aurais jamais eu le même problème, le runtime aurait vu la différence et aurait tout simplement switcher l'appli pour la faire utiliser la vieille version 1.0.
une bonne IDE de te permettra de mettre le mot clef final automatiquement.
Mmmh, y'a ca dans Eclipse ? Faudrait que j'active ca.
[^] # Re: idée
Posté par TImaniac (site web personnel) . En réponse au message Valider un document XML ne contenant pas de declaration DOCTYPE. Évalué à 2.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: Et vb.net ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
[^] # Re: idée
Posté par TImaniac (site web personnel) . En réponse au message Valider un document XML ne contenant pas de declaration DOCTYPE. Évalué à 2.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: OCaml, oui mais...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 4.
Quelqu'un a-t-il commencé à apprendre la programmation par autre chose que du procédural impératif ?
Ben dans ma FAC ils ont (pas moi j'étais pas là au début) commencé par Scheme, pourtant on dit que l'on reste à nos premiers amours en matière de programmation, ben ils sont tous beaucoup plus productifs et heureux en codant en Java :)
La notion d'objet est facile à appréhender par le programmeur qui peut "mapper" sa vision sur le monde réel. Bref c'est relativement intuitif (même si cela ne conduit pas toujours au meilleur design). Pour l'impératif, celui-ci a l'avantage de donner un seul ordre à la fois, dans un ordre précis qui est celui dans lequel le programmeur écrit : c'est donc très simple à appréhender (même si ce n'est pas forcement intuitif) et à utiliser.
Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème. C'est aussi ce qui fait la puissance de ces langages : il force le développeur à indiquer l'algorithme au compilateur/interprêteur qui peut alors en déduire plus d'information, conduisant parfois (souvent pour OCaml) à des optimisations qu'un compilateur plus traditionnel ne pourrait se permettre.
[^] # Re: NON, et encore NON
Posté par TImaniac (site web personnel) . En réponse à la dépêche Quatre actions contre la vente liée. Évalué à 3.
On peut très bien dire que les pièces qui constituent un PC ont été conçu pour fonctionner avec Windows (ce qui est souvent le cas malheuresement), et que donc le tout forme un appareil homogène.
Alors non non non et non, on applique les mêmes règles à Apple ou à personne, on va pas faire d'exception pour eux : on peut très bien installer une distri Linux sur un MAC, ou intaller un OS Mac sur un vieux mac : comme quoi techniquement les 2 sont dissociés, et c'est tout ce qui compte pour définir la vente liée et respecter le consommateur.
Non mais oh. C'est vrai quoi :)
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: benchmarks bidons
Posté par TImaniac (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Autant le chargement on pourrait l'enlever, autant l'interprêteur, comme tu l'indiques, est "fixe". Il contribue donc au score de Python de manière "régulière".
comme cela déjà été dit plus haut la vitesse pure n'est pas forcement le principale critére de choix d'un langage sans quoi on coderait encore tous en AS
Tout est une histoire de compromis et de polyvalance. l'ASM et un langage inteprêté comme Python sont un peu les extrêmes. Je te laisses te faire tes propres conclusions.
# idée
Posté par TImaniac (site web personnel) . En réponse au message Valider un document XML ne contenant pas de declaration DOCTYPE. Évalué à 2.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Quand au mec en prod, il aura beau faire tous les tests, s'il ne tombe pas direct sur l'appelle de méthode qui lève la fameuse exception, il sera pas plus gland et pourtant peut être qu'au bout de quelques jour ca va lui péter à la tronche...
Franchement question robustesse/sécurité on a vu mieux que de laisser ce genre de "détail" au client...
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Je veux ouvrir un projet web ASP.NET dans VS 2003 pour lire le source ?
Faudrait que j'essai tiens :) Mais effectivement je m'attend pas à des miracles, j'avoue que la premières fois que j'avais utilisé VS.NET je trouvais ca pas top top qu'il commence par me demander où je voulais mettre mon projet dans VS... Enfin c'est sans doute ce qu'il faut sacrifier pour avoir une intégration qu'il faut bien reconnaître est plutôt bien foutu : déploiement, déboggage.
C'est tellement con qu'ils sont revenus en arrière dans VS 2005 en intégrant Cassinni :)
Le serveur qu'on code en 10 lignes ? Oué c'est vrai que ca devait pas être bien dur à intégrer direct dans VS ;)
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Mais celui qui développe la lib n'est pas forcement le même que celui qui l'utilise ! Tu peux pas à chaque fois que tu fait une nouvelle version de ta lib passer une annonce et dire : "attention je vais mettre une nouvelle version de ma lib dans les repositories, tous ceux qui l'utilisent sont invités à recompiler leur application ! " Ca va se finir que tout le monde va utiliser sa version de lib qui marche bien dans son coin, et on aura pleins de lib en double, triple, bien difficile de mettre tout ca à jour. Enfin si je regarde les appli que j'utilise en Java c'est malheuresement ce qui se profile : à part le point commun (JDK), tout le monde embarque ses libs.
qu'il n'y a aucune norme propre en matière de packaging d'applications .NET
Euh, la norme d'encapsulation est très bien défini, c'est les .exe et les .dll avec un espace reconnu et unique : le GAC. C'est même normalisé ca. Pour les fichiers de config, la norme veut que l'on mette un truc.exe.config à côté de truc.exe. Pour IIS c'est pareil, il n'y a pas trop le choix des emplacements je trouve. Mais bon c'est vrai que le dev peut faire sa propre sauce. Mais bon cela n'a aucun impact sur la sécurité ou la robustesse.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
Désolé j'utilise la beta 2 de visual studio 2005 et j'ai le refactoring :)
Le machin qui oblige à lier ses projets web avec IIS
C'est le problème de l'intégration (déboggage, etc.). Si tu pars de ce principe y'a le même problème avec tomcat (de toute façon au final, sous vs comme sous eclipse tu finis par faire un script ant ou nant)
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
[^] # Re: du déjà vu
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. É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: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
T'as pas compris ce que j'ai mis. La lib a été mise à jour "indépendament" de l'appli. L'appli n'a pas été mis à jour ! (ce qui cause d'ailleur le problème).
c comme si le mec avait fait apt-get update
ce qui a mis à jour la lib
mais pas l'appli (qui elle n'a pas changé)
Donc, dans ce cas c'est blanc bonnet et bonnet blanc. Soit tu as un pb dans le code de la librairie, soit dans le code de ton appli.
Arf. Sauf que c'était un bug que le programmeur avait peut être contourner, ou bien qui ne le genaît pas dans son cas d'utilisation, enfin bref tu ne peux absolument rien affirmer, et tu peux très bien faire planter une appli qui ne s'y attendais pas.
[^] # Re: Nécessité de Java?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
Et ? quel est le rapport avec la choucroute ? Tu peux utiliser du code unsafe dans un autre cadre que du binding.
Je vois pas le rapport. entre les patchs, les maj et les exceptions conditionnelles.
Je réexplique une dernière fois :
Tu fais une lib A qui contient une méthode qui ne lève pas d'exception. Tu la distribues en version 1.0.
Machin utilises ta lib, son compilo ne gueule pas vu que y'a pas d'exception.
Tu as trouvé un bug dans ta lib, tu lève une exception dans un cas particulier, tu distribues une version 1.0.1
Machin met à jour son OS et par le même fait ta lib.
Et là l'horreur se produit, machin se bouffe une exception alors qu'il était persuadé d'avoir blindé son appli ! Le client est furax.
Le runtime aurait du s'en apercevoir dès le début en déclarant la lib "non utilisable parcque ne correspond pas à son utilisation". Malheuresement ce n'est pas possible car les exceptions ne font pas parti de la signature d'une méthode, et Java n'a aucune gestion des versions à ce niveau de granularité.
En C# tu n'aurais jamais eu le même problème, le runtime aurait vu la différence et aurait tout simplement switcher l'appli pour la faire utiliser la vieille version 1.0.
une bonne IDE de te permettra de mettre le mot clef final automatiquement.
Mmmh, y'a ca dans Eclipse ? Faudrait que j'active ca.