/* Topic des codeurs couche-tard [1] */

grim7reaper · Le 15/06/2010, à 23:56

Pylade a écrit :

Premièrement, je me demande si je dois aller complétement vers de l’ADT. Cela aurait le mérite de fournir une API cohérente, mais j’ai quand-même des scrupules à faire des fonctions pour juste positionner un drapeau booléen. Je sais bien que dans un langage complétement orienté objet, on appliquerait la sacro-sainte loi de l’encapsulation ; mais demander l’utilisation d’une fonction pour une action aussi triviale qu’un opt->takes_value=1;, j’ai du mal.

Perso, je le ferais mais ça n'engage que moi.
C'est une habitude que j'ai prise au cas où le code évoluerait plus tard. Je me dis que ça ne coûte quasiment rien et que ça peut faire gagner beaucoup de temps.
Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).

Aujourd'hui c'est juste un "=1" mais si un jour te prend l'envie pour une raison x ou y de faire une initialisation plus complexe, des vérifications plus poussés, des traitements en plus,… et bien ça ne change absolument rien pour l'utilisateur : il appelle toujours ta fonction.
Dans le cas contraire, il doit réécrire tout le code qui initialise le champ takes_value et ça ce n'est pas cool pour lui.
Après c'est mon avis, c'est à toi de voir comment tu le sens et selon ta façon de coder.

Ensuite, j’hésite à protéger l’utilisateur contre un SIGSEGV s’il donne un NULL à manger à un destructeur. E.D. le faisait, dans un exemple de code, mais je ne suis pas sûr que dans mon cas cela soit très appréciable. En effet, j’ai conçu l’API de sorte à ce que l’utilisateur n’ait à aucun moment le besoin ni même l’envie de passer NULL aux destructeurs. Un tel cas a de très fortes chances de résulter de l’erreur de l’utilisateur ; et donc l’avertir qu’il a fait quelque chose de pas net via un SIGSEGV ne me semble pas une mauvaise chose.

Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )
Par exemple, mpc (music player daemon) SIGSEGV dès que tu te gourres dans ses options en ligne de commande et je trouve ça super chiant (en plus je doit nettoyer les coredump générés après).
Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".
Encore une fois ça n'engage que moi.

Et enfin troisièmement, j’hésite à créer un destructeur partiel pour mes structures gérant les options. Je m’explique : pour effectuer le traitement des options, j’ai besoin que les structures soient renseignée sur plusieurs points, notamment la liste des arguments de la ligne de commande qui permettrons d’activer une option. Or, une fois le traitement des options effectué, ces renseignements deviennent inutiles. Comme les structures ne sont pas immédiatement détruites, car elles restent nécessaires pour en tirer le résultat du traitement des options, et influencer le comportement du programme. Donc j’hésite à faire un destructeur partiel qui serait appelé à la fin de ma fonction principale de traitement. Cela permettrait d’économiser un peu de mémoire, mais pas beaucoup (je suis quand-même assez économe en mémoire). Je me demande si cela vaut vraiment la peine de détruire les structures dédiées aux options en deux fois… pour un gain assez faible.

Je n'ai pas tout saisi (pour moi une structure = un destructeur donc j'ai du mal à saisir le concept de destructeur partiel ) et ça semble assez spécifique à l'architecture de ta bibliothèque donc je ne prononcerais pas (ça m'éviteras de dire des conneries aussi ).

@nesthib : un bot IBM .

@ArkSeth : En GTK je suppose, non ?
Peut-être en écoutant ce qui se passe sur la fenêtre root (et ses filles).
Pour chopper la root tu peux voir ça, peut-être qu'une adaptation au clavier est faisable.
Mais je ne suis pas sûr d'avoir compris ton besoin exact.

Dernière modification par grim7reaper (Le 16/06/2010, à 00:05)

nesthib · Le 16/06/2010, à 00:03

cm-t · Le 16/06/2010, à 00:27

'Nuit

helly · Le 16/06/2010, à 00:48

plop

Pylades · Le 16/06/2010, à 00:48

nesthib a écrit :

si tu veux pour wget par contre ton code suivant est largement améliorable (cf. mon post)

Quitte à être vraiment performant :

wget -q 'http://forum.ubuntu-fr.org/extern.php?action=online_full&type=rss' -O - | sed -e 's/^[^"]*"/<a/' -e 's/<[^>]*>//g' -e 's/, /\n/g' | uniq -dc

Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr… ^^ Et puis pour le -c à uniq, mouais, bof… pas très important…

