Antoine a écrit 5722 commentaires

J'ai vraiment l'impression qu'on nous a donné un truc qui ne nous sert à rien avec ce paragraphe.

Bien sûr que si, ça sert à ce que l'APRIL fasse un communiqué de presse.

Et que cette personne a une réputation assez sulfureuse.

On me souffle qu'il dit "Linux" à la place de "GNU/Linux" et "propriétaire" à la part de "privatisativeur"...
Mazette !

Enfin, Subversion sera vraisemblablement le dernier centralisé développé en libre (c'est la fin d'un modèle).

Surtout qu'il est trivial d'utilisé un système décentralisé de façon centralisée. Qui peut le plus peut le moins.

Hmm, rpmdrake a été tellement « enhancé » qu'il ne se lance même plus. Deux mois que ça dure, un peu gênant :-/

https://qa.mandriva.com/show_bug.cgi?id=37132

Par exemple : le suivi par « changeset », concrètement, ça donne quoi ? Quand est-ce un avantage par rapport à un suivi par fichier ? N'est-ce pas là une application logicielle d'une méthode de travail qu'on pourrait très bien appliquer sous SVN ?

SVN fonctionne déjà par « changeset » sauf que le terme utilisé est révision.

Pourquoi?

Probablement parce que les faibles performances de la puce n'apportent aucun intérêt de ce côté-là.

Solipsis étant un projet logiciel libre en GPL v2+, le code sera disponible en mars prochain.

Il me semble qu'à une époque (je ne suis pas trop mal placé pour m'en souvenir :-)), le code était dispo en permanence sur un SVN avec une mailing-list publique de développement. Des raisons à cette régression ?

Donc que firefox lise mal des sites pourris (ce qui est le cas) c'est une chose

Non, c'est la même chose.
C'est stérile de critiquer MS qui cherche à soigner ses utilisateurs, et de dédouaner Mozilla qui a exactement les mêmes pratiques (alors que justement il leur serait plus facile de dire "c'est pas nous, c'est l'autre, on ne veut pas supporter ses conneries").

comme moi j'ai un cerveau
[...]
tu as des excréments de poulpe dans la tête
[...]
et d'ailleurs de la part d'un cuistre

Je vois, c'est un point de vue intéressant. Et sur UML, ton cerveau a quelque chose à nous dire ou il est trop occupé à traquer les excréments de pouple sur Internet ? :-)

je saurais pas que Ketitomi veut dire tir en rafale mais si je le vois hériter de Tomi il y aura une relation que j'aurais perdu si je n'avais que du baratin en japonais.

Et ça te fait une belle jambe de connaître la relation entre deux concepts que tu ne comprends pas, hein ?

même les gens que tu cites. je les crois assez intelligents pour décider de s'en servir s'ils en éprouvent le besoin, toi pas, c'est triste.

Magnifique, le passage à l'insulte par manque d'arguments. La prochaine fois, va te détendre un peu avant de répondre, merci.

1) Je te signale qu'on a actuellement un président d'origine hongroise.
2) "D'origine noire", ça ne veut rien dire. "Noir" n'est pas une nationalité : on est noir ou on ne l'est pas.
3) Ce n'est pas parce que Sarkozy est au pouvoir que n'importe quel citoyen français est complice de son élection et doit en éprouver de la honte ou du remords.

Quant à dire "Obama est bien parti" à un an de l'échéance, c'est comme les gens qui prédisaient l'élection de Delors ou de Jospin à la présidence. On verra bien...

tu crois que je fais de l'UML pour des gruikeries, de l'assembleur, des bouts de 10 lignes en php ou perl ou sed ou autre prototype en C que je jetterais ensuite si je me dis finalement non

Ce genre de remarque implique qu'a contrario UML est nécessaire pour "modéliser" de gros programmes, ce qui est faux.

dans UML il y a des diagrammes de classes. tes Linus Torvalds et Dennis Ritchie ne risquent pas de les utiliser - d'en avoir besoin - tant qu'ils feront du C ou autre langage sans classes (ou objets).

N'importe quoi, il peut très bien y avoir des notions sémantiques de type objet dans des programmes codés en C. Regarde gobject ou CPython (l'interpréteur Python) pour des exemples évidents.
De manière générale, quand on code en C proprement, on définit des structures de données (référençant elles-mêmes d'autres structures) et des fonctions qui agissent sur ces structures, il n'est pas difficile d'y voir un modèle objet sous-jacent, même rudimentaire.

quand à ton langage naturel, si je dois lire du japonais pour ça, merci du cadeau. (cas rencontrés pour les langages Ruby et D, par exemple). là, les petits dessins ça va aider.

Si tes petits dessins sont annotés en japonais, ça ne va franchement pas t'aider, non.

Donc il suffit de se faire passer pour un éditeur WYSIWYG en ajoutant une balise <meta> ;)

Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.

Et Firefox, ils ont cassé la compatibilité avec les sites pourris peut-être ?

ça sert à se faire comprendre par d'autres informaticiens

