lasher a écrit 2731 commentaires

L'armée a aussi permis de recadrer des gens qui étaient aussi très très mal partis. Ça m'énerve de devoir « défendre » l'armée, parce que je n'en suis pas spécialement friand, mais il faut quand même accepter le fait qu'elle a un rôle à jouer de nos jours. Le rôle d'un soldat n'est pas de faire la guerre, mais d'y mettre fin. Le rôle de l'armée est de protéger une nation contre des menaces extérieures.

Dans l'idéal, j'aimerais ne pas en avoir besoin, et le fait que justement son rôle se « socialise » en temps de paix montre me donne l'espoir qu'avec le temps le besoin d'une armée se fera de moins en moins sentir.

Pour rappel, la gendarmerie, c'est l'armée. Les pompiers parisiens sont tous militaires. Une bonne partie du rôle de l'armée en temps de paix ne se borne pas à préparer la guerre.

Non, c'est ce qui fait que certains langages me rebutent, ou pas.

Je code de façon consistante en C et Perl, je suis en train d'apprendre Ruby (après un bref essai pour Python). Ce que j'aime en Perl & Ruby, c'est la possibilité d'utiliser l'implicite quand ça permet de simplifier la lecture. Mais ça n'empêche pas de devoir se discipliner. En C il est tout à fait possible d'écrire des horreurs aussi, et pourtant tout appel de fonction doit bien être suivi de parenthèses ...

Oh ben oui, l'armée ne sert qu'à tuer des gens, c'est bien connu.

Plus exactement, Linux Magazine, tu parles duquel ? Y'a un site web ? Juste sur papier ? tout ça, tout ça.

T'as pas oublié de citer tes sources ... ?