nesthib a écrit :

/me & /you dans un combat de ce soir ^^

nesthib · Le 16/06/2010, à 01:06

Pylade a écrit :

Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr…

vala t'as tout compris ! puisque sed est en mémoire autant s'en servir

Кຼزດ · Le 16/06/2010, à 01:15

Plop

Pylades · Le 16/06/2010, à 01:25

grim7reaper a écrit :

Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).

Oui, justement, je profite de n’avoir pas avoir encore fait de release pour pouvoir figer l’API de haut niveau dans la forme qui me semble la meilleure.

Mais tu as probablement raison.
Cela me semble lourd de demander à l’utilisateur de une fonction pour une simple assignation. D’autant plus qu’il faudra alors lui expliquer que j’ai besoin d’un static const char* à un moment. Alors que si je le laisse faire l’assignation, il est sensé s’en rendre compte (quoique… il est toujours bon de le mentionner).

Mais je crois que je vais m’en remettre à cette sage décision.

grim7reaper a écrit :

Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )

Ce n’est pas toi qui m’avait recommandé de mettre le pointeur passé au destructeur à NULL pour obtenir un SIGSEGV au cas où un codeur négligeant réutilise une structure détruite ?

grim7reaper a écrit :

Par exemple, mpc (music player daemon) SIGSEGV dès que tu te gourres dans ses options en ligne de commande et je trouve ça super chiant (en plus je doit nettoyer les coredump générés après).

Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…
(Tiens, tant qu’on est sur ce sujet, tu savais que dpkg SIGSEGV ? Ce n’est vraiment pas sérieux, ça ; il faudrait que je retrouve le sujet.)

grim7reaper a écrit :

Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".

J’étais plutôt partisan des destructeurs void…

grim7reaper a écrit :

Je n'ai pas tout saisi (pour moi une structure = un destructeur donc j'ai du mal à saisir le concept de destructeur partiel ) et ça semble assez spécifique à l'architecture de ta bibliothèque donc je ne prononcerais pas (ça m'éviteras de dire des conneries aussi ).

En fait l’idée c’était de détruire une structure en deux fois, histoire de libérer un peu de mémoire entre temps. Mais ça ne fait gagner que peu de mémoire, et si le dev est sérieux, il s’arrange pour détruire complétement toutes mes structures le plus tôt possible.
Donc oublie.

Pylades · Le 16/06/2010, à 01:29

nesthib a écrit :

Pylade a écrit :
Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr…
vala t'as tout compris ! puisque sed est en mémoire autant s'en servir

Nan, mais même en partant du principe que tr est déjà en mémoire, la mise en place et l’utilisation du pipe doivent à elles seules suffire à annuler le peu de perfs gagnées…

nesthib · Le 16/06/2010, à 01:36

Pylade qui s'auto-flagelle

edit : rien

Dernière modification par nesthib (Le 16/06/2010, à 02:01)

grim7reaper · Le 16/06/2010, à 01:47

Pylade a écrit :

grim7reaper a écrit :
Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).
Oui, justement, je profite de n’avoir pas avoir encore fait de release pour pouvoir figer l’API de haut niveau dans la forme qui me semble la meilleure.
Mais tu as probablement raison.
Cela me semble lourd de demander à l’utilisateur de une fonction pour une simple assignation. D’autant plus qu’il faudra alors lui expliquer que j’ai besoin d’un static const char* à un moment. Alors que si je le laisse faire l’assignation, il est sensé s’en rendre compte (quoique… il est toujours bon de le mentionner).
Mais je crois que je vais m’en remettre à cette sage décision.

Figer une API c'est un truc relatif, rare sont les bibliothèques qui n'évoluent plus du tout.
C'est pour ça que je fais comme ça, c'est "au cas où".
Ça peut être inutile la majorité du temps, mais quand ça bouge au moins je suis prêt .

grim7reaper a écrit :
Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )
Ce n’est pas toi qui m’avait recommandé de mettre le pointeur passé au destructeur à NULL pour obtenir un SIGSEGV au cas où un codeur négligeant réutilise une structure détruite ?

