/* Topic des codeurs [7] */

tshirtman · Le 18/04/2012, à 10:52

oO

jquery te permet de pas t'occuper de pleins de soucis à la con de support de navigateur, et simplifie beaucoup de choses… maintenant, prototype.js est pas mal aussi, et y'a d'autres libs sympas, genre underscore.js (pour le fonctionnel), mais le JS standard, c'est assez bordélique.

Dernière modification par tshirtman (Le 18/04/2012, à 10:52)

Elzen · Le 18/04/2012, à 10:57

Bah le JavaScript normal, en tout cas dans l'écrasante majorité des cas où je l'utilise, ça consiste essentiellement à manipuler DOM.

Exactement le même DOM que j'utilise, par ailleurs, en Python, en Java ou en PHP, et que j'utiliserais probablement dans un autre langage si j'avais besoin de manipuler du XML dans un autre langage.

Donc un truc qui me remplace le « document.getElement… » qui a une utilité précise et que j'peux limite copier-coller d'une appli à l'autre même en changeant de langage, par un « $ » qui fait une tonne de trucs différents et qui est hyper-spécifique à jQuery, perso, j'trouve que ça complique les choses.

Ç't'un point de vue, hein, sans doute conditionné par le fait qu'il m'arrive relativement souvent de manipuler DOM dans l'autres langages, mais quand même, ça ne me semble pas si bizarre que ça

Dernière modification par ArkSeth (Le 18/04/2012, à 10:58)

HP · Le 18/04/2012, à 11:04

ArkSeth a écrit :

Ç't'un point de vue, hein, sans doute conditionné par le fait qu'il m'arrive relativement souvent de manipuler DOM dans l'autres langages, mais quand même, ça ne me semble pas si bizarre que ça

Ouais, du coup, l'idée de jQuery (et d'autres), c'est sûrement pas de ressembler à d'antiques libs de parcours de DOM… mais bon. Heureusement que certaines lib de manipulation du DOM se mettent, aujourd'hui, à imiter les frameworks js récents ; parce que c'est quand même plus pratique.

Elzen · Le 18/04/2012, à 11:08

Personnellement, j'n'ai pas grand chose à reprocher à DOM, si ce n'est le fait de considérer les caractères d'indentation entre deux balises comme des nœuds textes.

Après, « antique », p't'être, mais honnêtement, je ne vois absolument pas en quoi les trucs comme jQuery sont « plus pratiques », ça me semble être juste une syntaxe différente pour faire la même chose. Peut-être que je ne connais pas assez pour juger, ceci dit… mais peut-être est-ce plutôt les utilisateurs de jQuery qui ne connaissent pas assez DOM, ç'possible aussi

Elzen · Le 18/04/2012, à 11:17

T'veux dire, un truc comme « document.getElementsByClassName » ?

Ç'plus court à écrire, en effet. Par contre, le sens est moins évident à la lecture, je trouve.

xapantu · Le 18/04/2012, à 11:19

Et pour .css("#machin .truc p") ?

(voir, on peut aussi rajouter :last-child ou des trucs du genre pour plus de fun )

Dernière modification par xapantu (Le 18/04/2012, à 11:20)

Elzen · Le 18/04/2012, à 11:23

Ah, je vois… oùch, ça mériterait vraiment un nom largement plus clair, alors.

Ouaip, effectivement, dans ce cas-là, ça une certaine valeur ajoutée.

J'n'ai encore jamais eu besoin de faire des manips de ce genre, mais ça peut effectivement éviter de devoir se faire soi-même la petite fonction d'une dizaine de lignes qui trouverait ça de façon plus détaillée.

Après, je n'suis pas sûr que le rapport taille de la bibliothèque/intérêt soit si conséquent ( ), mais effectivement, y a de l'idée ^^

Dernière modification par ArkSeth (Le 18/04/2012, à 11:24)

The Uploader · Le 18/04/2012, à 11:27

tshirtman a écrit :

oO
jquery te permet de pas t'occuper de pleins de soucis à la con de support de navigateur, et simplifie beaucoup de choses… maintenant, prototype.js est pas mal aussi, et y'a d'autres libs sympas, genre underscore.js (pour le fonctionnel), mais le JS standard, c'est assez bordélique.

