reno a écrit 3886 commentaires

oui enfin y a pas que pour systemd que ça serait bénéfique.

Ça tombe bien, il ne semble pas avoir suggéré ça.

On peut mettre beaucoup de chose sur le dos de systemd mais faut pas tout mélanger non plus.

Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.

Oui enfin ça n'a pas l'air de déplaire les développeurs emblématiques de Linux car ils y participent eux mêmes!

Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.

Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..

Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..

Mais une "partie de systemd" va être dans le noyau: KDBUS, pour améliorer les perfs et la sécurité.

N'importe quoi.. Je remarque qu'on ne voit ou sont les boutons dans le style flat (il n'y a pas suffisamment de distinction entre le texte et les élements actifs menus/boutons) et tu me parles des panneaux de circulations qui n'ont pas de boutons, de menus donc comme contre exemple..

L'ésthétique (et non L'ésthétisme, barbare d'auteur) qui n'est ici, en passant, pas défini - participe de l'ergonomie.

Faux, ça peut être le cas mais au contraire il arrive que l'esthétique prime sur l'ergonomie: cas d'école le design flat si a la mode actuellement: on ne voit pas ou sont les boutons, du point de vue ergonomie c'est très mauvais..

Sa présence empêche la vectorisation automatique

Ce n'est pas la première fois que je lie ça donc j'imagine que ça doit être vrai, bon je trouve ça plutôt surprenant: la vectorisation 'automatique' c'est plutôt pour des boucles très régulières et dans ces cas là un compilateur intelligent (comme tu en donne un exemple) n'a même pas besoin d'introduire des check..

Ah oui, je me suis loupé aussi, mince!
Merci de m'avoir corriger.

Ça c'est une réactions aux vidéos de Jonathan Blow sur Jai.
Pas mal, mais dans Jai, tu peux avoir un pointeur sur un objet que tu change de SOA à AOS (ou vice versa) sans modifier le code et je ne crois pas que ça soit le cas ici, je vais essayer d'avoir + d'infos..

Tu réponds trop vite à Enj0lras.
Pour s'assurer qu'un index non-signé est valide pour un accès à un tableau,
c'est une opération: index < longueur.

Pour s'assurer qu'un index signé est valide pour un accès à un tableau,
c'est deux opérations: index < longueur ET index >= 0.

Un avis sur phoronix d'un propriétaire d'Odroid C1:
http://www.phoronix.com/forums/showthread.php?113338-Raspberry-Pi-2-Launches-With-Quad-Core-ARM-SoC&p=468097#post468097
Pas très élogieux..
Le C1 a un connecteur 'direct' Ethernet pas par USB, mais si ça marche aussi uniquement en 100Mbs, est-ce que c'est plus intéressant que le Raspberry Pi? Je ne sais pas, il faudrait mesurer: débit atteint, utilisation CPU..

J'ai lu sur un blog que c'était pour minimiser les risques liés aux changements, mais effectivement c'est dommage..

Merci pour ta réponse, en effet il faut connaître l'ordre pour la version simple, ça m'apprendra de survoler le PDF trop rapidement.

Non PAS "à vouloir chercher la performance"!

En pseudo-assembleur, la version 'sophistiquée':
xor Rx,Ry -> R1
and Rx,Ry -> R2
ushr R1,1 -> R1
add R1,R2 -> R1
4 instructions a décoder, 2 registres temporaires utilisés.

La version simple:
sub Ry,Rx -> R1
ushr R1,1 -> R1
add Rx,R1 -> R1
3 instructions a décoder, 1 registre temporaire utilisé.

Après ça peut dépendre du CPU..

Merci pour le lien, mais note que la version que je donne y est aussi dans le même chapitre 'x + (y - x)/2' ou
'x + ((y - x)>>1)' bonnet blanc et blanc bonnet..

La version '(x & y ) + ((x ^ y) >> 1)' ne s'exécute en 3 cycles que si tu peux faire 2 opérations en parallèle, donc dire que c'est mieux que 'x + ((y-x)>>1)', hum, d'un point de vue en mettre plein la vue ok, mais sinon pas vraiment non..

Et bien dans pas mal de langage si (a + b) dépasse l'entier maximum alors le résultat est indéfini ou tu as une exception, alors qu'avec (si a < b) milieu = a + (b - a)/2 il n'y a pas ce problème.

PS: Si a et b sont entiers alors ta formule (a + b)/2.0 est incorrecte: a + b a une valeur indéfinie AVANT la conversion en flottant, il aurait fallu écrire ((double)a + b)/2.0
et personnellement je n'aime pas l'utilisation des flottants pour des calculs entiers, c'est une source de bug bien vicieux.

Tu as probablement raison, mais je me souviens d'un livre ou un algorithme prouvé 'semi formellement' avait la perle suivant:
milieu de a,b = (a+b)/2.
J'avoue que quand j'ai vu ça j'étais mort de rire..

Well, I'm afraid that it all much too technical for me but thanks for your nice comment.
I didn't know that there were new formulation of QM under research.

Plus simple a utiliser..
Peut-être mais à titre personnel (et à mon grand regret) après avoir essayé de suivre des tutoriels sur Idris, ça me reste toujours hors de portée(1)!
Donc attention à ne pas sur-vendre non plus: programmer avec des preuve formelle ça reste beaucoup plus compliqué que programmer 'normalement'..

Après ce n'est pas une critique d'Idris ou des preuves formelles.

1: ou plus exactement quand je vois les efforts nécessaire rien que pour prouver des trucs simple, je n'en vois pas l'intérêt: je ne suis pas employé par Airbus..

Et bien c'est un peu agaçant de voire des réponses où l'auteur n'a pas lu le poste..

Personnellement je ne pense pas que les gc posent vraiment problème.

Ça c'est de l'assertion! Parles en aux développeurs qui font des jeux: 60 images/sec (16ms par image), ça va les intéresser..
Personnellement je travaille sur des générateurs réseaux et l'idée d'avoir un GC qui me rajoute des latences aléatoires, beurk..

Pas étonnant:
-Le C est simple a coder car le compilateur te laisse faire n'importe quoi, à débugger par contre..

-Ocaml et les autres langages fonctionnels ont un GC, ce qui simplifie beaucoup la programmation, mais tu en paye le prix à l'exécution..

Ton poste me laisse penser que tu n'as pas bien lu ce qu'on a marqué..

Un exemple, si tu marque "let maVar = 5;" il faut choisir le type entier pour maVar (i32 maintenant), autrement tu peux imposer a l'utilisateur de spécifier toujours la taille du type mais ça devient rapidement lourd..

Toi y en a comprendre?

Tu as un lien vers ce standard ?

Je n'ai pas de lien vers un standard Rust et j'ignore si ça existe ou pas, voici la discussion sur le comportement des entiers: http://www.reddit.com/r/rust/comments/2q40k2/a_tale_of_twos_complement/
le renommage int->size a eu lieu ensuite.

Et pour ce qui est de gcc, -ftrapv est réputé comme buggé
T’as un lien là-dessus ?

Le deuxième résultat de google sur ftrapv:
http://stackoverflow.com/questions/20851061/how-to-make-gcc-ftrapv-work

Bon il ne faut pas confondre spec et implémentation, maintenant comme le comportement de Rust inclue le trap par débordement par défaut (en mode non release), logiquement cela devrait être bien tester..

Mouais, l'intérêt de standardiser un comportement indéfini me semble relativement limité

L'intérêt est que quand ça arrive, ça devient beaucoup plus simple a débugger car en C/C++ comme le compilateur est libre de faire tout ce qu'il veut s'il sait une branche de code contient un comportement indéfini et ça peut être très, très compliqué a débugger..

En Rust, avoir une valeur indéfinie et non pas le comportement du programme indéfini simplifie le debugging au prix d'une faible perte de performance.

Et j'ignore pourquoi tu parles du comportement "modulo" ça c'était avant..

PS: il y a bien sûr des entiers avec le comportement "modulo" en Rust (Wrapped je crois) mais le problème est le comportement des entiers "normaux".