/* Topic des codeurs [6] */

Pylades · Le 27/10/2011, à 00:25

Rolinh a écrit :

Pourquoi un char? C'est aberrant. De plus, c'est une fausse idée de croire que si tu stockes dans un unsigned char (sur moins de bits qu'un int donc) tu y gagneras en performance (raisonnement type "un char occupe moins de place car les registres sont de 32 bits (exemple) de même que les entrées de la pile"). En fait, c'est même la plupart du temps le contraire (à moins que tu travailles avec une arithmétique modulo 256). J'ai un peu la flemme d'aller fouiller mais si tu y tiens, je peux te donner un exemple tiré de mon cours de programmation système de l'année dernière avec des bouts de codes en C et ce que ça donne en assembleur.

Bah je dis juste que ça rentre dans un unsigned char. Après, je me doute bien qu’il y a des chances qu’on ne gagne rien en faisant comme ça ; l’optimisation et l’assembleur ce n’est pas du tout ce qui m’amuse. C’est juste que puisque l’on peut faire tenir dans plus petit, je le ferais, au cas où. Mais ce n’est pas du tout un truc auquel j’attache de l’importance, c’était juste pour le plaisir de faire une remarque à la con.

Rolinh a écrit :

Πυλάδης a écrit :
C’est un peu bancal, t’aurais meilleur compte à utiliser un ternaire.
puts(rep > nb_alea ? "C’est plus." : "C’est moins.");
Ouais, voilà une belle démonstration de code rendu illisible...

Bah moi je trouve ça carrément plus lisible comme ça ! Une ligne au lieu de cinq ou six, et surtout une ligne dont on comprend tout de suite le sens, et pas de branchements redondants.

Rolinh a écrit :

Sinon, pour l'histoire du printf, pas besoin d'être si dur.

C’est juste qu’on a répété douze fois que printf c’est pour les sorties formatées, donc je m’emporte peu (mais juste un petit peu, ce n’est pas bien méchant).

tshirtman a écrit :

vous devriez discuter de ça dans un pad je pense

Dernière modification par Πυλάδης (Le 27/10/2011, à 00:26)

Pylades · Le 27/10/2011, à 00:31

Au fait, il faudra me relancer à propos de deux bugs dans Touhy.

kamui57 · Le 27/10/2011, à 05:36

Biaise : un ordi c'est bête, ça fait uniquement ce que tu lui dis, ce qui est dans une des langues qu'il a apprises. Il a appris certains mots du C, avec la syntaxe qui va avec (printf, int, tout ça), et leur signification. Mais empty_buf il connaît pas, alors faut que tu lui dises ce que c'est (la signification) et la syntaxe à utiliser. Je reprends ton dernier code.

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

void empty_buf(void); /* comment utiliser empty_buf */
int main (void) /* comment utiliser main */

{
/* ce que fait le main */
}

Tu as défini ce que fait main et comment l'utiliser, dans ce main tu utilises empty_buf, tu as défini comment utiliser empty_buf, mais tu n'as pas dit ce que fait empty_buf, donc le pc ne le sait pas et râle. Il faut donc rajouter la définition de empty_buf.

/*
 * empty the stdin buffer
 */
void
empty_buf(void)
{
    int chr = 0;

    while (chr != '\n' && chr != EOF)
        chr = getchar();
}

pour que le programme sache quoi faire.

Tu peux l'ajouter au-dessus et en dessous. Il faut simplement qu'au-dessus du main, la syntaxe de toutes les nouvelles fonctions (ici empty_buf) soient définie. Si tu mets la définition de la fonction au-dessus du main, la syntaxe étant définie en même temps, pas de problème. Si tu la mets en-dessous du main, il faut une ligne au-dessus du main qui explique la syntaxe de la fonction, c'est celle que tu as écrite.

Dites-moi si j'ai écrit des conneries

grim7reaper · Le 27/10/2011, à 08:52

Hello World!
I’m back (en fait depuis hier soir, mais bon comme hier je crachais du sang à tire-larigo et j’étais plus ou moins HS j’ai retardé mon message de retour ^^')

Вiɑise a écrit :

@ grim : canal carpien nan ? ça me paraitrait logique pour un codeur. :3

Nope, mais bien tenté
En fait je ne code pas autant qu’on pourrait le croire. Je suis plus dans de genre Knuth (à mon niveau bien sûr)

Donald Knuth a écrit :

my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study

Вiɑise a écrit :

Oué nan décidément je trouve pas de fonction pour vider le buffer qui fonctionne… Et google me dit de faire fflush (stdin)

Justement, fflush c’est pas bon pour stdin, je l’ai dit quand je t’ai parlé de la fonction :

/me a écrit :

C’est l’idée, d’ailleurs il y a une fonction qui a un nom tout à fait adapté : fflush.
Le souci c’est qu’il ne faut pas l’utiliser sur les flux en lecture (donc stdin, celui que lisent scanf et getchar), donc faut passer par des fonctions comme Rolinh et moi on a posté.

Le man confirme

man 3 fflush a écrit :

The standards do not specify the behavior for input streams.

Et comme stdin signifie STAndard INput :]

ArkSeth a écrit :

À ma fac, apparemment (c'était avant que j'y arrive, vu que j'ai fait un DUT avant d'embrayer sur la L3, donc j'n'ai pas vu leur apprentissage du C, donc j'n'ai pas vu ça moi-même), ils apprennent à mettre -Wall et -pedantic. Ce qui n'est pas mal ^^

Là où je suis, en première année aussi ils ont voulu donner cette habitude. Avec plus ou moins de succès…

Rolinh a écrit :

De plus, c'est une fausse idée de croire que si tu stockes dans un unsigned char (sur moins de bits qu'un int donc) tu y gagneras en performance (raisonnement type "un char occupe moins de place car les registres sont de 32 bits (exemple) de même que les entrées de la pile"). En fait, c'est même la plupart du temps le contraire (à moins que tu travailles avec une arithmétique modulo 256).

