ninis666 a écrit 95 commentaires

Pourquoi refuses-tu de faire tourner du code de ce Merlin Hugues ?

Ha pas sûr que ça ne fasse pas l'autocompletion (super la double négation :) ) : ton shell (au moins bash) devrait le permettre.

Mon petit de bientôt 7 ans, aime bien jouer avec scratch, un langage où tu places des blocs "visuel" d'instructions pour faire des animations. C'est supporté nativement par les distrib' (ubuntu ou debian), et même une version en ligne.

Bref, une alternative moderne à logo !

je dirais même plus printf("%f\n", s) !

Rha, mauvaise manip, peut pas éditer mon commentaire !

Bref, c'est naïf, mais ça peut marcher ; un problème d'indentation qui t'as conduit à ça : faudrait juste déplacer ton '}' du premier while à la fin et vérifier la confirmation à ce moment :

    float main()
    {
        int l,o ;
        float s;
        printf("************************************************\n**** Solveur de polynome ****\n************************************************\n\n");  
        l=lirechoix();
        while (l!=3)
        {
            if (l==1)
            {
                s=premier();
                scanf("%f",&s);
            }
            else if (l==2)
            {
                s=second();
                scanf("%f",&s);
            }
     /* } <--------- celui-ci */

        if (l == 1 || l == 2) {
            printf("Tapez 1 pour continuer vers une autre opération\nTapez une touche quelconque pour quitter\n");
            /*j'ai choisi d'ajouter cette étape pour ne pas encombrer les affichages et mettre l'utilisateur à l'aise au
            lieu de lui afficher le menu à chaque fois */
            if (scanf("%d",&o) == 1 && o == 1) /* <---- on vérifie qu'on a bien la bonne confirmation */
                 break;
          }

          l= lirechoix(); // pour renvoyer le menu s'il veut continuer

        } /* <-------- à bouger ici */
    }

Bien que ça ne soit pas très élégant, ça devrait marcher, c'est juste un problème d'indentation qui fait que tu as une accolade fermante de trop :)

        float main() {
             ...

                l=lirechoix();
                while (l!=3)
                {

             ...
                    {
                        s=second();
                        scanf("%f",&s);
                    }
              }
                    printf("Tapez 1 pour continuer vers une autre opération\nTapez une touche quelconque pour quitter\n");
                    /*j'ai choisi d'ajouter cette étape pour ne pas encombrer les affichages et mettre l'utilisateur à l'aise au
                    lieu de lui afficher le menu à chaque fois */
                    scanf("%d",&o);
                    while (o!=1)
                    {
                        return 0; // si l'utilisateur ne veut pas continuer
                    }
         ....
        }

J'ai pas testé mais avec un module PAM comme : https://github.com/cameron-gagnon/ssh_pass_logging , tu as une solution élégante pour logger les password.

Rien à voir avec ton problème, mais une bonne habitude serait de toujours vérifier la valeur de retour des fonctions, comme celle de scanf dans ton cas : En effet, scanf retourne le nombre d'argument qu'il a correctement lu.

Et aussi un autre petit truc, tu devrais éviter de trimbaler le '5' dans tout ton code :
- soit utiliser un '#define' pour fabriquer une symbole qui définirait cette constante
- soit calculer le nombre d'élément de ton tableau (vue qu'il est déclaré statiquement) avec quelque chose comme (sizeof(tab) / sizeof(tab[0]))

Oui, on est tous d'accord sur le fait que les protocoles avec chiffrement sont plus coûteux que leurs équivalant en clair, mais je ne comprends pas le sens de ce post … Tu veux en venir où ?

Excellent, merci !

En demandant à gcc de générer l'assembleur d'un truc qui itère sur des tableaux de A ou B, tu verras pourquoi :

struct A {
    int m_value;
    char c;
};

struct B{
    int m_value;
    char c;
} __attribute__((packed));

void foo(struct A *a, int size)
{
    int i;

    for (i = 0 ; i < size ; i++) {
        a[i].c = 66;
        a[i].m_value = 5555;
    }
}

void bar(struct B *b, int size)
{
    int i;

    for (i = 0 ; i < size ; i++) {
        b[i].c = 66;
        b[i].m_value = 5555;
    }
}

gcc -O0 -S prout.c -o prout.s

foo:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movq    %rdi, -24(%rbp)
    movl    %esi, -28(%rbp)
    movl    $0, -4(%rbp)
    jmp .L2
.L3:
    movl    -4(%rbp), %eax
    cltq
    leaq    0(,%rax,8), %rdx
    movq    -24(%rbp), %rax
    addq    %rdx, %rax
    movb    $66, 4(%rax)
    movl    -4(%rbp), %eax
    cltq
    leaq    0(,%rax,8), %rdx
    movq    -24(%rbp), %rax
    addq    %rdx, %rax
    movl    $5555, (%rax)
    addl    $1, -4(%rbp)
.L2:
    movl    -4(%rbp), %eax
    cmpl    -28(%rbp), %eax
    jl  .L3
    nop
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   foo, .-foo
    .globl  bar
    .type   bar, @function
