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

Rolinh · Le 15/06/2011, à 23:19

grim7reaper a écrit :

Bon courage !

Merci

grim7reaper a écrit :

Rolinh a écrit :
Je suis justement en train de revoir les optimisations en C et ça me fait direct penser à grim ^^
Hum c'est bizarre ça, je ne vois vraiment pas pourquoi
C'est quoi les optimisations en question ?

^^
En l'occurrence, elles sont spécifiques au processeur avec lequel on a travaillé en assembleur (ARM7).
Par exemple, pourquoi il faut préférer travailler avec des int(32bits signés) plutôt que des short(16bits signés), vu que les instructions sont sur 32bits. Ou encore utiliser un unsigned int si possible quand on sait qu'on va faire des divisions. Sinon, pourquoi utiliser un do while plutôt qu'un for en fonction des valeurs utilisées, etc. C'est vraiment intéressant en tout cas.

Pylades · Le 15/06/2011, à 23:35

ArkSeth a écrit :

Pylade a écrit :
Hum, false c’est plutôt fait pour être utilisé dans un contexte logique, non ? Pour moi NaN est bien plus explicite et approprié, mais c’est du détail.
Question de cohérence : NaN ne convient pas aux fonctions autres que numériques. Or il m'apparaît plus judicieux d'avoir un comportement cohérent (renvoyer faux en cas d'erreur peut être utilisé dans tout un tas de cas), quitte à rajouter des cas possibles en plus pour les comportements spécifiques (genre une fonction de division renverrait false si on lui demande de diviser un truc non numérique, et NaN si on lui demande de diviser par zéro).
Après, c'est vrai que pour un langage comme PHP, on pourrait aussi inventer une autre constante particulière, qui correspondrait au retour d'erreur « standard ».

Euh, comme on utilise ça dans un contexte où un nombre est attendu, renvoyer NaN ça ne me paraît pas délirant.

ArkSeth a écrit :

Pylade a écrit :
Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !
Ce n'est pas le rôle de certains opérateurs de comparaisons, comme supérieur, inférieur ou équivalence, où effectivement, il suffit que les types soient comparables.
En revanche, on peut, dans certains cas, avoir besoin de tester, plus qu'une équivalence, une égalité réelle. Un truc qui est capable de te dire que « 1,0 » et « 1 » ne sont pas tout à fait la même chose, c'est bien une comparaison.

Ben tu ne pourrais pas te rendre compte avant que t’es en train de comparer un flottant et un entier ? Tu ne trouves pas que cela serait plus sain ?

ArkSeth a écrit :

Pylade a écrit :
T’utilises deux implémentations différentes de la même interface en même temps ?
Ça arrive, de temps à autres. Genre pour faire des tests, quand tu as deux implémentations possibles et que tu veux savoir laquelle est la mieux.
Ou alors quand une classe hérite d'une autre, genre en GTK, ComboBox et ComboBoxText.
Idem, je ne dis pas que c'est le truc dont on se sert tous les jours, je dis que dans certains cas, ça peut être indispensable.

Mais tu ne les utilises pas en même temps, non ? ’fin là, j’ai la grosse flemme de réfléchir donc on va passer.

ArkSeth a écrit :

Pylade a écrit :
Et pourquoi donc, on peut additionner des chaînes et des entiers ? Ça a quoi comme sens ?
Ça a comme sens que PHP, comme le Shell, reçoit ses arguments (ce qui est passé en GET ou en POST en plus des argv habituels) nécessairement comme étant des chaînes de caractères.
Quand tu ouvres l'interpréteur python et que tu tapes, par exemple, « 2 », c'est une chaîne de caractère qui est envoyée, mais elle est automatiquement castée en entier. Et donc quand tu tapes « 2 + i », si la variables i a précédemment été définie comme entière, tu demandes bien, techniquement, d'additionner un entier à une chaîne de caractères.
Tu le demandes à l'interpréteur python, et il te fait les casts automatiques qui vont bien pour pouvoir effectuer l'opération. La seule différence avec PHP, c'est que PHP, qui se veut permissif, ne caste pas les arguments extérieurs dès leur réception (devoir différencier, dans le formulaire HTML, « 2 » et « "2" » comme on le fait dans l'interpréteur python, ce serait quand même sacrément lourd), et permet donc de les autocaster en interne.
Je ne dis pas que c'est le meilleur choix, mais c'est un choix qui se tient.

J’espère vraiment que tu as posté ça trop vite et sans réfléchir.

ArkSeth a écrit :

Pylade a écrit :
Tiens, tu ne m’avais pas répondu pour ça :
Comme je l'ai dit, mon objectif n'est pas de défendre PHP bec et ongles. J'vous laisse le descendre tant que vous voulez, tant que vous utilisez pour cela des arguments recevables. Et pour le coup, effectivement, ç't'assez moche. Que les caractères blancs soient zappés, ça se comprend, le « plop », moins.

Mais ce n’est pas juste moche, c’est un bug ! Ce n’est pas un comportement voulu !
À ton avis, comment j’ai deviné que ça allait faire ça ? Ben tout simplement, j’ai vu le bout de code qui provoque le support accidentel de l’octal (et de l’hexadécimal par la même occasion). Ce même bout de code provoque ce comportement. Tout simplement parce que l’argument est passé à strtol sans aucune vérification, par un mec qui n’a pas lu le manuel de la fonction et qui ne gère pas les erreurs.

Bon, et quand bien même tous ces défauts n’en seraient pas (mais je ne suis absolument pas convaincu) ou seraient corrigés, il resterait question cruciale : c’est quoi l’intérêt de PHP ? Non parce qu’un langage qui a des défauts (beaucoup, énormément), qui a une syntaxe moche et qui en plus n’a aucun avantage, ça sert à quoi ? PHP a pour seuls avantages Apache et d’être historique. Pour moi, ce ne sont pas des avantages recevables pour une utilisation sérieuse aujourd’hui.

ArkSeth a écrit :

Pylade a écrit :
En Python, print n’est qu’un raccourci vers, par défaut, sys.stdout.write en proposant quelques opération en plus (mais tu peux choisir d’utiliser un autre flux). C’est une aberration pour un langage OO ?
Tu peux régler cet « alias » pour qu'il pointe sur autre chose ? Et qu'entends-tu par « en proposant quelques opérations en plus », exactement ?
J'suppose que si on voit ça comme un genre de variable autodéclarée pointant vers une méthode précise d'un objet précis, et pas comme une commande à part, ça peut être recevable…

Oui, on peut lui passer un autre flux, par un argument nommé.
Et les opérations en plus, c’est pouvoir passer plusieurs arguments, de n’importe quel type, ils sont automatiquement convertis en chaîne, choisir le séparateur d’arguments… ce genre de petite facilités. Mais non, ça ne pointe pas sur une méthode d’un objet précis, c’est une fonction globale, relativement simple, que n’importe qui pourrait ré-implémenter.

grim7reaper a écrit :

Pylade a écrit :
l’inconsistance de l’ordre des arguments des fonctions d’IO
Heu c'est quoi le soucis là ?
Si c'est le fait de passer le FILE en premier, c'est pas plus con qu'autre chose. Tu dis où tu veux écrire avant de dire ce que tu veux écrire.

Ben la plupart du temps le FILE* arrive à la fin, mais pas pour fprintf et fscanf. C’est inconsistant.
J’aurais trouvé carrément mieux de toujours passer le FILE* au début, mais c’est du détail.

grim7reaper a écrit :

Pylade a écrit :
Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !
Bah si, tu testes une égalité (de type, certes) donc tu fais bien une comparaison. Donc c'est bien le boulot d'un opérateur de comparaison. Bien sûr, cet opérateur doit utiliser un symbole différent de l'opérateur traditionnel.

Un typeof, quoi… Là, OK (et encore, quand t’as un typage statique, je ne vois pas vraiment l’intérêt).

grim7reaper a écrit :

Pylade a écrit :
T’utilises deux implémentations différentes de la même interface en même temps ?
Bah comment dire, stun peu l'un des trucs les plus important venant de la POO ça (une interface/classe abstraite et des implémentations différentes derrière).

Euh, ouais, mais tu n’utilise pas les deux en même temps non ?

grim7reaper a écrit :

Pylade a écrit :
Je n’ai pas trop à me plaindre de GCC (quelques bugs, j’en ai trouvé trois, mais pas bien méchants).
À ce sujet, je me permet de te signaler que l'équipe de GCC est toujours en attente de tes rapports de bug
Le seul truc que l'on peut reprocher, c'est la différence d'ordre entre fputs et les autres.

Ben déjà j’ai la grosse flemme, et en plus je ne suis pas sûr de savoir faire un rapport correct, ce qui entretient la flemme. Et plus bon, ce n’est que pour des histoires de warnings indésirables ; donc pas vraiment méchant.

Et bon courage à Rolinh pour ce dernier exam.

Et moi, il faut que j’arrête de me prendre la tête avec ça, ne serait-ce parce que je dois aussi réviser. Donc je dis : jamais je n’utiliserai de mon plein gré PHP en l’état, et j’ai mes raisons, point.

tshirtman · Le 16/06/2011, à 00:09

Je ne vois qu'un seul avantage à PHP, pour faire une applie monopage, avec un petit formulaire ou presque rien, un fichier pas trop long, n'ayant aucune considération pour le MVC et tout… mais ça marche juste… en python, faut tout de suite déployer un framework quoi…

Кຼزດ · Le 16/06/2011, à 00:33

tshirtman a écrit :

Je ne vois qu'un seul avantage à PHP, pour faire une applie monopage, avec un petit formulaire ou presque rien, un fichier pas trop long, n'ayant aucune considération pour le MVC et tout… mais ça marche juste… en python, faut tout de suite déployer un framework quoi…

Pour du mono-page, les CGI passent pas trop mal.

Pylade · Le 16/06/2011, à 00:43

J'ai un aveu à vous faire.
En fait j'♥ PHP.

Pylades · Le 16/06/2011, à 00:44

Mais tuez-le !

nathéo · Le 16/06/2011, à 00:48

;

cm-t · Le 16/06/2011, à 02:06

Pylade a écrit :

J'ai un aveu à vous faire.
En fait j'♥ PHP.

'Nuit;

samυncle · Le 16/06/2011, à 02:27

.

nesthib · Le 16/06/2011, à 03:03

plop

samυncle · Le 16/06/2011, à 04:26

.

grim7reaper · Le 16/06/2011, à 06:50

Hello World!

Rolinh a écrit :

Sinon, pourquoi utiliser un do while plutôt qu'un for en fonction des valeurs utilisées, etc. C'est vraiment intéressant en tout cas.

Pour celles d'avant OK, mais pour celle là il me semble que c'est plus le boulot du compilo (mais c'est toujours bon à savoir même si on le fait rarement à la main), comme le déroulage de boucle.

Πυλάδης a écrit :

grim7reaper a écrit :
Pylade a écrit :
l’inconsistance de l’ordre des arguments des fonctions d’IO
Heu c'est quoi le soucis là ?
Si c'est le fait de passer le FILE en premier, c'est pas plus con qu'autre chose. Tu dis où tu veux écrire avant de dire ce que tu veux écrire.
Ben la plupart du temps le FILE* arrive à la fin, mais pas pour fprintf et fscanf. C’est inconsistant.
J’aurais trouvé carrément mieux de toujours passer le FILE* au début, mais c’est du détail.

Ok donc on est d'accord, c'est ce que je disais (mais la phrase s'est barré après ma remarque sur tes rapports de bug pour gcc >_<").

Πυλάδης a écrit :

grim7reaper a écrit :
Pylade a écrit :
Mais vérifier que deux variables ont le même type, ce n’est pas le rôle d’un opérateur de comparaison !
Bah si, tu testes une égalité (de type, certes) donc tu fais bien une comparaison. Donc c'est bien le boulot d'un opérateur de comparaison. Bien sûr, cet opérateur doit utiliser un symbole différent de l'opérateur traditionnel.
Un typeof, quoi… Là, OK (et encore, quand t’as un typage statique, je ne vois pas vraiment l’intérêt).

Hum, c'est pas dénué d'intérêt même pour un langage typé statiquement.
Suffit d'avoir du polymorphisme et tes variables ont déjà 2 types : un type statique et un type dynamique.

Πυλάδης a écrit :

grim7reaper a écrit :
Pylade a écrit :
T’utilises deux implémentations différentes de la même interface en même temps ?
Bah comment dire, stun peu l'un des trucs les plus important venant de la POO ça (une interface/classe abstraite et des implémentations différentes derrière).
Euh, ouais, mais tu n’utilise pas les deux en même temps non ?

Bah si ça peut arriver.
Je vais reprendre l'exemple traditionnel (qui vaut ce qu'il vaut) de l'interface Forme et de ses implémentations Cercle, Carré, Triangle, etc.
Bah généralement tu les utilises en même temps ces implémentations différentes, tu peux même avoir un conteneur qui contient plusieurs implémentations différentes de Forme.

Compteur du TdCCT · Le 16/06/2011, à 07:42

Scores totaux, depuis le début :

1) 3517    nesthib
2) 3124    samuncle
3) 2977    Πυλάδης
4) 2229    Кຼزດ
5) 1722    cm-t
6) 1714+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1326    na kraïou
8) 866    helly
9) 862    \\Ouranos//
10) 659    gnuuat
11) 625    tshirtman
12) 565    Lagierl
13) 432    Rolinh
14) 398    nathéo
15) 372    The Uploader
16) 263    Kanor
17) 196    Askelon
18) 193    :!pakman
19) 121    ǤƦƯƝƬ
20) 99    kamui57
21) 93    petifrancais
22) 78    edge_one
22) 78    pierguiard
24) 70    gulp
25) 42    sakul
26) 39    Le Rouge
27) 37    ilagas
28) 36    xapantu
29) 30    keny
30) 26    gustare
30) 26    d10g3n
32) 25    GentooUser
32) 25    Morgiver
34) 24    ไ୦บเઢ'
34) 24    Steap
36) 20    CROWD
37) 18    Ph3nix_
38) 16    kouskous
39) 15    timsy
40) 12    stratoboy
40) 12    sailing
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
44) 10    THS`
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
57) 4    ceric
57) 4    Dice-Man
57) 4    Pylade
66) 3    Revan26914
66) 3    raspouillas
66) 3    sweetly
69) 2    SoJaS
70) 1    geenux
70) 1    ArzhurBZH

Répartition Posts/heure

Compteur du TdCCT · Le 16/06/2011, à 07:42

Scores de la période en cours :

1) 134    Πυλάδης
2) 113    nesthib
3) 85    cm-t
4) 81    samuncle
5) 77    Кຼزດ
6) 52    tshirtman
7) 50    nathéo
8) 47    na kraïou
9) 27    :!pakman
10) 24    The Uploader
11) 21    grim7reaper
12) 13    Rolinh
13) 4    \\Ouranos//
13) 4    kamui57
13) 4    Pylade
16) 3    xapantu

Rolinh · Le 16/06/2011, à 08:52

grim7reaper a écrit :

Rolinh a écrit :
Sinon, pourquoi utiliser un do while plutôt qu'un for en fonction des valeurs utilisées, etc. C'est vraiment intéressant en tout cas.
Pour celles d'avant OK, mais pour celle là il me semble que c'est plus le boulot du compilo (mais c'est toujours bon à savoir même si on le fait rarement à la main), comme le déroulage de boucle.

Oui c'est sûr, c'est pas le genre de chose que l'on fait à la main en général.
Pour l'exemple, on avait une fonction qui calcule un checksum qui ressemble à ça:

int
checksum(int *data, unsigned int N)
{
    int sum = 0;
    
    for (; N != 0; N--) {
        sum += *(data++);
    }
    
    return sum;
}

Et donc il est mieux d'utiliser un do while comme ici plutôt qu'un for si l'on sait pertinemment que la valeur de N sera plus grande que 0. On évite ici un premier test inutile.

int
checksum(int *data, unsigned int N)
{
    int sum = 0;
    
    do {
        sum += *(data++);
    } while (N-- != 0)
    return sum;
}

Si on regarde le code assembleur généré, on voit qu'on évite une comparaison et un branchement supplémentaire.

Sinon, oui, on a aussi regardé le déroulage des boucles.
Ah oui, puis évidemment, le fait de passer une structure en argument d'une fonction auquel on a besoin de passer plus de quatre arguments. Ce dernier point me semble plus être le genre de choses auquel on peut facilement penser.

Dernière modification par Rolinh (Le 16/06/2011, à 08:54)

grim7reaper · Le 16/06/2011, à 18:46

Tiens, aujourd'hui j'étais en train de me pencher sur les zippers (structure de données fort utile, présenté la première fois par dans un papier d'un gars de l'INRIA) en Haskell.

Entre autres applications, je suis tombé sur un système de fichier : ZipperFS.
J'ai d'abord lu la présentation, puis un papier qui est en rapport avec ça. Et dans ce papier j'ai vu ça

Delimited continuations in operating systems a écrit :

Our prototype and illustrative code below are written in Haskell, a high-level general-purpose programming language, because it is suitable for operating systems [32] and its notation is concise and close to mathematical speciﬁcation.

Intrigué, j'ai cherché le papier sur lequel pointe cette référence 32 et je l'ai trouvé
Et là j'étais plutôt impressionné, je pensais pas qu'on pouvait faire ça avec Haskell , au passage je vous conseille la lecture dudit papier (on comprend globalement de quoi ça parle, pour comprendre dans les détails c'est un peu plus chaud). Vraiment intéressant !

En tout cas le concept est vraiment sympa, j'ai voulu voir où ça en est aujourd'hui (oui, le papier date quand même de 2005). Si j'en crois la page perso d'une des dev' (Rebekah Leslie en l'occurence) et bien ils bossent toujours dessus

Elzen · Le 16/06/2011, à 18:59

Bon, désolé pour le troll, mais j'essaye de bosser un peu Touhy, parce que ça traîne en longueur, ç't'affaire, donc je lirai/répondrai un peu plus tard.

Et à propos de Touhy, justement : le code est toujours aussi moche, mais maintenant j'ai de l'héritage multiple en plus dedans, youpi

Par contre, j'viens de tomber sur un truc vraiment naze de PyGTK : sur un Notebook, on a quatre choix pour modifier la position des onglets : TOP, LEFT, RIGHT et BOTTOM. Logique. Par défaut, les onglets sont alignés à gauche pour TOP et BOTTOM, et en haut pour LEFT et RIGHT. Ça paraît normal aussi.
Pour ce truc, je voudrais un onglet à droite, mais aligné en bas plutôt qu'en haut. J'me dis que pour jouer sur l'alignement, il faut changer la direction de LTR à RTL. J'essaye en TOP et en BOTTOM, pas de soucis : l'onglet apparaît bien soit en haut, soit en bas, mais aligné à droite.
Par contre, quand la position est réglée sur LEFT ou RIGHT, passer de LTR à RTL laisse les onglets alignés en haut, mais inverse leur position (ils se retrouvent à droite pour LEFT et à gauche pour RIGHT) C'est quoi ce comportement débile ?
J'fais comment pour avoir mon truc comme je veux, moi, du coup ?

Sinon, les gens qui codent le CLFB peuvent peut-être m'aider : pour les icônes fichiers contenus dans le répertoire du bureau (ou dans n'importe quel répertoire, en fait, je laisse la possibilité à l'utilisateur, s'il le souhaite, d'en choisir un autre, voire d'en afficher plusieurs), il faudrait que les fichiers s'ouvrent quand on (double-)clique sur le bureau, ce serait mieux. Comment vous faites pour récupérer la commande avec laquelle doit s'ouvrir un fichier ?
Dans les versions d'avant, qui n'étaient que des prototypes pour regarder ce que ça donne, j'aurais utilisé gnome-open sans problème, mais là, j'essaye de faire une version un minimum utilisable, donc ce serait mieux de pas dépendre d'applis gnome, quoi.
Accessoirement, pour ces mêmes icônes de fichiers, il faudrait aussi que je trouve comment associer à un fichier donné une icône du thème actuel…

grim7reaper · Le 16/06/2011, à 19:09

ArkSeth a écrit :

Comment vous faites pour récupérer la commande avec laquelle doit s'ouvrir un fichier ?

Y'a xdg-open (même si pour le CLFB c'est pas ce que j'utilise, je suis parti sur un fichier de conf' maison à remplir par l'user selon ses besoins).

Dernière modification par grim7reaper (Le 16/06/2011, à 19:09)

Pylades · Le 16/06/2011, à 19:42

xdg-open, il faut qu’on lui donne un *.desktop à manger, non ?

Sinon, il y a tout un micmac pour ça standardisé par FreeDesktop.org, avec notamment plein de fichiers pour ça dans /usr/share/applications/ ; mais c’est bien plus compliqué en réalité. Je me demande s’il y a une bibliothèque pour automatiser ça…

Sinon, je ne savais pas qu’il existait des publications sur l’info qui ressemblent en tous points à des publications de n’importe quelle autre science…

Dernière modification par Πυλάδης (Le 16/06/2011, à 20:16)

grim7reaper · Le 16/06/2011, à 19:53

Πυλάδης a écrit :

xdg-open, il faut qu’on lui donne un *.desktop à manger, non ?

Possible, j'ai jamais vraiment essayé de faire fonctionner ce truc…

Pylades · Le 16/06/2011, à 20:16

Et édition après la bataille…

xapantu · Le 16/06/2011, à 20:18

Πυλάδης a écrit :

Sinon, il y a tout un micmac pour ça standardisé par FreeDesktop.org, avec notamment plein de fichiers pour ça dans /usr/share/applications/ ; mais c’est bien plus compliqué en réalité. Je me demande s’il y a une bibliothèque pour automatiser ça…

gio gère ça, après, c'est un peu lourd si on veut juste ouvrir un fichier… Normalement, xdg-open devrait fonctionner, chez moi ça n'ouvre que nautilus, mais bon

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

(Ah ben non, ça fonctionne aussi sur un fichier quelconque…)

grim7reaper · Le 16/06/2011, à 20:31

Πυλάδης a écrit :

Sinon, je ne savais pas qu’il existait des publications sur l’info qui ressemblent en tous points à des publications de n’importe quelle autre science…

Bah c'est logique, c'est une science donc elle à ses publi comme les autres
Après, je ne sais pas si y a l'équivalent de Nature pour l'informatique… Y'a ptetr certains articles qui sortent dans Science…

Πυλάδης a écrit :

(Ah ben non, ça fonctionne aussi sur un fichier quelconque…)

C'est bien ce qu'il me semblait, mais j'en étais plus sûr.

Dernière modification par grim7reaper (Le 16/06/2011, à 20:32)

Elzen · Le 16/06/2011, à 20:32

J'viens de faire un test en console, et chez moi, xdg-open n'a pas l'air de réussir à ouvrir les fichiers sans extensions (y compris les répertoires) (Il me sort « unknown mime-type -- usign "application.octet-stream" » suivi de « Error: no "view" mailcap rules found for type "application/octet-stream" »), et pour un fichier .py, il me l'ouvre avec vim, donc pour une appli graphique, ç'pas glop

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#276 Le 15/06/2011, à 23:19

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

#277 Le 15/06/2011, à 23:35

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

#278 Le 16/06/2011, à 00:09

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

#279 Le 16/06/2011, à 00:33

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

#280 Le 16/06/2011, à 00:43

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

#281 Le 16/06/2011, à 00:44

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

#282 Le 16/06/2011, à 00:48

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

#283 Le 16/06/2011, à 02:06

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

#284 Le 16/06/2011, à 02:27

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

#285 Le 16/06/2011, à 03:03

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

#286 Le 16/06/2011, à 04:26

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

#287 Le 16/06/2011, à 06:50

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

#288 Le 16/06/2011, à 07:42

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

#289 Le 16/06/2011, à 07:42

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

#290 Le 16/06/2011, à 08:52

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

#291 Le 16/06/2011, à 18:46

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

#292 Le 16/06/2011, à 18:59

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

#293 Le 16/06/2011, à 19:09

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

#294 Le 16/06/2011, à 19:42

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

#295 Le 16/06/2011, à 19:53

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

#296 Le 16/06/2011, à 20:16

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

#297 Le 16/06/2011, à 20:18

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

#298 Le 16/06/2011, à 20:21

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

#299 Le 16/06/2011, à 20:31

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

#300 Le 16/06/2011, à 20:32

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

Pied de page des forums