Bon, ça m'a l'air du bon, tout ça :)
Je viens de me faire un ebuild, et trois remarques à chaud:
- s/644/655
- il manque install -d ${DESTDIR}${LIBDIR} (oui, si ${DESTDIR} n'est pas /, ${DESTDIR}/usr/lib n'existe pas forcément...)
- les liens symboliques vers des bibliothèques, fais les relatifs, pas absolus (ln -fs libetc.so... au lieu de ln -fs ${LIBDIR}/libetc.so...)

(pour répondre au commentaire de dessus: je pense que c'était de l'humour (noir, vu la référence à la base de registres) :))

Merci pour cette formidable outil qui ne me quitte plus \o/

[ Répondre ]

Je pense qu'il voulait parler de RS232 ;)

[ Répondre ]

Je pense qu'il faut prendre "devient" comme "en train de devenir"...

[ Répondre ]

Sur le fond, la situation n'est pas vraiment la même:
- Si demain MS fait que IE ne lise plus que les pages standard -> tous les sites passent aux standards.
- Si demain Firefox ne fonctionne plus qu'avec les pages standards -> "Firefox sai dla merde" et firefox retombera à 1% de parts de marché (et encore...)

Sur la forme, je suis d'accord: deux poids, deux mesures, ça pue

[ Répondre ]

Sur la même page:
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#s(...)
Ce qui je lirais plutôt comme "n'utilisez text/html que pour être compatible avec la vieille soupe infâme"...

[ Répondre ]

> Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page",
Comment peux tu manipuler l'arbre DOM du menu depuis la page ?
Comment fais tu si tu veux que les règles de style de ta page s'appliquent à ton menu ? (hors d'inclure le même fichier CSS à la fois dans le menu et dans la page)
Comment fais tu pour un menu dont la taille change dynamiquement (cas des menus "déroulants") ?

La balise object, ce n'est qu'une grosse boite. Ça peut suffire pour des choses basiques, mais c'est franchement limité par rapport au modèle d'une forêt de boites qui prévaut en XHTML/CSS.

[ Répondre ]

Non, les ">" dont là pour dire "fils direct". En les enlevant, le style s'appliquera au h de niveau deux ou supérieur:
[h]Premier niveau, ne s'applique pas[/h]
[section]
[h]Second niveau, s'applique[/h]
[section]
[h]Troisième niveau, s'applique[/h]
[section]
[h]Quatrième niveau, s'applique[/h]
...

Soit dit en passant, ton "body" est inutile (tout section est un descendant de body). Le mien sert justement à déterminer le "section" de premier niveau.

(en xpath, mon expression serait //body/section/h, tandis que la tienne est //body//section//h,//body//section//h//section//h, qui ne répond absolument pas au problème...)

[ Répondre ]

Grrr, un mauvais C-z a dû traîner, une parenthèse de mon message a sauté:
si tu envoies ton fichier via HTTP, le doctype ne suffit pas, il faut aussi envoyer le bon Content-type (le type donné par HTTP étant prioritaire). Tu peux mettre le doctype que tu veux, tant que tu envoies du text/html, ça reste de la soupe. Par contre, quand tu envoies du xml (plusieurs types mime possibles), là, tu dis "je fais du xhtml", et effectivement firefox te gueule dessus si tu fermes une balise de travers...

[ Répondre ]

> Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?


body > section > h {
...
}

Non ? (en tout cas, je trouve ça joli ;))

[ Répondre ]

>> Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
> C'est quoi cette argumentation de merde,

Ça s'appelle du bon sens. Quand dans un script ruby la première ligne est:
#!/usr/bin/env python
l'interpréteur python me sort une erreur quand j'essaie d'exécuter ce script avec un ./script. Normal. Manquerait plus que l'OS détecte que c'est une syntaxe ruby et qu'il fasse un exec(ruby) pour "faciliter la vie au développeur"...

[ Répondre ]

HTML 5 n'est pas le successeur de XHTML 1 mais de HTML 4, qui n'était pas un dialecte XML... Pas d'abandon donc, puisque HTML n'a jamais eu de syntaxe XML..

