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

cm-t · Le 03/12/2010, à 00:15

version du prof

pattern = Pattern.compile("((src|href)=(|\')([^\"|^\']+)(\'))");

ma version (suis encore débutant en regex)

            pattern = Pattern.compile("(((src|href)=(\"|\')([^\"|^\']+)(\"|\'))|(url)(\\(\"|\\(\'|\\()([^\"]+)(\"\\)|\'\\)|^\\'\\)|^\"\\)))");

mais du coup je dois faire un

if(null==matcher.group(5)){
                    urlFound = matcher.group(9);

il manque toutes les url in javascript pour que le graber soit op, je verrai ça demain

'HDP;

Pylades · Le 03/12/2010, à 00:16

On m'assassine.

gnuuat · Le 03/12/2010, à 00:30

Milop

cm-t · Le 03/12/2010, à 01:09

Pylade a écrit :

On m'assassine.

'Nuit;

Dernière modification par cm-t (Le 03/12/2010, à 02:05)

nesthib · Le 03/12/2010, à 01:26

plop

Кຼزດ · Le 03/12/2010, à 02:19

points…

samυncle · Le 03/12/2010, à 02:47

samυncle · Le 03/12/2010, à 04:47

Tient je suis pas de message ?

Compteur du TdCCT · Le 03/12/2010, à 07:42

Scores totaux, depuis le début :

1) 1987    nesthib
2) 1910    samuncle
3) 1596    Pylade
4) 1227    Кຼزດ
5) 1019    cm-t
6) 896+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 704    \\Ouranos//
8) 691    Р☢w ! ✰ :mad: ✰ (эй !)
9) 658    helly
10) 431    gnuuat
11) 412    Lagierl
12) 293    tshirtman
13) 196    Askelon
14) 172    nathéo
15) 167    Kanor
16) 121    ǤƦƯƝƬ
17) 93    petifrancais
18) 78    edge_one
19) 70    gulp
20) 68    pierguiard
21) 59    kamui57
21) 59    The Uploader
23) 37    ilagas
24) 32    Le Rouge
25) 30    keny
26) 25    GentooUser
27) 24    ไ୦บเઢ'
28) 20    Morgiver
28) 20    CROWD
30) 19    xapantu
31) 18    Ph3nix_
32) 15    timsy
33) 14    kouskous
34) 12    stratoboy
34) 12    sailing
36) 11    alexises
36) 11    Crocoii
38) 10    Toineo
38) 10    NutMotion
38) 10    pseudovingtcinqcaracteres
38) 10    pfriedZ
42) 8    Mornagest
42) 8    Sherwood51
44) 7    Vista
45) 6    Zeibux
45) 6    ubuntlin
45) 6    asma.geek
48) 5    tendances-tdct
48) 5    Steap
50) 4    danychou56
50) 4    Neros
50) 4    Biaise
50) 4    totoflute
50) 4    pinballyoda ㋛
55) 2    SoJaS
55) 2    ceric
57) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,fbf9f4&chl=00h%20-%2000h59|01h%20-%2001h59|02h%20-%2002h59|04h%20-%2004h59|07h%20-%2007h59|21h%20-%2021h59|22h%20-%2022h59|23h%20-%2023h59&chd=t:2,2,2,1,2,1,1,2&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 03/12/2010, à 07:42

Scores de la période en cours :

1) 20    samuncle
2) 12    cm-t
3) 10    nesthib
3) 10    Кຼزດ
5) 9    Pylade
5) 9    grim7reaper
7) 5    \\Ouranos//
8) 4    Lagierl
8) 4    gnuuat
10) 2    helly

Pylades · Le 03/12/2010, à 16:02

cm-t a écrit :

Pylade a écrit :
On m'assassine.

'Nuit;

*PAN*

T'façons, les regex de Python, c'est le mal. C'est un des trucs qu'il faut vraiment qu'ils améliorent. C'est vraiment inégal, Python. D'un côté, leur gestion des entiers, par exemple, est splendide ; mais de l'autre, leur gestion des flottants est complétement nase depuis la 3.1, leur API pour les regex incompréhensible, et la syntaxe assez désagréable (pas de « ; » obligatoire, pas de délimiteur de blocs mais des « : » et une indentation obligatoire…).

C'est dommage, il s'en faudrait de peu pour que cela soit un très bon langage, mais sa communauté est tellement campée sur des positions, imbue d'elle-même et cultivant sa différence que cela semble compromis…