Oui, mais là tu n'a aucun moyen de la prévenir autrement.
S'il libère le truc et le réutilise ça fonctionneras parfois et d'autre fois ça planteras. Le fait de mettre à NULL fera toujours planter et il pourra trouver son erreur, là il n'y a aucun autre moyen.
Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.

Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…

Oui, mais le dev n'est pas censé savoir si quand la lib SIGSEGV c'est normal parce qu'il a merdé ou si c'est un bug de ta part.

grim7reaper a écrit :
Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".

J’étais plutôt partisan des destructeurs void…

Ha, mais moi aussi je suis partisan des destructeurs en void .
Là je parlait des fonctions en général. Mettre un exit() ou autre truc qui kill le programme dans une lib je trouve que ça la fout mal.
C'est à l'appelant de gérer ça, toi tu ne connais pas le contexte donc tu ne quittes pas le prog du gars à l'arrache, normal quoi.

Pylades · Le 16/06/2010, à 02:58

grim7reaper a écrit :

Figer une API c'est un truc relatif, rare sont les bibliothèques qui n'évoluent plus du tout.
C'est pour ça que je fais comme ça, c'est "au cas où".
Ça peut être inutile la majorité du temps, mais quand ça bouge au moins je suis prêt .

Oui, t’as raison. C’est comme quand tu me disais de réduire la taille d’une de mes fonctions. Je l’ai fait un peu à contre-cœur, mais sachant que c’était sage. Et maintenant je suis bien content de l’avoir fait.
Donc on ne sait jamais, je pourrais un jour être bien content de passer par une fonction pour ça.

grim7reaper a écrit :

Oui, mais là tu n'a aucun moyen de la prévenir autrement.
S'il libère le truc et le réutilise ça fonctionneras parfois et d'autre fois ça planteras. Le fait de mettre à NULL fera toujours planter et il pourra trouver son erreur, là il n'y a aucun autre moyen.

Argument reçu, je suis convaincu.

grim7reaper a écrit :

Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.

Mouais, m’enfin avec free ce n’est pas pareil…

grim7reaper a écrit :

Pylade a écrit :
Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…
Oui, mais le dev n'est pas censé savoir si quand la lib SIGSEGV c'est normal parce qu'il a merdé ou si c'est un bug de ta part.

C’est vrai. Je n’y avais pas pensé. Je suis encore un peu un noob…

grim7reaper a écrit :

Ha, mais moi aussi je suis partisan des destructeurs en void .
Là je parlait des fonctions en général. Mettre un exit() ou autre truc qui kill le programme dans une lib je trouve que ça la fout mal.
C'est à l'appelant de gérer ça, toi tu ne connais pas le contexte donc tu ne quittes pas le prog du gars à l'arrache, normal quoi.

Tout à fait d’accord.
Pour moi, le SIGSEGV avait plus valeur d’avertissement que de sortie du programme, mais à la réflexion, je conçois que cela soit interprété comme tel.

Bon, j’ai mes réponses, je vais suivre mes deux premières pistes et laisser tomber la troisième.
Merci beaucoup !

grim7reaper · Le 16/06/2010, à 03:09

Pylade a écrit :

grim7reaper a écrit :
Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.
Mouais, m’enfin avec free ce n’est pas pareil…

C'est vrai, c'est un choix arbitraire que j'ai fait.
J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .

Je suis encore un peu un noob…

Ça va, là tu commences à en savoir plus que le gars moyen sur le C .
Et puis, on est tous le noob de quelqu'un.

Merci beaucoup !

De rien.

Allez BN World !

Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).

Pylades · Le 16/06/2010, à 03:24

grim7reaper a écrit :

J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .

Et fclose est l’archétype du destructeur…

Sinon, j’y pense (à l’instant, je dois être un peu fatigué) : si je documente le fait que NULL fait crasher, ça passe, non ? Cette question continue de me titiller un peu…

grim7reaper a écrit :

Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).

Ben bon courage pour tes révisions, alors.

Et moi je vais me pieuter. \o/
BN.

samυncle · Le 16/06/2010, à 03:27

.

nesthib · Le 16/06/2010, à 03:32

grim7reaper · Le 16/06/2010, à 12:58

Hello World !

Tiens, le compteur a eu un coup de mou.
Le responsable commence a être fatigué de marquer 10 points tout les soirs

Pylade a écrit :

grim7reaper a écrit :
J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .
Et fclose est l’archétype du destructeur…
Sinon, j’y pense (à l’instant, je dois être un peu fatigué) : si je documente le fait que NULL fait crasher, ça passe, non ? Cette question continue de me titiller un peu…

