shbrol a écrit 487 commentaires

l'exemple montre comment se servir des shared_lock qui te permettent d'utiliser le RAII avec des mutexes. Ca permet d'eviter les problemes en cas d'exception dans le corps de la fonction, et hop on oublie le unlock()…
Et il montre aussi comment 'upgrader' un shared_lock, c'est a dire passer de shared/reader à exclusive/writer, et ceci sans unlock() au milieu (tu n'en a pas forcément besoin maintenant, mais ca va peut etre venir).
A premiere vue, tout ce qui est utilisé dans l'exemple stackoverflow utilise la norme.

Il y a de fortes chances que l'API proposée par boost soit la même que celle du futur standard.

D'apres http://en.cppreference.com/w/cpp/thread/shared_mutex, ce n'est pas dans c++11, mais c'est prévu pour c++14.

Par contre, ca existe déja chez boost il me semble.

Rhaa, c'est malin ça ! Faire la mise en prod du 'dredi le 'eudi, pour éviter le mauvais sort… bravo !

… ah, chouette, une mise en prod le 'dredi ! Vivement demain !

La même chose, indépendante du mirroir choisi, et en précisant la version suivie :

Package: *
Pin: release o=Unofficial Multimedia Packages, a=testing
Pin-Priority: 50

You are doing harm to Debian users, and it is not appreciated.

Quand on arrive a ce point dans la discussion, on peut se demander si le probleme c'est pas plutôt ces cochons d'utilisateurs, qui continuent à prendre leurs paquets multimedia chez Christian plûtot que dans les dépots officiels, avec tout le mal qu'on se donne pour eux…

En tout cas vous savez ce qu'il vous reste à faire si le dépôt debian-multimedia.org traine encore dans votre /etc/apt/sources.list.

Ca fait quand meme un moment que le dépot "debian-multimedia.org" ne répond plus, il a été remplacé par "deb-multimedia.org". Je cite la page du dépot:

10/05/2012 :
New domain name deb-multimedia.org
You must edit your /etc/apt/sources.list to replaces the old repository name by the new one.

01/11/2012 :
I started to remove suite from debian-multimedia.org
The first suite is stable and experimental then testing in september (done 03/09) and unstable in november (done 01/11).
Of course people should move to the new domain name right now.

donc les utilisateurs habituels, qui font des mises a jour régulières, se sont déja rendu compte du changement de domaine et ont modifié leur configuration. Evidemment, il y a un risque pour la machine qui sort de six mois d'hibernation dans un placard, qu'on met à jour sans précautions, et qui va contacter notre ami ukrainien… lequel n'a encore rien mis en ligne pour l'instant. Bref…

Pour alimenter le troll: oui, les logiciels qui n'etaient présents que chez Christian sont petit à petit apparus chez Debian, ce qui fait dire à certains qu'il pourrait y avoir redondance. Mais si on veut des version récentes, le choix est vite vu:

XBMC sur les dépots officiels :

• stable: 2:11.0~git20120510.82388d5-1+b1
• testing: 2:11.0~git20120510.82388d5-1+b1
• unstable: 2:11.0~git20120510.82388d5-1+b1
• experimental: 2:12.0~git20130127.fb595f2-1

XBMC sur deb-multimedia.org :

• stable: 4:12.2-dmo2.wheezy1
• testing: 4:12.2-dmo2
• sid: 4:12.2-dmo2

Personnellement, je préfère les releases officielles, mais vous faites comme vous voulez.

Le générique de « Il était une fois l'homme » où l'on voit ces mecs se faire cramer par la fusée qui décolle à la fin.

… et la terre qui explose.

Mais aussi :

• Le générique de fin du prisonnier, avec la tête du n°6 qui grossit au dessus d'une vue du village, et des barreaux qui se referment

Merci pour la dénonciation des plugins fautifs, je vais regarder de plus près à quoi ils servent : le cache, je ne sais pas, les derniers ajouts dommage c'était sympa, et c'est idiot si ça bouffe du CPU en permanence.

Pour les DirtyRegions, j'avait déja modifié la config pour la 11, je vais vérifier les changements apportés par la 12.

Mmh… interessant. Peux tu donner un peu plus de détails sur les plugins à désactiver pour optimiser l'utilisation CPU ?