bar:
.LFB1:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movq    %rdi, -24(%rbp)
    movl    %esi, -28(%rbp)
    movl    $0, -4(%rbp)
    jmp .L5
.L6:
    movl    -4(%rbp), %eax
    movslq  %eax, %rdx
    movq    %rdx, %rax
    salq    $2, %rax
    addq    %rax, %rdx
    movq    -24(%rbp), %rax
    addq    %rdx, %rax
    movb    $66, 4(%rax)
    movl    -4(%rbp), %eax
    movslq  %eax, %rdx
    movq    %rdx, %rax
    salq    $2, %rax
    addq    %rax, %rdx
    movq    -24(%rbp), %rax
    addq    %rdx, %rax
    movl    $5555, (%rax)
    addl    $1, -4(%rbp)
.L5:
    movl    -4(%rbp), %eax
    cmpl    -28(%rbp), %eax
    jl  .L6
    nop
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret

C'est pourquoi il faut aligner correctement les champs des structures ou de n'utiliser les attributs d'alignement que si on n'a pas le choix …

De mon temps, c'était plus facile de lire l'assembleur produit par gcc, (c'était du 32 bits) !

mouais, ton appli peut aussi essayer toutes les valeurs possibles de display jusqu'à en trouver une qui peut être ouverte … Donc non, ça ne protège pas grand chose non plus …

Tu parles d'ioctl.h, je suppose que tu as du écrire un bout de code pour le tester ; dans ce cas, es-tu sûr que tu ouvres le bon device ? Peut-être que l'ioctl ne se fait pas sur le bon fd ou qu'elle ne soit tout simplement pas supportée par le driver.

Le driver (le .ko) que tu charges gère-t-il bien le périphérique comme le décrit sa documentation ? Je pense que tu devrais voir quelques lignes dans les logs kernels (cf. dmesg) qui dit que ton driver est chargé, et s'il est assez gentil, t'affichera les devices qu'il a pu trouver et gérer …

D'expérience, c'est pas une bonne idée de gérer ça dans des handler de signaux (je pense que c'est ce que tu veux dire par interruption ?).

Je comprends pas bien ce que tu veux faire, mais ça devrait t'aider à mieux voir le truc :

Si tu as des impératifs de temps de traitement rapide de plusieurs connections, je pense qu'il vaut mieux sauver les événements dans ton cycle de read (ou de poll) sur to FD et laisser le traitement de ceux-ci dans un autre thread.

C'est plus simple avec un bout de code genre :

int event_process_step(void)
{
   struct event ev;

    if (pop_event(&ev) == 0)
        return 0;

    return process_event(&ev);
}

int event_read_step(int fd)
{
    struct event ev;
    int ret;

    ret = read(fd, &ev, sizeof ev);
    if (ret == sizeof ev)
       ret = push_event(&ev);
    else
        ret = -1;

    return ret;
}

/*
 * Soit avec des threads
 */
void *thread_read(void *arg)
{
    struct poll_table *table = arg;

    for (;;) {
        fd = poll_get_fd(table);
        if (fd < 0)
            break;
        if (fd == 0)
            break;
       if (event_read_step(fd) < 0)
               break;
    }

   return NULL;
}

void *thread_process(void *arg)
{
    for (;;) {
        int worked;

        worked = event_process_step();
        if (workded < 0)
            break;
        if (worked == 0)
            more_work();
    }

   return NULL;
}

/*
 * Soit sans thread
 */
void loop_process(struct poll_table *table)
{

    for (;;) {
        int worked;

        fd = poll_get_fd(table);
        if (fd < 0)
            break;
        if (fd == 0)
            break;
       if (event_read_step(fd) < 0)
               break;

        worked = event_process_step();
        if (workded < 0)
            break;
        if (worked == 0)
            more_work();
     }
}

/*
 * Ou même avec un peu de repartition de charge
 */
void loop_process_fair(struct poll_table *table)
{

   for (;;) {
        int worked;

        worked = 0;
        while (worked < MAX_READ_WORK) {

            fd = poll_get_fd(table);
            if (fd < 0)
                break;
            if (fd == 0)
                break;
           if (event_read_step(fd) < 0)
                   break;

           worked ++;
       }

        while (worked < MAX_PROCESS_WORK) {

            done = event_process_step();
            if (done < 0)
                break;
            if (done == 0)
                break;

            worked ++;
        }

        more_work();

    }
}

Bref, tu vois l'idée …

chage : C'est un truc UNIX standard ; il te reste plus qu'à scripter un peu un truc avec pour être lancé par un cron.

bash$ man chage
...
...
       -E, --expiredate EXPIRE_DATE
           Set the date or number of days since January 1, 1970 on which the user's account will no longer be accessible. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). A user whose account is locked must contact the system administrator before being able to use the system again.

           Passing the number -1 as the EXPIRE_DATE will remove an account expiration date.
...

Ça me fait toujours tiquer quand on utilise un genre pour désigner un métier. L'avantage de l'anglais est qu'il n'est pas genré, on dirait plus "lead developer", tout en anglais … Du coup la question du genre ne se pose plus !

Il faut mettre à jour tes clefs gpg pour ces dépôts :

gpg --keyserver pgpkeys.mit.edu --recv-keys 9D6D8F6BC857C906 && gpg -a --export 9D6D8F6BC857C906 | sudo apt-key add -
gpg --keyserver pgpkeys.mit.edu --recv-keys 8B48AD6246925553 && gpg -a --export 8B48AD6246925553 | sudo apt-key add -
gpg --keyserver pgpkeys.mit.edu --recv-keys 67ECE5605BCF1346 && gpg -a --export 67ECE5605BCF1346 | sudo apt-key add -
gpg --keyserver pgpkeys.mit.edu --recv-keys ED444FF07D8D0BF6 && gpg -a --export ED444FF07D8D0BF6 | sudo apt-key add -

Puis, mettre à jour:

apt update

C'est un peu vieux, mais ça explique le rendu par OpenGL, avec du vrai code :
http://tfc.duke.free.fr

Avec le XRite (colormunki), j'ai pas le souvenir d'avoir trop galéré non … il a été détecté correctement par le kernel sans bidouiller, et était utilisable directement avec displaycal.

Pour la qualité des écrans, je peux pas trop t'aider, mais d'expérience, pour la photo, il faut calibrer son écran :
- récupérer les profiles icc fournis par le constructeur et les charger ; c'est pas mal, mais ça ne tiendra pas compte de l'environnement de l'écran (l'intensité et la température des sources de lumières extérieures etc.).
- utiliser une sonde de calibrage.

Comme tu peux l'imaginer, le mieux c'est avec une sonde, c'est relativement assez cher, mais c'est un super investissement, surtout si tu veux faire de la photo ; moi j'utilise une sonde X-Rite (150€), reconnue par dispcal. Ça va utiliser la sonde pour mesurer la correction à appliquer et te générer le profile icc pour ton écran dans son environnement.

Pour résumer ton propos, c'est que tu n'as pas besoin de tests parce que ton code, de part sa maturité, s'est révélé sans bugs, malgré tes nouvelles évolutions.

Moi comme beaucoup, je ne peux (veux ?) pas : Les tests unitaires, c'est justement un truc qui permets de m'assurer que malgré les modifs internes, rien n'est à priori cassé … Sans vouloir faire le vieux con, cela fait maintenant un paquet d'année que je code (toujours dans dans le même langage, toujours avec le même compilo), et sans forcement m'en rendre compte, il m'arrive encore de changer le comportement d'une API en voulant y faire des évolutions mineures.

Aussi consciencieux que j'essaie de l'être, c'est très difficile de me dire que tout ce que j'ai codé est résistant à tous les cas tordus sans tests ; et là je ne parle pas que du test unitaire, mais du code de debug, voire les générateurs d'input tout pourris etc.

L'argument de dire que quand on utilise de vieux algo / structure de données donne moins de bug ne prouve rien ! D'autant plus que les contraintes de l'époque ne sont plus les mêmes aujourd'hui …

Les problèmes d'allocation mémoire, ce n'est qu'une infime partie des bugs qui ne sont pas détectés par les outils d'analyse de code généralement …

Il y a tout un tas de problèmes que tu ne peux pas détecter même en diversifiant les contextes de combinaison d'appel de tes fonctions, avec en vrac :

• les effets de bord de ré-utilisation des ressources déjà utilisées
• les effets de bord dû aux accès concurrentiels
• les effets de bord dû au fait que tu ne contrôle pas l’environnement d’exécution ou les entrés de tes fonctions
• etc.

Bref, tout ça pour dire qu'à mon humble avis, me concernant, c'est très difficile et peu rassurant de ne pas avoir à minima du test unitaire à l'intérieur des API qu'on écrit soit même.

Il faut ajouter les sources depuis les dépôts de owncloud comme décrit chez eux : http://download.owncloud.org/download/repositories/10.0/owncloud/ (en cliquant sur l'icone debian ou ubuntu qui va bien).

Perso, je préfère nextcloud parce que j'avais pas trouvé trouvé de client libre gratuit sur android.

Moi je colmaterais le trou avec de la pâte epoxy, puis poncerais l’excédant. Bon le truc c'est qu'elle n'est pas noire mais gris, de plus tu condamneras définitivement le port …

Toujours aussi énervés et énervants tes commentaires ; la seule erreur de son post concerne la licence, alors que tout le monde ici comprend ce qu'il voulait dire : on a accès aux sources. De là a dire que c'est de la "désinformation" et que c'est le marketing de la boîte qui prétend que c'est Open Source, c'est toi qui en fait pour le coup :) ; à moins d'avoir mal cherché, nulle part sur le site je n'ai vue que les sources sont libres.

Bref, moi je trouve que c'est une bonne machine, qui est largement moins opaque que les trucs de Casio / TI / HP / whatever.

PS :
D'habitude je laisse couler tes remarques (qui sont toujours dans le même esprit, négatif, qui ne mènent à rien au final), mais là, il fallait que ça sorte.