Étienne a écrit 707 commentaires

  • [^] # Re: Rebuild Debian

    Posté par  . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 10.

    On peut builder le même programme avec le même compilateur et les mêmes options sur le même OS et on devrait obtenir (si je ne m'abuse) le même résultat
    
    #include <stdio.h>
    int main() {
        printf(__TIME__);
    }
  • [^] # Re: houuu la pub mensongère

    Posté par  . En réponse à la dépêche Version majeure d'Ekiga, logiciel libre de visioconférence. Évalué à 2.

    sûrement une extension qui bloque

    HTTPS Everywhere ? Il semblerait que les images ne soient pas délivrées en https.

  • [^] # Re: Du taf en perspective

    Posté par  . En réponse à la dépêche codeurs, traducteurs, cppreference a besoin de vous . Évalué à 2.

    ça doit marcher avec g++ 4.7 :

    $ g++ -std=c++11 -o array array.cpp
    $ ./array
    3 2 1 a b
    
    

    Le code utilise 4 nouveautés du c++11 :

    • le conteneur array bien sûr (existe depuis assez longtemps dans gcc au moins dans tr1/array)
    • les initializer lists : introduit en version 4.4
    • l'inférence de type avec le mot clé auto : introduit en version 4.4
    • la boucle for sur un range : for (auto& s : a3) : introduit en version 4.6

    source : http://gcc.gnu.org/projects/cxx0x.html

  • [^] # Re: Allons-y

    Posté par  . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 5.

    Le portage a été fait de manière à permettre la prise en charge de plusieurs SoC ARM de manière standardisée

    Ce serait intéressant de savoir plus précisément comment MS s'y prend pour gérer ça. Du côté de Linux, après quelques années un peu bordéliques, les choses avancent bien mais c'est vrai que c'est plus compliqué que sur la plateforme x86 (pour ceux que ça intéresse LWN en parle assez souvent).

    Merci pour la dépêche en tout cas.

  • [^] # Re: I beg your pardon?

    Posté par  . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 4.

  • [^] # Re: Ya plus qu'a

    Posté par  . En réponse à la dépêche Le moteur de Doom 3 placé sous GPL v3. Évalué à 10.

    Des tuyaux ?

    Non ça c'est Mario.

  • # Erreur dans la réponse ?

    Posté par  . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.

    Dans la réponse

    La raison pour laquelle MINIX 3 n'a pas dominé le monde est liée à une erreur que j'ai faite aux alentours de 1992.

    Est-ce qu'il ne parle pas plutôt de MINIX 1 (1.5 en 1992) ?

    Étienne

  • [^] # Re: Bonne initiative

    Posté par  . En réponse à la dépêche FreeMedForms : la médecine libre s’enrichit de deux nouvelles applications. Évalué à 1.

    Je dirai que le départ serait d'assurer un réseau sans fil privé et sécurisé qui permettrait de déporter les bases sur un serveur. Sinon...

    Sur un autre cas d'utilisation : "les visites médicales", il serait intéressant de pouvoir avoir une copie de la base en local et de la réintégrer en revenant. Je sais que MédiClick par exemple permet cela. Dans un cabinet de groupe, les médecins partagent l'accès à la base mysql sur le serveur, une instance de mysql peut (ou doit je ne sais pas) également être installé sur les postes clients pour pouvoir justement utiliser son portable en visite.

    Étienne

  • [^] # Re: Positionnement par rapport à medintux

    Posté par  . En réponse à la dépêche FreeMedForms : la médecine libre s’enrichit de deux nouvelles applications. Évalué à 1.

    Merci beaucoup pour les explications.

    Étienne

  • # Positionnement par rapport à medintux

    Posté par  . En réponse à la dépêche FreeMedForms : la médecine libre s’enrichit de deux nouvelles applications. Évalué à 3.

    On a déjà parlé sur linuxfr de MedinTux, quelles sont les différences entre ces deux logiciels, j'avais l'impression que FreeMedForms est un "concurrent" de MedinTux mais je vois sur Utiliser FreeDiams avec MedinTux que MedinTux peut s'interfacer avec FreeDiams.

    Merci bien,

    Étienne

  • [^] # Re: Poettering

    Posté par  . En réponse à la dépêche /usr friendly. Évalué à 3.

    Oui, mais ça marchait bien avec l'ancien système d'init non ?

    Pas mieux qu'avec systemd.

    Étienne

  • # colorscheme en 256 couleurs

    Posté par  . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 2.

    Pour le colorscheme, j'utilise inkpot qui permet d'utiliser les 256 couleurs du terminal et est très agréable. Et dans le vimrc :

    "force l'affichage en 256 couleurs (parfois le termcap n'est pas à jour où que $TERM n'est pas à XXX-256color)
    set t_Co=256
    let g:inkpot_black_background=1
    colorscheme inkpot
    
    

    Étienne

  • [^] # Re: Mes plugins favoris.

    Posté par  . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 5. Dernière modification le 03 novembre 2011 à 11:01.

    • clangcomplete pour avoir une complétion en C++ qui marche enfin
  • # Changer le répertoire courant

    Posté par  . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 3.

    Il m'arrive souvent de vouloir changer le répertoire courant (:chdir ou :lchdir) pour me retrouver dans le répertoire du fichier en cours d'édition (afin de facilement travailler sur les fichiers du même répertoire). J'ai ajouté ces 2 commandes dans mon vimrc :

    command LCdf execute "lchdir ".escape(expand("%:p:h"), ' ')
    command Cdf execute "chdir ".escape(expand("%:p:h"), ' ')

    Explications :

    • % : nom du fichier en cours d'édition
    • %:p : transforme en nom complet (voir :help ::p)
    • %:p:h : ne garde que le dirname (voir :help ::h)

    La fonction escape permet de rajouter un \ devant les espaces.

    Étienne

  • [^] # Re: mon truc à moi

    Posté par  . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 3.

    Dans le même esprit

    :'<,'>!command

    Passe la sélection courante sur l'entrée standard de la commande et la remplace par la sortie de la commande. Avec bien sur les variations :

    :%!command
    :12,.!command
    etc.

    Étienne

  • [^] # Re: Tant pis, je me lance

    Posté par  . En réponse au journal Microsoft et les virus, une longue histoire d'amour.. Évalué à 4.

    Il faut donc bien qu'un boulet ouvre un document Word venu de nulle part sans connaître son expéditeur.

    Tant il est vrai qu'il est extrêmement compliqué de forger le champ From d'un mail. C'est pas compliqué de visiter la page facebook ou web d'une personne et de voir avec qui elle est en contact.

    Étienne

  • [^] # Re: Un peu d'explications sur le bug introduit

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 10.

    Faut pas non plus les prendre pour des cons, c'est facile après coup quand on a l'explication de les trouver complètement crétins. Le vrai problème c'est d'avoir poussé une version non stable dans Fedora.

    D'autant que le leaf ne veut pas dire "salut, nous sommes des fonctions inoffensives, tu peux nous optimiser" ça veut dire "salut, je ne viendrais pas taper dans une autre unité de compilation que la mienne", ce qui objectivement est vrai. Si les problèmes de multi-threading étaient simples, surtout à un niveau aussi bas, ça se saurait.

    Étienne

  • [^] # Re: Oups

    Posté par  . En réponse au journal Linux se commercialise. Évalué à 2.

    Et un support de 3 ans... C'est vraiment un monde de prêt à jeter, triste monde...

    Je ne crois pas que la mission de la Linux Foundation soit de lutter contre la société de consommation. Son objectif est de favoriser l'adoption de Linux. La question est pourquoi 3 ans ? Parce que ça correspond aux besoin des constructeurs. Si la support était de 10 ans, les constructeurs ne fourniraient pas pour autant de mise à jour pendant 10 ans. Les 3 ans correspondent au développement, commercialisation, support (disons 1 ans de développement et 2 ans de support à la louche).

    Étienne

  • [^] # Re: GLibc & Fedora

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 9.

    On pourrait rebaptiser ton journal "Merci aux mainteneurs Fedora de la GNU libc" ;)

    Étienne

  • [^] # Re: Un peu d'explications sur le bug introduit

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 1.

    Comment sais-tu que dans 20 ans ce sera toujours le cas?

    C'est pour ça que je mettais qu'un diagnostique par le compilateur est tout à fait possible. N'oublions pas que l'attribut vient d'être rajouté, nul besoin de se précipiter. Ajouter un diagnostique pour émettre un warnings sur les cas 1 et 2 que je présentait me parait tout à fait faisable. La sémantique est assez comparable au const du C++ par exemple, à savoir qu'avec une variable const on ne peut appeler uniquement :

    • des fonctions qui prennent la variable en paramètre const (la copie étant un cas particulier de cette règle)
    • des fonctions const de cette classe

    Peut-être que pour le leaf, cela existe déjà, mais sinon le rajouter permettrai de l'utiliser de façon sûr.

    Étienne

  • [^] # Re: GLibc & Fedora

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 6.

    Euh, ce ne sont pas les développeurs de la glibc qui forcent Fedora à intégrer une nouvelle version, ce sont les mainteneurs de Fedora (peut-être que certains ont une double casquette). Il y a peut-être aussi un problème d'organisation ou de confiance dans les mainteneurs d'une brique aussi essentielle que la glibc chez Fedora.

    Étienne

  • [^] # Re: Un peu d'explications sur le bug introduit

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 5.

    Résumé : ne pas utiliser attribute((leaf)), truc écrit par un humain et donc source de bug. Vaut mieux laisser le compilo faire de l'optimisation globale (lors du link etc...) quand possible et sinon faire comme prévu sans cet attribut.

    Ou plus exactement ne l'utiliser que pour les fonctions qui ne fait que travailler sur ses paramètres. Par exemple il est tout à fait légitime que la fonction sin(3) soit marquée leaf. L'erreur, je pense, est de marquer leaf une fonction qui fait un appel système. Mais si une fonction qui recherche l'index d'un élément est un bon candidat par exemple :

    ssize_t findFirstElement(char* array, size_t arraySize, char lookup)
    {
        for (ssize_t i=0; i < arraySize; i++)
        {
            if (array[i] == lookup) return i;
        }
        return -1;
    }
    
    

    Les critères à réunir sont :

    1. pas d'appel de fonction non leaf
    2. pas d'utilisation de variable autre que les paramètres de la fonction (ou éventuellement à une variable statique de l'unité de compilation)
    3. pas d'appel système

    Je n'ai pas accès à un gcc 4.6 pour faire un essai mais un diagnostique pour les points 1 et 2 seraient possibles, voir même une suggestion de rajouter l'attribut (pour le point 1, ça concerne quasi exclusivement les mainteneurs de la glibc, je pense qu'ils ont compris maintenant).

    Ceci dit les gains ne doivent pas être monumentales, cela ne concerne que les optimisations liées aux variables globales, et si un code est bourré de variables globales, je pense qu'il y a d'autres priorité que de rajouter des __attribute__((__leaf__)) partout.

    Étienne

  • [^] # Re: Sémantique

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 10.

    On dirait que le problème c'est que le C est assez pauvre pour gérer la programmation concurente et ce genre d'effets de bord ...

    Je ne sais pas pourquoi tu as un score négatif car la remarque est tout à fait pertinente. Le langage C n'a aucune sémantique liée à la programmation concurrente (sauf éventuellement le mot clé volatile qui n'était d'ailleurs pas prévu pour ça au début). Tout ce qui existe est sous forme de bibliothèque additionnelle. Et donc on a d'un côté une sémantique du C que connait les compilateur avec les fameux "undefined behaviors" permettant au compilateur de nombreuses optimisations et de l'autre du multithreading qui, par endroit, va à l'encontre de la sémantique du C. Les extensions des compilateurs (comme __thread, __sync* de gcc) sont la preuve que le C en lui même ne suffit pas.

    Depuis quelques semaines, le C11 a été normalisé et ajoute justement quelques outils pour gérer le multithreading (mais il va falloir un peu de temps, il suffit de voir que le C99 est loin d'être très généralisé) :

    • _Thread_local : indique qu'une variable a un thread local storage, c'est à dire qu'elle n'est pas partagée entre threads (c'est disponible avec gcc depuis assez longtemps au travers du mot clé __thread)
    • _Atomic : définit une variable comme étant atomique

    Étienne

  • # Un peu d'explications sur le bug introduit

    Posté par  . En réponse au journal Merci aux développeurs de la GNU libc !. Évalué à 10.

    Je ne vais pas parler ici des considérations politiques mais j'ai trouvé que le bug introduit dans la glibc est particulièrement intéressant. Pour ceux qui n'ont épluché les liens du journal, voici une tentative d'explication.

    Dans gcc 4.6 a été ajouté un attribut de fonction leaf (cf Function Attributes). Cet attribut permet de signifier qu'une fonction ne va fait appel à aucune autre fonction. Lorsque le compilateur voit qu'on appel une fonction "leaf", il sait que toutes les variables de l'unité de compilation courante qui ne sont pas passées à la fonction ne pourront être modifiées par cette fonction et peut ainsi optimiser plus agressivement. Par exemple si j'écris le code suivant :

    static int g_count; /* variable globale */
    
    __attribute__((__leaf__))
    int calcValue(int);
    
    int incGCount()
    {
        g_count++;
    }
    
    int myFunc2()
    {
        int i;
        int result = 0;
        g_count=0;
        for (i=0; i != 3 && g_count != 3; i++)
        {
            result+=calcValue(i);
            ++g_count;
        }
        return result;
    }
    
    

    Ici, calcValue étant marqué comme leaf, on sait que cette fonction ne va appeler aucune fonction de notre unité de compilation, en particulier elle n’appellera pas incGCount() et donc, voyant que i et g_count ont toujours la même valeur, le compilateur peut tout à fait remplacer la fonction myFunc2 par ceci :

    int myFunc2()
    {
        g_count=3;
        return calcValue(0)+calcValue(1)+calcValue(2);
    }
    
    

    Autre observation, les fonctions (entre autre) pthread_mutex_lock et pthread_mutex_unlock ne font appel à aucune fonction (en dehors de leur unité de compilation et elles n’appellent pas non plus de callback), donc elles ont été marquées comme leaf par les mainteneurs de la glibc. Et donc si je veux rendre myFunc2 thread-safe en protégeant l'accès à g_count par un mutex, je ferais :

    int incGCount()
    {
        pthread_mutex_lock(&g_mutex);
        g_count++;
        pthread_mutex_unlock(&g_mutex);
    }
    
    int myFunc2()
    {
        int i;
        int result = 0;
        pthread_mutex_lock(&g_mutex);
        g_count=0;
        pthread_mutex_unlock(&g_mutex);
        for (i=0; i != 3 && g_count != 3; i++)
        {
            result+=calcValue(i);
            pthread_mutex_lock(&g_mutex);
            g_count++;
            pthread_mutex_unlock(&g_mutex);
        }
    }
    
    

    La fonction peut être optimisée par le compilateur qui sait que ni pthread_mutex_lock ni pthread_mutex_unlock ne vont consulter ou modifier g_count. Or si ces fonctions ne touchent évidemment pas g_count, en revanche le mutex sert à protéger l'accès à g_count et la prise du mutex peut bloquer parce qu'un autre thread a pris le mutex et est en train d'appeler incGCount(). Le compilateur ayant pris comme postulat que g_count n'était pas modifié a pu convertir le code comme ceci :
    int myFunc2()
    {
        pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
        pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
        pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
        pthread_mutex_lock(&g_mutex); pthread_mutex_unlock(&g_mutex);
        
        g_count=3;
        return calcValue(0)+calcValue(1)+calcValue(2);
    }
    
    

    Et là c'est le drame et heap corruption via multi-threaded "git grep".

    Étienne

  • [^] # Re: Oups

    Posté par  . En réponse au journal Linux se commercialise. Évalué à 1.

    Je doute que tu ai encore des mises à jour de ton téléphone après 6 ans. La durée de vie est ici à comprendre en terme de durée de support.