Yep, c’est comme les mecs qui utilisent les champs de bits pour gagner en vitesse : bah des fois c’est l’inverse.
Sinon je plussoie ton exemple en assembleur.
D’une manière générale, char c’est pour les caractères, si on veut des entiers il y a short, int, long (voire long long).
C’est encore une fois une histoire de sémantique, on utilise le bon type selon ce qu’on veut faire.

Rolinh a écrit :

Sinon, pour l'histoire du printf, pas besoin d'être si dur. C'est aussi un peu une question de religion car en pratique, niveau perf, c'est kifkif mais si, et je suis d'accord, c'est plus correct d'utiliser puts pour des chaînes non-formatées.

C’est un peu plus que de la religion. C’est de la sémantique.
Arpès oui, niveau perf on sens rarement la différence mais c’est pas une raison. Et comme je l’ai dit, si on tiens vraiment à utiliser printf pour ça, la bonne forme c’est :

printf("%s", "foobar");

Et pas

printf("foobar");

Parce que là, OK c’est gentil, mais le jour où foobar sera une variable ça peut faire mal.

Rolinh a écrit :

Je suis curieux de voir ce qu'en pense grim mais j'ai l'impression qu'il va plutôt se ranger de mon côté (je peux me tromper).

Les ternaires, en général, je ne suis pas contre tant que ça reste simple. Ça peut même apporter un gain de lisibilité.
Dans le cas présent, le ternaire est simple, mais on l’utilise dans un appel de fonction donc c’est discutable. Par contre, dans le cas d’une débutante comme Вiɑise, je suis pas sûr que le ternaire soit plus lisible (perso, quand je débutais, les ternaires était une aberration pour moi).

