TImaniac a écrit 6420 commentaires

IBM, Sony et Toshiba seraient prets à ouvrir/liberer les specifs du processeur the Cell.
ils veulent plutôt développer des libs utilisant le Cell sur un modèle Open Source. Parcque bon libérer les spécifs, quand tu veux faire un proc généraliste sans drivers proprio, ca me paraît un minimum si on veut espérer vendre le proc tout de même :)

Firefox se balance royalement des HIG de Gnome (je te laisse googeuliser), contrairement à epiphany.

Certains contrôles ressemble à leur équivalent GTK mais ne fonctionnent pas pareil : typiquement les tab (suffit de chercher le bouton pour fermer un onglet).
Quand je dis à Gnome que je veux des barres d'outil avec icone et texte en dessous, je m'attend à ce que Firefox fasse pareil. Ben non.
Pour les jeux d'icones pareil, Firefox utilise son jeu d'icone à lui, alors que Gnome en défini un grand nombre.

Bref : des différences d'ergonomie, d'intégration et parfois d'aspect visuel.

Parcque ce n'est pas le sujet.

Elle définit la politique commune !
une constitution ne doit pas défini la politique commune. Surtout qu'elle ne me plaît pas cette politique :)

aucun article de la partie I et II ne définit qui doit faire quoi pour adopter une loi au niveau européen.
Etant donné que là non plus je n'aime pas du tout qui fait quoi, je préfères retirer la partie III actuelle, quitte à la réécrire sans reprendre tout ce qui concerne les politiques communes.

Pour reformuler, je trouve que c'est une grosse regression que de faire sauter le verrou du veto sur les domaines économiques, surtout dans un contexte aussi peu démocratique qu'est celui proposé par l'Europe. Après c'est mon avis, d'autres peuvent préférer le contraire, mais comme quoi il faut arrêter d'affirmer bêtement que ce TCE ne fait qu'apporter des améliorations à l'existant.

N'oublions pas que le TCE conserve toute la partie 3, et dire Oui maintenant au TCE c'est accepter cette partie, c'est valider les orientations actuelles, alors que dire non c'est également remette en cause le système actuel. La plupart des partisans du non sont d'accord sur ce point et proposent de ne conserver que les parties 1 et 2.

Qu'on me dise pas : "ah ben fallait pas voter Oui à Maastricht !", on m'avait pas demandé mon avis à l'époque (pas encore majeur à l'époque ;) )

Tout ce qui est décrié dans la constitution est déjà présent dans les traités actuels.
Ah non !
Moi je décries :

- le fait qu'il y est besoin de l'unanimité dans les domaines du social et de l'environnement et seulement la majorité dans le reste (économique entre autre) : conclusion il sera beaucoup plus difficile de faire progresser ces 2 premiers domaines contrairement aux autres domaines. Perso j'aurais préféré tout simplement l'inverse.

- Le fait qu'on élargisse les compétences de l'UE à d'autres domaines que l'économie tout en refusant de proposer un modèle démocratique que nous partageons pourtant tous : la séparation des pouvoirs. Même s'il y a quelques avancées démocratiques (notamment l'obligation de transparence du conseil), je préfères le système actuel limité à l'économie, qu'un système toujours pas vraiment démocratique élargi à tous les domaines.
Faut pas se leurer, le but est de faire une Europe fédérale, sur le principe de "l'union fait la force". Moi je suis entièrement pour, mais je préfère une europe sans politique qu'une europe avec une politique qui ne représente pas son peuple. Ou comment faire la première union non démocratique de pays démocratiques. Même aux US il y a plus de démocratie.

Tu me dis où t'as trouvé ca dans les traités déjà existants.

Toi tu trouves peut être cela banal, moi je trouve que ce n'est pas du tout dans l'esprit du libre.
De plus je n'invites pas spécialement à changer de navigateur à cause de la licence, je prend soin de précisé ce qu'apporte Epiphany : la simplicité et l'intégration dans Gnome.

Pour ceux qui sont sous Gnome et qui n'ont pas besoin de 1000 fonctionnalités "utiles" comme les skins, il est peut être temps de redécouvrir des navigateurs alternatifs comme Epiphany, parfaitement intégré à Gnome (bien mieux que Firefox), il utilise le moteur de mozilla et gère les onglets.
mes 2 cents

C'est pas du tout Sun qui y réfléchi mais le projet Apache.
Sinon on en a déjà parlé par ici : http://linuxfr.org/~vallou/18094.html(...)

