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

nesthib · Le 03/08/2011, à 02:19

plop

samυncle · Le 03/08/2011, à 03:08

nesthib a écrit :

plop

Compteur du TdCCT · Le 03/08/2011, à 06:42

Scores totaux, depuis le début :

1) 3953    nesthib
2) 3421    Πυλάδης
3) 3416    samuncle
4) 2525    Кຼزດ
5) 2011    cm-t
6) 1800+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1639    na kraïou
8) 880    helly
9) 877    \\Ouranos//
10) 752    tshirtman
11) 659    gnuuat
12) 565    Lagierl
13) 448    Rolinh
14) 431    The Uploader
15) 428    nathéo
16) 271    Kanor
17) 202    :!pakman
18) 196    Askelon
19) 121    ǤƦƯƝƬ
20) 103    kamui57
21) 95    HP
22) 93    petifrancais
23) 78    edge_one
23) 78    pierguiard
25) 70    gulp
26) 45    Le Rouge
27) 42    sakul
28) 37    ilagas
29) 36    xapantu
30) 30    keny
30) 30    Atem18
32) 26    gustare
32) 26    d10g3n
34) 25    GentooUser
34) 25    Morgiver
36) 24    ไ୦บเઢ'
36) 24    Steap
38) 20    CROWD
39) 18    Ph3nix_
40) 16    kouskous
41) 15    timsy
41) 15    pfranco
43) 12    stratoboy
43) 12    sailing
45) 11    alexises
45) 11    Crocoii
47) 10    Toineo
47) 10    NutMotion
47) 10    pseudovingtcinqcaracteres
47) 10    pfriedZ
47) 10    CasseTaTele
47) 10    Zeibux
47) 10    THS`
47) 10    golgoth42
47) 10    ꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳
56) 8    Mornagest
57) 7    Vista
58) 6    ubuntlin
58) 6    asma.geek
60) 5    tendances-tdct
60) 5    kinouchou
62) 4    danychou56
62) 4    Neros
62) 4    Biaise
62) 4    totoflute
62) 4    pinballyoda ㋛
62) 4    NLS le pingouin
62) 4    ceric
62) 4    Dice-Man
62) 4    Pylade
71) 3    Revan26914
71) 3    raspouillas
71) 3    sweetly
74) 2    SoJaS
75) 1    geenux
75) 1    ArzhurBZH
75) 1    monsieurweller

Répartition Posts/heure

Compteur du TdCCT · Le 03/08/2011, à 06:42

Scores de la période en cours :

1) 20    nesthib
1) 20    Πυλάδης
3) 16    na kraïou
4) 12    samuncle
5) 6    HP
6) 5    tshirtman
6) 5    cm-t
6) 5    \\Ouranos//
9) 3    Кຼزດ
10) 2    helly

helly · Le 03/08/2011, à 10:12

Question gestion d’erreurs (yep, la classe Reflecteur est faite, donc ptr_todo++)
Maintenant, la question est la gestion d’erreur :
1) En cours, on faisait toujours dériver nos classes d’erreur de je ne sais plus quelle classe de base (Error ou un nom dans le genre) mais dans le bouquin de Stroustrup, il ne le fait pas. Il a raison le barbu ? (en même temps, j’avais jamais trop compris l’intêret de faire dériver de cette classe Error.

2) Est ce que c’est forcément obligatoire de créer une classe erreur (par exemple Err_Rotor) en public de la classe Rotor ?
Les définitions de classe dans une classe, je trouve pas ça franchement lisible.
Si je créé une classe Err_Rotor qui n’a rien à voir avec Rotor c’est grave ?
La seule différence c’est qu’elle sera Err_Rotor e au lieu de Rotor::Err_Rotor e, nan ?

3) Obiwan Kenobi.

The Uploader · Le 03/08/2011, à 10:30

Les définitions de classe dans une classe, je trouve pas ça franchement lisible.

Bah dans un langage broken et bloated comme Java qui ne connait pas les struct (si je me souviens bien), j'pense que c'est toujours bien mieux de faire une inner class (aka "nested class") avec des champs publiques, que de faire une classe "outer" qui n'a que des getters et setters publics pour tous les champs de la classe, et dont les setters ne vérifient rien (un truc pas glop du tout, mais que j'ai vu souvent en cours de JEE), et :
-qui ne sera utilisé que par une seule classe interne au projet,
-qui n'a aucun sens a être "public".

=> http://download.oracle.com/javase/tutor … ested.html

helly · Le 03/08/2011, à 10:31

Ouais mais ça tombe bien, j’utilise pas un-langage-broken-et-bloated-comme-java .

The Uploader · Le 03/08/2011, à 10:32

Après, le lien explique bien les nested classes. ^^

Mais en C++, tu pourrais peut-être utiliser une struct, non ?
Bon après, si t'as struct commence à avoir des pointeurs de fonctions, s'pa une bonne idée.

Dernière modification par The Uploader (Le 03/08/2011, à 10:34)

helly · Le 03/08/2011, à 10:36

Mbof .

grim7reaper · Le 03/08/2011, à 10:47

helly a écrit :

1) En cours, on faisait toujours dériver nos classes d’erreur de je ne sais plus quelle classe de base (Error ou un nom dans le genre) mais dans le bouquin de Stroustrup, il ne le fait pas. Il a raison le barbu ? (en même temps, j’avais jamais trop compris l’intêret de faire dériver de cette classe Error.

J'ai tendance à faire hériter mes exceptions de std::logical_error quand c'est des trucs de la faute du codeur (genre le gus passe 0 à ma fonction division) et de std::runtime_error quand c'est des trucs imprévisibles (fichier qui ne s'ouvre pas).
Tiens, ils semblent d'accord avec moi :

http://stlplus.sourceforge.net/stlplus/docs/exceptions.html#common a écrit :

There are two sub-groups of exception: logic_error and runtime_error. These represent two different concepts:
Logic Error
Logic errors represent problems in the internal logic of a program; in theory, these are preventable, and even detectable before the program runs (e.g., violations of class invariants).
Runtime Error
Runtime errors represent problems outside the scope of a program; they cannot be easily predicted and can generally only be caught as the program executes.

Et pour ceux qui n'entre dans aucune de ces deux catégories tu peux hériter de std::exception.
Mais si tu ne veux pas en faire hériter t'es pas obligé (mais en général c'est mieux de le faire).

helly a écrit :

2) Est ce que c’est forcément obligatoire de créer une classe erreur (par exemple Err_Rotor) en public de la classe Rotor ?
Les définitions de classe dans une classe, je trouve pas ça franchement lisible.

Heu non, j'ai même jamais fait ça (et je l'ai rarement vu faire…)
Les classes imbriquées c'est pas mal quand tu fais des itérateurs par exemple (c'est comme ça que fait la STL), mais des exceptions bof

helly a écrit :

Si je créé une classe Err_Rotor qui n’a rien à voir avec Rotor c’est grave ?
La seule différence c’est qu’elle sera Err_Rotor e au lieu de Rotor::Err_Rotor e, nan ?

Bah non c'est pas grave, moi j'aurais fait comme ça.

helly a écrit :

3) Obiwan Kenobi.

Hum, 42 !

The Uploader a écrit :

Mais en C++, tu pourrais peut-être utiliser une struct, non ?

Tu sais, en C++, une struct c'est EXACTEMENT la même chose qu'une class.
Il n'existe qu'une unique différence : dans une class par défaut la visibilité est private, dans une struct c'est public.

Dernière modification par grim7reaper (Le 03/08/2011, à 11:03)

tshirtman · Le 03/08/2011, à 11:17

Si t'as une distinction module/classe, c'est bien d'avoir l'exception dans le même module que la classe qu'il concerne, mais dans la classe, ça me semble overkill… y'a vraiment que java pour faire ça

(après tu peux avoir une classe définit dans une classe, mais c'est quand tu t'aventure dans la méta programmation, les exceptions n'ont à mon sens, pas grand chose à voir).

edit: sinon je lis un peu sur pypy et RPython, ça manque un peu de doc… c'est dommage
http://morepypy.blogspot.com/2011/02/py … afted.html
http://morepypy.blogspot.com/2011/08/py … tring.html

:]

Dernière modification par tshirtman (Le 03/08/2011, à 11:18)

The Uploader · Le 03/08/2011, à 11:22

grim7reaper a écrit :

The Uploader a écrit :
Mais en C++, tu pourrais peut-être utiliser une struct, non ?
Tu sais, en C++, une struct c'est EXACTEMENT la même chose qu'une class.
Il n'existe qu'une unique différence : dans une class par défaut la visibilité est private, dans une struct c'est public.

Je sais, mais si helly n'aime pas les nested classes, ben c'était une solution de substitution uniquement visuelle.

Dernière modification par The Uploader (Le 03/08/2011, à 11:22)

grim7reaper · Le 03/08/2011, à 11:43

tshirtman a écrit :

http://morepypy.blogspot.com/2011/02/py … afted.html

Bench foireux, il ignore la LTO (d'ailleurs on lui fait remarquer dans les commentaires) avec gcc alors que pypy utilise un truc du genre.
Avec le LTO activé, le C est plus rapide…
Puis bon, je plussoie cette partie du dernier commentaire :

In general, if you want to compare the performance of languages, you're actually supposed to try to write the *fastest* implementation in each language. Not just some arbitrary one.

sinon ça n'a aucun sens.

Bon sinon ce mec est peut‑être fort en python, mais il ne sait pas coder en C ça saute au yeux (prototype de main foireux, manque le return, allo/desalloc dans une boucle…)

helly · Le 03/08/2011, à 11:46

Bon, elle commence à ressembler à quelquechose mon Énigma maintenant .

Gestion des erreurs [DONE]
Template [REPORTED]
.

Bon, j’vais mettre le code un peu plus en forme…

Dernière modification par helly (Le 03/08/2011, à 11:47)

grim7reaper · Le 03/08/2011, à 11:52

Faut pas avoir peur des templates en C++, c'est juste du Haskell obfusqué

Y'a vraiment un mec qui part sur cette comparaison (et il a pas tout à fait tord) et il pond des trucs assez hallucinant (genre des monades en C++ et avec il développe un petit EDSL )

Dernière modification par grim7reaper (Le 03/08/2011, à 11:53)

helly · Le 03/08/2011, à 12:25

Ouais, il faut juste que je saute le pas…

/me va faire commander le nouveau Stroustrup demain, ça y sera peut être super bien expliqué .

Dernière modification par helly (Le 03/08/2011, à 12:27)

Elzen · Le 03/08/2011, à 16:40

Bon, la majorité du reste (marque-pages, terminal et compagnie) étant relativement dans une forme qu'on pourrait presque qualifier d'à peu près releasable, retour sur la gestion des périphériques.

Alors, dans l'immédiat, le début marche : j'peux lister les périphs, en prenant en compte ma config additionnelle, monter/démonter les clefs (sous réserve que policykit soit bien configuré), et je gère aussi quelques montages virtuels avec fuse.

Ce qui est plus ennuyeux, c'est que j'ai remarqué après coup que les lecteurs CD n'avaient pas l'air gérés du tout, ce qui est quand même un peu dommage, quand on a autre chose qu'un netbook, et que je ne sais pas du tout comment récupérer les étiquettes des périphériques (autrement qu'à la manière crade : un grep sur $(ls -l /dev/disk/by-label), c'est super moche). Donc pour l'instant, ils s'appellent tous « Périphérique »…

Bon, donc retour sur les liens donnés par grim7reaper à l'époque, j'vais voir si je trouve quelque chose.

Edit : eh bah finalement, le code que grim7reaper avait sorti pour récupérer le point de montage (c'est page 35 de ce sujet-ci, si ça vous intéresse) m'a été très utile : après quelques expérimentations hasardeuses de mon côté où je n'ai rien réussi à récupérer de correct, j'ai simplement copié/collé son truc en remplaçant la propriété « DeviceMountPaths » par « IdLabel », et ça a marché direct. Donc encore merci

Par contre, pour les lecteurs CDs, j'suis encore au point mort. Mais je cherche.

Tiens, à ce propos, en allant rechercher lesdits liens, j'suis tombé sur ça :

The Uploader a écrit :

Thunar, le code est plus propre.

Justement, je viens de constater que bien que j'ai réglé policykit correctement (en tout cas, udisks en console marche très bien sans râler), Thunar, qui arrive pourtant à monter sans problème, me sort un gros [Not Authorized] quand j'essaye de démonter.
Et pourtant, heureusement, il démonte bien le disque correctement, même s'il râle. Curieux, non ?

Dernière modification par ArkSeth (Le 03/08/2011, à 18:59)

Pylades · Le 03/08/2011, à 18:26

Hey, grim7reaper, t’avais pas à une époque poster un lien vers un article qui expliquait comment émuler public et private en C ? Si oui et que t’as toujours le lien, tu pourrais le remettre s’il te plaît ?

tshirtman · Le 03/08/2011, à 19:12

grim7reaper a écrit :

tshirtman a écrit :
http://morepypy.blogspot.com/2011/02/py … afted.html
Bench foireux, il ignore la LTO (d'ailleurs on lui fait remarquer dans les commentaires) avec gcc alors que pypy utilise un truc du genre.
Avec le LTO activé, le C est plus rapide…

J'y connais rien, mais ils sont tous les deux d'accords que la LTO ne marchera pas pour des bibliothèques partagées, ce qui est important quand les projets grossissent… pypy à plus de potentiels d'optimisation que C…

Puis bon, je plussoie cette partie du dernier commentaire :
In general, if you want to compare the performance of languages, you're actually supposed to try to write the *fastest* implementation in each language. Not just some arbitrary one.
sinon ça n'a aucun sens.

En effet, mais c'est l'implémentation du même algorithme, sous sa forme la plus efficace, pas du programme, qui est importante.

Bon sinon ce mec est peut‑être fort en python, mais il ne sait pas coder en C ça saute au yeux (prototype de main foireux, manque le return, allo/desalloc dans une boucle…)

oui, le coup de l'alloc/désalloc fait partie du potentiel d'optimisation montré par pypy, si j'ai bien compris, que C ne peux pas voir, alors que les deux algos sont identiques…

helly · Le 03/08/2011, à 19:16

Πυλάδης a écrit :

Hey, grim7reaper, t’avais pas à une époque poster un lien vers un article qui expliquait comment émuler public et private en C ? Si oui et que t’as toujours le lien, tu pourrais le remettre s’il te plaît ?

Hey toi, ça en est où la lib qui-fait-jsais-plus-quoi que tu devais créer ?

grim7reaper · Le 03/08/2011, à 19:23

@Πυλάδης : Je ne crois pas non.
J'avais posté un lien pour faire du polymorphisme en C, mais pas du public/private.

Cela dit, y'a ptetr moyen de moyenner quelque chose avec un truc du genre :

/* Header. */
typedef struct priv_* priv;

typedef struct
{
    int public1;
    float public2;
    priv private_part;
} Obj;

/* Source. */
struct priv_
{
    int private1;
};

tshirtman a écrit :

J'y connais rien, mais ils sont tous les deux d'accords que la LTO ne marchera pas pour des bibliothèques partagées, ce qui est important quand les projets grossissent… pypy à plus de potentiels d'optimisation que C…

Oui, le coup des shared lib je ne le remets pas en cause.
C'est sûr que sur ce coup pypy à un avantage à faire du JIT.

tshirtman a écrit :

En effet, mais c'est l'implémentation du même algorithme, sous sa forme la plus efficace, pas du programme, qui est importante.

Mouais, ça dépend ce que tu veux comparer, mais si tu codes de la même manière en C qu'en Python y'a forcément un des deux langages qui sera désavantagé (Cf. la remarque suivante où le gars pond un code à vomir).
Faut tenir un minimum compte des spécificités de chaque langages quand même…

tshirtman a écrit :

oui, le coup de l'alloc/désalloc fait partie du potentiel d'optimisation montré par pypy, si j'ai bien compris, que C ne peux pas voir, alors que les deux algos sont identiques…

Rien à voir, le mec fait juste de la merde en barre. Il ne montre aucune optimisation là, il montre juste que Python gère automatiquement la mémoire et qu'en C tu dois le faire seul. Ho ptain, ça c'est un scoop !
Pourquoi il fait l'alloc/free dans la boucle ? C'est totalement WTFBBQ.
Il a pas besoin de trouzmille buffer, il fait l'alloc une fois, fait sa boucle et desalloue à la fin. Là c'est du code totalement moisi…
On en revient à ce que je dis plus haut, si tu tiens pas un minimum compte des particularités des langages dans un bench bah tu handicapes généralement l'un des deux dès le départ.

Dernière modification par grim7reaper (Le 03/08/2011, à 19:29)

tshirtman · Le 03/08/2011, à 19:43

cela dit, son premier code, sans malloc/free, et donc *avantagé par rapport au python*, tourne certes plus vite que la version avec, mais toujours deux fois plus lentement que le code python il ajoute les malloc/free pour mettre en avant le fait que python fait aussi ça derrière et qu'il faut en tenir compte pour être juste…

grim7reaper · Le 03/08/2011, à 19:53

tshirtman a écrit :

cela dit, son premier code, sans malloc/free, et donc *avantagé par rapport au python*,

En quoi il est avantagé ?
Je ne connais pas pypy mais je ne vois pas ce qui l'empêche d'utiliser l'allocation sur pile comme le C peut le faire.

tshirtman a écrit :

tourne certes plus vite que la version avec, mais toujours deux fois plus lentement que le code python

Oui j’ai fait, pypy c’est plus rapide sur ce coup.
Cela dit, le benchmark est pas super représentatif (on fait rarement 10000000 sprintf avec la même chaîne de format dans un programme…), mais bon ça permet quand même de mettre en avant un avantage de l'optimisation dynamique (mais je ne suis pas sûr que le gain soit si fort dans un vrai programme).

Faut pas se leurrer non plus, ce benchmark montre que PyPy peut faire des optimisations impossibles pour un compilo C (comme Haskell peut optimiser bien plus de truc qu'un compilo C).
Mais de là à dire « PyPy is faster than C », faut pas pousser. C'est peut‑être vrai mais ce n'est pas ce bench qui le prouvera, il faudrait bencher sur un vrai programme, version C vs version Python avec PyPy. Genre un algo de compression ou que que sais‑je, parce que ça c'est absolument pas représentatif.
Donc PyPy optimise plus de truc qu'un compilo C je suis OK, PyPy est plus rapide que C je suis pas encore convaincu.

tshirtman a écrit :

il ajoute les malloc/free pour mettre en avant le fait que python fait aussi ça derrière et qu'il faut en tenir compte pour être juste…

Bah non justement, il fait pas ça derrière. Ça me ferait mal que Python alloue/désalloue à chaque tour de boucle.

Dernière modification par grim7reaper (Le 03/08/2011, à 20:11)

Pylades · Le 03/08/2011, à 20:50

grim7reaper a écrit :

@Πυλάδης : Je ne crois pas non.
J'avais posté un lien pour faire du polymorphisme en C, mais pas du public/private.
Cela dit, y'a ptetr moyen de moyenner quelque chose avec un truc du genre :
/* Header. */
typedef struct priv_* priv;

typedef struct
{
    int public1;
    float public2;
    priv private_part;
} Obj;

/* Source. */
struct priv_
{
    int private1;
};

Merci. Enfin de toutes façons ce n’est pas grave puisque je ne peux pas faire ce que voulais (je n’avais pas assez réfléchi avant).

tshirtman · Le 03/08/2011, à 21:39

grim7reaper a écrit :

tshirtman a écrit :
cela dit, son premier code, sans malloc/free, et donc *avantagé par rapport au python*,
En quoi il est avantagé ?
Je ne connais pas pypy mais je ne vois pas ce qui l'empêche d'utiliser l'allocation sur pile comme le C peut le faire.

Ben c'est un langage dynamique, toute donnée est "construite" comme ça il me semble… enfin, après, c'est vrai que j'en sais rien, mais on déclare pas les variables, donc on les instancie bien par l'équivalent de malloc non? (pour avoir un stack, il faut connaitre sa taille au moment de l'appel de la fonction).

tshirtman a écrit :
tourne certes plus vite que la version avec, mais toujours deux fois plus lentement que le code python
Oui j’ai fait, pypy c’est plus rapide sur ce coup.
Cela dit, le benchmark est pas super représentatif (on fait rarement 10000000 sprintf avec la même chaîne de format dans un programme…), mais bon ça permet quand même de mettre en avant un avantage de l'optimisation dynamique (mais je ne suis pas sûr que le gain soit si fort dans un vrai programme).

Oui, c'est assez difficile de savoir quelle optimisation sera la plus intéressante "in the wild", mais le formattage de chaine, quand t'as tes sites webs bourrés de templates et qui crachent des pages en continue, ça peut avoir son importante (et sûrement à d'autres endroit), mais en même temps, qui ferait des sites webs en C? :] (hum, j'ai un collegue, qui veut en faire en C++, mais il a ses raisons et il est plutot bon en C++).

Faut pas se leurrer non plus, ce benchmark montre que PyPy peut faire des optimisations impossibles pour un compilo C (comme Haskell peut optimiser bien plus de truc qu'un compilo C).
Mais de là à dire « PyPy is faster than C », faut pas pousser. C'est peut‑être vrai mais ce n'est pas ce bench qui le prouvera, il faudrait bencher sur un vrai programme, version C vs version Python avec PyPy. Genre un algo de compression ou que que sais‑je, parce que ça c'est absolument pas représentatif.
Donc PyPy optimise plus de truc qu'un compilo C je suis OK, PyPy est plus rapide que C je suis pas encore convaincu.

Ben Il me semble que pypy benchmark beaucoup sur ce genre d'algos… mais bon, j'ai pas regardé leurs codes sources, et encore moins leurs équivalent C, ils comparent surtout avec CPython… http://speed.pypy.org

tshirtman a écrit :
il ajoute les malloc/free pour mettre en avant le fait que python fait aussi ça derrière et qu'il faut en tenir compte pour être juste…
Bah non justement, il fait pas ça derrière. Ça me ferait mal que Python alloue/désalloue à chaque tour de boucle.

Ben comme j'ai dit, j'en sais rien, mais je suis pratiquement sur qu'il alloue et relache (pour être collecté plus tard) à chaque tour de boucle… à moins que ce soit une optimisation faite après, mais en python, si tu fais ça, c'est comme ça…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1726 Le 03/08/2011, à 02:19

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

#1727 Le 03/08/2011, à 03:08

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

#1728 Le 03/08/2011, à 06:42

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

#1729 Le 03/08/2011, à 06:42

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

#1730 Le 03/08/2011, à 10:12

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

#1731 Le 03/08/2011, à 10:30

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

#1732 Le 03/08/2011, à 10:31

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

#1733 Le 03/08/2011, à 10:32

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

#1734 Le 03/08/2011, à 10:36

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

#1735 Le 03/08/2011, à 10:47

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

#1736 Le 03/08/2011, à 11:17

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

#1737 Le 03/08/2011, à 11:22

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

#1738 Le 03/08/2011, à 11:43

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

#1739 Le 03/08/2011, à 11:46

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

#1740 Le 03/08/2011, à 11:52

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

#1741 Le 03/08/2011, à 12:25

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

#1742 Le 03/08/2011, à 16:40

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

#1743 Le 03/08/2011, à 18:26

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

#1744 Le 03/08/2011, à 19:12

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

#1745 Le 03/08/2011, à 19:16

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

#1746 Le 03/08/2011, à 19:23

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

#1747 Le 03/08/2011, à 19:43

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

#1748 Le 03/08/2011, à 19:53

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

#1749 Le 03/08/2011, à 20:50

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

#1750 Le 03/08/2011, à 21:39

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

Pied de page des forums