JaguarWan a écrit 331 commentaires

  • [^] # Re: Outils

    Posté par  . En réponse au journal Ecrasez un Mammouth !. Évalué à 4.

    Bah, je voulais voir un exemple de La Vie Réelle® et aussi pouvoir remercier les LinuxFRiens qui m'ont aidé :) Donc hop, une pierre deux coups :)
  • [^] # Re: Date limite

    Posté par  . En réponse au journal Ecrasez un Mammouth !. Évalué à 1.

    Heu, le coup de la 404 ça doit être un problème de conformance HTTP: quand je détecte un forbidden/not found, j'envoie directement la page 404 comme un document normal :)
    Je mettrais un CGI pour contrôler ça dans la prochaine version :)

    Pour wget, mon serveur ne ferme pas la connection tant que le client est là... Avec un telnet on voit qu'il envoie Content-Length et Content-Type, mais il doit manquer quelque chose pour que wget soit content car même dans des conditions "normales" il reste bloqué à 100%...

    Vu que le serveur ne répondait plus beaucoup, je lui ai balancé un kill -11 pour voir s'il était en deadlock :)

    Après lecture du core dump, il apparaît qu'il était tout simplement en stress intense, c'est impressionnant un LinuxFRisage :)
  • [^] # Bien vu...

    Posté par  . En réponse au journal Ecrasez un Mammouth !. Évalué à 2.

    Premier bug révélé par l'affluence (j'ai été surpris quand j'ai vu la taille du access.log !), les transferts de "gros" fichiers ne sont plus fiables.

    En effet, je compile habituellement Mammouth avec seulement deux threads travailleurs de chaque sorte (MM_LIMIT_THREAD dans net/mm_net_def.h), mais là j'en avais prévu idix (juste au cas où ^_^').

    Malheureusement, je n'avais pas prévu de mécanismes garantissant un envoi séquentiel pour les nouveaux streams, vu qu'empiriquement ça semblait bien marcher... Ce qui fait que vous recevez le fichier en entier, mais tout mélangé suivant la vélocité relative des 10 travailleurs d'écriture :]

    Bon, bah ça fait un nouvel item sur ma todo list, en prévision d'une très prochaine version 0.2.1 :D

    En attendant, il est conseillé de récupérer les sources sur tuxfamily ^_^'
  • # Date limite

    Posté par  . En réponse au journal Ecrasez un Mammouth !. Évalué à 4.

    Attention, le serveur ne pourra plus être écrasé à partir de demain ce vendredi soir, car mon sympathique hébergeur déménage sa bête ce week end :)
  • [^] # Re: Conclusion...

    Posté par  . En réponse au journal Connerie Inside (tm). Évalué à 10.

    Hmm, ça me donne envie de lancer une gazette en ligne pour cette merveilleuse profession injustement méconnue du grand public qu'est la colo-proctologie.

    Je l'appellerai "The Annus Insider"®.

    -------------------------------------->[|] arf, fermé !
                                                   ___|
      hop par les escaliers       ___|
    [*]<-----------------------___|
  • [^] # Re: CGIs et serveurs Web, même combat.

    Posté par  . En réponse au message POST. Évalué à 1.

    Merci beaucoup pour cette réponse précise ^_^
  • # Méthode goret

    Posté par  . En réponse au message Lettres en couleur (sous console). Évalué à 2.

    Si tu te contrefous de la portabilité, tu peux utiliser les abominables séquences d'échappement du shell, genre rouge=\e[1;31m, vert=\e[1;32m...

    C'est assez poilu, tu en conviendras.

    Je pense par conséquent que tu devrais essayer de programmer ça en ncurses, qui est prévu pour faire ce genre de chose (man curs_color) et qui se trouve sur à peu près tous les *nix.
  • # J'acquiesce vigoureusement

    Posté par  . En réponse au journal La liberté .... belle utopie. Évalué à 7.

    Il semble que beaucoup de linuxiens prennent le débutant pour un simple utilisateur de clickodrome, qui serait dégouté à vie de GNU/Linux si on l'initie à la ligne de commande.

    <mavie>
    Je suis personnellement un transfuge récent, ça ne fait qu'à peine deux ans que j'utilise GNU/Linux. Avant ça, comme beaucoup, j'utilisais Windows, et avant lui, MS-DOS.

    Au moment où j'ai commencé mes études, il a fallu que je switche pour Windows XP afin de pouvoir utiliser le réseau local essentiellement Windowsien (genre les partages SMB de plus de 12 caractère invisibles pour les 9x, etc...).

    Et bien, ce switch m'a vraiment déplu. Certes, la nouvelle politique multi-utilisateur était sympathique, mais je détestais XP, à cause de son interface ridicule par défaut, du chien jaune pour rechercher les fichiers, du répertoire SharedDoc ouvert en écriture par défaut, de la disparition de DOS, et par dessus tout les trous de sécurité monstrueux.

    En effet, ce que j'aimais bien dans 9x, qui bien paramétré tournait comme une horloge, c'est que si la couche graphique était bloquante, on pouvait utiliser le DOS en dessous pour passer outre.

    J'ai donc décidé de passer à GNU/Linux, car en cours on apprenait le shell avec des xterm sous Windowmaker et que c'était bien plaisant.
    </mavie>

    Or, qu'est-ce que l'on conseille au débutant ? Mandrake Linux, parce que c'est click click friendly. Je l'ai cordialement détestée, ma Mandrake 9.2. Les drivers ATI pourris ne compilaient pas parce que les sources du noyal étaient pas là, et quand je les ai installées, il fallait patcher le driver car Mandrake fait des kernels super customs. Pour installer des packages il fallait toujours insérer les trois CD à moins de deviner juste (pas le net à cette époque)... Si on modifiait des fichiers de conf (placés à des endroits spécifiques à la distribution), les outils graphiques les écrasaient impitoyablement à la moindre option cochée. Par contre KDE était sympathique, et le shell excellent.

    Alors, j'ai essayé Slackware, car sur un site proposant des tutoriaux excellents, http://trustonme.net(...) , on en disait beaucoup de bien. Et là ce qui m'a plu, c'est que les compilations marchaient toujours. Les sources du noyau étaient là de base, et en plus elles n'étaient pas bidouillées. Les paquetages officiel n'avaient jamais de problème de dépendance si lourdingues à résoudre sous Mandrake. Les fichiers de conf était là où ils étaient censés se trouver et super bien commentés. En plus il y avait des fortunes sympa dans le shell, et un beau KDE.

    J'étais super content (mais je n'ai pas vomi) d'avoir trouvé un OS qui disposait à la fois d'un shell puissant et d'une belle interface, et d'une conf modifiable par l'être humain même quand l'interface graphique est morte suite à des expérimentations hasardeuses (et croyez moi, avec une ATI, mon X a souffert au début).

    Alors, pourquoi ne pas conseiller des distributions comme Debian ou Slackware à un débutant ? Un débutant sous GNU/Linux n'est pas forcément un gars qui veut faire du Windows gratuitement, mais ça peut bien être aussi quelqu'un qui en a marre de Windows et recherche quelque chose de plus puissant.
  • [^] # Re: aucun souci

    Posté par  . En réponse au message mise a jour glibc avec swaret. Évalué à 1.

    De même, je suis en slack-current à jour et je n'ai eu aucun problême.
  • [^] # Re: Release Songs

    Posté par  . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 1.

    Celle ci fait très Pink Floyd...
  • # WindowMaker

    Posté par  . En réponse au journal Gestionnaire de fenetre ideal.. Évalué à 2.

    Tu peux docker ce que tu veux sous WindowMaker, avec le super Trombone Magnétique ! J'adore la petite animation d'explosion quand on "dé-docke" une application morte :)
  • [^] # Re: meuh

    Posté par  . En réponse au message un peu d'assembleur SPARC. Évalué à 2.

    Plus simple : utilises les instrutions lrint() ou lrintf(), qui font partie du standard C99.
  • # La vérité est ailleurs

    Posté par  . En réponse au message Libération de structures dynamiques. Évalué à 3.

    Après simulation, je pense que ton bug se trouve ailleurs.

    ------------------------------------------8<-----------------------------------------

    #include <stdlib.h>
    #include <stdio.h>

    #define NAME "plop"

    typedef struct Game
    {
    char *name;
    int data;
    } game_t;

    int count(void)
    {
    return 42;
    }

    int main(void)
    {
    game_t *games[count()]; /* je savais pas que ça marchait ! */
    game_t *game = NULL;
    const char *plop = NAME;
    int i = 0;

    /* alloue un game */
    game = malloc(sizeof(*game));
    if (game == NULL) { perror("malloc()"); exit(1); }

    game->name = calloc(strlen(NAME) + 1, sizeof(char));
    if (game->name == NULL) { perror("calloc()"); exit(1); }

    /* initialise */
    memcpy(game->name, plop, strlen(plop));
    game->data = 1337;

    /* enregistrement */
    games[i ++] = game;
    printf("Supaire nom : %s\n", games[i - 1]->name);
    printf("data : %i\n", games[i - 1]->data);

    /* suppression */
    free(games[0]->name);

    #ifdef CRASHME
    printf("Supaire nom : %s\n", games[i - 1]->name);
    #endif
    printf("data : %i\n", games[i - 1]->data);

    free(games[0]);

    #ifdef CRASHME
    printf("Supaire nom : %s\n", games[i - 1]->name);
    printf("data : %i\n", games[i - 1]->data);
    #endif

    return 0;
    }

    ------------------------------------------8<-----------------------------------------

    jaguarwan@Jaguar:~$ gcc coincoin.c
    jaguarwan@Jaguar:~$ valgrind --tool=memcheck --leak-check=yes ./a.out
    ==5996== Memcheck, a memory error detector for x86-linux.
    ==5996== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
    ==5996== Using valgrind-2.2.0, a program supervision framework for x86-linux.
    ==5996== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
    ==5996== For more details, rerun with: -v
    ==5996==
    Supaire nom : plop
    data : 1337
    data : 1337
    ==5996==
    ==5996== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
    ==5996== malloc/free: in use at exit: 0 bytes in 0 blocks.
    ==5996== malloc/free: 2 allocs, 2 frees, 13 bytes allocated.
    ==5996== For counts of detected errors, rerun with: -v
    ==5996== No malloc'd blocks -- no leaks are possible.

    ------------------------------------------8<-----------------------------------------

    jaguarwan@Jaguar:~$ gcc -DCRASHME coincoin.c
    jaguarwan@Jaguar:~$ valgrind --tool=memcheck --leak-check=yes ./a.out
    ==6123== Memcheck, a memory error detector for x86-linux.
    ==6123== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
    ==6123== Using valgrind-2.2.0, a program supervision framework for x86-linux.
    ==6123== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
    ==6123== For more details, rerun with: -v
    ==6123==
    Supaire nom : plop
    data : 1337
    ==6123== Invalid read of size 1
    ==6123== at 0x1B902778: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x1B9648E4: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048649: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46060 is 0 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B902781: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x1B9648E4: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048649: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46061 is 1 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B985A01: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B964874: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048649: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46063 is 3 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B9858F0: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B964874: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048649: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46060 is 0 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    Supaire nom : plop
    data : 1337
    ==6123==
    ==6123== Invalid read of size 4
    ==6123== at 0x8048687: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46028 is 0 bytes inside a block of size 8 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x8048676: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B902778: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x1B9648E4: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048692: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46060 is 0 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B902781: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x1B9648E4: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048692: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46061 is 1 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B985A01: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B964874: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048692: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46063 is 3 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    ==6123==
    ==6123== Invalid read of size 1
    ==6123== at 0x1B9858F0: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B964874: _IO_vfprintf_internal (in /lib/libc-2.3.4.so)
    ==6123== by 0x1B96B0F1: _IO_printf (in /lib/libc-2.3.4.so)
    ==6123== by 0x8048692: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA46060 is 0 bytes inside a block of size 5 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x804862D: main (in /home/jaguarwan/a.out)
    Supaire nom : plop
    ==6123==
    ==6123== Invalid read of size 4
    ==6123== at 0x80486A3: main (in /home/jaguarwan/a.out)
    ==6123== Address 0x1BA4602C is 4 bytes inside a block of size 8 free'd
    ==6123== at 0x1B9033ED: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
    ==6123== by 0x8048676: main (in /home/jaguarwan/a.out)
    data : 1337
    ==6123==
    ==6123== ERROR SUMMARY: 28 errors from 10 contexts (suppressed: 11 from 1)
    ==6123== malloc/free: in use at exit: 0 bytes in 0 blocks.
    ==6123== malloc/free: 2 allocs, 2 frees, 13 bytes allocated.
    ==6123== For counts of detected errors, rerun with: -v
    ==6123== No malloc'd blocks -- no leaks are possible.
  • # Demoniste r0xx0r des poneys en sueur

    Posté par  . En réponse au journal Le logo debian dans WoW !. Évalué à 3.

    Et n'oubliez pas la pétition ---> www.blizzpub.net/petition/

    Je pense qu'il est temps de prendre la fuite, les trolls élite niveau 55 me regardent de travers !

    ------------->[*]
  • [^] # Re: Algorithme de detection de coins

    Posté par  . En réponse au message Fauteuil roulant. Évalué à 1.

    J'ai examiné ça et ça m'a l'air intéressant :)
    Par contre j'ai plein de 403 forbidden sur ton lien, c'est réservé aux étudiants de polytechnique ?
  • [^] # Re: Amiens

    Posté par  . En réponse au message Fauteuil roulant. Évalué à 1.

    En fait, avec le gradient j'ai déjà les contours, le problème c'est que je dois récupérer ceux appartenant au fauteuil. J'ai trouvé une méthode très intéressante, la transformée de Hough, mais pas moyen de trouver un exemple d'implémentation T_T.

    Ou alors il faudrait trouver un élément structurant très pertinent pour enlever tous ce qui n'appartient pas au fauteuil, mais j'ai l'impression que c'est encore plus compliqué puisque assez empirique...

    C'est amusant qu'il y ait plein d'anciens de l'IUT ici :)
  • [^] # Re: Amiens

    Posté par  . En réponse au message Fauteuil roulant. Évalué à 1.

    Arf, je fais mon stage à l'IUT d'Amiens :)
  • [^] # Re: re

    Posté par  . En réponse au journal World of Warcraft Natif. Évalué à 1.

    C'est vrai que NWN est excellent, mais je l'ai laché à l'époque car il n'y avais que trois pelé un et un tondu en multijoueur...
  • [^] # Re: Crash de l'update 1.4 sius Linux

    Posté par  . En réponse au journal World of Warcraft Natif. Évalué à 1.

    Déjà fixé, il suffit de mettre un OLEAUT32.DLL natif dans la fausse arboresence Windows. Mais il est clair que ce genre de choses n'aurait pas lieu avec un client natif...
  • # Changements

    Posté par  . En réponse au journal Qt4 béta2. Évalué à 3.

    Je comptais apprendre QT pendant les vacances, vous pensez qu'il vaut mieux attendre QT4 pour s'y mettre ou y aller sans arrière pensée ?
  • # Confus

    Posté par  . En réponse au journal Constitution européenne: l'avis d'un prof de droit. Évalué à 3.

    Je suis un petit con de 18 ans qui voteras pour la première fois lors de ce référendum.
    Voici ce qui engendre la confusion dans mon esprit faible et manipulé (car malheureusement, sot que je suis, j'envisage actuellement de voter non).

    Pro-Oui: "Il faut faire confiance aux élus."
    Une consitution, normalement, c'est pas une affaire de confiance, c'est entre autre le "firewall" qui permet d'éviter que le pouvoir soit accaparé par une institution (quand elle est démocratique bien sur). Quand on configure un firewall, on est censé etre confiant envers les autres machines ?

    Pro-Oui: "Si tu votes Non, c'est affreux, on va garder le traité de Nice !"
    Le traité de Nice, il expire dans 4 ans, c'est plus court que le mandat d'un mauvais président. Le TCE n'a pas de date d'expiration. Apparemment, le TCE est composé à 90% de ce que contient le traité de Nice (et les autres). Où est l'urgence de remplacer Nice par Nice légèrement patché mais sans date d'expiration ?

    Pro-Oui: "Si tu votes Non, on s'en fout on le prendra quand meme tel quel le texte, na ! :p"
    Dans ce cas, il sert à quoi le référendum ?

    Moi, j'adorerais voter oui à un texte qui donnerait un pouvoir beaucoup plus conséquent au parlement, et qui n'aurait pas de traité économique codé en dur...
    Parce que niveau politique économique :

    "Contrairement à ce qui est dit, la partie III du Traité constitutionnel ne définit pas le contenu des politiques de l'Union : ce contenu sera défini au cas par cas, notamment à travers l'adoption des lois et des lois cadres, par le Parlement européen et le Conseil sur proposition de la Commission. Ainsi, si l'on prend l'exemple de la principale politique commune, la politique agricole, les articles qui la concernent (III-225 à III-232) ne définissent pas son contenu opérationnel mais simplement son champ d'application (articles III-225 et III-226), ses objectifs et ses principes généraux (article III-227 à III-229) ainsi que les règles de vote applicables aux actes de l'Union dans le domaine agricole (articles III-230 à 232)."

    C'est un peu, "Bon, je veux que ce programme il donne tel résultat, à partir de tel données, d'après ce schéma UML, mais je vous laisse le choix de l'algo et du langage, hein." Grosse liberté en effet.
  • [^] # Re: Oublié :(

    Posté par  . En réponse au journal Faille Mozilla/Firefox. Évalué à 3.

    Je ne suis pas aussi sur que ça marche... Les tests n'affichent que des lignes de 'X' sur mon Konqueror 3.4.0, tandis que les autres posts parlent de véritables morceaux de mémoire avec de vrais morceaux de données utilisateur (ou alors ma mémoire est réellement remplie de kilomètres de X ? Comment ça, "pervers" ?)
  • [^] # Re: question de style

    Posté par  . En réponse au message Terminé. Évalué à 1.

    Merci pour les conseils, je ne savais pas qu'on pouvait utiliser sizeof() de cette manière, et c'est très pratique !

    Les prototypes en tete du fichier, je les avait laissés car ils me servaient de table des matières pour les gros modules ;)
  • [^] # Re: Gni ?

    Posté par  . En réponse au message récupérer des données d'un disque.... Évalué à 2.

    J'avais eu besoin de retrouver des fichiers malencontreusement placés sur une partition trouée, et l'utilitaire Sleuth Kit avait fait des merveilles :)
  • [^] # Re: y a un autre moyen

    Posté par  . En réponse au message Fourberies de libpthread.... Évalué à 2.

    Merci beaucoup, j'ai modifié mon code de la sorte et ça marche uniformément bien maintenant :)