Sinon pour l’histoire de la déclaration de empty_buf, je laisse Вiɑise lire post de kamui57.
Si ça ne passe toujours pas, j’essayerai d’expliquer à mon tour ^^

Dernière modification par grim7reaper (Le 27/10/2011, à 08:54)

Rolinh · Le 27/10/2011, à 09:14

Comme je l'ai dit, je ne suis pas contre les ternaires. C'est le fait de faire l'opération en argument de son puts qui me dérange.
Sinon, je pense idem: il est inutile d'embrouiller Biaise avec l'opérateur ternaire à ce niveau.
Et je m'étais fait la même remarque à propos du char mais je n'avais pas détaillé (/me, plus tôt -> "Pourquoi un char? C'est aberrant.").

Ok pour l'histoire du printf. Toujours est-il que ce n'est pas ce qu'il y a de plus problématique dans le code de Biaise.

Titus007 · Le 27/10/2011, à 10:52

@Biaise :

Comme tu n'as pas eu le cours sur les fonctions et leur appels (et qu'en tant que très débutant je peux comprendre que tu aies du mal avec les explications des experts), je tente un cours rapide (veuillez m'excuser si je raconte n'importe quoi).

Grosso modo, j'ai l'impression que tu as appris à coder en mettant toutes les lignes de codes dans ton main (en dehors du header).

Ça donne :

#define blabla
int main(void)
{
   /* blabla */
}

Rolinh te dit d'utiliser la fonction empty_buf() or elle n'existe dans les librairies standard que tu définies au début.