Dans l'absolu oui ça passe (fclose() le fait bien).
Après moi je ne le ferais pas car ce n'est pas mon "style", mais le faire n'est pas incorrect.
Sinon fclose() n'est pas plus l'archétype du destructeur que free() (qui libère aussi une structure).

grim7reaper a écrit :
Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).
Ben bon courage pour tes révisions, alors.

Merci

Dernière modification par grim7reaper (Le 16/06/2010, à 12:59)

Compteur du TdCCT · Le 16/06/2010, à 12:59

Scores totaux, depuis le début :

1) 525    samuncle
2) 440    nesthib
3) 435    Pylade
4) 393+5  grim7reaper ** bonus +5 pour avoir répondu à ce post : ./viewtopic.php?pid=3486252#p3486252 **
5) 341    mathieuI
6) 239    cm-t
7) 189    helly
8) 163    gnuuat
9) 121    ǤƦƯƝƬ
10) 107    tshirtman
11) 83    petifrancais
12) 50    \\Ouranos//
13) 38    pierguiard
14) 37    ilagas
15) 30    keny
16) 25    GentooUser
17) 23    Kanor
18) 19    Le Rouge
19) 18    Ph3nix_
20) 14    kouskous
21) 12    stratoboy
21) 12    sailing
23) 11    Lagierl
24) 10    CROWD
24) 10    Toineo
26) 9    xapantu
27) 8    Mornagest
28) 7    Vista
29) 6    Zeibux
29) 6    Р'tite G☢gole :mad:
31) 5    timsy
32) 4    danychou56
32) 4    Neros
32) 4    Biaise
35) 3    gulp
36) 1    ceric
36) 1    pfriedK
36) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,c0c0c0&chl=00h%20-%2000h59|01h%20-%2001h59|02h%20-%2002h59|03h%20-%2003h59|11h%20-%2011h59|21h%20-%2021h59|23h%20-%2023h59&chd=t:4,6,1,4,3,1,6&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 16/06/2010, à 12:59

Scores de la période en cours :

1) 150    Pylade
2) 130    samuncle
3) 115    grim7reaper
4) 113    nesthib
5) 106    mathieuI
6) 66    gnuuat
7) 56    helly
7) 56    cm-t
9) 32    tshirtman
10) 20    keny
11) 15    \\Ouranos//
11) 15    ǤƦƯƝƬ
13) 13    petifrancais
13) 13    pierguiard
15) 9    Kanor
16) 7    Vista
17) 5    sailing
17) 5    timsy
19) 4    Toineo
19) 4    Lagierl
19) 4    xapantu
22) 3    gulp
22) 3    Р'tite G☢gole :mad:
24) 2    kouskous
24) 2    Mornagest

grim7reaper · Le 16/06/2010, à 13:46

42 points me séparent de Pylade (si on ne tient pas compte du bonus de 5 points).

Pylades · Le 16/06/2010, à 13:55

grim7reaper a écrit :

Tiens, le compteur a eu un coup de mou.
Le responsable commence a être fatigué de marquer 10 points tout les soirs

Ouais, c’est un peu ça, j’avoue… Enfin, une bonne nuit (ou bonne matinée) va m’a permis de bien récupérer. C’est ça va mieux, parce qu’hier, ce n’était tip-top au réveil (heureusement, le soir, les démons de minuit me tiennent éveillé et en forme).

Du coup, j’ai complétement oublié à nesthib que j’avais encore amélioré la ligne permettant de détecter les doublons :

wget -q 'http://forum.ubuntu-fr.org/extern.php?action=online_full&type=rss' -O - | sed -e 's/: </\n</' -e 's/<[^>]*>//g' -e 's/, /\n/g' | uniq -dc

Tellement cool que je l’ai mis en alias.
Tiens, pourquoi j’ai perdu la coloration syntaxique dans le .bash_aliases ? À cause des double quotes que j’ai été obligé de mettre ?
Hum, apparemment ça ne vient pas des double quotes, mais quand même de la ligne permettant de détecter les doublons… Bizarre… Investigations futures possibles.

nesthib · Le 16/06/2010, à 20:03

euh… en quoi c'est amélioré ? parce que la je vois pas

grim7reaper · Le 16/06/2010, à 21:19

Plop à 1 point.