Lucrèce, pas Lutèce…

J'ai sous les yeux des CV de candidats stagiaires Master 2 MIAGE. Visiblement, l'enseignement de l'Ada est toujours d'actualité.

Je préfèrerais voir mes impôts partir dans un programme de financement d'ordinateur+internet pour les démunis, là ça servirait à quelque chose.

Oui, ça servira au moins à enrichir le vendeur d'ordinateur et le fournisseur d'accès.

Et puis on appellerait ça le "Plan informatique pour tous"… mais on me dit dans l'oreillette que ceci a déjà été fait, avec le succès que l'on connait.

Le mot important dans la phrase, c'est "correct", dans le sens "correct pour la norme C". Dans le texte original, ca doit être "well formed".

Bref, ça n'empêche pas d'écrire et compiler les programmes auxquels tu penses. Ces programmes vont répondre au besoin (peut-être), tourner indéfiniment (sauf bug), donc fonctionner correctement du point de vue de l'utilisateur. Par contre, du point de vue de la norme, il n'est pas "bien formé", parce qu'il ne se termine pas.

Heu, attends… tu veux dire qu'on pourrait acheter tout ça en une seule fois, sur un même support physique, ce qui veut dire que le marchand va renoncer à te vendre ça à la découpe, petit à petit, en encaissant à chaque fois ?
Alors, il ne faut surtout pas espérer que ce paquet tout-en-un soit au prix habituel où tu trouves une seule version par support physique. Ca sera plutôt le prix habituel, multiplié par le nombre de versions présentes (et il y aura des clients pour ça…)

La vérité, c'est que tout le monde sait que ça s'appelle une panosse.

Oui, j'ai bien compris le probleme que pose le masquage des extensions, c'est la réponse proposée qui m'intrigue : puisque l'utilisateur ne pourra pas distinguer 'foo.c' et 'foo.o' sans les extensions (2x 'foo'), alors le système devrait interdire des fichiers qui ne diffèrent que par l'extension.
Ca règle le probleme de l'utilisateur, qui verra maintenant 'foo.c' et 'bar.o' affichés sous la forme 'foo' et 'bar'. Par contre, il faudra aussi expliquer cette nouvelle règle à messieurs Makefile et associés, ca va ête croustillant.
C'est quand même plus simple si on affiche le nom complet du fichier, avec son extension, non ?
(en gros, cacher les extension, c'était créer un problème là ou il n'y en avait pas…)

… trop de problèmes, comme la non interdiction d'un nom de fichier ayant le même nom et pas la même extension.

Oops… tu voudrais que le systeme interdise deux fichier avec le même nom, mais une extension différente, dans le même répertoire, c'est bien ça ?
Et aussi pour foo.h, foo.cc et foo.o ?

Comme dans l'esprit IPV6, tout est accessible de partout, cela conduirait à utiliser du ssl partout, alourdissant et ralentissant les échanges locaux. Adieu les transferts à 100 Mo/s de mes réseaux Gigabit !

Heu… la j'ai peur. On ne peut pas monter un parefeu en IPv6, qui cacherait les services internes qui doivent rester privés ?

les USA dépensent le double de la France dans la santé, pour un résultat désastreux.

Désastreux parce que tu prends le point de vue des malades. Maintenant, si tu regardes du coté des médecins, pharmaciens, etc. le système américain est bien meilleur : deux fois plus de pognon en circulation…

si la longueur est supérieur à la taille de ton fichier, tu te doutes qu'il y a un problème non?

Exemple donnée plus haut : sur le disque, le fichier est compressé, et tu le lit directement via une bibliothèque qui fait la décompression a la volée. Cette bibliothèque ne te donne pas la taille réelle des données (souvent elle ne le peut pas). Donc la taille du fichier sur disque ne donne aucune information pertinente, elle sera probablement inférieure à la longueur lue, sans que ça pose de problème.

En C++, del, c'est une fonction peut-être ?

Tu veux dire delete ?
(j'ai pas fait de C++ depuis longtemps…, les choses ont peut-etre changé)

Moi je connaissais "milieu de gamme" et pas "moyen de gamme"….

et au bout de la DIN, un clavier Model-M !