Dernière modification par Pylade (Le 03/12/2010, à 16:02)

tshirtman · Le 03/12/2010, à 16:07

Que dirait tu d'un développeur qui n'indenterait pas son code?
ah, tu peux mettre des ";" si ça te fait plaisir, ou si tu veux mettre deux instructions sur la même lignes… mais je ne vois pas l'intérêt de forcer à en mettre…
il y a des délimiteurs de blocs, c'est l'indentation elle même, c'est juste pas "{}" , les : ouais, on aurait peut être pu s'en passer, je sais pas, mais sémantiquement je trouve pas ça insensé…

Pylades · Le 03/12/2010, à 16:16

tshirtman a écrit :

Que dirait tu d'un développeur qui n'indenterait pas son code?

Ça dépend, même s'il est fort probable que je dise que c'est moche. Mais l'obligation, ça peut être emmerdant, en particulier dans l'interpréteur interactif…

tshirtman a écrit :

ah, tu peux mettre des ";" si ça te fait plaisir,

Certes, mais si ça n'est pas obligatoire ça n'a aucun intérêt.

tshirtman a écrit :

ou si tu veux mettre deux instructions sur la même lignes…

Oui, c'est vrai. Et c'est bien.

tshirtman a écrit :

mais je ne vois pas l'intérêt de forcer à en mettre…

Ça permet de délimiter clairement les instructions et de pouvoir aller à la ligne proprement (surtout quand il est conseillé de façon plus ou moins officielle d'avoir des lignes de 79 caractères).

tshirtman a écrit :

il y a des délimiteurs de blocs, c'est l'indentation elle même, c'est juste pas "{}"

Mais ça n'est pas pratique et pas flexible, et c'est là qu'est ma critique.

tshirtman a écrit :

les : ouais, on aurait peut être pu s'en passer, je sais pas, mais sémantiquement je trouve pas ça insensé…

Non, mais il y a plus simple et plus joli.

Et note que ma critique ne portait pas que sur la syntaxe !

Кຼزດ · Le 03/12/2010, à 16:25

Pylade a écrit :

cm-t a écrit :
Pylade a écrit :
On m'assassine.

'Nuit;
*PAN*

T'façons, les regex de Python, c'est le mal. C'est un des trucs qu'il faut vraiment qu'ils améliorent. C'est vraiment inégal, Python. D'un côté, leur gestion des entiers, par exemple, est splendide ; mais de l'autre, leur gestion des flottants est complétement nase depuis la 3.1, leur API pour les regex incompréhensible, et la syntaxe assez désagréable (pas de « ; » obligatoire, pas de délimiteur de blocs mais des « : » et une indentation obligatoire…).

Je mets un +1 à tshirtman, et je proteste, l'API pour les regex est tout à fait utilisable… Même si l'idéal serait d'avoir quelque chose d'aussi intégré que dans ruby, c'est pas bien compliqué (en comparant à php, java, ou d'autres).
Les ; ça sert à rien, les instructions sont déjà délimitées par les retours à la ligne (et les instructions multiligne se voient), donc ce serait rajouter un caractère en plus pour rien, juste pour contenter les gens qui ont l'habitude d'en mettre.

Mais ça n'est pas pratique et pas flexible, et c'est là qu'est ma critique.

En même temps, quelqu'un qui n'indente pas correctement son code (oui, j'ai des profs qui le font) ne mérite que la pendaison, donc ça n'a pas a être flexible.
Pour le cas de l'interpréteur, oui c'est chiant, mais je considère personnellement que l'interpéteur n'est pas fait pour développer un programme complexe, juste pour tester une API/un concept vite fait, et donc que ça ne poste pas trop d eproblèmes.

Oui, c'est vrai. Et c'est bien.

Exemples de cas où c'est utile ?

tshirtman · Le 03/12/2010, à 16:27

Je répondais juste sur la syntaxe, pour le reste, j'utilise pas souvent le moteur de regex, et en effet, c'est pas le truc qu'on saisit le plus rapidement, après, ben ça marche quoi… sur l'arithmétique des flottant, un bug est un bug… j'ai pas de réponse à ce niveau.

Pylade a écrit :

Ça dépend, même s'il est fort probable que je dise que c'est moche. Mais l'obligation, ça peut être emmerdant, en particulier dans l'interpréteur interactif…

ouais, dans l'interpréteur, c'est un peu chiant, mais bon, tu peux prendre ipython ou bpython pour ça, ils sont plus destinés à l'usage interactif.

Ça permet de délimiter clairement les instructions et de pouvoir aller à la ligne proprement (surtout quand il est conseillé de façon plus ou moins officielle d'avoir des lignes de 79 caractères).

ta notion de propreté ne serait elle pas fortement influencé par la syntaxe du C? (et puis bouffer un caractère pour rien, quand t'es limité à 79, excuse moi mais bon…)

Mais ça n'est pas pratique et pas flexible, et c'est là qu'est ma critique.

dans la plupart des cas tu peux ouvrir une parenthèse, et ne plus tenir compte de l'indentation, tu refermes quand t'as finis ton bloc…

Non, mais il y a plus simple et plus joli. tongue

exemple? (plus simple qu'un seul caractère, utilisé de la même façon qu'en langage habituel? ( un ":" sert en général a énoncer qu'on définit quelque chose)… je vois pas bien…

Pylades · Le 03/12/2010, à 17:55

Кຼزດ a écrit :

Pylade a écrit :
cm-t a écrit :

'Nuit;
*PAN*

T'façons, les regex de Python, c'est le mal. C'est un des trucs qu'il faut vraiment qu'ils améliorent. C'est vraiment inégal, Python. D'un côté, leur gestion des entiers, par exemple, est splendide ; mais de l'autre, leur gestion des flottants est complétement nase depuis la 3.1, leur API pour les regex incompréhensible, et la syntaxe assez désagréable (pas de « ; » obligatoire, pas de délimiteur de blocs mais des « : » et une indentation obligatoire…).
Je mets un +1 à tshirtman, et je proteste, l'API pour les regex est tout à fait utilisable… Même si l'idéal serait d'avoir quelque chose d'aussi intégré que dans ruby, c'est pas bien compliqué (en comparant à php, java, ou d'autres).
Les ; ça sert à rien, les instructions sont déjà délimitées par les retours à la ligne (et les instructions multiligne se voient), donc ce serait rajouter un caractère en plus pour rien, juste pour contenter les gens qui ont l'habitude d'en mettre.

Utilisable. Tout juste. Mais si tu vas par là, tout est utilisable, hein… Et puis bon, se vanter d'être mieux que PHP ou Java, excuses-moi mais je trouve ça triste…
Pour le délimiteur d'instruction, j'ai expliqué pour ça serait bien d'en avoir un.

Кຼزດ a écrit :

Pylade a écrit :
Mais ça n'est pas pratique et pas flexible, et c'est là qu'est ma critique.
En même temps, quelqu'un qui n'indente pas correctement son code (oui, j'ai des profs qui le font) ne mérite que la pendaison, donc ça n'a pas a être flexible.
Pour le cas de l'interpréteur, oui c'est chiant, mais je considère personnellement que l'interpéteur n'est pas fait pour développer un programme complexe, juste pour tester une API/un concept vite fait, et donc que ça ne poste pas trop de problèmes.

Ben si, ça pose problème. Que tu t'en foutes, c'est une chose, mais tu ne peux nier que ça pose problème. Et puis moi, je ne me considère pas comme suffisamment savant pour décréter qu'une indentation différente est nécessairement mauvaise. Il ne me viendrait jamais l'idée de faire une option courte « -` », et pourtant, ma bibliothèque le permet. Ça, c'est de la flexibilité : je ne la bride pas inutilement.

Кຼزດ a écrit :

Pylade a écrit :
Oui, c'est vrai. Et c'est bien.
Exemples de cas où c'est utile ?

Exemples de cas où n'écrire qu'une instruction par ligne est utile ?

tshirtman a écrit :

Je répondais juste sur la syntaxe, pour le reste, j'utilise pas souvent le moteur de regex, et en effet, c'est pas le truc qu'on saisit le plus rapidement, après, ben ça marche quoi…

Mais c'est tellement laborieux…

tshirtman a écrit :

sur l'arithmétique des flottant, un bug est un bug… j'ai pas de réponse à ce niveau.

Ben ouais, mais communauté est tellement imbue d'elle même que jamais ils n'admettrons de revenir à une version qui marche correctement ; cela serait reconnaître qu'il y a eu tort…

tshirtman a écrit :

Pylade a écrit :
Ça dépend, même s'il est fort probable que je dise que c'est moche. Mais l'obligation, ça peut être emmerdant, en particulier dans l'interpréteur interactif…
ouais, dans l'interpréteur, c'est un peu chiant, mais bon, tu peux prendre ipython ou bpython pour ça, ils sont plus destinés à l'usage interactif.

Qu'on puisse contourner les problèmes, est-ce une raison pour ne pas les résoudre proprement ?

tshirtman a écrit :

Pylade a écrit :
Ça permet de délimiter clairement les instructions et de pouvoir aller à la ligne proprement (surtout quand il est conseillé de façon plus ou moins officielle d'avoir des lignes de 79 caractères).
ta notion de propreté ne serait elle pas fortement influencé par la syntaxe du C? (et puis bouffer un caractère pour rien, quand t'es limité à 79, excuse moi mais bon…)

Je suis peut-être influencé par le C, mais bon, pour ce genre de choses il me semble que l'on peut tous tomber d'accord sur le fait que devoir se réfugier derrière des parenthèses ou des crochets pour couper une ligne si l'on ne veut pas céder à l'ignoble échappement de la nouvelle ligne, ce n'est pas vraiment propre…
(Et ton argument du caractère en plus est spécieux.)

tshirtman a écrit :

Pylade a écrit :
Mais ça n'est pas pratique et pas flexible, et c'est là qu'est ma critique.
dans la plupart des cas tu peux ouvrir une parenthèse, et ne plus tenir compte de l'indentation, tu refermes quand t'as finis ton bloc…

Ouais, le coup de la parenthèse… bof…

tshirtman a écrit :

Pylade a écrit :
Non, mais il y a plus simple et plus joli. tongue
exemple? (plus simple qu'un seul caractère, utilisé de la même façon qu'en langage habituel? ( un ":" sert en général a énoncer qu'on définit quelque chose)… je vois pas bien…

Ben, par exemple, des délimiteurs de blocs clairs et une indentation sans valeur sémantique.
Tu sais, le Whitespace n'était pas supposé servir d'exemple pour d'autres langages…

Dernière modification par Pylade (Le 03/12/2010, à 17:56)

tshirtman · Le 03/12/2010, à 19:04

pylade a écrit :

Exemples de cas où n'écrire qu'une instruction par ligne est utile ?

tu tombe bien bas… 1/ c'est très simple d'en écrire plusieurs 2/ c'est la plupart du temps bien plus clair d'en écrire une seule…

Mais c'est tellement laborieux…

moins qu'en C

Ben ouais, mais communauté est tellement imbue d'elle même que jamais ils n'admettrons de revenir à une version qui marche correctement ; cela serait reconnaître qu'il y a eu tort… roll

revenir en arrière n'est jamais une solution, prétendre que tu n'as pas sorties une version, c'est nul, stupide, infâme… corriger le bug pour la prochaine, oui c'est une solution…

Les listes sont ouvertes, tu peux aller aider… comprendre un peu mieux les enjeux et chercher une "bonne" solution.

Qu'on puisse contourner les problèmes, est-ce une raison pour ne pas les résoudre proprement ?

pourrir la solution élégante pour le cas ou on écrit le code, pour améliorer (très légèrement un cas d'utilisation de toutes façon peu adaptée à l'écriture de gros codes (c'est plus la gestion de l'historique qui me gène) franchement, bof…

Je suis peut-être influencé par le C, mais bon, pour ce genre de choses il me semble que l'on peut tous tomber d'accord sur le fait que devoir se réfugier derrière des parenthèses ou des crochets pour couper une ligne si l'on ne veut pas céder à l'ignoble échappement de la nouvelle ligne, ce n'est pas vraiment propre…
(Et ton argument du caractère en plus est spécieux.)
Ouais, le coup de la parenthèse… bof…

Non mais je rêve? tu veux m'imposer de mettre des {} partout sachant que 90% des cas n'en ont pas besoins, et tu rechine à utiliser "()" pour ls 10% qui restent? tu troll là en fait?

Ben, par exemple, des délimiteurs de blocs clairs et une indentation sans valeur sémantique. tongue

bref tuer l'une des spécificités majeures de ce langage, qui a tant d'effet sur la clareté du code, la légèreté de la syntaxe…

Tu sais, le Whitespace n'était pas supposé servir d'exemple pour d'autres langages… tongue[

Rolinh · Le 03/12/2010, à 19:28

Wouaaa, sacré débat là

Moi l'indentation forcée de Python c'est justement un truc que je trouve cool

Parce que par exemple, pour le C je ne dépasse jamais 80 colonnes et trois niveau d'imbrications (j'aime bien le coding style BSD KNF) (heu... en fait, sauf avec GTK parce que là c'est le massacre et on ne peut pas faire autrement... ) mais ça n'empêche pas certaines personnes de pondre des horreurs d'indentation (non non, je ne fais pas allusion au GNU style coding ). Pour cela, Python garantit une certaine homogénéité et c'est très bien.

Pylades · Le 03/12/2010, à 19:38

Sherwood51 a écrit :

Wouaaa, sacré débat là
Moi l'indentation forcée de Python c'est justement un truc que je trouve cool
Parce que par exemple, pour le C je ne dépasse jamais 80 colonnes et trois niveau d'imbrications (j'aime bien le coding style BSD KNF) (heu... en fait, sauf avec GTK parce que là c'est le massacre et on ne peut pas faire autrement... ) mais ça n'empêche pas certaines personnes de pondre des horreurs d'indentation (non non, je ne fais pas allusion au GNU style coding ). Pour cela, Python garantit une certaine homogénéité et c'est très bien.

Justement, je ne pense pas que cela soit bien. C'est brider le langage. Par exemple, certains ne voudrons pas rajouter un niveau d'indentation supplémentaire pour leurs fonctions externes (surtout ceux qui ont une niveau d'indentation de huit espaces, je pense ; les méchants ). Et bien si l'indentation a une valeur sémantique ils ne peuvent pas…

tshirtman a écrit :

Pylade a écrit :
Exemples de cas où n'écrire qu'une instruction par ligne est utile ?
tu tombe bien bas… 1/ c'est très simple d'en écrire plusieurs 2/ c'est la plupart du temps bien plus clair d'en écrire une seule…

Ben oui… mais c'était justement pour montrer que l'argument de mathieuI n'en était pas un !

tshirtman a écrit :

Pylade a écrit :
Mais c'est tellement laborieux…
moins qu'en C

Ben ça n'existe pas dans la bibliothèque standard du C (ce n'est pas son but) ; mais il y a des bibliothèques qui font ça très bien. Mais je ne penses de toutes façons par que l'utilisation de regex soit vraiment le propos du C.
En revanche, c'est déjà plus le propos de Python ; et sa gestion des regex est mauvaises. Il y a donc des progrès à faire.

tshirtman a écrit :

Pylade a écrit :
Ben ouais, mais communauté est tellement imbue d'elle même que jamais ils n'admettrons de revenir à une version qui marche correctement ; cela serait reconnaître qu'il y a eu tort… roll
revenir en arrière n'est jamais une solution, prétendre que tu n'as pas sorties une version, c'est nul, stupide, infâme… corriger le bug pour la prochaine, oui c'est une solution…

Ben, quand le bug constitue le fondement de tes modifications…
Imagine que Canonical décide de supprimer APT pour le remplacer par un wizard d'installation de paquets binaires. N'irais-tu pas crier au bug et demander le retour à ce qui se faisait avant ?

tshirtman a écrit :

Les listes sont ouvertes, tu peux aller aider… comprendre un peu mieux les enjeux et chercher une "bonne" solution.

Je l'ai déjà, la bonne solution. Retirer cette gestion foireuse du cœur du langage pour éventuellement l'incorporer comme une nouvelle possibilité de print. Mais cela ne tient pas qu'à moi…

tshirtman a écrit :

Non mais je rêve? tu veux m'imposer de mettre des {} partout sachant que 90% des cas n'en ont pas besoins, et tu rechine à utiliser "()" pour ls 10% qui restent? tu troll là en fait?

Je dis que j'aime bien les délimiteurs clairs et fonctionnels. Cependant, des parenthèses qui ne sont là que pour pallier à un manque de flexibilité du langage, bof… Mais oui, en effet je troll un peu, juste ce qu'il faut.

tshirtman a écrit :

Pylade a écrit :
Ben, par exemple, des délimiteurs de blocs clairs et une indentation sans valeur sémantique.
bref tuer l'une des spécificités majeures de ce langage, qui a tant d'effet sur la clareté du code, la légèreté de la syntaxe…

Faut croire que ça doit être subjectif, alors…

tshirtman a écrit :

Pylade a écrit :
Tu sais, le Whitespace n'était pas supposé servir d'exemple pour d'autres langages…

Sans blague, ça me fait vraiment penser au Whitespace, ça ! Pour un langage qui n'est pas destiné à devenir un shell, j'aime bien que les caractères d'espacement soient strictement équivalents quelle que soit leur qualité et leur quantité (sauf dans chaînes littérales, où de toutes façons des séquences d'échappement devraient être utilisés). Mais ça doit être subjectif aussi…

De toutes façons, arrêtons de parler de la syntaxe, ce n'est qu'un reproche mineur que je fait. Le principal est ailleurs.

Dernière modification par Pylade (Le 03/12/2010, à 19:43)

cm-t · Le 03/12/2010, à 19:48

euh, alors en fait c'est du java

et j'ai découvert le «?» qui devrai simplifier ma regex

Pylades · Le 03/12/2010, à 19:52

Ouais… (j'aurais dû m'en douter, en voyant le troisième bout de code).
Mais ça ne change rien du tout, ça m'a l'air exactement pareil que les regex de Python ; et c'est le mal aussi.
Nan mais franchement, a-t-on idée de faire un truc aussi difficilement utilisable ?

Sinon, le « ? », c'est pour le non-greedy, comme en Perl ?

Dernière modification par Pylade (Le 03/12/2010, à 19:53)

tshirtman · Le 03/12/2010, à 19:54

ta solution pour réparer les futures versions de python (pour les flottants) c'est pas ici qu'il faut la proposer… mais bon, leur parle pas de tes autres idées, tu serai reçus ^^.

Et non revenir en arrière ne voudrait pas dire je pense, changer juste ça, donc ce serait perdre d'autres avancées…

pour l'utilisation des parenthèses, c'est sortir du mode de fonctionnement normal du tokenizer, quand y'a besoin, python est un langage pragmatique, ils font le maximum pour que la syntaxe soit élégante et sémantiquement cohérente, mais parfois on a besoin de briser la règle, c'est une solution simple pour le faire.

Pylades · Le 03/12/2010, à 20:01

Ah, oui, bien sûr, il ne faut pas annuler les avancées de la 3.1. ^^
(Même s'il y a dedans quelques autres trucs qui m'ont moyennement plu.)

Pour les parenthèses, j'ai déjà dit que ce n'était pas ce qui me choquait le plus. Je peux le comprendre, même si je ne suis pas fan…

tshirtman · Le 03/12/2010, à 20:23

Y"a quoi comme différence dans la syntaxe des regex (pas l'api) entre python et perl? à ma connaissance c'est pratiquement la même chose, mais je fais pas de perl…

Rolinh · Le 03/12/2010, à 20:38

Pylade a écrit :

Justement, je ne pense pas que cela soit bien. C'est brider le langage. Par exemple, certains ne voudrons pas rajouter un niveau d'indentation supplémentaire pour leurs fonctions externes (surtout ceux qui ont une niveau d'indentation de huit espaces, je pense ; les méchants ). Et bien si l'indentation a une valeur sémantique ils ne peuvent pas…

Je ne suis pas sûr de comprendre ta remarque (je code avec un <TAB> de 8 sur 80 colonnes). Tu pourrais reformuler?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1826 Le 03/12/2010, à 00:15

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

#1827 Le 03/12/2010, à 00:16

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

#1828 Le 03/12/2010, à 00:30

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

#1829 Le 03/12/2010, à 01:09

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

#1830 Le 03/12/2010, à 01:26

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

#1831 Le 03/12/2010, à 02:19

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

#1832 Le 03/12/2010, à 02:47

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

#1833 Le 03/12/2010, à 04:47

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

#1834 Le 03/12/2010, à 07:42

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

#1835 Le 03/12/2010, à 07:42

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

#1836 Le 03/12/2010, à 16:02

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

#1837 Le 03/12/2010, à 16:07

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

#1838 Le 03/12/2010, à 16:16

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

#1839 Le 03/12/2010, à 16:25

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

#1840 Le 03/12/2010, à 16:27

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

#1841 Le 03/12/2010, à 17:55

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

#1842 Le 03/12/2010, à 19:04

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

#1843 Le 03/12/2010, à 19:28

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

#1844 Le 03/12/2010, à 19:38

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

#1845 Le 03/12/2010, à 19:48

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

#1846 Le 03/12/2010, à 19:52

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

#1847 Le 03/12/2010, à 19:54

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

#1848 Le 03/12/2010, à 20:01

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

#1849 Le 03/12/2010, à 20:23

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

#1850 Le 03/12/2010, à 20:38

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

Pied de page des forums