Tu confonds plein de choses... Unicode a travaillé pendant des années pour que des concepts auparavant fortement liés soient maintenant indépendants. Ces concepts (que tu mélanges), c'est :
Un caractère : pour Unicode, un caractère, c'est un point de code (pour faire très simple). Ils ont recensé tous les caractères au monde, en se posant des vrais questions (genre 'A' et 'a', c'est deux caractères différents ? 'A' (latin) et 'A' (alpha majuscule grec), c'est deux caractères différents ?) et ont attribué un numéro et une description à chaque caractère. Les fameux U+0000, ce sont les points de code, ça désigne un caractère de manière unique.
Un encodage : c'est la manière de représenter informatiquement un caractère. Par exemple, UTF-8 est un encodage. Latin1 aussi mais il ne permet pas de coder tous les caractères Unicode (donc c'est moisi, il faut s'en débarrasser).
Une police : c'est la manière d'afficher à l'écran un caractère, peu importe son encodage. Avec des variantes du genre gras, italique, etc pour chaque caractère.
Auparavant, tout était mélangé, comme le montre la fameuse police Symbol évoqué plus haut. Maintenant, c'est beaucoup plus clair et c'est tant mieux. Donc le problème de comment afficher un caractère unicode ne dépend ni du caractère, ni de l'encodage, mais uniquement du système de polices de caractère.
Comme l'ont déjà dit d'autres, la spécificité de LLVM est que cette représentation intermédiaire est bien spécifié (il suffit de cliquer sur le lien). Et c'est même plus que ça, c'est un langage assembleur à part entière qui peut être utilisé tel quel. Est-ce qu'on a la même chose pour GCC ? Non (et c'est bien dommage à mon sens). Et même, je dirais qu'aucune machine virtuelle que je connaisse ne permet de coder directement en "assembleur" aussi facilement.
Quand au troll sur la licence, on ne peut contester que LLVM est utilisé en partie à cause de ça. Maintenant, est-ce que ça change quoi que ce soit au reste, c'est-à-dire aux vrais arguments techniques ? Non, absolument pas. En tout cas, pour ma part, je m'y intéresse pour ses qualités techniques, et pas à cause de sa licence. Je suis un libriste tendance RMS, et ça ne me dérangerait absolument pas que LLVM soit GPL. Ce n'est pas le cas, ce n'est pas grave, c'est compatible GPL quand même.
Ma Debian serait une petite distribution sans envergure, je ne dis pas. Mais on parle là d'une des distributions les plus utilisées au niveau serveur. Alors je veux que ça ait un sens, mais je ne suis pas sûr que sa méthode pour y parvenir soit très bonne.
Ouais enfin, c'est quand un peu con de ne pas gérer un /usr sur une partition différente. Cette configuration est quand même la norme sur des serveurs, donc la gérer me semble être le minimum pour ne pas se foutre de la gueule des gens.
D'ailleurs, on constate aussi qu'il ne gère pas un /etc/mtab qui n'est pas un lien sur /proc/self/mounts. Or sur ma Debian, ce n'est pas un lien...
Il fait un logiciel pour qui ce gars ? Lui tout-seul ?
D'un autre côté, on se plaint depuis des années que X est (très) en retard. Pour rattrapper le retard, il va falloir casser certaines compatibilités (et certaines susceptibilités). Si on attend que Fltk se soit mis à jour, on n'est pas sorti de l'auberge. Quand il n'y aura plus qu'à porter les "petits", je pense qu'on aura gagné.
Un tri... Sur un tableau, on a tendance à trier le contenu (trier les indices n'a pas grand intérêt), alors que sur une map, on triera plutôt selon les clefs (quand ça a un sens, ce qui n'est pas gagné).
Un langage pour les gouverner tous... ça n'existe pas !
Que les tableaux et les maps (et les chaines de caractères) soient intégrés dans un langage de script, ça ne me choque pas, au contraire, je dirais que ça simplifie la vie. Mais que ce soit intégré dans un langage bas niveau comme le C ou comme veut l'être Go, non merci. Quand on utilise un langage bas niveau, c'est pour pouvoir tout contrôler et optimiser là où il faut. Un join sur un tableau de string, ça peut très bien se faire en C de manière très optimisée, sans doute bien plus rapidement que n'importe quel langage qui intègrerait tout.
Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]
Bienvenue dans PHP ! Et tout codeur PHP sait tous les problèmes que ce genre de considération peut poser. Un tableau et une map, ce n'est pas la même chose. Ils n'ont pas la même utilité. Et on peut tout à fait les mettre les deux dans un langage sans les fusionner. Ce qui permettra d'optimiser certaines opérations suivant qu'on a un tableau ou une map.
De même, les templates C++ sont équivalents aux interfaces Go, sauf qu'on ne déclare pas l'interface, on utilise des méthodes d'un type et on peut instancier le template avec n'importe quel type qui implémente les méthodes. La définition des interfaces devaient être incluses dans le nouveau C++ sous le nom de concept mais a été annulé.
Non, tu n'es pas seul. Je trouve sa syntaxe vraiment bizarre. Il y a plein de choses que j'aime pas, notamment make, l'omission des parenthèses (autour de la condition du if par exemple) qui rendent le code difficilement compréhensible, la différence array/slice, le mélange entre pointeurs et références cachés (comme les map) qui fait que suivant le truc, l'argument est passé par valeur ou par référence, le goto, la précédence des opérateurs simpliste qui fait que 3 * 2 << 2 n'est pas égal à 2 << 2 * 3 (alors que dans la plupart des autres langages, c'est le cas)...
Bref, beaucoup d'inconvénients pour peu d'avantages (pour moi, un gc n'est pas un avantage).
Sur Jamendo, les tags étaient assez bien gérés (je ne sais pas si c'est toujours comme ça). En gros, on pouvait ajouter un tag avec "+tag" et on pouvait en retirer avec "-tag". Si le tag était présent, ça lui donnait plus de poids ou ça lui enlevait du poids (jusqu'à disparaître). Du coup, le système convergeait assez bien vers un consensus.
Posté par rewind (Mastodon) .
En réponse au journal IE9.
Évalué à 4.
Oui c'est bien ce que je dis. HTML5, c'est défini comme du XHTML5 écrit avec les pieds mais tout le monde doit avoir la même déformation des pieds (n'y voyez aucune allusion à GNOME), comme ça les navigateurs qui corrigeait pas de la même manière avant vont maintenant tous faire la même chose.
Posté par rewind (Mastodon) .
En réponse au journal IE9.
Évalué à 5.
XHTML n'est pas mort, juste le nom. HTML5, c'est un dialecte XML comme les autres, avec en plus une normalisation pour ceux qui savent pas fermer des balises pour que tous les navigateurs "corrigent" de la même manière.
Sur Wikipedia (Loi) : «Adage (non légal) qui ne signifie pas que l'on doit connaître l'ensemble des lois, mais selon lequel on ne peut invoquer l'ignorance de la loi pour échapper à la loi.»
Ce que tu dis est vrai selon ta vision où il n'existe que des contrats entre entités économiques privées (et, sous-entendu, peu de lois pour réguler). Malheureusement pour toi, il y a aussi l'État qui peut fourrer son nez dedans et obliger MS à faire autre chose. Et tu le sais parfaitement puisque ça s'est déjà produit aux US, qui ne sont pourtant pas des grands fans de l'État.
«Nul n'est censé ignorer la loi» (puisque je crois que c'est à ça que tu fais allusion), ça ne concerne que le pénal (meurtres, viols, toussa), pas le reste. Il n'y a aucune «obligation» de connaître les lois, encore moins exhaustive (et heureusement). Il faut juste savoir ce qui est interdit pénalement, ce qui me semble être le minimum dans une société civilisée.
Ne faisant pas de python, chaque fois que je regarde du code python, j'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?
La lib QtCore fait entre 2 et 3 fois la taille de la GLib, sans compter qu'intégrer une lib C++ dans une lib C c'est moins évident que l'inverse.
Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M.
Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject, tous les projets cités l'utilisent. Donc GObject = 309K.
Et bien tu vois, entre l'un et l'autre, honnêtement, il n'y a pas tant de différence. Il y aurait un facteur 10, je dis pas, on pourrait critiquer, mais là, moins de 3, ça va pas chercher très loin, on reste dans le même ordre de grandeur.
tu gères comment la dépendance circulaire, si on doit jouer au zero sum entre GLib et QtCore ?
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre. Et un projet peut utiliser soit l'une, soit l'autre.
GStreamer est le seul framework multimédia potable sous *nix
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là. Les dev GNOME ne jurent que par GStreamer qui n'a jamais été massivement adopté pour des raisons à la fois de non-stabilité (comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques) et de non compatibilité de l'API entre la 0.8 et la 0.10.
Pango n'est pas hébergé par FreeDesktop ni même utilisé par Qt ou KDE.
Il est cité comme projet fd.o sur les wikipedia fr et en. Donc il est supporté par fd.o même s'il n'est pas hébergé par fd.o. Et oui Qt avait sa propre solution (et je ne pense pas que l'un ait eu l'antériorité sur l'autre) donc KDE utilisait le truc de Qt. Mais il se trouve qu'un nouveau projet est arrivé pour unifier tout ça : HarfBuzz. Attendons de voir ce que ça donnera.
Par ailleurs, GStreamer est né en dehors de GNOME et a une vie indépendamment de celui-ci.
Ha ça c'est sûr, tout le monde en est convaincu : d'ailleurs, si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy), GStreamer est utilisé par GNOME depuis 2002 (alors que seuls quelques applis KDE l'ont utilisé : Juk et Amarok (même si tout le monde utilisait le backend Xine d'Amarok pour les raisons cités précédemment)), et même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME. Vraiment, là, c'était trop gros, ça ne passe pas.
Forcément, si les mecs de KDE croient que pour balancer une spécification, suffit de balancer une implémentation complète puis de faire un plébiscite
C'est marrant, tu dis plus haut qu'une dépendance à la GLib, c'est pas grave, mais une dépendance à Qt Core (l'équivalent de GLib en somme), c'est inacceptable. Pourtant, quand on regarde de près, c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre. D'ailleurs, on constatera que dans les dépendances de KDE, il y a GLib mais dans les dépendances de GNOME, point de Qt Core. Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.
Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango. L'un comme l'autre ont été imposé par GNOME. GStreamer étant la solution son de GNOME, et Pango étant la solution de rendu de fontes (issue à la base de Gtk si je me souviens bien, qui est quand même le concurrent de Qt Gui). Les deux, en plus de la GLib, se traîne GObject ! On pourrait aussi citer PolicyKit ou DeviceKit ou encore le vénérable HAL. Tous sont dans ce cas d'utiliser GLib+GObject. Hormis Pango (pour lequel il existe un équivalent dans Qt), KDE n'a jamais refusé d'intégrer ces composants développés par RedHat pour la plupart et donc avec GNOME en tête.
Dans le cas présent, pour une fois, c'est KDE qui propose la première implémentation. Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues. Ça va de "ça ne nous intéressait pas" (contredit plus loin par "on l'a mis dans GNOME Shell") à "ça s'est fait sans nous" (alors que aseigo montre que KDE a pris en compte les remarques venant de GNOME). Bref, que des justifications très égocentriques.
[^] # Re: Utilité
Posté par rewind (Mastodon) . En réponse au journal Unicode. Évalué à 10.
Tu confonds plein de choses... Unicode a travaillé pendant des années pour que des concepts auparavant fortement liés soient maintenant indépendants. Ces concepts (que tu mélanges), c'est :
Auparavant, tout était mélangé, comme le montre la fameuse police Symbol évoqué plus haut. Maintenant, c'est beaucoup plus clair et c'est tant mieux. Donc le problème de comment afficher un caractère unicode ne dépend ni du caractère, ni de l'encodage, mais uniquement du système de polices de caractère.
[^] # Re: fog22... ou pas
Posté par rewind (Mastodon) . En réponse au journal "Linux a bien du retard ...". Évalué à 3.
Avec Mickael Vendetta, Steevy Boulay, Cindy Sanders, j'en passe et des meilleurs, la France est également une championne dans ce domaine !
[^] # Re: IR
Posté par rewind (Mastodon) . En réponse à la dépêche LLVM 2.9 !. Évalué à 5.
Comme l'ont déjà dit d'autres, la spécificité de LLVM est que cette représentation intermédiaire est bien spécifié (il suffit de cliquer sur le lien). Et c'est même plus que ça, c'est un langage assembleur à part entière qui peut être utilisé tel quel. Est-ce qu'on a la même chose pour GCC ? Non (et c'est bien dommage à mon sens). Et même, je dirais qu'aucune machine virtuelle que je connaisse ne permet de coder directement en "assembleur" aussi facilement.
Quand au troll sur la licence, on ne peut contester que LLVM est utilisé en partie à cause de ça. Maintenant, est-ce que ça change quoi que ce soit au reste, c'est-à-dire aux vrais arguments techniques ? Non, absolument pas. En tout cas, pour ma part, je m'y intéresse pour ses qualités techniques, et pas à cause de sa licence. Je suis un libriste tendance RMS, et ça ne me dérangerait absolument pas que LLVM soit GPL. Ce n'est pas le cas, ce n'est pas grave, c'est compatible GPL quand même.
[^] # Re: Edition de commentaire
Posté par rewind (Mastodon) . En réponse à la dépêche Ça continue d'avancer LinuxFr.org en Rails. Évalué à 10.
Ou alors, laissez la possibilité d'éditer uniquement pour les commentaires qui n'ont pas de réponses.
[^] # Re: Et les autres?
Posté par rewind (Mastodon) . En réponse à la dépêche /run or not /run. Évalué à 2.
Ma Debian serait une petite distribution sans envergure, je ne dis pas. Mais on parle là d'une des distributions les plus utilisées au niveau serveur. Alors je veux que ça ait un sens, mais je ne suis pas sûr que sa méthode pour y parvenir soit très bonne.
[^] # Re: Et les autres?
Posté par rewind (Mastodon) . En réponse à la dépêche /run or not /run. Évalué à 8.
Ouais enfin, c'est quand un peu con de ne pas gérer un /usr sur une partition différente. Cette configuration est quand même la norme sur des serveurs, donc la gérer me semble être le minimum pour ne pas se foutre de la gueule des gens.
D'ailleurs, on constate aussi qu'il ne gère pas un /etc/mtab qui n'est pas un lien sur /proc/self/mounts. Or sur ma Debian, ce n'est pas un lien...
Il fait un logiciel pour qui ce gars ? Lui tout-seul ?
[^] # Re: Darwin vs diversité
Posté par rewind (Mastodon) . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 10.
D'un autre côté, on se plaint depuis des années que X est (très) en retard. Pour rattrapper le retard, il va falloir casser certaines compatibilités (et certaines susceptibilités). Si on attend que Fltk se soit mis à jour, on n'est pas sorti de l'auberge. Quand il n'y aura plus qu'à porter les "petits", je pense qu'on aura gagné.
# Une capture d'écran ?
Posté par rewind (Mastodon) . En réponse à la dépêche Project Bossanova. Évalué à 3.
On ne pourrait pas avoir une capture d'écran du jeu pour se faire une idée plus précise ?
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Un tri... Sur un tableau, on a tendance à trier le contenu (trier les indices n'a pas grand intérêt), alors que sur une map, on triera plutôt selon les clefs (quand ça a un sens, ce qui n'est pas gagné).
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 3.
Un langage pour les gouverner tous... ça n'existe pas !
Que les tableaux et les maps (et les chaines de caractères) soient intégrés dans un langage de script, ça ne me choque pas, au contraire, je dirais que ça simplifie la vie. Mais que ce soit intégré dans un langage bas niveau comme le C ou comme veut l'être Go, non merci. Quand on utilise un langage bas niveau, c'est pour pouvoir tout contrôler et optimiser là où il faut. Un join sur un tableau de string, ça peut très bien se faire en C de manière très optimisée, sans doute bien plus rapidement que n'importe quel langage qui intègrerait tout.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
Bienvenue dans PHP ! Et tout codeur PHP sait tous les problèmes que ce genre de considération peut poser. Un tableau et une map, ce n'est pas la même chose. Ils n'ont pas la même utilité. Et on peut tout à fait les mettre les deux dans un langage sans les fusionner. Ce qui permettra d'optimiser certaines opérations suivant qu'on a un tableau ou une map.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
De même, les templates C++ sont équivalents aux interfaces Go, sauf qu'on ne déclare pas l'interface, on utilise des méthodes d'un type et on peut instancier le template avec n'importe quel type qui implémente les méthodes. La définition des interfaces devaient être incluses dans le nouveau C++ sous le nom de concept mais a été annulé.
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 10.
Non, tu n'es pas seul. Je trouve sa syntaxe vraiment bizarre. Il y a plein de choses que j'aime pas, notamment
make, l'omission des parenthèses (autour de la condition duifpar exemple) qui rendent le code difficilement compréhensible, la différence array/slice, le mélange entre pointeurs et références cachés (comme lesmap) qui fait que suivant le truc, l'argument est passé par valeur ou par référence, legoto, la précédence des opérateurs simpliste qui fait que3 * 2 << 2n'est pas égal à2 << 2 * 3(alors que dans la plupart des autres langages, c'est le cas)...Bref, beaucoup d'inconvénients pour peu d'avantages (pour moi, un gc n'est pas un avantage).
# Dans le même ordre d'idée
Posté par rewind (Mastodon) . En réponse à l’entrée du suivi Autoriser la suppression de tags. Évalué à 2 (+0/-0).
Sur Jamendo, les tags étaient assez bien gérés (je ne sais pas si c'est toujours comme ça). En gros, on pouvait ajouter un tag avec "+tag" et on pouvait en retirer avec "-tag". Si le tag était présent, ça lui donnait plus de poids ou ça lui enlevait du poids (jusqu'à disparaître). Du coup, le système convergeait assez bien vers un consensus.
[^] # Re: Par pitie
Posté par rewind (Mastodon) . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 3.
Diviser pour régner
http://fr.wikipedia.org/wiki/Diviser_pour_r%C3%A9gner_%28informatique%29
[^] # Re: XHTML ?
Posté par rewind (Mastodon) . En réponse au journal IE9. Évalué à 4.
Oui c'est bien ce que je dis. HTML5, c'est défini comme du XHTML5 écrit avec les pieds mais tout le monde doit avoir la même déformation des pieds (n'y voyez aucune allusion à GNOME), comme ça les navigateurs qui corrigeait pas de la même manière avant vont maintenant tous faire la même chose.
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#parsing
[^] # Re: XHTML ?
Posté par rewind (Mastodon) . En réponse au journal IE9. Évalué à 5.
XHTML n'est pas mort, juste le nom. HTML5, c'est un dialecte XML comme les autres, avec en plus une normalisation pour ceux qui savent pas fermer des balises pour que tous les navigateurs "corrigent" de la même manière.
[^] # Re: Justice ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 2.
Sur Wikipedia (Loi) : «Adage (non légal) qui ne signifie pas que l'on doit connaître l'ensemble des lois, mais selon lequel on ne peut invoquer l'ignorance de la loi pour échapper à la loi.»
Plus d'informations : http://www.vie-publique.fr/decouverte-institutions/citoyen/citoyennete/definition/devoirs-definition/que-signifie-nul-n-est-cense-ignorer-loi.html
[^] # Re: Concurrence déloyale ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 2.
Ce que tu dis est vrai selon ta vision où il n'existe que des contrats entre entités économiques privées (et, sous-entendu, peu de lois pour réguler). Malheureusement pour toi, il y a aussi l'État qui peut fourrer son nez dedans et obliger MS à faire autre chose. Et tu le sais parfaitement puisque ça s'est déjà produit aux US, qui ne sont pourtant pas des grands fans de l'État.
[^] # Re: Justice ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 5.
«Nul n'est censé ignorer la loi» (puisque je crois que c'est à ça que tu fais allusion), ça ne concerne que le pénal (meurtres, viols, toussa), pas le reste. Il n'y a aucune «obligation» de connaître les lois, encore moins exhaustive (et heureusement). Il faut juste savoir ce qui est interdit pénalement, ce qui me semble être le minimum dans une société civilisée.
[^] # Re: Et hop !
Posté par rewind (Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 2.
Stack overflow
# Nommage dans python
Posté par rewind (Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 7.
Ne faisant pas de python, chaque fois que je regarde du code python, j'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 5.
Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M. Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject, tous les projets cités l'utilisent. Donc GObject = 309K. Et bien tu vois, entre l'un et l'autre, honnêtement, il n'y a pas tant de différence. Il y aurait un facteur 10, je dis pas, on pourrait critiquer, mais là, moins de 3, ça va pas chercher très loin, on reste dans le même ordre de grandeur.
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre. Et un projet peut utiliser soit l'une, soit l'autre.
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là. Les dev GNOME ne jurent que par GStreamer qui n'a jamais été massivement adopté pour des raisons à la fois de non-stabilité (comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques) et de non compatibilité de l'API entre la 0.8 et la 0.10.
Il est cité comme projet fd.o sur les wikipedia fr et en. Donc il est supporté par fd.o même s'il n'est pas hébergé par fd.o. Et oui Qt avait sa propre solution (et je ne pense pas que l'un ait eu l'antériorité sur l'autre) donc KDE utilisait le truc de Qt. Mais il se trouve qu'un nouveau projet est arrivé pour unifier tout ça : HarfBuzz. Attendons de voir ce que ça donnera.
Ha ça c'est sûr, tout le monde en est convaincu : d'ailleurs, si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy), GStreamer est utilisé par GNOME depuis 2002 (alors que seuls quelques applis KDE l'ont utilisé : Juk et Amarok (même si tout le monde utilisait le backend Xine d'Amarok pour les raisons cités précédemment)), et même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME. Vraiment, là, c'était trop gros, ça ne passe pas.
Tu veux dire "faire comme les devs GNOME" ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 10.
C'est marrant, tu dis plus haut qu'une dépendance à la GLib, c'est pas grave, mais une dépendance à Qt Core (l'équivalent de GLib en somme), c'est inacceptable. Pourtant, quand on regarde de près, c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre. D'ailleurs, on constatera que dans les dépendances de KDE, il y a GLib mais dans les dépendances de GNOME, point de Qt Core. Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.
Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango. L'un comme l'autre ont été imposé par GNOME. GStreamer étant la solution son de GNOME, et Pango étant la solution de rendu de fontes (issue à la base de Gtk si je me souviens bien, qui est quand même le concurrent de Qt Gui). Les deux, en plus de la GLib, se traîne GObject ! On pourrait aussi citer PolicyKit ou DeviceKit ou encore le vénérable HAL. Tous sont dans ce cas d'utiliser GLib+GObject. Hormis Pango (pour lequel il existe un équivalent dans Qt), KDE n'a jamais refusé d'intégrer ces composants développés par RedHat pour la plupart et donc avec GNOME en tête.
Dans le cas présent, pour une fois, c'est KDE qui propose la première implémentation. Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues. Ça va de "ça ne nous intéressait pas" (contredit plus loin par "on l'a mis dans GNOME Shell") à "ça s'est fait sans nous" (alors que aseigo montre que KDE a pris en compte les remarques venant de GNOME). Bref, que des justifications très égocentriques.