DOM ou SAX c'est pour parser un fichier XML uniquement.
Perl c'est pour parser tout court. Si faut parser du XML il est évidemment bien plus pratique d'utiliser DOM ou SAX.
Pour ce qui est de regex, rien ne vaudra jamais un langage compilé avec une lib regex bien foutue, cad qui sache compiler une regex. Une regex compilé ira beaucoup plus vite qu'un script perl. Après c'est surtout une question de confort de programmation : les fanas de Perl te montreront un script qui tient en 1 ligne et qui fait la même chose que ton programme compilé qui en fait 60.

Après tout dépend de ce que tu veux faire, si c'est juste un script, Perl peut être un bon choix, si par contre c'est proposer une API ou proposer une interface graphique, Perl a tout de suite beaucoup moins d'intérêt ;)

les service ca coute pas tres cher a produire...
Ca c'est la meilleur du siècle. Qui dit service dit la plupart du temps humain. Qui dit humain dit salaire. Qui dit salaire = des sous.

XML c'est un langage générique de structuration de données à base de balise. Basiquement ca ne fait strictement rien, c'est pas fait pour programmer mais pour structurer des données. Après il y a des dérivés d'XML qui permettent de transformer un document XML en autre chose (genre XSLT), mais bon dans ton cas autant te dire que ca sert à rien.

Si tu ne peux pas utiliser de langage interprété, tourne toi vers ton langage favori compilé et cherche comment lire et écrire dans un fichier, tout en trouvant la classe sur les expressions régulières (regex). Tu n'auras quasiment aucune différence d'un langage un autre, l'algo étant relativement simple.
http://www.regular-expressions.info/(...)

Mon dieu quelle horreur. Tu connais la classe regex ?
Bon sinon un élément de réponse pour le monsieur qui pose la question :
http://www.regular-expressions.info/(...)

" In just one line of code, whether that code is written in Perl, PHP, Java, a .NET language or a multitude of other languages."

MMh ca n'empêche que cette couche C doit avoir tous les inconvénients de Gnome pour être exploitable, cad offrir des possibilités d'introspection par exemple pour faciliter le binding...
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).

Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.
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.

Depuis le début je disais qu'il était tout à fait possible de faire un binding à partir des .h automatiquement. Ma question était donc : que va apporter l'introspection. J'ai eu des réponses qui m'on convaincu et j'ai compris l'apport d'une telle méthode. Cependant certains s'évertuaient encore à dire qu'il n'était pas possible de se contenter du parsing de .h. Basiquement si. Je l'ai fait pour binder gstreamer, et même si ce n'était pas super bien intégré dans le langage cible c'était tout à fait exploitable.

T'as lu ma phrase ? J'ai dis que c'était idiot.

Avec ta couche supérieur en C par dessus le C++ le compilateur aura les même problèmes quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.
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.

Ah oui j'oubliais, il y a tout de même un conseil à donner : ne pas ouvrir les pièces jointes ;)

Merci de t'inquiéter, mais ca fait longtemps que je programme en C. Par contre tu n'as l'air d'avoir bien saisie le sens d'introspection. Enfin j'ai la réponse à ma question plus bas sur l'utilité de la démarche et le pourquoi de l'utilisation de cette technique.

Yahoo. Donc tu proposes de mettre une couche C à KDE. Clap clap clap. Tu dis que en c++ c ouachement mieux parcque c optimisé par rapport à C machin machin, et tu proposes de justement de rajouter une couche qui, si on te suit, n'est pas optimisé puisqu'en C. Cherche l'erreur.

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

Franchement plutôt que de s'embêter à installer 15000 softs (anti-virus, anti-spyware & co), installe Firefox, thunderbird et un bon firewall (pour protéger Windows des agressions extérieures, surtout quand on a une connection Free ;) ). Ensuite tu désinstalles outlook express et tu caches l'icone IE.
Franchement j'ai toujours fonctionné comme ca, j'ai lancé adaware une fois pour le fun, y'avait kedal.

T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
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)

C'est une idée fausse hélas très répandue sur OCaml.
Non ce n'est pas une idée fausse, c'est mon idée tirée de mon expérience.
Même si OCaml permet de programmer de plusieurs manière, je ne lui vois pas beaucoup d'intérêt si c'est pour l'utiliser de manière impérative. Je me trompes peut être mais à mon sens toute la puissance de OCaml réside dans le mixage objet/fonctionnel qui permet d'exprimer avec force ce qu'on veut faire, ce qui permet au compilo de faire tout pleins de déductions et d'optimisation. Cela dis je suis peut être complètement à côté de la plaque :)

Le langage C++ au lieu de poser des problemes, comme tu pense le penser
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.