Exactement.

Elzen · Le 18/04/2012, à 11:32

Le problème de « sélecteur CSS », c'est que c'est super flou, comme notion.

Genre un truc qui ne trouve les éléments uniquement que d'après leur nom de classe CSS (comme le « getElementsByClassName » que j'évoquais) est tout-à-fait qualifiable de « sélecteur CSS » dans le contexte propre à JavaScript.

Le fait de connaître les différents vocabulaires dans leurs domaines d'applications respectifs ne sert à rien quand il s'agit d'utiliser un terme spécifique d'un domaine à l'intérieur d'un autre domaine, ce qui est un peu le cas ici

Mais je parlais du nom de la fonction elle-même, qui est encore pire : « css », ça pourrait tout aussi bien (et c'est ce qui me semblerait au premier abord) désigner une fonction du genre de getComputedStyle (un truc qui renvoie l'objet de style actuellement affecté à un élément).

Edit : d'ailleurs, techniquement, un sélecteur CSS, dans le contexte des CSS elles-mêmes, c'est une information pour sélectionner les éléments, me semble. Dans l'exemple « #machin .truc p », il y a plusieurs sélecteurs.

Dernière modification par ArkSeth (Le 18/04/2012, à 11:35)

Kanor · Le 18/04/2012, à 11:52

jQuery c'est le bien.
et ça permet d'avoir du code javascript réutilisable plus facilement entre différent projet.

Elzen · Le 18/04/2012, à 12:25

J'adore ce concept qui consiste à considérer que si, après avoir un peu argumenté en faveur de ses positions, l'autre persiste à avoir un avis différent, et à émettre plusieurs remarques allant dans le sens de ce qu'il pense, c'est nécessairement qu'il est de mauvaise foi…

Le fait qu'une combinaison de sélecteurs soit aussi appelé un sélecteur, soit. Je n'me suis pas penché sur la dénomination officielle dans la doc du W3C depuis un moment, donc je te crois sur parole.

Le fait qu'on puisse se référer à la doc est certes une bonne chose.
Ceci dit, personnellement, j'ai tendance à considérer qu'un nom de classe, de variable ou de fonction, même lorsqu'il est accompagné d'une bonne doc (ce qui n'est malheureusement pas toujours le cas, mais c'est un tout autre problème) doit être clairement lisible, pour qu'une personne qui connaît la syntaxe puisse savoir ce que fait un bout de code donné, au moins dans les grandes lignes, sans avoir à retenir une tonne de trucs qui n'ont rien à voir avec l'exemple particulier considéré.
Donc moi, personnellement, après je n'prétends pas imposer cet avis à quiconque, mais j'aime autant quand même qu'on me laisse le garder, je trouve que des noms « à ralonge », c'est mieux que d'appeler ses variables a, b et c ou d'appeler sa fonction « css » parce qu'elle fait un truc qui est en rapport avec le CSS parmi les milliers d'autres trucs qui le sont.

Quant au fait qu'on soit côté serveur, tu ne l'avais pas dit (on ne parlais pas de jQuery, à la base, donc d'un truc censé se passer côté client ?) mais j'ne vois pas l'intérêt de le préciser, en l'occurrence : si on peut avoir besoin d'accéder à un élément donné, on peut avoir besoin d'accéder à ses propriétés de style par défaut, aucun des deux ne me semble plus aberrant que l'autre.

Quant au fait que la classe se nomme HTML… certes. Mais étant donné que le style CSS associé à un élément HTML donné peut être vu, en toute logique, comme une propriété de cet élément, je ne vois pas en quoi ce n'est pas SOLID que l'objet ait un accesseur sur une de ses possibles propriétés.

D'ailleurs, figure-toi que tu n'as donné aucun détail sur le langage que tu utilisais (tout ce que je peux déduire de ton bout de code, c'est que ce n'est visiblement pas du JavaScript). Donc demander qu'on se réfère à la doc, ou qu'on sache différencier une classe de quelque chose d'autre (ou même qu'on sache que ça respecte les principes SOLID, qui ne sont pas encore universels), dans ces conditions…

Dernière modification par ArkSeth (Le 18/04/2012, à 12:29)

The Uploader · Le 18/04/2012, à 12:42

Son bout de code, c'est du Ruby.

doc.css prête à confusion, perso, si ça ne prend pas le CSS du doc'... (je crois que c'est ce que ça fait si je lis bien HP. dans ce cas le nom est Ok pour moi)

J'aime pas les noms à rallonge (et c'est encore pire avec du CamelCase), mais j'aime un code qui s'auto-documente...

Parce que la doc n'est pas forcément à jour (ni les commentaires). Mais le code l'est. Et le code, c'est le plus important.

S'il prête à confusion, c'est qu'il y a un problème. On ne devrait pas connaître des règles ou connaître la doc' ou mettre des commentaires (sauf exception) pour enlever la confusion.

ArkSeth a écrit :

(ou même qu'on sache que ça respecte les principes SOLID, qui ne sont pas encore universels)

Faire de l'OO sans respecter ses principes (SOLID) qui lui donnent tout son intérêt et permettent d'avoir du code maintenable, c'est perdre son temps et celui des autres.

Dernière modification par The Uploader (Le 18/04/2012, à 14:10)

Elzen · Le 18/04/2012, à 14:27

The Uploader a écrit :

Faire de l'OO sans respecter ses principes (SOLID) qui lui donnent tout son intérêt et permettent d'avoir du code maintenable, c'est perdre son temps et celui des autres.

Ah mais perso, j'suis d'accord (enfin, dans les grandes lignes. J'pense quand même qu'il est éventuellement possible de trouver un cas suffisamment particulier pour que ce soit « mieux » de faire non-SOLID sur un point précis ; faire du SOLID n'est mieux que dans la quasi-totalité des cas), mais ce n'est pas parce que HP, toi et moi sommes manifestement d'accord sur l'intérêt des principes SOLID que ça a nécessairement été utilisé partout.

Dernière modification par ArkSeth (Le 18/04/2012, à 14:28)

Pylades · Le 18/04/2012, à 14:31

ArkSeth a écrit :

Bah j'n'ai jamais vraiment apprit à faire un Makefile, en même temps, on m'a filé un exemple au début, et depuis je fais ce que je peux ^^
Je regardera ça, merci

Je viens de me rendre compte que quand même, $(FNAME), c’est un peu plus court que $(patsubst %.tex,%,$@)…

ArkSeth a écrit :

Personnellement, j'n'ai pas grand chose à reprocher à DOM, si ce n'est le fait de considérer les caractères d'indentation entre deux balises comme des nœuds textes.

Normal, les whitespaces ont une valeur sémantique, en XML.

Elzen · Le 18/04/2012, à 14:35

Je ne parlais pas de la théorie ; d'un point de vue purement pratique, ça peut parfois être assez lourd ^^

Disons qu'il pourrait être intéressant qu'une méthode d'accès type DOM fournisse une propriété du type childNodes mais qui ne renvoie que les balises, sans les nœuds textes.

Sinon, une remarque concernant le début de ça ?

The Uploader · Le 18/04/2012, à 18:15

tshirtman a écrit :

Envie de lire un peu d'assembleur apple][ ?
surtout si c'est le code source original de prince of persia?
hop:
https://github.com/jmechner/Prince-of-Persia-Apple-II

linuxfr a écrit :

Les disquettes étaient enterrées dans un placard depuis plus de 20 ans, il n'était pas sûr que les données soient récupérables. Voici les photos de la copy party.

Énormes les photos !

Rolinh · Le 18/04/2012, à 18:27

ArkSeth a écrit :

Bah j'n'ai jamais vraiment apprit à faire un Makefile, en même temps, on m'a filé un exemple au début, et depuis je fais ce que je peux ^^

On m'a envoyé un peu de lecture intéressante à propos de make et des Makefile en même temps qu'un patch aujourd'hui. Voilà le lien.
Je ne suis pas trop au courant de ce qui est standardisé POSIX etc à ce niveau et ce genre de lecture fais toujours du bien.

grim7reaper · Le 19/04/2012, à 09:19

Dan Kegel a écrit :

Building a gcc / glibc cross-toolchain for use in embedded systems development used to be a scary prospect, requiring iron will, days if not weeks of effort, lots of Unix and Gnu lore, and sometimes willingness to take dodgy shortcuts.

Je confirme…

The Uploader · Le 19/04/2012, à 21:49

Quelques changements mineures sur Gauge (j'ai mis du temps à retrouver mon mot de passe Gitorious et à mettre ma nouvelle clé SSH..) :

commit adcc73e0f85e6a1f55c9c4de6411e3c42136b5fd (HEAD, refs/remotes/origin/master, refs/heads/master)
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 22:37:10 2012 +0200

    Game elements will add/remove their own sprites
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 main.rb |    1 +
 1 file changed, 1 insertion(+)

diff --git a/main.rb b/main.rb
index 049e125..c91f160 100755
--- a/main.rb
+++ b/main.rb
@@ -12,6 +12,7 @@ module Gauge
                attr_reader :obs_queue
                attr_reader :screen
                attr_reader :background
+               attr_accessor :sprites
                def initialize
                        @paused = false
                        @screen = Rubygame::Screen.open([640, 400], 0, [Rubygame::HWSURFACE, Rubygame::DOUBLEBUF])

commit 0765711eff0c90a20de22afde1f7e640f033cc4c
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 22:35:50 2012 +0200

    Some code cleanup
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 main.rb |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/main.rb b/main.rb
index ff8f9ad..049e125 100755
--- a/main.rb
+++ b/main.rb
@@ -40,9 +40,7 @@ module Gauge
                        loop do
                                @drawme = false
                                update
-                               if @drawme
-                                       draw
-                               end
+                               draw if @drawme
                        end
                end
 

commit 208de3053decde7385a9788e846e8e35c4e5f7d6
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 22:35:29 2012 +0200

    Pause event when p key is pressed
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 main.rb |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/main.rb b/main.rb
index c5a1d9b..ff8f9ad 100755
--- a/main.rb
+++ b/main.rb
@@ -13,6 +13,7 @@ module Gauge
                attr_reader :screen
                attr_reader :background
                def initialize
+                       @paused = false
                        @screen = Rubygame::Screen.open([640, 400], 0, [Rubygame::HWSURFACE, Rubygame::DOUBLEBUF])
                        @screen.title = "Gauge"
                        @screen.show_cursor = false
@@ -49,11 +50,13 @@ module Gauge
                        seconds_passed = @clock.tick().seconds
                        @event_queue.each do |event|
                                case event
+                                       when Rubygame::Events::KeyPressed
+                                               @paused = !@paused if event.key == :p
                                        when Rubygame::Events::QuitRequested
                                                Rubygame.quit
                                                exit
                                        else
-                                               @obs_queue.push(event)
+                                               @obs_queue.push(event) if not @paused
                                end
                        end
                end

commit b868a824dddd18940b024ac4c759472eb9d1d159
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 22:01:36 2012 +0200

    Removed unused argument when invoking Events::DrawMe
    
    SDL needs to redraw all sprites below the one firing the event anyway
    (see sprite depth in rubygame).
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 lib/mouse_sprite.rb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/mouse_sprite.rb b/lib/mouse_sprite.rb
index b6acd25..325e8ed 100644
--- a/lib/mouse_sprite.rb
+++ b/lib/mouse_sprite.rb
@@ -12,7 +12,7 @@ module Gauge
                def mousemoved
                        undraw(@game.screen, @game.background)
                        @rect.topleft = @event.pos
-                       @game.push(Gauge::Events::DrawMe.new(self))
+                       @game.push(Gauge::Events::DrawMe.new)
                end
        end
 end

commit a1eda5bec9b1038ac7ee45c16e0f2a0f52193a93
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 22:01:21 2012 +0200

    Removed music test from main
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 main.rb |    1 -
 1 file changed, 1 deletion(-)

diff --git a/main.rb b/main.rb
index 04c720b..c5a1d9b 100755
--- a/main.rb
+++ b/main.rb
@@ -33,7 +33,6 @@ module Gauge
                        subscribe(Gauge::Events::DrawMe)
                        @sprites.draw(@screen)
                        @screen.flip
-                       Rubygame::Music.load("./data/music/1.mp3").play
                end
 
                def run

commit bdd80cf0855224d1cff45392f58efa3a25de0122
Merge: 6cfaa6b 9fb49c4
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 20:47:29 2012 +0200

    Merge branch 'circle'
    
    Conflicts:
        main.rb
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>

commit 9fb49c472ea33639ff64fec93493639799448520
Author: Maximilien Noal <mnoal@epsi.fr>
Date:   Thu Apr 19 20:31:39 2012 +0200

    20 frames per second set
    
    Signed-off-by: Maximilien Noal <mnoal@epsi.fr>
---
 main.rb |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/main.rb b/main.rb
index 765d0b8..64d654f 100755
--- a/main.rb
+++ b/main.rb
@@ -1,5 +1,4 @@
 #!/usr/bin/env ruby
-require "ruby-debug"
 require "rubygame"
 require "test/unit"
 $LOAD_PATH << './lib'
@@ -25,7 +24,7 @@ module Gauge
                        @obs_queue = ObserverQueue.new
                        @obs_queue.enable_new_style_events
                        @clock = Rubygame::Clock.new
-                       @clock.target_framerate = 60
+                       @clock.target_framerate = 20

Je ne pense pas y toucher beaucoup tout pendant que j'aurais mon mémoire de fin d'année et mon stage en cours, mais je n'ai pas abandonné.

Dans le même genre de projet (en plus des nombreux remakes de Dune 2 déjà existants), il y a The Zod Engine
C'est un remake (avec les graphismes, musiques, et sons directement repris du jeu d'origine) de Z, mais uniquement multijoueur. Il existe même un paquet sur l'AUR de ArchLinux.

Ça fonctionne super bien, et les graphismes sont même un peu améliorés.
Le mode multi du jeu originel (en IPX) fonctionne avec DOSBox, mais le remake est plus stable de ce côté là.

Dernière modification par The Uploader (Le 19/04/2012, à 22:13)

Pylades · Le 20/04/2012, à 01:47

Hey, Rolinh, c’est normal que dfc n’accepte de me dessiner le graphe que si mon terminal fait 87 colonnes, alors qu’ainsi il a quand même six colonnes de marge ?
Et j’ai vu qu’il n’y a pas de cible de désinstallation dans le makefile. Pourquoi ?

Sinon, c’est quand même bien sympathique, ce petit outil. Félicitations.

Rolinh · Le 20/04/2012, à 09:51

Πυλάδης a écrit :

Hey, Rolinh, c’est normal que dfc n’accepte de me dessiner le graphe que si mon terminal fait 87 colonnes, alors qu’ainsi il a quand même six colonnes de marge ?

Tu parles bien de la version en développement? Si c'est cela, alors c'est qu'il faut que j'adapte ma fonction qui calcule l'espace nécessaire à l'affichage. J'ai pu me tromper de quelques colonnes et je n'ai pas encore pris le temps de la tester en profondeur.

Πυλάδης a écrit :

Et j’ai vu qu’il n’y a pas de cible de désinstallation dans le makefile. Pourquoi ?

Parce que je n'ai pas pris le temps de le faire.
Mais vu tous les soucis que me posent gettext(3) du point de vue multiplate-forme, je suis en train de me demander si je ne vais pas finir par utiliser Cmake. Ça me parait "overkill" quand même mais je ne vois pas trop comment faire sinon... Le problème étant que je n'arrive pas à faire un Makefile compatible POSIX qui permette de compiler dfc sur toutes les plate-formes supportées (Linux, FreeBSD/PC-BSD, MacOS).

Πυλάδης a écrit :

Sinon, c’est quand même bien sympathique, ce petit outil. Félicitations.

Merci Content que ça plaise.

Ah, il me semble que certains utilisent Debian sid ici. Donc j'en profite pour signaler que la version 2.5.0 à débarqué dans les dépôts.

grim7reaper · Le 20/04/2012, à 10:04

Bah oui, c’est pour ça que j’ai quasiment arrêté les Makefile fait main.
C’est jouable quand tu vises une plateforme, après ça deviens ingérable pour faire un truc propre à la main (donc faut du autohell, du CMake ou du Scons pour citer les plus connu).

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

Rolinh · Le 20/04/2012, à 10:18

@grim: bah jusqu'à ce que je touche à gettext(3), ça allait très bien. Donc je n'avais pas de raison d'utiliser autre chose. Mais bon, là je crois que je me suis décidé à utiliser CMake.

Sinon, merci à Cyril Roelandt pour son patch pour le support de l'export vers html.
Ça rend carrément trop bien! --> preuve
(Je ne l'ai pas encore pushé car je fais 2-3 adaptations)

Pylades · Le 20/04/2012, à 14:59

Rolinh a écrit :

Tu parles bien de la version en développement?

Oui. Et OK, c’est noté.

Rolinh a écrit :

Parce que je n'ai pas pris le temps de le faire.

Tu n’as plus aucune excuse, maintenant.

uninstall:
    ${RM} ${BINDIR}/dfc
    ${RM} ${MANDIR}/man1/dfc.1
    # Pour les manpages localisées, la ligne d’install me semble un
    # peu délirante…
    ${MAKE} -C po uninstall

uninstall:
    for po in ${LANGUAGES}; \
        do ${RM} ${LOCALEDIR}/$${po}/LC_MESSAGES/${EXEC}.mo \
        done

Et au passage, je te conseille fortement de regarder l’option -D de install(1).

Rolinh · Le 20/04/2012, à 15:19

@Pylade:
Bon, dans la mesure où je pense passer à CMake, ça n'aura plus beaucoup d'importance mais merci.

Par contre, c'est volontaire la non-utilisation de l'option -D de uninstall. La raison? C'est une extension GNU. Par conséquent, cela ne fonctionne pas sous les systèmes *BSD (OSX utilise gmake par défaut) à moins d'utiliser gmake.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#626 Le 18/04/2012, à 10:52

Re : /* Topic des codeurs [7] */

#627 Le 18/04/2012, à 10:57

Re : /* Topic des codeurs [7] */

#628 Le 18/04/2012, à 11:04

Re : /* Topic des codeurs [7] */

#629 Le 18/04/2012, à 11:08

Re : /* Topic des codeurs [7] */

#630 Le 18/04/2012, à 11:17

Re : /* Topic des codeurs [7] */

#631 Le 18/04/2012, à 11:19

Re : /* Topic des codeurs [7] */

#632 Le 18/04/2012, à 11:23

Re : /* Topic des codeurs [7] */

#633 Le 18/04/2012, à 11:27

Re : /* Topic des codeurs [7] */

#634 Le 18/04/2012, à 11:32

Re : /* Topic des codeurs [7] */

#635 Le 18/04/2012, à 11:52

Re : /* Topic des codeurs [7] */

#636 Le 18/04/2012, à 12:25

Re : /* Topic des codeurs [7] */

#637 Le 18/04/2012, à 12:42

Re : /* Topic des codeurs [7] */

#638 Le 18/04/2012, à 14:27

Re : /* Topic des codeurs [7] */

#639 Le 18/04/2012, à 14:31

Re : /* Topic des codeurs [7] */

#640 Le 18/04/2012, à 14:35

Re : /* Topic des codeurs [7] */

#641 Le 18/04/2012, à 18:15

Re : /* Topic des codeurs [7] */

#642 Le 18/04/2012, à 18:27

Re : /* Topic des codeurs [7] */

#643 Le 19/04/2012, à 09:19

Re : /* Topic des codeurs [7] */

#644 Le 19/04/2012, à 21:49

Re : /* Topic des codeurs [7] */

#645 Le 20/04/2012, à 01:47

Re : /* Topic des codeurs [7] */

#646 Le 20/04/2012, à 09:51

Re : /* Topic des codeurs [7] */

#647 Le 20/04/2012, à 10:04

Re : /* Topic des codeurs [7] */

#648 Le 20/04/2012, à 10:18

Re : /* Topic des codeurs [7] */

#649 Le 20/04/2012, à 14:59

Re : /* Topic des codeurs [7] */

#650 Le 20/04/2012, à 15:19

Re : /* Topic des codeurs [7] */

Pied de page des forums