Comment marche une fonction non définie ? (Au passage, ça marche pareil pour les fonctions standard, sauf qu'elles se retrouvent dans les librairies définies au début.)
L'intérêt des fonctions c'est quand tu te retrouves avec cette situation :

#define blabla
int main(void)
{
   /* blabla */
   /* bout de code */
   /*  blabla2 */
   /* même bout de code */
   /* blabla3 */
   /* re même bout de code */
   /* etc */
}

En fait, tu vas créer ta propre fonction qui va reprendre le bout de code. La façon de faire, c'est de sortir le code du main et le mettre dans une fonction que tu vas appeler dans le main.

#define blabla

void fonction(void)
{
   /* bout de code */
}

int main(void)
{
   /* blabla */
   fonction();
   /*  blabla2 */
   fonction();
   /* blabla3 */
   fonction();
   /* etc */
}

Le compilo va remplacer ton appel de fonction par les bouts de code que tu as défini hors de ton main. Comme il lit ligne par ligne, on définit la fonction avant le main. Sauf que le programmeur veut en général lire le main d'abord, et mettre les fonctions qu'on a définies ensuite car elles l'intéressent moins. La façon élégante de le faire est comme ceci :

#define blabla

void fonction(void);

int main(void)
{
   /* blabla */
   fonction();
   /*  blabla2 */
   fonction();
   /* blabla3 */
   fonction();
   /* etc */
}

void fonction(void)
{
   /* bout de code */
}

On dit au compilo qu'on a défini une fonction, donc qu'il y aura du code à intégrer dans le main, mais on écrit la fonction après le main puisque c'est le main qui est en général le plus important pour le programmeur.

Dans ton cas, ça donnerait quelque chose de ce genre :

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

void empty_buf(void);

int main (void)
{
    int nb_alea=0;
    int rep=0;
    char choix=' ';
    do
    {
        srand (time (NULL));
        nb_alea=rand() %100;
        
        do
        {
            printf("Devinez un nombre entre 0 et 99 : \n");
            scanf("%d",&rep);
            if (rep>nb_alea)
                printf("C'est moins !\n");
            else
                if (rep<nb_alea)
                    printf("C'est plus !\n");
        }                    
        while (rep!=nb_alea);
        
        empty_buf();
    
        printf("Félicitations !\nPour rejouer, tapez R : \n");
        scanf("%c",&choix);
    }
    while ((choix=='R') || (choix=='r'));       
    return 0;
}

void empty_buf(void)
{
    int chr = 0;

    while (chr != '\n' && chr != EOF)
        chr = getchar();
}

Tu vois que la fonction empty_buf() est définie hors du main, et qu'elle est appelé dans ton main par la ligne :

empty_buf();

Les void en plus sont pour définir la syntaxe de la fonction, le premier étant pour dire que ta fonction ne retournera rien, le deuxième pour dire que tu n'as rien besoin de mettre en arguments (entre les parenthèses).

Voilà, j'espère que j'aurais été plus clair et que tu auras compris l'intérêt des fonctions.

(Désolé à Rolinh, grim7reaper et kamui57 mais en tant que débutant moi-même, si elle ne connaît pas les fonctions, vos explications sont un peu obscures et prennent des raccourcis qui ne sont pas prenables...)

grim7reaper · Le 27/10/2011, à 10:57

Titus007 a écrit :

(Désolé à Rolinh, grim7reaper et kamui57 mais en tant que débutant moi-même, si elle ne connaît pas les fonctions, vos explications sont un peu obscures et prennent des raccourcis qui ne sont pas prenables...)

Perso, je n’ai pas abordé ce sujet donc c’est normal que mes explications soient obscures (c’est rien de le dire )

Titus007 · Le 27/10/2011, à 11:07

Oups, désolé.

Вiɑise · Le 27/10/2011, à 11:14

Merci Titus, c'est une victoire ! En fait dans l'exemple de Rolinh certains trucs étaient en commentaires et je croyait que c'était fait exprès, qu'il fallait laisser.
Bon et puis avec tes explications ça va mieux.

Bien maintenant que je passe à la suite de mon manuel. ^^

Rolinh · Le 27/10/2011, à 11:18

Ah ben ça c'est de l'explication! Bravo.

Titus007 a écrit :

(Désolé à Rolinh, grim7reaper et kamui57 mais en tant que débutant moi-même, si elle ne connaît pas les fonctions, vos explications sont un peu obscures et prennent des raccourcis qui ne sont pas prenables...)

Rhô, je ne pensais pas que mes explications étaient obscures (ça doit être le côté obscure de la force, toussa ) surtout que je lui ai répondu plusieurs fois en étant à chaque fois plus précis. Je n'ai juste pas donné des exemples de code comme tu l'as fait mais tout le reste était là.
En même temps, c'est assez difficile de se mettre dans la tête de quelqu'un qui en est au tout tout début (et pourtant, j'enseigne un peu de programmation à temps partiel) donc je m'excuse si j'oublie des trucs dans mes explications. C'est plus facile aussi quand tu as la personne à côté de toi: tu vois tout de suite quand elle fait des gros yeux.

Вiɑise · Le 27/10/2011, à 11:28

C'est un peu ça oui. Tfaçon chuis pas capable de comprendre sans un exemple complet et qui marche.
Et à l'IUT j'ai un prof dans le cours duquel on ne fait jamais aucun exercice, je te laisse deviner combien je rame…

Titus007 · Le 27/10/2011, à 11:28

Rolinh a écrit :

En même temps, c'est assez difficile de se mettre dans la tête de quelqu'un qui en est au tout tout début (et pourtant, j'enseigne un peu de programmation à temps partiel) donc je m'excuse si j'oublie des trucs dans mes explications. C'est plus facile aussi quand tu as la personne à côté de toi: tu vois tout de suite quand elle fait des gros yeux.

Clairement ! J'ai eu l'occasion de faire des petits cours de math à des jeunes, et physiquement on voit tout de suite quand ça ne va pas.

Vos explications étaient très bien, pour peu que la personne en face sache comment définir une fonction. Il manquait juste cette connaissance à Biaise pour comprendre.

grim7reaper · Le 27/10/2011, à 11:42

Вiɑise a écrit :

C'est un peu ça oui. Tfaçon chuis pas capable de comprendre sans un exemple complet et qui marche.

Bah c’est toujours mieux d’avoir des exemples, et de pratiquer.
Surtout en programmation, la pratique c’est extrêmement important. Plus tu pratiques, plus tu t’améliores.
La théorie c’est bien et ça a aussi son importance, mais si tu ne mets pas en pratique ça ne sert à rien (surtout en programmation).

Sinon, petite remarque sur ton code : tu appelles srand dans ta boucle do{…}while(…);. C’est déconseillé, en général on appelle cette fonction une seule fois dans le programme (donc avant la boucle). C’est rand qu’il faut appeler à chaque tour (ça c’est bon, tu l’as bien fait).

Le truc c’est que srand fait beaucoup de trucs compliqués et potentiellement long pour démarrer le générateur de nombre pseudo-aléatoire. Donc, en général, on le fait une bonne fois pour toute au début du programme. rand lui sert juste à tirer un nombre du générateur, ça c’est rapide et on peut le faire à chaque tour de boucle.

Вiɑise · Le 27/10/2011, à 17:42

C'est fait, bonne idée en effet. Merci

Elzen · Le 27/10/2011, à 23:19

grim7reaper a écrit :

Là où je suis, en première année aussi ils ont voulu donner cette habitude. Avec plus ou moins de succès…

J'garantis pas que tout le monde ait vraiment accroché (m'enfin, je n'garantis pas non plus que tout le monde ait vraiment accroché au C tout court). Mais ceux avec qui je code le plus souvent, en tout cas, ils ont ça, et de temps en temps, j'leur fais même accepter quelques arguments de plus ^^

Πυλάδης a écrit :

Au fait, il faudra me relancer à propos de deux bugs dans Touhy.

/me attrape Πυλάδης et le rebalance par la fenêtre.

Ah, nan, c'était pas ça ?

Dernière modification par ArkSeth (Le 27/10/2011, à 23:19)

Rolinh · Le 28/10/2011, à 09:56

Plop les codeurs,

j'aimerais sécuriser mon serveur dédié et je suis en train de me poser plusieurs questions.
Alors je ne parle pas des aspects à propos de la configuration de ssh, utilisation de fail2ban et autres mais plutôt à propos des données.
J'avais dans l'idée d'écrire un script qui fait du backup. L'idée serait d'avoir un serveur qui tourne chez moi en permanence (mon ancien serveur@home fera l'affaire) avec un service ssh et que, mettons 2X par jour, mon serveur dédié s'auto-backup sur mon serveur@home.
Sauf que voilà, utiliser simplement une solution à partir de rsync serait un peu stupide. En effet, si je me fais hacker mon serveur, corrompre des fichiers ou même effacer des fichiers, j'aurais l'air malin si mon script de backup vient de faire un rsync et que je retrouve les mêmes fichiers corrompu sur mon serveur de backup.

Avez-vous une suggestion intéressante pour éviter ce problème? J'hésitais presque à faire un dépôt git qui contiendrait l'entier de mes /home, /etc, /var et /srv mais ce n'est sûrement pas optimal comme solution.

Dernière modification par Rolinh (Le 28/10/2011, à 09:58)

valAa · Le 28/10/2011, à 10:41

Hello, suis pas un grand spécialiste mais voilà mon avis :
Il faut conserver plusieurs sauvegardes.
À toi de fixer ensuite le temps de rétention. Soit automatique (tu gardes par exemple trois semaines de sauvegardes, et tu vériffies au moins une fois tous les 15j que ton serveur va bien), soit manuelle (tu supprimes une sauvegarde complète après avoir vérifié que la suivante a été réalisée correctement et qu'il n'y a pas eu de pertes de données entre les deux).
Cela va dépendre un peu de ton espace disque.
Pour éviter une explosion de l'occupation du disque, on fait alors de la sauvegarde incrémentale http://fr.wikipedia.org/wiki/Sauvegarde … 9mentielle
Par exemple : une sauvegarde complète par semaine, et une sauvegarde incrémentale par jour.
Si tu mets trois jours à te rendre compte que ton serveur a été compromis, tu restaure la dernière complète avant l'attaque, puis les différentes incrémentales jusqu'à l'attaque.
Tout ça peut se mettre en place avec rsync, soit dans un script soit avec un frontend sympa muni d'une interface web comme BackupPC.

Dernière modification par valAa (Le 28/10/2011, à 10:43)

tshirtman · Le 28/10/2011, à 11:00

Une bonne solution est la sauvegarde incrémentale, backuppc est pas mal pour ça, il permet d'utiliser rsync en backend, et se connecter avec une clé ssh, tu peux configurer les sauvegardes pleines et incrémentales (genre une full par semaine, incrémentale entre temps, et le tout gardé 3 semaines), c'est pas mal, les dossiers sauvegardés ne sont pas exactement identiques, au sens qu'ils sont sous un format particulier, donc c'est mieux de tout faire par l'interface web, mais au pire, c'est pas impossible de s'en sortir en se baladant dans l'arborescence de sauvegarde, c'est son seul point noir à mon sens. La restauration de données marche très bien.

edit: arg, j'avais pas lus le message de valAa en entiers avant de poster xD

Dernière modification par tshirtman (Le 28/10/2011, à 11:01)

Rolinh · Le 28/10/2011, à 11:19

Merci pour ces réponses. Je me pencherais dessus ce weekend, quand j'aurais un peu de temps devant moi.

Sinon, il y a un/des spécialiste(s) Matlab/Octave par ici?

Dernière modification par Rolinh (Le 28/10/2011, à 11:19)

sweetly · Le 28/10/2011, à 11:26

Rolinh a écrit :

Merci pour ces réponses. Je me pencherais dessus ce weekend, quand j'aurais un peu de temps devant moi.
Sinon, il y a un/des spécialiste(s) Matlab/Octave par ici?

J'eus fait il y a longtemps. Dis-voir ton problème, peut-être me rappellerai-je de quelques trucs.

Rolinh · Le 28/10/2011, à 11:50

Pour l'instant je n'en ai pas trop mais ça risque de venir dans la soirée
=> J'ai un TP d'imagerie numérique à finir pour 23h59. Je dois faire de l’échantillonnage et quantification de signal afin d'en ressortir l'image. Il y aussi une évaluation du bruit dans une image par la méthode du PSNR. Enfin bon, ça va m'occuper et je risque bien de manquer un peu de connaissances en ce qui concerne octave bien que je l'utilise depuis déjà 2ans (mais relativement occasionnellement)...

Dernière modification par Rolinh (Le 28/10/2011, à 11:51)

The Uploader · Le 28/10/2011, à 12:15

salut

Euh je sais pas si ça te concerne, mais en tout cas dans les comparaisons de codecs, le PSNR est dépassé depuis longtemps : il adore les images floues car il n'aime pas les "améliorations psycho visuelles" (qui prennent en compte les failles de l'oeil humain) et est de fait très éloigné de la qualité subjective d'une image par rapport à une autre (ce qu'en dirait un humain, quoi). La méthode "propre" (mais qui a aussi ses défauts si je me souviens bien), c'est le SSIM : http://fr.wikipedia.org/wiki/Structural_Similarity

