Vivi a écrit 819 commentaires

je suis en thèse d'évolution artificielle appliquée à la biologie

bon, l'évolution artificielle, les algos génétiques tu connais bien ... mais l'évolution "naturelle" ? J'espère que tu ne transposes pas aveuglèment les résultats de l'une à l'autre.

L'évolution est une facon d'explorer un espace dans lequel une population de solution est optimisée au fur et à mesure des générations.

Ça c'est la version "mathémathique", à la sauce ingénieur-informaticien.

Tu confondrais pas avec totem ? Je crois bien que Rhythmbox n'a toujours marché qu'avec GStreamer.

il est pas/plus dispo en France (peut-être à cause de la réglementation sur le volume maximum dans les écouteurs, d'après ce que j'ai lu).

Moi je l'ai acheté chez les suisses, (voir lien au dessus)

Sans vouloir faire de polemique, utiliser the Inquirer comme source, ...

oui d'ailleurs quand on google "Rockton Technology", le premier lien c'est ça:
http://www.sterlingplumbing.com/onlinecatalog/detail.jsp?item=43073(...)

moi je dis c'est louche.

c'est un UB : le fait que ton test ait marché une fois ne garanti pas que ça marchera toujours.

Il est tout à fait possible que ton tableau i soit dans une page où tu as le droit d'écrire et que, pas de bol, i+2 pointe pile sur le début d'une page où tu n'as pas le droit d'écrire. Et là i[2] = 0 ⇒ SIGSEGV.

On pourrait écrire je pense un programme C qui fait ça (avec un peu de mmap()) mais j'ai la flemme :)

la norme C est claire là-dessus : tu peux faire un peu ce que tu veux comme arithmétique de pointeurs (addition, sousraction) tant que les opérandes et le résultats pointent sur un élément de bloc (array object) existant ou l'élément juste suivant« one past the last element of the array object »)

Dans ton exemple, ça veut dire que l'on peut considérer i, i+1, et aussi i+2. Par contre la norme dit bien qu'on a pas le droit de déréférencer le i+2 « If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated. »
Donc, nan, ton i[2] = 0; ne va pas.

Pariel, pour les truc[-1], tout dépend comment tu as obtenu truc. Si c'est comme ça, pas de problèmes :

int *machin = malloc (42 * sizeof (int));
int *truc = machin + 1;

En particulier, la notation de l'inférence de types n'est pas évidente pour qui n'a pas fait de lambda calcul.

pas vraiment, ça n'a rien à voir. Tel qu'il est présenté traditionnellement, le lambda-calcul est non-typé.
Et l'inférence de types, c'est conceptuellement assez simple. (« j'aditionne 2 à x ? donc x est un entier ; j'applique List.length à x ? donc x est une liste, etc.)

la différence entre les fonctions renvoyant quelque chose et les instructions de renvoyant rien

au contraire, c'est beaucoupl plus simple qu'en C et consorts car en caml il n'y a que des expressions, pas de distingo expressions / instructions.

on a une bonne intuition de la manière dont fonctionne un vrai ordinateur, et je pense qu'avoir cette intuition est utile.

bof, le C est déjà bien loin de la machine (et de toutes façons je ne pense pas que cette "intuition" soit trés utile).

En particulier, le fait qu'il y ait un opérateur par type pour une même opération, c'est super chiant. Certes, ça permet l'inférence de types, mais ça reste super chiant de devoir se rappeler de la liste des opérateurs de chaque type.

ouais enfin il n'y a que deux familles d'opérateurs, ceux pour entiers et ceux pour flottants qui ont un point en plus. C'est pas la mort à mémoriser. Remarque que certains langages à inférence de type se débrouillent avec un seul jeu d'opérateur.

L'équipe développant OCaml à l'INRIA a pour thème la recherche sur les langages de programmation, leur sémantique, implémentation, typage, tout ça ... Réaliser un environnement de programmation de qualité industrielle n'est apparemment pas leur objectif.