Par contre, un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...

[ Répondre ]

> , d'ailleurs, les seuls moments où on a recours au pointeur de char, c'est des "const char*", donc pas pour les manipuler.
Haem...
http://cplusplus.com/reference/iostream/istream/getline.html
http://cplusplus.com/reference/iostream/streambuf/xsgetn.htm(...)

[ Répondre ]

> en C++, on n'utilise pas de chaine de charactères en char*
Tu veux dire, comme avec std::fstream ? :)

[ Répondre ]

Tu as raison, j'ai posté trop vite.
Mea culpa, la prochaine fois je tournerai ma langue 7 fois avant de cliquer sur envoyer (je dis ça à chaque fois...)

[ Répondre ]

> Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

[ Répondre ]

Bon, on va répéter pour ceux au fond qui n'ont pas écoutés:
Le but est (entre autre) d'être directement et nativement compatible au niveau ABI (et quasi immédiatement au niveau API) avec GObject (c'est un projet Gnome, après tout), même pour le modèle objet. Tu peux m'expliquer comment tu fais ça avec D ? L'ABI de D est très proches de celle du C++, et n'a rien à voir avec celle de Vala/GObject qui est du pur C.

Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C (disons, pour simplifier, que j'ai déjà une instance f). Si ça a été codé en vala:
foo_bar(FOO(f)); (fonctionne de la même manière que gtk_window_set_title(GTK_WINDOW(w), "Hello, world"); )
en C++:
_ZN3Foo3barEv(f); (je ne l'ai pas inventé, c'est le nom qu'a donné G++ à la méthode...)
Et encore, ce code dépend de l'ABI C++ du compilateur, et j'ai considéré que la fonction n'était pas virtuelle. Vois tu où se situe Vala, maintenant ?

Pour rentrer dans le troll, j'avais regardé du côté de D il y a quelques années lorsqu'il venait à peine d'être libéré, et c'était à l'époque assez intéressant. Mais maintenant qu'aujourd'hui on a GCJ, j'ai du mal à voir l'intérêt.

> L'avantage est que le compilateur est un front-end à gcc et qu'il peut donc être disponible sur un grand nombre de plate formes.
Vala transformant en code C pour le faire avaler à GCC, je pense qu'on peut difficilement faire plus portable :)

[ Répondre ]

C'est le cas d'à peu près tous les langages (sauf peut être Brainfuck ;)), et je n'ai jamais dit que C++ était une sous merde inutilisable que seul un barbare sous l'emprise de substances illicites utiliserait, hein (c'est "l'approche windows" qui a choqué ? ce n'était pas dans un but péjoratif, c'était juste pour illustrer que philosophiquement, il y avait un gouffre énorme entre Objective-C et C++). Tout ce que mon message dit, c'est que l'Objective-C est au C++ ce que kate est à KDevelop. Je conçois et respecte que l'on puisse aimer les IDEs-usine-à-gaz, mais d'autres aiment bien les éditeurs simples et sobres.

[ Répondre ]

Non, le code généré par Vala est très lisible et extrèmement proche de ce qu'aurait écrit un développeur C+GObject (certains argueront que ce n'est justement pas lisible, mais là n'est pas le troll :))

> Et qu'est ce que ça change ?
100% et immédiatement compatible avec le C et l'énorme paquet de code GObject existant, le tout avec une syntaxe un peu moins lourde

> Créer un langage propre et qui marche est loin d'être trivial...
Justement, c'est plus proche d'un préprocesseur que d'un vrai langage...

[ Répondre ]

Étant "fanboy" (comme le mot est à la mode ici) d'Objective-C, je vais vaguement essayer d'expliquer l'intérêt de ces langages.
En un mot: C++ est une couche très épaisse au dessus du C. Objective-C est une couche très fine au dessus du C. Les implications:
- se retrouvent en termes de complexité. Ajouter une couche Objective-C au dessus d'un compilateur C est trivial (pour l'anectode, un développeur du projet Étoilé a réecrit la couche logique (pas syntaxique) de l'objective-c en deux jours!). Ajouter le ++ au C, par contre, est un réel cauchemar pour l'implémenteur (une histoire de grammaire qui n'est plus LALR). Pour l'utilisateur, cela se ressent fortement. Le créateur du C++ a dit quelque chose du genre "je ne m'attend pas à ce que qui que ce soit comprenne le langage dans sa totalité" (c'est assez proche de la philosophie Perl: on ajoute du bloat et du bloat syntaxique et chaque développeur apprend son propre sous-langage - mis à part qu'en C++, ce sous langage est relativement commun). Personnellement, je suis (très) loin d'être une lumière, mais j'ai réussit à me coder un binding générique Objective-C <-> Python pleinement fonctionnel en quelques jours (et j'ai très eu d'expérience en Objective-C derrière moi) - en ramant plus sur la partie Python que Objective-C. Après, je ne débattrai pas plus longuement sur l'intérêt de la simplicité, la littérature abonde là dessus.
- Une équivalence entre le C et l'Objective-C. Le C++ est vaguement capable de réutiliser ce qui est fait en C (donc C => C++ - et encore, il y a des cas assez rares où un code C ne compile pas en C++ - simple exemple: en C, tu peux avoir une variable "class". C++ réserve ce mot clef). En Objective-C également, la réutilisation du code C est à 100% possible (et sans les cas rares du C++) mais l'inverse est également vrai: même en n'ayant qu'un compilateur C sous la main il est possible de réutiliser des librairies Objective-C. Réutiliser les librairies C++ en C sans compilateur C++ est totalement exclu.
Pour résumer, Objective-C est très proche de l'approche Unix (transparence, simplicité et couche fine) tandis que le C++ est plus proche de l'approche Windows (cacher les détails d'implémentation, préférer la complétude à la simplicité, la "couche épaisse" n'étant qu'un corollaire de ces deux derniers points)
Vala, quant à lui, serait un Objective-C avec une couche un peu plus épaisse, ce qui lui permet d'ajouter des concepts de plus haut niveau et de s'affranchir de concepts qui seraient de trop bas niveau au goût de certains développeurs objet. Tout en restant à 100% équivalent au C, simple et transparent. Un excellent compromis à mon goût (même si la syntaxe C#-like me sort par les trous de nez :))

C# ne vise pas à être "une couche au dessus du C" (qu'elle soit fine ou épaisse) et n'a donc rien à voir avec les autres que tu as cités. Il serait beaucoup plus proche du Java.

Maintenant, Vala et Objective-C font ils doublons ? Oui et non. De loin, ils poursuivent les mêmes objectifs, mais de près:
- On peut mettre directement du C dans du code Objective-C. Objective-C, en fait, n'étend que légèrement le C pour les définitions et les déclarations de classes/méthodes/fonctions (à la limite, Objective-C aurait pu être fait à coup de directives du préprocesseur. D'ailleurs, il me semble que la première implémentation d'Objective-C n'était qu'un préprocesseur), tandis que Vala est un langage à part entière.
- Objective-C cible le C et les développeurs C. Vala cible GObject et des développeurs de "haut niveau" (garbage collector par exemple. Je sais, il y en a aussi en Objective-C, mais vu son échec retentissant...)
Ces deux différences suffisent, AMHA, à justifier l'existence des deux en parallèle.
Un petit bémol pour Vala, toutefois, est le fait qu'il s'appuie sur GObject dont le modèle objet est singulièrement limité comparé à l'Objective-C: pas de categories, impossibilité de surharger une méthode, réflexion limitée.

Bon, c'est pas tout ça, mais j'étais censé bosser aujourd'hui moi, pas mouler... :-/

[ Répondre ]

> Donnez des technologies ou réflexions qu'a apporté Ubuntu. Bonne chance.
Upstart
En même temps, au vu du résultat, je sais pas trop si on peu appeler ça un "apport" -->[]

[ Répondre ]