« Ca vient aussi de la méthode d'apprentissage de la lecture : la méthode globale, on retient un mot, une phrase par coeur, mais une fois le mot hors contexte on n'est incapable de le lire. J'ai vu beaucoup de jeunes lire sans problème certains livres car ils connaissaient les phrases par coeur, pas parce qu'ils savaient lire (les même mots dans d'autres phrases, ils ne savent pas les lire)... »

Hé, faut se renseigner un peu, la méthode globale ça fait un bon moment que c'est plus enseigné dans les écoles (ie au moins 20 ans). Faudra trouver une autre raison pour la modification de l'orthographe. De nos jours on emploie une méthode plus ou moins mixte (et soyons honnêtes, la méthodes purement phonétique marche très bien, mais pas avec tout le monde, et ce « pas avec tout le monde » n'est pas forcément très faible en quantité).

J'en ai une toute bête à proposer : quand il y a plus de 10 ans je découvrais les BBS et autres machins via les réseaux, quand je discutais avec des gens, je n'avais pas ma vitesse de frappe actuelle. Du coup pour pouvoir communiquer à une vitesse raisonnable j'ai ... utilisé une écriture phonétique (certes, je restais « cohérent » : 'k' => 'qu', 'f' => 'ph', etc.). La grosse différence, c'est qu'à l'époque il y avait assez peu de gens avec un accès au net et surtout qui faisaient de l'IRC ou autres machins du même genre, et du coup par émulation on apprenait peut-être un peu plus à faire un effort sur l'écriture. De nos jours on a un accès massif aux réseaux par tout le monde. Il y a peut-être une « émulation inverse », vu que maintenant on a beaucoup d'ados/jeunes adultes ayant grandi avec le net qui ont des interlocuteurs possédant les mêmes « travers ». Cette explication est peut-être bidon, mais me satisfait bien plus que de blâmer une énième fois l'école et son mode d'apprentissage de la lecture.

Avant je ne sais pas, mais depuis au moins ffx 3, ils utilisent jemalloc [1], qui a été créé pour FreeBSD.

[1] http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemall(...)

Il y a aussi le cas de l'embarqué, du calcul intensif/haute performance ... Bref tous les cas où les ressources sont considérées comme « rares » ou critiques.

Je suis bien d'accord, et ce concept de « démocratie », c'est franchement has-been. Je veux dire, bon, on a un chef pour la France, ok ? Puisqu'on en a un, on le garde, à vie s'il le faut. Parce que bon, c'est le chef, et il gueule plus fort que tous les autres (en plus il a plein d'autres chefs comme amis, ça montre bien qu'il sait de quoi il parle).

Moi je dis, une fois qu'on a élu un président, il faudrait que l'opposition soit dissoute, parce que bon, elle a perdu, donc elle a plus qu'à fermer sa gueule. Ben ouais, elle avait qu'à gagner.

Et pourquoi dans des cas aussi simples ne pas faire de warning pour avertir, sans optimiser?

Parce que la plupart du temps le compilateur a raison de supprimer le code. Sauf quand il a tort. Il ne va pas faire un warning pour chaque boucle simple qu'il optimise, sinon on est pas rendu (mais on peut lui dire de générer un rapport si on veut savoir ce qu'il a fait ...). Dans le cas de la fonction qui agit sur un mot de passe, je dirais que 9 fois sur 10, le memset est réellement inutile car il ne s'agit pas de code ni de données sensibles.

Est-ce car les cas réels ne sont pas aussi simples?
Je me sers d'une boucle à peine plus compliquée que la première donnée pour faire des micro-benchmarks (j'accumule dans une variable acc que j'affecte ensuite à un pointeur pacc pour empêcher le compilateur de supprimer le code).

Concernant le deuxième exemple, je l'ai emprunté à Marc Espie, qui s'en servait sur fr.comp.lang.c pour donner un exemple de suppression automagique (car memset est une fonction standard, donc le compilateur « sait » comment elle fonctionne, quand il peut se permettre de la virer, etc.) de code de la part de gcc. C'est un « vrai » code dans le sens où je pense qu'il est légitime de vouloir nettoyer la mémoire quand on est un peu obsédé niveau sécurité.

Dans la vraie vie, avec des codes réels, il y a plein de cas où le compilateur supprime avec raison tout un tas de trucs en se disant « au final c'est pareil ». Sauf quand c'est pas vrai.

source, source, source...
En fait, c'était un commentaire ironique. :)

Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.

Il ne modifie pas le comportement du programme, dans le sens où du point de vue formel, il n'a rien fait d'illégal. Voici un autre exemple, plus simple :

void dummy(double *array, size_t len) {
double acc = 0.0;
for (int i = 0; i < len; ++i)
__acc += array[i];
}

Un bon compilateur, qui optimise bien, va tout simplement supprimer la boucle (et avec l'inlining, il ne subsistera plus rien du code original). Un mec qui voudrait (par exemple) utiliser dummy() pour flusher arbitrairement la mémoire cache ne pourrait plus le faire.

Autre exemple : memset fait partie des fonctions standard du C. À ce titre, elle est donc « magique », et le compilateur peut faire un peu ce qu'il veut avec du moment que ça ne viole pas les contraintes du programme. Si par exemple je tape un code du genre (piqué à Marc Espie sur fclc)
void f() {
char passwd[250];
// code qui demande un mot de passe a l'utilisateur.
// code qui s'en sert
memset(passwd, 0, sizeof passwd);
}
Ben là, le compilateur peut dire « hé mais de toute manière, passwd est local à la fonction, donc faire un memset dessus ça prend du temps et des ressources pour rien ». Et paf, il le vire. Sauf qu'en fait, le memset était là pour éviter qu'un petit malin essaie ensuite de lire dans la zone mémoire où passwd est alloué (par exemple pour lire une ancienne valeur de passwd). Du point de vue du « sens » du programme, tout est respecté. Du point de vue sécurité, c'est une « catastrophe ».

Pour revenir au problème une correspondance privée (ce qui est le cas pour ceux qui participent à la liste de développement) ne peut pas être rendue publique sans l'accord des rédacteurs. C'est à la fois une atteinte à la vie privée au regard du droit français, et sans doute contraire au contrat d'utilisation tacite passé lors de l'inscription sur la liste.

D'ailleurs, il faut voir le nombre de journalistes qu'on a mis en examen à cause de ça ...

Enfin, je maintiens que toute correspondance technique en vue du développement ou de l'amélioration d'un logiciel peut bénéficier de la protection du code de la propriété intellectuelle.

C'est ton avis ou bien tu as des sources sérieuses pour le confirmer ?

Oh bah oui, c'est tellement « normal ». Dans la vraie vie, un codeur embauché par une boite pour programmer en flash va évidemment demander à un autre codeur en flash de lui faire son boulot pour x €. Suis-je bête, comment n'y avais-je pas pensé.

Euh pour le coup des descriptions, ça vient du fait que Les 120 journées de Sodome a été écrit en secret quand il était embastillé. En fait la première partie du bouquin est totalement narrée (par 4 mères maquerelles toutes plus moches les unes que les autres), puis la deuxième partie arrive, celle où les quatre personnages principaux se mettent à sérieusement s'amuser avec les jeunes filles et jeunes garçons qu'ils ont fait enlever (avant ça, ils leur font subir deux-trois amuse-gueules, mais interdiction de dépuceler qui que ce soit ...).

Par manque de temps, Sade a simplement décrit dans la deuxième partie du livre tout ce que les enfants subissent, mais il comptait bien les narrer avec le style qui lui est propre.

« b) Silverlight tourne sous Windows et Mac »
Sous Mac x86. J'ai un Mac PPC, et j'en connais vraiment pas mal d'autres qui sont dans mon cas (ils n'ont pas nécessairement les sous pour changer de machine).

