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

grim7reaper · Le 03/08/2011, à 21:56

tshirtman a écrit :

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).

En fait, il me paraît pas aberrant qu'en interne PyPy ai un équivalent à ça et qu'il l'utilise quand ça s'y prête.
Bon après j'en sais rien et peut‑être qu'il fait vraiment tout avec le heap, à voir.

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

Oui effectivement, dans ce cadre là, ça peut être appréciable. Mais encore faut‑il que la chaîne de formatage soit fixe (car c'est là dessus qu'est basée l'optimisation).
Parce qu'une fois qu'une page est générée, en général y'a pas une sorte de mise en cache qui est réalisée au lieu de la générer à chaque fois ?

tshirtman a écrit :

mais en même temps, qui ferait des sites webs en C? :]

Je me le demande aussi.

tshirtman a écrit :

(hum, j'ai un collegue, qui veut en faire en C++, mais il a ses raisons et il est plutot bon en C++).

Et pourquoi ce choix ?

tshirtman a écrit :

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

Ouais, quand ils font des comparaisons PyPy/C sur des trucs comme ça là ça vaudrait un article et ça serait intéressant pour avoir une vue plus réaliste.

tshirtman a écrit :

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…

Ha oui, mais là c'est bien différent. Entre marquer la mémoire disponible pour le GC (ce que fait Python) et la rendre à l'OS (ce que fait free) c'est pas la même chose (y'en a un qui implique des appels systèmes et qui est donc bien plus lent).
Pour être vraiment équivalent dans ce cas faut que l'exemple C utilise un GC, ou à la limite un système de pool.

Donc je persiste, son exemple avec les alloc/desalloc en boucle n'a pas de sens (du moins la comparaison n'a aucune valeur) car c'est pas le même comportement.

tshirtman · Le 03/08/2011, à 22:05

grim7reaper a écrit :

Oui effectivement, dans ce cadre là, ça peut être appréciable. Mais encore faut‑il que la chaîne de formatage soit fixe (car c'est là dessus qu'est basée l'optimisation).
Parce qu'une fois qu'une page est générée, en général y'a pas une sorte de mise en cache qui est réalisée au lieu de la générer à chaque fois ?

Ben on a souvent des boucles, dans les templates

tshirtman a écrit :
(hum, j'ai un collegue, qui veut en faire en C++, mais il a ses raisons et il est plutot bon en C++).
Et pourquoi ce choix ?

Il en a marre du PHP :], bon, il regarde le python aussi, par ce qu'il aime bien, mais il fait partis des gens qui "pensent en C++", donc c'est un truc qui l'intéresse aussi… il m'a dit que ça c'était pas mal, l'autre fois… http://www.webtoolkit.eu/wt et là il s'écrit un petit serveur http, en C++, un peu par curiosité et un peu pour voir ce qu'il pourrait se donner comme API pour coder un site directement dessus…

Ha oui, mais là c'est bien différent. Entre marquer la mémoire disponible pour le GC (ce que fait Python) et la rendre à l'OS (ce que fait free) c'est pas la même chose (y'en a un qui implique des appels systèmes et qui est donc bien plus lent).
Pour être vraiment équivalent dans ce cas faut que l'exemple C utilise un GC, ou à la limite un système de pool.
Donc je persiste, son exemple avec les alloc/desalloc en boucle n'a pas de sens (du moins la comparaison n'a aucune valeur) car c'est pas le même comportement.

Ben je pense qu'il à choisit de faire ça par ce que pour lui, en temps que dev de Pypy, ça lui parait plus proche de ce que fait pypy, peut être que ça désavantage un peu C par rapport à pypy, mais s'il est honnête, moins que la situation inverse ne désavantage pypy…

grim7reaper · Le 03/08/2011, à 22:17

tshirtman a écrit :

Ben je pense qu'il à choisit de faire ça par ce que pour lui, en temps que dev de Pypy, ça lui parait plus proche de ce que fait pypy

Bah alors il a tout intérêt à revoir sérieusement certaines notions d'informatique si pour lui un free est équivalent à rendre de la mémoire à un GC (idem pour l'alloc)…

tshirtman a écrit :

peut être que ça désavantage un peu C par rapport à pypy

Non pas un peu, beaucoup.
Un appel système c'est très cher en général (sûrement ce qu'il y a de plus coûteux après les I/O).

tshirtman a écrit :

mais s'il est honnête, moins que la situation inverse ne désavantage pypy…

Faire une version C avec allocateur maison ça rendrait la comparaison plus pertinente sans pour autant désavantager PyPy (qui resterait en tête de toute manière).
Je peux comprendre que ça le faisait chier de faire ça, mais dans ce cas autant ne pas publier cette comparaison (la première étant suffisante et bien moins biaisée)

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

Elzen · Le 03/08/2011, à 23:39

grim7reaper a écrit :

tshirtman a écrit :
mais en même temps, qui ferait des sites webs en C? :]
Je me le demande aussi.

jeuxvideo.com

Enfin, c'est ce dont je me souviens d'une offre de CDD de développeur web chez eux qui m'était passée sous les yeux : apparemment, pour eux, « développeur web », ça veut dire bosser sur le code C du serveur.

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

Sir Na Kraïou · Le 04/08/2011, à 02:14

:mæd:

samυncle · Le 04/08/2011, à 02:18

na kraïou a écrit :

:mæd:

:mαd:

nesthib · Le 04/08/2011, à 02:25

plop

Pylades · Le 04/08/2011, à 03:59

.

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

Scores totaux, depuis le début :

1) 3963    nesthib
2) 3431    Πυλάδης
3) 3421    samuncle
4) 2525    Кຼزດ
5) 2011    cm-t
6) 1800+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1649    na kraïou
8) 880    helly
9) 877    \\Ouranos//
10) 755    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 04/08/2011, à 06:42

Scores de la période en cours :

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

tshirtman · Le 04/08/2011, à 07:27

@grim: un free ne rends pas la mémoire à l'OS il me semble, il retourne dans la pool que le programme utilise, mais n'est pas rendu à l'OS avant la fin de l'execution (sauf bricolage bien plus complexe que free, il me semble).

grim7reaper · Le 04/08/2011, à 09:24

tshirtman a écrit :

@grim: un free ne rends pas la mémoire à l'OS il me semble

Oui et non.
C'est pas si simple. Ça dépend énormément des implémentations.
Mais quelque soit l'implémentation free rend quand même la mémoire à l'OS en cours d'éxécution, mais c'est vrai qu'il ne le fait pas à chaque fois comme je semblais le dire (chez moi il me semble qu'il le fait dès qu'une page entière est libérée par exemple).

Reste que malloc (qui est lui aussi dans la boucle), lui, fait bien une demande au système (appel au syscall brk, bien que là aussi malloc ne demande pas au système dans 100% des cas, ça reste fréquent (plus de 3000 appels à brk dans l'exemple du gars)) et que ça reste plus lent que ce que fait Python (demande de mémoire à son gestionnaire interne ce qui implique rarement une demande au système) donc ça ne change rien à mon raisonnement (c'est juste un peu moins lent que ce que j'avais dit).

En plus, en C on sait que le couple malloc/free grève pas mal les perf quand on bosse avec beaucoup de petit bloc mémoire (ici 44 octet), c'est bien pour ça qu'on préfèra utiliser des pool dans ces cas‑là.

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

The Uploader · Le 04/08/2011, à 09:30

J'aime les plugin redmine qui fonctionne parfaitement en mode devel, mais pas en mode production! Même quand on modifie temporairement les options de production.rb pour qu'il soit identique à development.rb. -_-

Heureusement il reste "script/server -e production --debugger"

La bataille commence... è_é

</journal de bord Rails>

Dernière modification par The Uploader (Le 04/08/2011, à 09:31)

grim7reaper · Le 04/08/2011, à 10:02

@The Uploader : Le Ruby nouveau est arrivé

tshirtman · Le 04/08/2011, à 10:41

grim7reaper a écrit :

tshirtman a écrit :
@grim: un free ne rends pas la mémoire à l'OS il me semble
Oui et non.
C'est pas si simple. Ça dépend énormément des implémentations.
Mais quelque soit l'implémentation free rend quand même la mémoire à l'OS en cours d'éxécution, mais c'est vrai qu'il ne le fait pas à chaque fois comme je semblais le dire (chez moi il me semble qu'il le fait dès qu'une page entière est libérée par exemple).
Reste que malloc (qui est lui aussi dans la boucle), lui, fait bien une demande au système (appel au syscall brk, bien que là aussi malloc ne demande pas au système dans 100% des cas, ça reste fréquent (plus de 3000 appels à brk dans l'exemple du gars)) et que ça reste plus lent que ce que fait Python (demande de mémoire à son gestionnaire interne ce qui implique rarement une demande au système) donc ça ne change rien à mon raisonnement (c'est juste un peu moins lent que ce que j'avais dit).
En plus, en C on sait que le couple malloc/free grève pas mal les perf quand on bosse avec beaucoup de petit bloc mémoire (ici 44 octet), c'est bien pour ça qu'on préfèra utiliser des pool dans ces cas‑là.

C'est pour ça que les gens qui pensent que c'est toujours plus efficace de gérer la mémoire à la main on tords

grim7reaper · Le 04/08/2011, à 10:53

Bah au contraire.
Dans le cas présent c'est plus efficace de le gérer à la main (i.e utiliser son propre système de pool mémoire) que de laisser le système s'en occuper.

Mais oui, les gens qui pensent que c'est toujours plus efficace de gérer la mémoire à la main ont tort, tout comme ceux qui pensent l'inverse…

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

The Uploader · Le 04/08/2011, à 11:34

Bon c'ayez, j'ai réglé mes bugs.

En fait le mode devel en "réparait" un automatiquement, le reste je l'ai introduit hier soir >_<'

@grim' : malheureusement les nouveautés sont surtout intéressantes pour RoR, or Redmine est très chatouilleux (point de vue dépendances). ^^
Pour Gauge/Rubygame, je vois pas trop ce que Ruby 1.9.3 apporte d'intéressant..?

Mais c'est cool d'avoir enfin une nouvelle version en tout cas. J'avais l'impression que le développement de l'implémentation de référence ne bougeait plus trop..

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

grim7reaper · Le 04/08/2011, à 12:00

The Uploader a écrit :

Pour Gauge/Rubygame, je vois pas trop ce que Ruby 1.9.3 apporte d'intéressant..?

Bah je sais pas, moi je signale juste la sortie pour ceux que ça intéressent
Après, ne faisant pas de Ruby moi‑même je ne me suis pas penché sur les apports de cette nouvelle version

Dernière modification par grim7reaper (Le 04/08/2011, à 12:01)

Elzen · Le 04/08/2011, à 12:01

La dernière version de pynotify n'a plus la méthode attach_to_status_icon

Et zenity --notification n'a plus l'air de marcher (ça ne balance pas de message d'erreur, ça fait juste… rien)

C'est quoi ce bazar ?

…bon, je backup sur les snapshots, et je garde les paquets sous la main au cas où j'aurais besoin de bloquer ces versions-là aussi

Edit : encore mieux, j'arrive plus à virer zenity…

root@fadreils: ~#  apt-get autoremove --purge zenity
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  zenity*
0 mis à jour, 0 nouvellement installés, 1 à enlever et 0 non mis à jour.
Après cette opération, 324 ko d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? 
dpkg : avertissement : « ldconfig » introuvable dans la variable PATH ou non exécutable
dpkg : avertissement : « start-stop-daemon » introuvable dans la variable PATH ou non exécutable
dpkg: error: 2 expected programs not found in PATH or not executable.
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
E: Sub-process /usr/bin/dpkg returned an error code (2)
root@fadreils: ~#

/me va définitivement arrêter de faire des mises à jour

Edit2 : c'est bon, c'était bien juste le $PATH de mon root qui était incomplet, comme suggéré dans la note. J'l'avais sans doute pas remarqué parce que j'ai plus l'habitude d'utiliser sudo que su… d'ailleurs, où va-t-il chercher son $PATH, en sudo ? Vu que les répertoires manquants ne sont pas non plus dans mon $PATH utilisateur

Dernière modification par ArkSeth (Le 04/08/2011, à 13:02)

Pylades · Le 04/08/2011, à 21:18

Hey, les mutteux, vous racontez quoi dans votre config ? Il y a juste à faire ça ?

set realname='/me'
set folder=~/.mail/
set editor=vim
my_hdr From: Me <me@serv.tld>
set spoolfile=/var/spool/mail/me

Il devine tout seul que j’ai plein de boîtes et qu’elle sont en Maildir ? Je n’ai besoin de configurer le POP et l’IMAP que dans le muttrc ? O_o'
Par défaut, il ne supprime pas les messages reçus du serveur (je veux tester d’abord) ?

’fin bref, toussa, quoi…

Dernière modification par Πυλάδης (Le 04/08/2011, à 21:18)

grim7reaper · Le 04/08/2011, à 21:33

Πυλάδης a écrit :

Hey, les mutteux, vous racontez quoi dans votre config ?

Plein de trucs, mais c'est splitté en plusieurs fichiers.

Πυλάδης a écrit :

Il y a juste à faire ça ?

set realname='/me'
set folder=~/.mail/
set editor=vim
my_hdr From: Me <me@serv.tld>
set spoolfile=/var/spool/mail/me

Ça me semble un bon début.
Bon chez moi spoolfile == folder, et mon editor ressemble plus à ça :

set editor="vim -c \"set spell spelllang=fr,en\""

mais sinon ouais ça me semble correct

Πυλάδης a écrit :

Il devine tout seul que j’ai plein de boîtes et qu’elle sont en Maildir ?

Non, par défaut c'est du mbox.
Faut lui préciser en positionnant la variable mbox_type à Maildir.

Πυλάδης a écrit :

Je n’ai besoin de configurer le POP et l’IMAP que dans le muttrc ? O_o'

Bah non, qu'est ce que ça viendrait foutre là dedans O_o' ?
mutt c'est un MUA, pas un MRA.

Πυλάδης a écrit :

Par défaut, il ne supprime pas les messages reçus du serveur (je veux tester d’abord) ?

fetchmail a une option keep.

DaveNull · Le 04/08/2011, à 21:45

Bonsoir les codeurs !

Je me permet de poster dans ce topic pour la première fois par-ce que je me décide enfin à me mettre à apprendre la programmation (c'est pas que j'ai tenté à moult reprises déjà, mais ça tombait tout le temps à des moments où je finissais par ne pas avoir beaucoup de temps, et de motivation à cause du fait que je n'avais pas de projet particulier.
Mais bon, là c'est différent, j'ai un projet, un langage, le python (ça je le savais depuis longtemps, tshirtman et d'autres m'en avaient convaincus) : Je voudrais me coder un petit site dynamique, à commencer par un blog (d'autres choses suivront sans doute), en utilisant Django.

D'ailleurs à ce sujet, ma première question : est-ce que quelqu'un ici a déjà utilisé Django ? Est-ce qu'il existe des alternatives bien commentées ? Voilà, j'aurais besoin de quelques conseils.

Deuxième question : Je me trouve devant le choix d'utiliser soit un système de base de données de type SQL, soit, ce que je voudrais bien faire, stocker les données dans un fichier (notement pour sauver de la RAM, mon serveur n'en aura pas beaucoup, et je sais d'expérience que mySQL (oui je sais y'a mieux, mais je n'ai utilisé que ça jusqu'à maintenant)en pompe beaucoup).
Donc les questions qui se posent : Est-ce que c'est beaucoup plus lourd pour le serveur, pour la lenteur de chargement des pages, a sécurité, etc... , Est-ce que y'a une solution qui est plus difficile qu'une autre ? Est-ce que y'a des exemples que je pourrais étudiar de programmes qui font ça ?

J'avais imaginé un fichier de base de données où les catégories étaient classées par un système d'indentation, pour la visibilité :

Catégorie1
    Item1
    Item2
        Sous-item1
    Item3
Catégorie2

Les items étant des chemins vers des fichiers textes contenant des bouts de HTML
Et-ce que c'est con ? est-ce qu'il y a une meilleure méthode (Syntaxe à balises ?) ? Des formats déjà existants* ?

Finalement, est-ce que je me lance dans un projet de fou furieux pour un premier projet ?

Edit : Pendant ces vacancves où j'aurais pas internet, je comptais potasser ça. Est-ce un bon choix ?
Re-edit : aurtograf & syntaxe

* J'ai cru comprendre que XML pouvait faire ça, mais ce ne serait pas un peu une usine à gaz pour stocker, somme toute, que des chemins, ou des bouts de code html...

Dernière modification par DaveNull (Le 04/08/2011, à 22:20)

tshirtman · Le 04/08/2011, à 22:31

Hum, je ne connais pas bien django, mais je ne suis pas sur que vouloir se passer de BDD lui convienne bien, regarde si tu peux pas le monter sur du sqlite plutot, pour les trucs avec pas des milliers d'accès par secondes à la BDD ça suffit souvent…

Sinon, flask c'est sympa et rapide à comprendre aussi, faut que je joue un peu avec, en plus gros y'a pyramid, mais la doc a beau être énorme c'est pas très facile de s'y retrouver je trouve (trop de façons de faire la même chose, et beaucoup de choses à comprendre avant de se lancer).

Pylades · Le 04/08/2011, à 22:36

grim7reaper a écrit :

Bon chez moi spoolfile == folder, et mon editor ressemble plus à ça :
set editor="vim -c \"set spell spelllang=fr,en\""
mais sinon ouais ça me semble correct

Chez moi, spelllang est fixé dans $MYVIMRC (si, et seulement si vim est compilé avec la fonctionnalité syntax). :]
Après pour spell, je n’ai pas réussi à exécuter une autocommande lorsque justement filetype n’est fixé à rien, mais je ne désespère pas…
Mais sinon, set editor='vim +set\ spell', c’est plus joli.

grim7reaper a écrit :

Πυλάδης a écrit :
Je n’ai besoin de configurer le POP et l’IMAP que dans le muttrc ? O_o'
Bah non, qu'est ce que ça viendrait foutre là dedans O_o' ?
mutt c'est un MUA, pas un MRA.

Ben qu’est-ce qu’il raconte, lui, alors : http://libretto.debian.free.fr/mutt ?

(P’tain chuis fatigué… >_<')

Dernière modification par Πυλάδης (Le 05/08/2011, à 01:03)

grim7reaper · Le 04/08/2011, à 22:46

Πυλάδης a écrit :

Chez moi, spelllang est fixé dans $MYVIMRC (si, et seulement si vim est compilé avec la fonctionnalité syntax). :]

Pas con en effet.

Πυλάδης a écrit :

Mais sinon, set editor='vim +set\ spell', c’est plus joli.

Ouais mais tu sais, moi et la syntaxe de Vim…
Tfaçon j'ai jamais pris la peine de l'apprendre (spour ça que ma conf de Vim casse pas des briques), trop limité comme langage.
[troll]Je serais sous Emacs qui, lui, a un vrai langage pour se configurer j'aurais ptetr fait un effort[/troll]

Πυλάδης a écrit :

grim7reaper a écrit :
Πυλάδης a écrit :
Je n’ai besoin de configurer le POP et l’IMAP que dans le muttrc ? O_o'
Bah non, qu'est ce que ça viendrait foutre là dedans O_o' ?
mutt c'est un MUA, pas un MRA.
Ben qu’est-ce qu’il raconte, lui, alors : http://libretto.debian.free.fr/mutt ?

Oui, mutt a bien un espèce de truc intégré mais les gens bien ne l'utilisent pas.
Y'a que les bouseux qui utilisent ça je pense
Philosophie Unix : un programme fait un truc et le fait bien.
Chacun son taff et les moutons seront bien gardés : mutt est un MUA, fetchmail est un MRA, procmail est un MDA et msmtp est un MTA léger.
(Cf. ici pour une explication rapide de ces sigles).

Édit : tiens d'ailleurs ton gus, quelques lignes plus bas, il écrit :

Le gus a écrit :

J'ai essayé d'utiliser directement mutt avec pop mais ça ne fonctionne pas.
L'excellent tuto sur muttfr explique tout sur fetchmail c'est vraiment simple.

donc bon, j'avais raison

Dernière modification par grim7reaper (Le 04/08/2011, à 22:49)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1751 Le 03/08/2011, à 21:56

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

#1752 Le 03/08/2011, à 22:05

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

#1753 Le 03/08/2011, à 22:17

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

#1754 Le 03/08/2011, à 23:39

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

#1755 Le 04/08/2011, à 02:14

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

#1756 Le 04/08/2011, à 02:18

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

#1757 Le 04/08/2011, à 02:25

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

#1758 Le 04/08/2011, à 03:59

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

#1759 Le 04/08/2011, à 06:42

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

#1760 Le 04/08/2011, à 06:42

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

#1761 Le 04/08/2011, à 07:27

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

#1762 Le 04/08/2011, à 09:24

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

#1763 Le 04/08/2011, à 09:30

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

#1764 Le 04/08/2011, à 10:02

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

#1765 Le 04/08/2011, à 10:41

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

#1766 Le 04/08/2011, à 10:53

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

#1767 Le 04/08/2011, à 11:34

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

#1768 Le 04/08/2011, à 12:00

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

#1769 Le 04/08/2011, à 12:01

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

#1770 Le 04/08/2011, à 21:18

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

#1771 Le 04/08/2011, à 21:33

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

#1772 Le 04/08/2011, à 21:45

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

#1773 Le 04/08/2011, à 22:31

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

#1774 Le 04/08/2011, à 22:36

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

#1775 Le 04/08/2011, à 22:46

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

Pied de page des forums