Ça a été évoqué plusieurs fois sur la ML. C'est pas aussi simple que ça apparemment.

Actuellement il y a GODI http://godi.ocaml-programming.de/(...) qui se rapproche assez de ce que tu cherches.

Le codage d'une fonction, nécéssite souvent moins de code dans un langage interprété que dans un langage compilé.

n'importe quoi. En tous cas, ça n'a rien à voir avec l'aspect interprété non du langage.

Le programme est plus donc facile à lire et à comprendre pour un néophyte.

ce qui est aide le néophyte à mon avis, c'est d'avoir un code bien organisé, bien modularisé et bien documenté. Pas grand chose à voir avec le langage.

La puissance des ordinateurs ne cessant d'augmenter, la lenteur des langages interpretés devient un mythe (*)

Euh non ... ils sont toujours plus lent qu'un programme équivalent compilé, c'est pas un mythe. Maintenant, c'est peut-être pas toujours gênant mais ça dépend des applications.

Les traitements devant être rapides peuvent être implémentés dans un langage de bas niveau.

Donc avantage pour les langages avec une implémentation compilée rapide qui ne nécessite pas ce changement de langage et les problèmes qui vont avec (interfaçage et tout ça).

La majeure partie de temps, une application moderne affiche des IHM. Ce qui se code très bien en langage interprété.

En langage compilé aussi d'ailleurs.

Pas de problème de compilation, d'édition de liens, etc...

Remplacés par des problèmes de disponibilité des modules à charger à l'éxécution. Le problèmes est le même, il est simplement déplacé ...

Beaucoup de problèmes de bas niveau sont gérés par le langage

Là encore, ceci n'est pas l'apanage des langages "dynamiques".

(pour le patch gnome)

- déjà ton ticket dans bugzilla date de 2 semaines, ça va ... laisse leur le temps

- ton anglais est trés approximatif, ça n'aide pas

- ensuite si tu veux proposer un patch, ben attache un patch ! et pas un mélange de texte et de "changez ça en ça, et plus loin remplacez ça par ça en ayant fait toutes les autres modifications qui s'imposent" (sans spécifier de quel fichier il s'agit)

- quand tu termines par "j'ai bricolé ça, ça a l'air de marcher mais j'suis pas trop sûr", ça n'incite pas à intégrer ton code direct

- de toutes façons, tu ne peux pas modifier l'API publique donc il faudra trouver autre chose.

Cairo est en double licence : LGPL et MPL

ou OCaml (ou plein d'autres qui ont leurs avantages et leur inconvénients)

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.

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 ...

oui d'ailleurs :

The format of GObject metadata is strongly influenced by the Mozilla XPCOM format.

(ça vient du README de la fameuse lib d'introspection)

J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.
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 ...

Visiblement Mono n'a pas besoin de ces informations
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.

J'ai bien compris, je voulais l'utilité de ces informations dans un binding.
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 »

Tu pourrais préciser l'utilité dans un binding ?

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.

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)

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).

Bref ces benchmarks ne sont aucunement significatifs et ne veulent rien dire du tout !!!

n'importe quoi : ça veut bien dire quelque chose mais il faut analyser. Il faut un peu faire marcher son cerveau, aller lire le code des différents benchs, comprendre pourquoi ça été ecrit comme ça, et en tirer les conclusions qui conviennent.

C'est stupide de prendre tous ces chiffres pour argent comptant (« mon langage est 23% mieux que le tien ! ») mais c'est encore plus stupide de tout rejeter en bloc.

s/hexdigest/digest/

C'est quoi l'intérêt de la recherche fondamentale ?

comme on dit toujours :

c'est pas en améliorant la bougie qu'on a inventé l'ampoule électrique.

Oui l'API est en train d'être changée, c'est le grand "API shakeup". Voir les Ml cairo, c'est assez actif en ce moment.