Ben du coup, Silverlight j'oublie (tu me diras, avec mon linux/ppc, je devais déjà oublier Java et Flash ...).

Non, Darwin est un fork de FreeBSD 5.x, pas de Next. Par contre, le format des binaires, Mach-O, était bien celui utilisé pour Next. Et le noyau Mach n'était utilisé ni sur F/BSD, ni sur Next à ma connaissance (mais là je dis sans doute une bêtise).

Ben '+' == \{1,\}, '?' == \{0,1\}.

On a donc plutôt /[a-z]\{1,\}/ pour faire l'équivalent de /[a-z]+/ .

Mmmh, les programmes générés par gcj ne sont au final pas plus rapides que ceux utilisant déjà une bonne JVM.

« Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution. »

Autant sur ce troll je suis globalement avec toi, autant ta définition de machine virtuelle est selon moi totalement erronée. Tu insistes beaucoup sur le « virtuel » dans « machine virtuelle », mais tu fais totalement l'impasse sur « machine ». C'est pourtant le mot le plus important, vu qu'il s'agit du nom (et pas de l'épithète qui lui est accolé). :-) Une machine virtuelle suppose nécessairement un jeu d'instructions intermédiaire. Le C, le C++, etc., n'en proposent pas, et ne sont donc pas des langages utilisant des VM. Le fait qu'un runtime plus ou moins léger soit rajouté à un langage n'en fait pas une VM. Sinon, que penser de machins comme OpenMP, qui permet de faire du parallélisme « facile » ? Il y a des directives/pragmas de compilation, une bibliothèque proposant tout un tas de fonctions utilitaires, ainsi qu'un runtime qui réagit entre autres à la topologie de ta machine, à l'existence et la valeur de certaines variables d'environnement, etc.

Bah il faut bien avouer que le C est limité. Comment je fais pour récupérer le bit d'overflow qui apparaît de temps en temps quand je fais de la crypto, moi, hein ? :-)

Euh. LISP a fait l'expérience des premiers ramasse-miettes et autres bidules qu'on trouve désormais dans les VM. Alors certes en tant que tel le langage n'a jamais eu besoin de VM, mais en pratique, on en était déjà vraiment pas très loin (je me souviens de mon prof d'IA qui racontait avec émoi ses lundi matin, où il lançait le garbage collector sur la machine, puis passait les 3h suivantes à siroter son café et préparer son prochain programme ...)

« En fait, tu reproches au C des choses qui viennent avec des fonctionnalités qui n'existent pas avec C#, c'est débile comme argumentation! »

It's not a bug, it's a feature ? :-) Plus sérieusement, le problème de la taille des types (genre sizeof(char) == 1 d'après la norme, mais en fait, un char fait 16 bits à cause de contraintes d'alignement), ça existe depuis suffisamment longtemps pour que stdint.h ait été rajouté à C99, avec tous les types de taille fixe garantis qui vont bien. Ce n'est pas pour rien.

Plus ça va, et plus je finis par admettre que le C n'est qu'un assembleur portable. Et pourtant, je fais de gros efforts pour être conforme avec C99, mais c'est vraiment *dur*, à cause de tous les comportement indéfinis que comporte ce langage.

« oui mais aujourd'hui, il y a valgrind, et cela change tout. »
Tu supposes que tu as affaire à de bons programmeurs, capables de piger ce que sort valgrind. Honnêtement, c'est loin d'être toujours le cas ...