J'assure mes arrières, ce soir je risque de ne pas faire long feu…

Dernière modification par grim7reaper (Le 17/06/2010, à 04:43)

Pylades · Le 16/06/2010, à 21:20

J’ai encore amélioré le première expression, que j’avais déjà améliorée, qui passe de

s/^[^"]*"/<a/

à

s/: </\n</

ce qui est, tu en conviendra, à la fois plus court et plus efficace en termes de perfs.

Ainsi, le boulot est fait avec une seule courte ligne de commande, et pas un script bidon complet.

Elzen · Le 16/06/2010, à 21:52

grim7reaper a écrit :

@ArkSeth : En GTK je suppose, non ?
Peut-être en écoutant ce qui se passe sur la fenêtre root (et ses filles).
Pour chopper la root tu peux voir ça, peut-être qu'une adaptation au clavier est faisable.
Mais je ne suis pas sûr d'avoir compris ton besoin exact.

Mon besoin exact, c'est d'avoir des raccourcis claviers, tout simplement ^^
Rien de particulièrement particulier, j'voudrais savoir le faire dans le cas général (genre comme un lecteur de musique, pouvoir effectuer une action (mettre en pause, par exemple) alors que la fenêtre principale est fermée et qu'il n'y a plus qu'une icône dans le systray, ce genre de trucs. Ça m'embête de savoir que c'est possible sans trouver comment ^^)

Sinon, dans la série des questions bizarres, j'ai peut-être mal fait un truc, mais je n'arrive pas à mettre une image de fond à une barre de menus (vous savez, avec un set_app_paintable sur le widget et un set_back_pixmap sur sa fenêtre une fois réalisé)... elles ont une situation différente des autres composants, ou j'ai juste loupé mon coup, selon vous ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#126 Le 15/06/2010, à 23:56

Re : /* Topic des codeurs couche-tard [1] */

#127 Le 16/06/2010, à 00:03

Re : /* Topic des codeurs couche-tard [1] */

#128 Le 16/06/2010, à 00:27

Re : /* Topic des codeurs couche-tard [1] */

#129 Le 16/06/2010, à 00:48

Re : /* Topic des codeurs couche-tard [1] */

#130 Le 16/06/2010, à 00:48

Re : /* Topic des codeurs couche-tard [1] */

#131 Le 16/06/2010, à 01:06

Re : /* Topic des codeurs couche-tard [1] */

#132 Le 16/06/2010, à 01:15

Re : /* Topic des codeurs couche-tard [1] */

#133 Le 16/06/2010, à 01:25

Re : /* Topic des codeurs couche-tard [1] */

#134 Le 16/06/2010, à 01:29

Re : /* Topic des codeurs couche-tard [1] */

#135 Le 16/06/2010, à 01:36

Re : /* Topic des codeurs couche-tard [1] */

#136 Le 16/06/2010, à 01:47

Re : /* Topic des codeurs couche-tard [1] */

#137 Le 16/06/2010, à 02:58

Re : /* Topic des codeurs couche-tard [1] */

#138 Le 16/06/2010, à 03:09

Re : /* Topic des codeurs couche-tard [1] */

#139 Le 16/06/2010, à 03:24

Re : /* Topic des codeurs couche-tard [1] */

#140 Le 16/06/2010, à 03:27

Re : /* Topic des codeurs couche-tard [1] */

#141 Le 16/06/2010, à 03:32

Re : /* Topic des codeurs couche-tard [1] */

#142 Le 16/06/2010, à 12:58

Re : /* Topic des codeurs couche-tard [1] */

#143 Le 16/06/2010, à 12:59

Re : /* Topic des codeurs couche-tard [1] */

#144 Le 16/06/2010, à 12:59

Re : /* Topic des codeurs couche-tard [1] */

#145 Le 16/06/2010, à 13:46

Re : /* Topic des codeurs couche-tard [1] */

#146 Le 16/06/2010, à 13:55

Re : /* Topic des codeurs couche-tard [1] */

#147 Le 16/06/2010, à 20:03

Re : /* Topic des codeurs couche-tard [1] */

#148 Le 16/06/2010, à 21:19

Re : /* Topic des codeurs couche-tard [1] */

#149 Le 16/06/2010, à 21:20

Re : /* Topic des codeurs couche-tard [1] */

#150 Le 16/06/2010, à 21:52

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums