/* Topic des codeurs [8] */

grim7reaper · Le 23/03/2013, à 09:21

The Uploader a écrit :

SInon ceci a l'air pas mal : http://sciruby.com/

Je vais jeter un œil, j’en avait entendu parler.
Mais si c’est comme Scipy c’est un peu usine à gaz quoi, moi je voulais juste faire des tableaux à N-dimensions avec de bonnes perf’.
Enfin, je vais jeter un œil (bien que d’après le github, ça semble pas bien vivace niveau développemnt )
Au pire, je m’habituerai à l’indexation de NArray ou referait une couche pour changer l’indexation.

The Uploader a écrit :

T'as regardé sur ruby toolbox ?

Je vais aller voir.

Édit : Ok, pour SciRuby pour le moment ils se concentrent sur NMatrix d’où le manque d’activité sur le dépôt de SciRuby.

Dernière modification par grim7reaper (Le 23/03/2013, à 09:26)

Pylades · Le 23/03/2013, à 12:41

grim7reaper a écrit :

Donc là je suis franchement perspicace

Perspicace tu l’es ; mais ça ne serait pas plutôt « perplexe », pour cette histoire ?

grim7reaper · Le 23/03/2013, à 12:58

Ho putain le fail !
Bon allez, je le laisse ^^

tshirtman · Le 23/03/2013, à 21:07

Puisqu'on parle de ruby

Je recherchait cette vidéo http://youtu.be/csyL9EC0S0c (par ce qu'elle est très rigolote et dis du mal de jeff atwood) en passant par le site du gars (http://programmingistessible.com) et je suis tombé la dessus http://programmingisterrible.com/post/4 … parse-ruby, qui dit que ruby n'as pas de grammaire formelle, ce qui m'étonne un peu si le language à une spec complète, et que le parsing du ruby est horrible (je veux bien le croire), donc loin de moi l'idée de lancer une flamewar, mais je veux bien des avis pour ceux qui connaissent mieux ruby que moi.

grim7reaper · Le 23/03/2013, à 21:29

Avant peut-être (Cf. ici où Matz lui-même dit d’aller voir dans parse.y pour plus de détail), maintenant (depuis la standardisation ISO), il y a bien la grammaire incluse dans le standard (du moins dans le draft, mais il n’y a pas de raison que le standard soit moins complet que le draft).

Édit : après avoir lu l’article, il n’y a rien qui me choque vraiment. Je pense que le mec trolle un peu.
Après, Matz lui même dit que parse.y est la partie la plus moche de Ruby (mais bon les parsers en Flex/Bison c’est rarement sexy de toute façon…).
Sinon, pour mieux se rendre compte : petite visualisation de la grammaire Ruby (comparé à Java 1.5 (Java 7 est probablement plus complexe maintenant) et Javascript)

Dernière modification par grim7reaper (Le 23/03/2013, à 21:40)

Mindiell · Le 23/03/2013, à 22:31

Question con, si je suis capable de faire à peine 1 million de NOP en un peu plus d'une seconde, c'est plutôt mal barré pour faire un émulateur, non ?

grim7reaper · Le 24/03/2013, à 06:51

Un émulateur de quoi ?
Mais oui, ça semble mal parti si rien qu’en faisant des NOP tu atteins à peine le MHz…
Mais tu as fait ça en quel langage/sur quel genre de machine ? Ça me semble très lent quand même

Mindiell · Le 24/03/2013, à 08:02

en python sur mon PC

EDIT : Le code minime et les infos du PC

#!/usr/bin/python

import time

class Processor():
    def __init__(self):
        self.opcodes = {
            1: self.nop
            }
        self.program_stream = None
        self.reset()

    def reset(self):
        self.program_counter = 0
        self.opcode = 0
        self.program_size = len(self.program_stream or b'')

    def load_program(self, program_file):
        with open(program_file, 'rb') as f:
            self.program_stream = f.read()
        self.reset()

    def run(self):
        while self.next_step():
            pass

    def next_step(self):
        # Reading next opcode
        if self.program_counter<self.program_size:
            self.opcode = self.program_stream[self.program_counter]
            self.program_counter += 1
            #if self.opcode in self.opcodes:
            self.opcodes[self.opcode]()
            return True

    def nop(self):
        pass


myProc = Processor()
myProc.load_program("source.test")
start = time.perf_counter()
myProc.run()
end = time.perf_counter()
print("Time elapsed : {0}".format(end-start))
print(myProc.program_counter)

Mon PC :
Mémoire : 3 Go
Processeur : Intel Core2 Duo 2.5 GHz

J'ai pas trop l'impression d'avoir codé salement, et si je suis déjà obligé d'optimiser des trucs, c'est même pas la peine ;/

Dernière modification par Mindiell (Le 24/03/2013, à 08:33)

grim7reaper · Le 24/03/2013, à 08:34

Et tu veux émuler quoi ?

Python est probablement un mauvais choix pour un émulateur, c’est généralement du C, C++ ou assembleur.
Mais pour faire des NOP, je suis quand même super étonné que ça soit si lent. C’est quoi ton code pour tester ta « vitesse de NOP » ?

Édit : Ok, je viens de voir ton édit ^^

Dernière modification par grim7reaper (Le 24/03/2013, à 08:34)

grim7reaper · Le 24/03/2013, à 08:46

Bon après avoir viré les perf_counter (j’ai pas encore Python 3.3 sur mon PC) et remplacé la clef 1 par '1' (vu que mon fichier source contient des 1 en ASCII, pas en binaire), bah j’arrive à 0,67s d’exécution (tout compris par contre, pas juste le run).
Mon processeur fait du 2,00 GHz (2,90 en pointe).

Édit : 0.5s si je merge run et next_step (vu que pour le moment run ajoute une indirection inutile).

Dernière modification par grim7reaper (Le 24/03/2013, à 08:49)

Elzen · Le 24/03/2013, à 17:12

Article de présentation de SSh publié : une relecture serait la bienvenue, et le dernier point peut éventuellement intéresser quelques personnes, si vous ne le connaissiez pas déjà

Dernière modification par Elzen (Le 24/03/2013, à 17:12)

The Uploader · Le 24/03/2013, à 17:18

Mindiell a écrit :

Mon PC :
Mémoire : 3 Go
Processeur : Intel Core2 Duo 2.5 GHz

J'ai encore pire que ça (Core2Duo T5800 à 2 Ghz, 4 Go de mémoire) et j'ai des tonnes d'émulateurs lourds (le plus lourd étant DOSBox avec Syndicate Wars par exemple, toute la 3D utilise entièrement le CPU de toutes manières) donc oui je crois que c'est Python le coupable là... Java ou Ruby ce serait pareil évidemment.

Donc : vive le C.

-----

[nvidia-96xx-all/AUR]

Bon ben en fait ça compile avec linux 3.8 (un patch pour nvidia-313-18 qui marche sans rien faire sur nvidia-96xx O_o ) :

--- a/kernel/conftest.sh
+++ b/kernel/conftest.sh
@@ -160,6 +160,7 @@ build_cflags() {
 
     if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then
         CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include"
+        CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include/uapi"
         CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include/generated"
         CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include/generated/uapi"
     elif [ "$ARCH" = "arm" ]; then
--

Suffisait de rajouter une ligne à NVIDIA-src/usr/usr/nv/conftest.sh, et d'aller chopper le patch sur le rapport de bug gentoo (comme pour le patch pour linux 3.7). Erf.... Heureusement que je semble être le seul utilisateur de nvidia-96xx-all, vu que nvidia-96xx-all est resté incompilable pour linux 3.8 pendant 3/4 semaines et que linux 3.8 est arrivé dans le dépôt [core] d'Archlinux il y a une ou deux semaines.

Par contre y'a plusieurs utilisateurs de nvidia-96xx (tout court) et ce dernier ne semble pas être à jour. Faudrait peut-être que je notifie le mainteneur.

Conclusion : vive gentoo (x2)

Dernière modification par The Uploader (Le 24/03/2013, à 17:45)

Mindiell · Le 24/03/2013, à 18:33

@The Uploader : Oui, je sais bien que c'est Python Je pensais juste qu'il serait pas si lent que ça.

@grim7reaper : Tu as quelle version de python ? C'est p'tet une version plus rapide Le but c'est d'émuler en python, en C / C++ je sais déjà faire.

J'ai modifié pour écrire en ASCII et faire opcodes {'1': self.nop} mais je stagne autour de la seconde. Je suis déçu !
Par contre, on m'a causé de pypy qui devrait être plus rapide. Je vais tester ça.

EDIT : je confirme !

Time elapsed : 0.0557291507721

Donc, 20 fois plus rapide pour ce "test". Je peux donc émuler, grosso modo, un processeur 20MHz

Dernière modification par Mindiell (Le 24/03/2013, à 18:52)

grim7reaper · Le 24/03/2013, à 18:53

Mindiell a écrit :

@grim7reaper : Tu as quelle version de python ? C'est p'tet une version plus rapide

J’ai testé avec Python 3.2.3

Mindiell a écrit :

Le but c'est d'émuler en python, en C / C++ je sais déjà faire.

Je ne suis pas sûr qu’il y ai une grosse différence (excepté celles dues au langage lui-même), l’architecture d’un émulateur ne variant pas énormément d’un langage à un autre.
À la limite, tu peux voir une différence d’achitecture entre un émulateur « classique » et un émulateur fidèle (genre bsnes).

Mindiell a écrit :

J'ai modifié pour écrire en ASCII et faire opcodes {'1': self.nop} mais je stagne autour de la seconde. Je suis déçu !

Ha j’avais pas fais ça pour optimiser, juste que ton code tournais pas tel quel chez moi donc je t’expliquais les modif’ que j’avais faite ^^

Mindiell a écrit :

Par contre, on m'a causé de pypy qui devrait être plus rapide. Je vais tester ça.

Yep, c’est le but de pypy, et apparemment ça dépote vraiment bien (et sur des cas bien particuliers, plus que du C, mais bon la JVM (et Haskell aussi je crois) peut aussi poutrer du C sur des cas bien particuliers donc ça ne veut pas dire grand-chose en soit).

Mindiell a écrit :

EDIT : je confirme !
Time elapsed : 0.0557291507721
Donc, 20 fois plus rapide pour ce "test". Je peux donc émuler, grosso modo, un processeur 20MHz

Très grosso modo hein
Je ne sais pas ce que tu veux émuler, mais les instructions en général prennent bien plus de temps qu’un NOP (surtout ce qui accède à la mémoire).

Dernière modification par grim7reaper (Le 24/03/2013, à 18:55)

Mindiell · Le 24/03/2013, à 18:58

grim7reaper a écrit :

Mindiell a écrit :
Le but c'est d'émuler en python, en C / C++ je sais déjà faire.
Je ne suis pas sûr qu’il y ai une grosse différence (excepté celles dues au langage lui-même), l’architecture d’un émulateur ne variant pas énormément d’un langage à un autre.
À la limite, tu peux voir une différence d’achitecture entre un émulateur « classique » et un émulateur fidèle (genre bsnes).

Bah émuler des procs, voire des machines complètes. Et garder le côté sympa, portable, install simple, pas de compil, etc... de Python.
Va falloir que je me remette au C++ finalement

La machine que je souhaite émuler fait du 12 micro seconde le NOP, je calculerai plus tard si je peux faire ça avec du python... (faut j'aille manger )

Dernière modification par Mindiell (Le 24/03/2013, à 18:58)

The Uploader · Le 24/03/2013, à 19:02

ça m'a l'air très intéressant. T'as un dépôt public ?

(si j'étais fou, je referais DOSBox en Ruby, tiens. Comme d'autres l'ont refait en Java avec pas mal d'améliorations et l'ont nommé jDOSBox)

(y'a aussi un port javascript de jDOSBox: http://sourceforge.net/projects/jsdosbox Démo ici : http://jsdosbox.appspot.com/ pour jouer à Prince of persia dans le navigateur)

Dernière modification par The Uploader (Le 24/03/2013, à 19:07)

grim7reaper · Le 24/03/2013, à 19:23

@Mindiell : Ok. Sinon, y’a le VHDL qui est sympa aussi (mais là on dépasse le cadre de l’émulation )

@Rolinh : si ta proposition tiens toujours, le code de mon parser INI en Ruby a atteint le stade « présentable » donc je peux le publier.
La bidouille avec ALSA devrait bientôt l’être aussi.
Comme ce sont mes premiers codes en Ruby je serais bien sûr ouvert à toutes remarques

The Uploader · Le 24/03/2013, à 19:26

T'as un dépôt pour ton code Ruby ? Ou tu peux le poster dans le sujet ?

*lève la main pour le code review ruby*

Dernière modification par The Uploader (Le 24/03/2013, à 19:32)

Mindiell · Le 24/03/2013, à 21:34

Pfff, j'ai testé le même code en C++ (j'ai eu du mal à y revenir la vache !)

Eh ben 100 Millions de NOP en moins d'une seconde le truc... Décevant le python !

grim7reaper · Le 24/03/2013, à 21:45

Bah en même temps, compilé vs interprété.
À cela tu ajoutesdes années d’expérience (surtout vrai pour le C, mais aussi le C++) niveau compilateur (qui sont donc de nos jours d’excellent optimiseurs) et voilà le résultat.
À ce propos (optimisation), c’est quoi ton code ?
Nan parce que ça ne serait pas surprenant que le compilo’ optimise à la hache, voire fasse tout sauter, si c’est possible (et les compilo’ sont parfois TRÈS impressionnant là-dessus).

The Uploader · Le 24/03/2013, à 23:05

CPU : Intel Core 2 Duo T5800 @ 2.00 Ghz
Ram : 4 Go
kernel : linux 64 bits 3.8.4-ck (ordonnanceur de processus : Brain Fuck Scheduler v0.428 au lieu du Completely Fair Scheduler) + BFQ au lieu du CFQ pour les I/O
Fichier source.test :
'1' répété 12464984 fois sur une seule ligne (ça fait un fichier de 12,5 Mo)
ruby :

ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]

python :

Python 3.3.0

code python :

#!/usr/bin/env python

import time

class Processor():
    def __init__(self):
        self.opcodes = {
            '1': self.nop
            }
        self.program_stream = None
        self.reset()

    def reset(self):
        self.program_counter = 0
        self.opcode = 0
        self.program_size = len(self.program_stream or b'')

    def load_program(self, program_file):
        with open(program_file, 'rb') as f:
            self.program_stream = f.read()
        self.reset()

    def run(self):
        while self.next_step():
            pass

    def next_step(self):
        # Reading next opcode
        if self.program_counter<self.program_size:
            self.opcode = self.program_stream[self.program_counter]
            self.program_counter += 1
            #if self.opcode in self.opcodes:
            #self.opcodes[self.opcode]()
            return True

    def nop(self):
        pass


myProc = Processor()
myProc.load_program("source.test")
start = time.perf_counter()
myProc.run()
end = time.perf_counter()
print("Time elapsed : {0}".format(end-start))
print(myProc.program_counter)

(sans mettre #self.opcodes[self.opcode]() en commentaire ça plantait, alors j'ai fait pareil pour le code ruby. De toutes façons ça change rien j'pense)

code ruby :

#!/usr/bin/env ruby

require 'benchmark'

class Processor

  attr_accessor :program_counter
  
  def initialize
    @opcode = nil
    @opcodes = { 1 => self.nop }
    @program_counter = nil
    @program_stream = ""
    @program_size = nil
    self.reset
  end
  
  def reset
    @program_counter = 0
    @opcode = 0
    @program_size = @program_stream.length
  end
  
  def load_program(prg_file)
    File.open(prg_file, 'r') do |f|
      @program_stream = f.read
    end
    reset
  end
  
  def run
    while next_step do
    end
  end
  
  def next_step
    # Reading next opcode
    if @program_counter < @program_size
      @opcode = @program_stream[@program_counter]
      @program_counter += 1
      #if @opcodes.member? @opcode
      #@opcodes[@opcode]
      return true
    end
  end  
  
  def nop
  end
end  

if __FILE__ == $0
  myProc = Processor.new
  myProc.load_program("source.test")
  Benchmark.bm do |x|
    x.report { myProc.run() }
  end
  puts "@program_counter=" + myProc.program_counter.to_s
end

retour python :

./proc.py
Time elapsed : 12.90083047600092
12464985

retour ruby :

./proc.rb
       user     system      total        real
   5.930000   0.000000   5.930000 (  5.925641)
@program_counter=12464985

(Je sais pas pourquoi j'ai fait tout ça en fait. Mais merci Mindiell pour l'amusement d'une demi heure que ça m'a procuré de faire la version Ruby tout en faisant autre chose à côté ^^ )

Dernière modification par The Uploader (Le 24/03/2013, à 23:26)

naingenieu · Le 24/03/2013, à 23:54

Je me suis remis au C++ et franchement j'adore... ça reste un peu compliqué à bien comprendre mais j'étais vraiment pas allé assez loin les templates etc :bave:

d'ailleurs si quelqu'un a des bons tutos sur le c++ ( en dehors des classiques developpez et sdz ) je suis preneur ( l'anglais me dérange pas trop au cas où même si pur des notiions compliqués le français est appréciable )

Elzen · Le 25/03/2013, à 01:32

Tiens, j'n'ai encore jamais vraiment approché le C++. Vous pensez que ce serait la peine que je me penche un peu dessus ?
(Déjà, je n'ai toujours pas commencé à me mettre au Haskell…)

Elzen a écrit :

Article de présentation de SSh publié : une relecture serait la bienvenue, et le dernier point peut éventuellement intéresser quelques personnes, si vous ne le connaissiez pas déjà

Relecture demandée aussi pour mon article sur les URLs et le DNS, si vous avez le temps ^^

The Uploader a écrit :

(si j'étais fou, je referais DOSBox en Ruby, tiens. Comme d'autres l'ont refait en Java avec pas mal d'améliorations et l'ont nommé jDOSBox)

Quel genre d'améliorations ?

Genre, pour mon King Quest VII qui délire toujours, ça pourrait aider ?
(J'préférerais vraiment pouvoir l'avoir dans ScummVM ><)

grim7reaper · Le 25/03/2013, à 06:47

@The Uploader : j’ai fait ton test, sauf que moi j’ai pas commenté les accès au hash pour exécuter l’opcode.
Linux 64-bit, CPU à 2,00 GHz (pointe à 2,90GHz).

Ruby 1.9.3p194 :

        Command being timed: "./rb"
        User time (seconds): 4.44
        System time (seconds): 0.01
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.46
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 17100
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 4529
        Voluntary context switches: 3
        Involuntary context switches: 380
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

Python 3.2.3 :

        Command being timed: "./py"
        User time (seconds): 8.16
        System time (seconds): 0.02
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:08.19
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 67616
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 17243
        Voluntary context switches: 1
        Involuntary context switches: 697
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

On remarque que Python est plus lent, peut-être est-ce dû au fait qu’il fait beaucoup plus de page fault (4 530 vs 17 243) que Ruby.

naingenieu a écrit :

d'ailleurs si quelqu'un a des bons tutos sur le c++ ( en dehors des classiques developpez et sdz ) je suis preneur ( l'anglais me dérange pas trop au cas où même si pur des notiions compliqués le français est appréciable )

developpez.com en a quelques-uns qui traitent de sujet un peu avancé quand même.
Sinon, tu peux jeter un œil à The C++ Source (si tu suis un peu le C++, tu devrais reconnaître le nom de grand ponte du C++ dans l’Advisory Board), Dr. Dobbs et Guru of the Week.

Après en bouquin il y a Modern C++ Design d’Andrei Alexandrescu :

Wikipédia a écrit :

The book makes use of and explores a C++ programming technique called template metaprogramming. While Alexandrescu didn't invent the technique, he has popularized it among programmers. His book contains solutions to practical problems which C++ programmers may face. Several phrases from the book are now used within the C++ community as generic terms: modern C++ (as opposed to C/C++ style), policy-based design and typelist.

Après si tu veux investir dans des livres, cette discussion en cite de très bon.

@Elzen : j’ai lu celui sur le SSH (bon un peu rapidement), pas de remarque pour le moment.

Mindiell · Le 25/03/2013, à 07:02

The Uploader a écrit :

(sans mettre #self.opcodes[self.opcode]() en commentaire ça plantait, alors j'ai fait pareil pour le code ruby. De toutes façons ça change rien j'pense)

Si, ça compte, c'est un appel de fonction, ça aide à ralentir encore plus
Le plantage est du, à mon avis, au fait que tu lis le fichier en binaire et donc tu lis un entier 49 et non un char '1'. Donc la clef n'existe pas dans opcodes{}

The Uploader a écrit :

(Je sais pas pourquoi j'ai fait tout ça en fait. Mais merci Mindiell pour l'amusement d'une demi heure que ça m'a procuré de faire la version Ruby tout en faisant autre chose à côté ^^ )

Bah, de rien
Je ne sais pas pourquoi non plus à part troller sur la vitesse python/ruby mais sur un exemple un peu spécifique.

Bref, je crois que je vais malheureusement me rabattre sur du C++

Je veux émuler un truc très lent pour le moment, mais je ne m'interdis pas d'aller jusqu'à la Super NES par exemple.

The central processor was running at 330KHz.

EDIT:

@grim7reaper: C'est normal ces "page fault" ? Tu affiches ça comment ?

Dernière modification par Mindiell (Le 25/03/2013, à 07:04)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#876 Le 23/03/2013, à 09:21

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

#877 Le 23/03/2013, à 12:41

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

#878 Le 23/03/2013, à 12:58

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

#879 Le 23/03/2013, à 21:07

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

#880 Le 23/03/2013, à 21:29

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

#881 Le 23/03/2013, à 22:31

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

#882 Le 24/03/2013, à 06:51

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

#883 Le 24/03/2013, à 08:02

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

#884 Le 24/03/2013, à 08:34

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

#885 Le 24/03/2013, à 08:46

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

#886 Le 24/03/2013, à 17:12

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

#887 Le 24/03/2013, à 17:18

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

#888 Le 24/03/2013, à 18:33

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

#889 Le 24/03/2013, à 18:53

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

#890 Le 24/03/2013, à 18:58

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

#891 Le 24/03/2013, à 19:02

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

#892 Le 24/03/2013, à 19:23

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

#893 Le 24/03/2013, à 19:26

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

#894 Le 24/03/2013, à 21:34

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

#895 Le 24/03/2013, à 21:45

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

#896 Le 24/03/2013, à 23:05

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

#897 Le 24/03/2013, à 23:54

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

#898 Le 25/03/2013, à 01:32

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

#899 Le 25/03/2013, à 06:47

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

#900 Le 25/03/2013, à 07:02

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

Pied de page des forums