Voir par exemple la 6ème comparaisons des codecs AVC de MSU : http://www.compression.ru/video/codec_c … h264_2010/

Dernière modification par The Uploader (Le 28/10/2011, à 12:18)

Rolinh · Le 28/10/2011, à 12:33

@ The Uploader: je te fais confiance et pense que tu as sûrement raison. Le truc, c'est que le but ici n'est pas de déterminer qu'elle est la meilleure façon de comparer la compression d'une image mais simplement d'implémenter une méthode de test, en l’occurrence le PSNR (même si elle est peut-être mauvaise). Il s'agit simplement d'un exercice. D'ailleurs, il nous est demandé de comparer avec ce qu'en pense notre propre œil, ce n'est peut-être pas pour rien ^^

sweetly · Le 28/10/2011, à 12:45

Rolinh a écrit :

Pour l'instant je n'en ai pas trop mais ça risque de venir dans la soirée
=> J'ai un TP d'imagerie numérique à finir pour 23h59. Je dois faire de l’échantillonnage et quantification de signal afin d'en ressortir l'image. Il y aussi une évaluation du bruit dans une image par la méthode du PSNR. Enfin bon, ça va m'occuper et je risque bien de manquer un peu de connaissances en ce qui concerne octave bien que je l'utilise depuis déjà 2ans (mais relativement occasionnellement)...