Je ne dois donc pas être informaticien, vu que je n'ai jamais fait d'UML, que je ne le comprends même pas et que j'en m'en tamponne joyeusement :-)

Me demande si Linus Torvalds et Dennis Ritchie comprennent et utilisent l'UML, tiens... Le standard pour se faire comprendre entre informaticiens, mis à part le code lui-même, ça reste tout de même le langage naturel.

si les méthodes étaient des objets comme en python, je dis pas, mais ce n'est pas le cas.

Ben, justement, les méthodes n'étant pas des objets, c'est un pis-aller qui vaut toujours mieux que rien.

Et puis c'est le meilleur moyen d'obfusquer le nom d'une méthode à coup de str_replace et autres

Tu peux obfusquer du code dans n'importe quel langage, même Python.

La plupart de nos web design sont intimement liés au système, et demande parfois des modifications drastiques de code de configurations... J'ai déjà du mal à retenir un langage, ces modules, les finesses des interpréteurs, les conf du brouteurs web, troubleshooter les virtualisations, les architectures n-tiers, les reverses proxy, les proxy authentifiants ....

C'est parce que tu es solution-driven et process-oriented !

ca évite de faire des trucs dégeus comme $this->$method() où tu te retrouves à te battre pour trouver quelle est la vraie méthode appelée

"Se battre" ? C'est une blague ? Où est le problème exactement ?
PHP est une grosse daube, mais la possibilité de faire ce genre d'indirection est un des rares bons points du langage.

Donc la classe std::string ne contient pas énormément de fonctions, il faut regarder du côtés de fonctions et fonctors de la stl.

C'est ridicule comme justification, une chaîne de caractères n'est pas un conteneur comme les autres et ne mérite pas les mêmes méthodes que, disons, une liste ou une table hash. Voilà ce qui arrive quand on généralise à outrance selon de vagues caractéristiques communes ("foolish consistency is the hobgoblin of little minds").

La c'est de l'imperatif tout ballot, pas de l'objet.

J'adore les gens qui se pincent le nez face à l'« impératif tout ballot ». On dirait les membres d'une église qui ont appris le dogme par coeur. La faiblesse de C++ n'a rien à voir avec ce genre de soi-disant défauts.

mais certains compilateurs nomment encore les fichiers comme ça quand aucun nom n'est donné par l'utilisateur

Dont gcc, qui est quand même le compilateur par défaut sous Linux !
Résultat de la compilation par gcc d'un source bidon :

$ gcc toto.c
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

Beaucoup de contre-vérités...

Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.

Il n'y a pas d'accès bus externe puisque la pile locale reste presque toujours quelque part dans le cache L1. Je ne dis pas que l'amélioration est inexistante (un adressage de registre est toujours plus léger qu'un adressage indirect) mais c'est loin d'être "une très grande différence".

Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique.

Faux, non seulement on pouvait déjà transférer des données sur 64 bits (en utilisant par exemple les registres MMX qui sont présents sur tous les CPU depuis dix ans), mais en plus les transferts mémoires sont limités par la bande passante externe du CPU, qui est minuscule par rapport à la puissance de traitement disponible au coeur du CPU.

Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits

C'est déjà le cas depuis le Pentium (depuis 1995 !).

Les "double" tiennent enfin, à nouveau, sur un seul registre.

Encore faux. Les "double" ont toujours tenu sur un seul registre, puisqu'ils ont toujours eu des registres dédiés au sein de l'unité de calcul à virgule flottante (en tout cas depuis que cette dernière existe, c'est-à-dire bien longtemps).

Le double a une mantisse beaucoup plus large pour le même prix.

Le même prix ? C'est vite dit. Il prend deux fois plus de place en mémoire, ce qui n'est pas très gênant certes, mais surtout les opérations effectuées sur les double sont plus lourdes que sur les float, ce qui fait que la plupart des CPU peuvent en exécuter moins par cycle.

Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.

Encore faux, seuls les pointeurs doublent de taille, les entiers selon les cas restent sur 32 bits (int) ou passent à 64 (long), quand aux flottants leur taille est inchangée comme expliqué plus haut.

C'est quoi cette mode de mettre des GC partout ? Un GC n'est pas la réponse à tout, loin de là...

Non, mais c'est la plupart du temps une bonne réponse au problème de la gestion mémoire des objets alloués.

par défaut, il vaut mieux savoir désallouer ce que tu as alloué

La source de bugs en général ce n'est pas "comment désallouer" mais "quand désallouer"...

En même temps, je ne sais pas s'ils ont fini par améliorer les choses et fournir une stdlib digne de ce nom, mais les std::string c'est juste une surcouche assez pauvre au-dessus d'un char* (et quand je faisais du C++ je devais régulièrement reprendre ce char* pour faire des opérations sur les chaînes, à cause de la merdicité absolue de l'API std::string).

la gestion des références de GObject permet déjà d'avoir une gestion de la mémoire bien plus souple qu'en C de base. Vala gère ces références automatiquement (bien que tout reste paramétrable) et fait donc des appels aux destructeurs correctement.

Au fait, il est capable de casser les cycles de références ?