Octave et/ou Matlab sont obligatoires ? Pas moyen de faire ça en python, avec numpy et matplotlib ? Enfin bon, sur un sujet comme ça, je ne vois pas trop ce qui pourrait te bloquer, de toute manière, niveau codage.

Rolinh · Le 28/10/2011, à 13:01

C'est Matlab ou Java obligatoire. M'enfin, ça sera bien plus vite fait avec Matlab. C'est vrai que ça ne devrait pas être bloquant mais j'imagine qu'utiliser des fonctions comme rgb2gray ou imhist est prohibé parce que sinon... bah... il ne reste pas grand chose à faire.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1201 Le 27/10/2011, à 00:25

Re : /* Topic des codeurs [6] */

#1202 Le 27/10/2011, à 00:31

Re : /* Topic des codeurs [6] */

#1203 Le 27/10/2011, à 05:36

Re : /* Topic des codeurs [6] */

#1204 Le 27/10/2011, à 08:52

Re : /* Topic des codeurs [6] */

#1205 Le 27/10/2011, à 09:14

Re : /* Topic des codeurs [6] */

#1206 Le 27/10/2011, à 10:52

Re : /* Topic des codeurs [6] */

#1207 Le 27/10/2011, à 10:57

Re : /* Topic des codeurs [6] */

#1208 Le 27/10/2011, à 11:07

Re : /* Topic des codeurs [6] */

#1209 Le 27/10/2011, à 11:14

Re : /* Topic des codeurs [6] */

#1210 Le 27/10/2011, à 11:18

Re : /* Topic des codeurs [6] */

#1211 Le 27/10/2011, à 11:28

Re : /* Topic des codeurs [6] */

#1212 Le 27/10/2011, à 11:28

Re : /* Topic des codeurs [6] */

#1213 Le 27/10/2011, à 11:42

Re : /* Topic des codeurs [6] */

#1214 Le 27/10/2011, à 17:42

Re : /* Topic des codeurs [6] */

#1215 Le 27/10/2011, à 23:19

Re : /* Topic des codeurs [6] */

#1216 Le 28/10/2011, à 09:56

Re : /* Topic des codeurs [6] */

#1217 Le 28/10/2011, à 10:41

Re : /* Topic des codeurs [6] */

#1218 Le 28/10/2011, à 11:00

Re : /* Topic des codeurs [6] */

#1219 Le 28/10/2011, à 11:19

Re : /* Topic des codeurs [6] */

#1220 Le 28/10/2011, à 11:26

Re : /* Topic des codeurs [6] */

#1221 Le 28/10/2011, à 11:50

Re : /* Topic des codeurs [6] */

#1222 Le 28/10/2011, à 12:15

Re : /* Topic des codeurs [6] */

#1223 Le 28/10/2011, à 12:33

Re : /* Topic des codeurs [6] */

#1224 Le 28/10/2011, à 12:45

Re : /* Topic des codeurs [6] */

#1225 Le 28/10/2011, à 13:01

Re : /* Topic des codeurs [6] */

Pied de page des forums