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

Rolinh · Le 12/12/2010, à 13:21

grim7reaper a écrit :

Un commit ce n'est pas juste l'action de mettre un commentaire, ça crée le fichier de correction aussi.

juste

grim7reaper a écrit :

versionning = gestion des versions

oui mais là ça fait juste une façon de le dire, ce n'est pas un mot qui veut dire la même chose.

D'accord avec grim7reaper: pusher dans ce contexte ne va vraiment pas.

Et je rejoins aussi Pylade pour sa réponse à ArkSeth. On en parlait plus haut

Et merci Pylade

grim7reaper · Le 12/12/2010, à 13:22

ArkSeth a écrit :

J'essayerais bien de le faire moi-même, mais j'suis pas sûr d'avoir les compétences requises (genre pour qu'il y ait l'autocomplétion, je sais pas du tout faire)

Il y a la bibliothèque GNU readline qui fait ça (elle gère aussi l'historique et d'autres choses).
C'est utilisé par pas mal de projet (dont Vim il me semble).

Rolinh a écrit :

oui mais là ça fait juste une façon de le dire, ce n'est pas un mot qui veut dire la même chose.

Bah ça y ressemble fortement alors…

Wikipedia a écrit :

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is actually computer software.

Pour moi c'est de la gestion de version.

Dernière modification par grim7reaper (Le 12/12/2010, à 13:24)

Rolinh · Le 12/12/2010, à 13:25

ArkSeth a écrit :

Comment je gère le travail collectif ? Je bosse tout seul dans 99.999% des cas
(Mais si une bonne âme vient bien m'apprendre comment marche mercurial, ce serait sympa)

Pas besoin de faire un travail collectif, ça peut servir même si on bosse tout seul.
Comme je viens de mettre en place un petit mercurial privé (super pratique pour faire les TP et sauvegarder ses fichiers de confs qu'il suffit de "puller" quand on utilise une autre machine!), je veux bien te servir de bonne âme

ArkSeth a écrit :

Pour « fetch », je dirais que le terme approprié est « mise à niveau »

Pas du tout. Cela n'a rien à voir avec une mise à niveau.

Rolinh · Le 12/12/2010, à 13:28

grim7reaper a écrit :

Pour moi c'est de la gestion de version.

Je ne conteste pas cela
Ce que je veux dire c'est que l'on a deux termes pour en traduire un. "Gestion de version" vs "versionning" et non "version management" ou un truc du genre.

grim7reaper · Le 12/12/2010, à 13:33

Rolinh a écrit :

ArkSeth a écrit :
Pour « fetch », je dirais que le terme approprié est « mise à niveau »
Pas du tout. Cela n'a rien à voir avec une mise à niveau.

« Pas du tout », je ne sais pas. Mais dans certains cas « mise à niveau » ne convient pas. Le programme fetchmail ne fait pas une mise à niveau de mes mails, il va les récupérer sur les serveurs distants.

Rolinh a écrit :

Ce que je veux dire c'est que l'on a deux termes pour en traduire un. "Gestion de version" vs "versionning" et non "version management" ou un truc du genre.

Oui, enfin je ne t'apprend pas que l'on ne fait pas toujours une traduction littérale .

Rolinh · Le 12/12/2010, à 13:35

Non c'est clair mais je trouve que des fois dans le français il manque des mots pour désigner précisément quelque chose et on se retrouve obligé d'en combiner plusieurs afin de vouloir dire ce que l'on veut.

Elzen · Le 12/12/2010, à 13:37

Rolinh a écrit :

Et je rejoins aussi Pylade pour sa réponse à ArkSeth. On en parlait plus haut

Y compris dans la partie où il reconnaît qu'il exagère ?

grim7reaper a écrit :

Il y a la bibliothèque GNU readline qui fait ça (elle gère aussi l'historique et d'autres choses).
C'est utilisé par pas mal de projet (dont Vim il me semble).

Merci. Je regarderai ça, un jour…

Rolinh a écrit :

Pas besoin de faire un travail collectif, ça peut servir même si on bosse tout seul.

Si je bosse seul, c'est toujours sur la même machine, modulo quelques sauvegardes auxquelles je ne touche quasiment jamais.

Rolinh a écrit :

je veux bien te servir de bonne âme

Super On s'y prend comment ?

Rolinh a écrit :

Pas du tout. Cela n'a rien à voir avec une mise à niveau.

Alors c'est que j'ai mal compris le concept de « fetch », dans ce cas…
Ce n'est pas le fait de regarder les deux versions du code (celle locale et celle sur le serveur), de repérer à quel endroit il y a un bout de code plus récent qu'un autre, et de faire les transferts qui vont bien pour qu'à la sortie, les deux versions soient à jour l'une par rapport à l'autre ?
Parce qu'en bon français, c'est à ça que correspond une mise à niveau, si je ne m'abuse : on étudie la surface du terrain, on repère les creux et les bosses, et on rabote/comble le tout pour qu'à la fin, la surface soit toute lisse et sans accrocs.

grim7reaper a écrit :

« Pas du tout », je ne sais pas. Mais dans certains cas « mise à niveau » ne convient pas. Le programme fetchmail ne fait pas une mise à niveau de mes mails, il va les récupérer sur les serveurs distants.

Question de contexte Dans ce cas-là, effectivement, ça se traduit par récupération, mais c'est vous qui parliez de code et de gestion de versions.

Rolinh a écrit :

Non c'est clair mais je trouve que des fois dans le français il manque des mots pour désigner précisément quelque chose et on se retrouve obligé d'en combiner plusieurs afin de vouloir dire ce que l'on veut.

Ça arrive dans toutes les langues. Et pas seulement pour les traductions.
C'est la conséquence directe et normale du fait qu'une langue soit une mise en mot des concepts : des fois, les gens qui inventent les mots n'ont pas bien compris les concepts.

Dernière modification par ArkSeth (Le 12/12/2010, à 13:40)

Pylades · Le 12/12/2010, à 13:51

Encore over-grillé !

ArkSeth a écrit :

Pylade a écrit :
Quel intérêt, si tu as un shell qui gère les alias sur type mime ?
L'intérêt se lit dans l'extrait de code extrapolé ci-dessus
Un truc qui soit basé sur les noms de fichiers et pas sur les commandes shells, vu que c'est un navigateur de fichiers et pas un shell, quoi ^^
J'essayerais bien de le faire moi-même, mais j'suis pas sûr d'avoir les compétences requises (genre pour qu'il y ait l'autocomplétion, je sais pas du tout faire)

Oui, j'ai édité.

Mais pour l'autocomplétion, je pense que ça va être compliqué pour pas mal de monde ici. Il faudrait regarder le code de bash et essayer de comprendre… mais la motivation, toussa…

Dernière modification par Pylade (Le 12/12/2010, à 13:52)

Rolinh · Le 12/12/2010, à 13:52

ArkSeth a écrit :

Y compris dans la partie où il reconnaît qu'il exagère ?

Heu non ^^
Quand je suis sous awesome, je n'utilise pas de gestionnaire de fichiers. Je fais tout avec zsh et justement, les alias sur les extensions prennent toute leur importance. Je trouve même beaucoup plus "convénient" (comment on dit ça?) qu'un gestionnaire de fichier classique pour, par exemple faire une recherche.
Parce que bon, j'ai aussi des alias qui te feront crier au scandale (comme "G" pour "| grep" ) qui me facilite la vie parce que c'est super vite tapé.
Et pour avoir essayé Ranger, je ne lui trouve aucune utilité. Mais bon, c'est un avis personnel.

ArkSeth a écrit :

Super On s'y prend comment ?

C'est vrai que la doc n'est pas facile à trouver. Tu as un serveur Apache ou similaire à dispo?

ArkSeth a écrit :

Rolinh a écrit :
Pas du tout. Cela n'a rien à voir avec une mise à niveau.
Alors c'est que j'ai mal compris le concept de « fetch », dans ce cas…
Ce n'est pas le fait de regarder les deux versions du code (celle locale et celle sur le serveur), de repérer à quel endroit il y a un bout de code plus récent qu'un autre, et de faire les transferts qui vont bien pour qu'à la sortie, les deux versions soient à jour l'une par rapport à l'autre ?
Parce qu'en bon français, c'est à ça que correspond une mise à niveau, si je ne m'abuse : on étudie la surface du terrain, on repère les creux et les bosses, et on rabote/comble le tout pour qu'à la fin, la surface soit toute lisse et sans accrocs.

Ah oui, vu comme ça ta définition n'est pas mal non plus. Dans ma tête j'avais aussi un peu l'idée de l'exemple de grim7reaper aussi.

grim7reaper · Le 12/12/2010, à 14:01

Pylade a écrit :

Mais pour l'autocomplétion, je pense que ça va être compliqué pour pas mal de monde ici. Il faudrait regarder le code de bash et essayer de comprendre… mais la motivation, toussa…

grim7reaper a écrit :

Il y a la bibliothèque GNU readline qui fait ça (elle gère aussi l'historique et d'autres choses).
C'est utilisé par pas mal de projet (dont Vim il me semble).

Après, si tu veux réinventer la roue au lieu d'utiliser une bibliothèque qui a fait ses preuves

Rolinh a écrit :

Je trouve même beaucoup plus "convénient" (comment on dit ça?)

Pratique ?

Dernière modification par grim7reaper (Le 12/12/2010, à 14:02)

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

grim7reaper a écrit :

Pylade a écrit :
Mais pour l'autocomplétion, je pense que ça va être compliqué pour pas mal de monde ici. Il faudrait regarder le code de bash et essayer de comprendre… mais la motivation, toussa…
grim7reaper a écrit :
Il y a la bibliothèque GNU readline qui fait ça (elle gère aussi l'historique et d'autres choses).
C'est utilisé par pas mal de projet (dont Vim il me semble).
Après, si tu veux réinventer la roue au lieu d'utiliser une bibliothèque qui a fait ses preuves
[…]

Je n'avais pas vu !

(Mais je m'en suis rendu compte ensuite, d'où mon « over-grillé ».)

Dernière modification par Pylade (Le 12/12/2010, à 14:04)

Rolinh · Le 12/12/2010, à 14:04

grim7reaper a écrit :

Rolinh a écrit :
Je trouve même beaucoup plus "convénient" (comment on dit ça?)
Pratique ?

Merci. Je me sens bête sur le coup

tshirtman · Le 12/12/2010, à 14:11

grim7reaper a écrit :

tshirtman a écrit :
push c'est facile, c'est pousser
Littéralement oui, mais dans ce contexte je trouve ça très moche de dire « Je pousse un correctif dans la branche principale »

moi je trouve tout à fait correct…

Rolinh a écrit :

grim7reaper a écrit :
Un commit ce n'est pas juste l'action de mettre un commentaire, ça crée le fichier de correction aussi.
juste
grim7reaper a écrit :
versionning = gestion des versions
oui mais là ça fait juste une façon de le dire, ce n'est pas un mot qui veut dire la même chose.
D'accord avec grim7reaper: pusher dans ce contexte ne va vraiment pas.
Et je rejoins aussi Pylade pour sa réponse à ArkSeth. On en parlait plus haut
Et merci Pylade

historisation? mais oui sinon c'est pas grave d'avoir besoin de plusieurs mots pour dire la même chose… toutes les langues ne sont pas équivalentes, c'est le concept…

Pylades · Le 12/12/2010, à 15:02

/me est un grand fou, il a commencé ce dont parlait ArkSeth.

Questions : existe-t-il une alternative à chdir en C standard ? Existe-t-il un équivalent de puts mais qui n'ajoute pas de saut de ligne à la fin (non, printf ne marche pas dans ce cas) ?

grim7reaper · Le 12/12/2010, à 15:07

Pylade a écrit :

/me est un grand fou, il a commencé ce dont parlait ArkSeth.
Questions : existe-t-il une alternative à chdir en C standard ?

Non. Le standard du C n'est pas fait pour interagir avec le système (arborescence, thread, etc) vu qu'il est censé pouvoir tourner sans OS et/ou sur des archi embarqué qui n'ont pas ce genre de notion.
Posix par contre, oui.

Existe-t-il un équivalent de puts mais qui n'ajoute pas de saut de ligne à la fin

fputs("foobar", stdin);

?

(non, printf ne marche pas dans ce cas) ?

Pourquoi ?
Qu'il ne convienne pas je le comprend, mais qu'il ne fonctionne pas…

Dernière modification par grim7reaper (Le 12/12/2010, à 15:08)

Elzen · Le 12/12/2010, à 15:10

Rolinh a écrit :

Je trouve même beaucoup plus "convénient" (comment on dit ça?)

Pratique va bien, effectivement, sinon, j'aurais dit « ça me convient même beaucoup mieux ».

Rolinh a écrit :

Parce que bon, j'ai aussi des alias qui te feront crier au scandale (comme "G" pour "| grep" ) qui me facilite la vie parce que c'est super vite tapé.

C'est effectivement très moche Mais comme j'ai déjà dit que l'aspect « vite tapé » était loin d'être le plus important pour moi, je pense qu'il est inutile de revenir sur le sujet ^^

Rolinh a écrit :

Et pour avoir essayé Ranger, je ne lui trouve aucune utilité. Mais bon, c'est un avis personnel.

D'après les captures, Ranger a l'air d'être un navigateur « graphique, mais en mode texte », ce qui ne correspond pas au CLFB que j'envisageais ci-dessus (et je te rejoins sur le fait que ce genre de navigateurs de fichiers, j'accroche pas).
En revanche, l'utilité de CLFB même par rapport aux bizarreries de zsh s'exprime dans le cas où tu veux seulement manipuler les fichiers, et pas faire tout ce qu'un shell te propose. Ce serait extraire la fonctionnalité pour en faire un truc séparé.
Avec ton zsh, ça t'arrive bien quand même de temps en temps de lancer parted, python, ou un autre interpréteur de commandes dynamique de temps en temps, non ? Là ce serait pareil, mais avec un truc dédié à (et donc optimisé pour) la gestion de fichiers

Rolinh a écrit :

C'est vrai que la doc n'est pas facile à trouver. Tu as un serveur Apache ou similaire à dispo?

J'ai fadrienn (et j'ai un serveur web sur fadreils aussi au cas où).
Tiens d'ailleurs, en parlant de « ou similaire », quelqu'un sait s'il y a un équivalent au module action d'apache sur lighttpd ?

tshirtman a écrit :

moi je trouve tout à fait correct…

Là je les rejoins : en français, ça sonne vraiment très mal
Si tu voulais le dire sans penser à l'équivalent anglais, tu formulerais ça très différemment, je pense. Et c'est ça, faire une bonne traduction : reproduire les mêmes idées en les détachant de la formulation d'origine.

Pylade a écrit :

/me est un grand fou, il a commencé ce dont parlait ArkSeth.

Tu veux qu'on voit un peu ensemble les specs que j'imaginais ?
Par contre, j'suis pas assez callé en C pour répondre à tes questions, mais j'veux quand même bien essayer de te filer un coup de main dans la mesure de mes modestes moyens.
(Et je veux bien ouvrir une zone de discussion dessus sur fadrienn, si tu veux, comme ça tu pourras même en parler avec des apostrophes typographiques ^^ Et j'ajouterai peut-être même un système de gestion de versions quand Rolinh m'aura apprit )

grim7reaper · Le 12/12/2010, à 15:16

Je peux éventuellement filer un coup de main, en tant que conseiller technique bien sûr et pourquoi pas participer au code en fonction de mon temps libre…

Pylades · Le 12/12/2010, à 15:31

grim7reaper a écrit :

Pylade a écrit :
/me est un grand fou, il a commencé ce dont parlait ArkSeth.
Questions : existe-t-il une alternative à chdir en C standard ?
Non. Le standard du C n'est pas fait pour interagir avec le système (arborescence, thread, etc) vu qu'il est censé pouvoir tourner sans OS et/ou sur des archi embarqué qui n'ont pas ce genre de notion.
Posix par contre, oui.

C'est ce que je craignait. Ça va bien, niveau portabilité, de lire PWD au lieu d'utiliser getcwd ? Existe-t-il une variable d'environnement qui indique quel caractère joue le rôle de séparateur de répertoire dans les chemins (un peu comme IFS, mais pour les chemins) ?

grim7reaper a écrit :

Pylade a écrit :
Existe-t-il un équivalent de puts mais qui n'ajoute pas de saut de ligne à la fin
fputs("foobar", stdin);
?

En effet. Je pensais qu'elle agissait comme puts.

grim7reaper a écrit :

Pylade a écrit :
(non, printf ne marche pas dans ce cas) ?
Pourquoi ?
Qu'il ne convienne pas je le comprend, mais qu'il ne fonctionne pas…

clfb.c: In function 'main':
clfb.c:9: warning: format not a string literal and no format arguments

(Et je n'avais vraiment pas envie de faire un hack crado pour que ça marche.)

ArkSeth a écrit :

[…]
Pylade a écrit :
/me est un grand fou, il a commencé ce dont parlait ArkSeth.

Tu veux qu'on voit un peu ensemble les specs que j'imaginais ?
Par contre, j'suis pas assez callé en C pour répondre à tes questions, mais j'veux quand même bien essayer de te filer un coup de main dans la mesure de mes modestes moyens.
(Et je veux bien ouvrir une zone de discussion dessus sur fadrienn, si tu veux, comme ça tu pourras même en parler avec des apostrophes typographiques ^^ Et j'ajouterai peut-être même un système de gestion de versions quand Rolinh m'aura apprit )

Bon, ça va se traîner un peu, hein, le 3 janvier je rentre dans une période d'examens qui dure jusqu'au 20, et puis ce n'est pas comme si j'avais quarante-deux mille trucs à faire, mais presque.
Pour la gestion des versions, j'avais déjà fait le git init, mais je peux apprendre Mercurial. ^^

grim7reaper · Le 12/12/2010, à 15:48

Pylade a écrit :

C'est ce que je craignait. Ça va bien, niveau portabilité, de lire PWD au lieu d'utiliser getcwd ?

PWD n'existe pas sous Windows (il y a peut-être %CD% qui est équivalent…) donc ce n'est pas portable.

Existe-t-il une variable d'environnement qui indique quel caractère joue le rôle de séparateur de répertoire dans les chemins (un peu comme IFS, mais pour les chemins) ?

Pas que je sache, mais je ne suis pas très calé niveau variable d'environnement.

clfb.c: In function 'main':
clfb.c:9: warning: format not a string literal and no format arguments
(Et je n'avais vraiment pas envie de faire un hack crado pour que ça marche.)

Tu avais fait un truc comme ça, nan ?

printf(toto);

C'est juste une mauvais utilisation, comme ça (ce n'est pas un hack crado, juste une « bonne » utilisation de la fonction) ça fonctionne . Mais de toute façon c'est bidon d'un point de vue sémantique d'utiliser printf ici (je le donne juste la syntaxe pour info).

printf("%s", toto);

Pour la gestion des versions, j'avais déjà fait le git init, mais je peux apprendre Mercurial. ^^

Moi je « connais » (i.e, j'ai des bases) en Mercurial, darcs, bzr et git.

Dernière modification par grim7reaper (Le 12/12/2010, à 15:58)

xapantu · Le 12/12/2010, à 15:57

grim7reaper a écrit :

Pour la gestion des versions, j'avais déjà fait le git init, mais je peux apprendre Mercurial. ^^
Moi je « connais » (i.e, j'ai des bases) en Mercurial, darcs, bzr et git.

Tiens, ça me fait penser qu'il faudrait proposer de faire un sujet "choix de son gestionnaire deversion" dans la rubrique programmation, comme "aide au choix du langage"... Je dis ça mais vu que je connais que bzr et svn… je vais pas pouvoir proposer grand chose. (enfin, je connais un peu git, mais à part git clone, je connais pas grand chose )

grim7reaper · Le 12/12/2010, à 15:59

Sinon, je suis tombé sur ça

Paul McKenzie a écrit :

You don't need to handle back slashes.
Always use *forward* slashes for file names. The ANSI C standard allows forward slashes to be used in file names as the path separator, regardless of the separator used by the operating system.. This way, you don't have any problems porting your code from one OS to another.
So in a C or C++ program, "/Dir1/Dir2/File3" is eqiuvalent to \Dir1\Dir2\File3 in Windows/DOS and /Dir1/Dir2/File3 in UNIX. This is one of the little known facts of file name handling.
Regards,

Quelqu'un a un Windows pour vérifier ça ?
Ça me paraît bizarre et je ne trouve pas de source qui confirme (et j'ai pas de Windows pour tester…)

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

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

grim7reaper a écrit :

Pylade a écrit :
C'est ce que je craignait. Ça va bien, niveau portabilité, de lire PWD au lieu d'utiliser getcwd ?
PWD n'existe pas sous Windows (il y a peut-être %CD% qui est équivalent…) donc ce n'est pas portable.
[…]

Ouais, et puis je me suis rendu compte que PWD n'est pas actualisé lorsqu'on change de répertoire, donc bon… ^^

Voici un embryon de code bien crado, notamment lorsque qu'on est à la racine. Mais bon, c'est juste une POC…

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int main(void)
{
    char vi[256];
    char* nl;
    do
    {
        getcwd(vi, sizeof vi);
        printf("clfb: %s> ", strrchr(vi, '/') + 1);
        fgets(vi, sizeof vi, stdin);
        nl = strrchr(vi, '\n');
        if (nl)
        {
            *nl = '\0';
            chdir(vi);
        }
    } while (nl);
    putchar('\n');
    return 0;
}

Elzen · Le 12/12/2010, à 16:09

Pylade a écrit :

Existe-t-il une variable d'environnement qui indique quel caractère joue le rôle de séparateur de répertoire dans les chemins (un peu comme IFS, mais pour les chemins) ?

En théorie, Windows accepte "\" et "/" comme séparateur de répertoires de façon indifférente. Et comme tous les autres systèmes, à ma connaissance, utilisent "/", je pense que tu peux utiliser "/" sans problème.
Mais d'un autre côté, est-ce vraiment utile de faire un truc compatible Windows, à plus forte raison quand c'est pour marcher en ligne de commande, ce à quoi la plupart des utilisateurs Windows sont allergiques ? ^^
Tu fais le truc pour que ça marche sur les UNIX-like Libres, et comme tu publies le code sous licence Libre, si quelqu'un veut l'utiliser ailleurs, il n'a qu'à le porter pour son système… non ? (Enfin, il faut quand même respecter les normes)

Pylade a écrit :

le 3 janvier je rentre dans une période d'examens qui dure jusqu'au 20, et puis ce n'est pas comme si j'avais quarante-deux mille trucs à faire, mais presque.

À peu près pareil ^^"
Mais bon, si avoir une todolist qui va de la Terre à la Lune nous empêchait d'essayer de faire des choses qui ne sont pas dessus, ça se saurait…

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

grim7reaper a écrit :

Sinon, je suis tombé sur ça
Paul McKenzie a écrit :
You don't need to handle back slashes.
Always use *forward* slashes for file names. The ANSI C standard allows forward slashes to be used in file names as the path separator, regardless of the separator used by the operating system.. This way, you don't have any problems porting your code from one OS to another.
So in a C or C++ program, "/Dir1/Dir2/File3" is eqiuvalent to \Dir1\Dir2\File3 in Windows/DOS and /Dir1/Dir2/File3 in UNIX. This is one of the little known facts of file name handling.
Regards,
Quelqu'un a un Windows pour vérifier ça ?
Ça me paraît bizarre et je ne trouve pas de source qui confirme (et j'ai pas de Windows pour tester…)

Si, c'est le cas, mais je n'étais au courant que pour les chemins relatifs. Le problèmes c'est pour les chemins absolu, mais bon, comme les Windows n'ont pas de racine…

Cependant, ça serait bien de connaître ce séparateur pour afficher correctement le répertoire courant à l'utilisateur. ^^

grim7reaper · Le 12/12/2010, à 16:24

@Pylade

char vi[PATH_MAX];

C'est mieux (même si tu dois définir PATH_MAX à la main, vu que POSIX ne garantis pas sa présence, c'est toujours mieux qu'une constante magique).
Sinon il y a bien _PC_PATH_MAX, mais je ne sais pas où elle se situe en terme de standard.

@ArkSeth : non, il vaut mieux faire un truc portable dès le début. Je râle assez souvent que je dois bosser sous Windows et que je ne peux pas utiliser les même outils.

Dernière modification par grim7reaper (Le 12/12/2010, à 16:25)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2226 Le 12/12/2010, à 13:21

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

#2227 Le 12/12/2010, à 13:22

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

#2228 Le 12/12/2010, à 13:25

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

#2229 Le 12/12/2010, à 13:28

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

#2230 Le 12/12/2010, à 13:33

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

#2231 Le 12/12/2010, à 13:35

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

#2232 Le 12/12/2010, à 13:37

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

#2233 Le 12/12/2010, à 13:51

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

#2234 Le 12/12/2010, à 13:52

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

#2235 Le 12/12/2010, à 14:01

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

#2236 Le 12/12/2010, à 14:03

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

#2237 Le 12/12/2010, à 14:04

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

#2238 Le 12/12/2010, à 14:11

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

#2239 Le 12/12/2010, à 15:02

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

#2240 Le 12/12/2010, à 15:07

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

#2241 Le 12/12/2010, à 15:10

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

#2242 Le 12/12/2010, à 15:16

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

#2243 Le 12/12/2010, à 15:31

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

#2244 Le 12/12/2010, à 15:48

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

#2245 Le 12/12/2010, à 15:57

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

#2246 Le 12/12/2010, à 15:59

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

#2247 Le 12/12/2010, à 16:07

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

#2248 Le 12/12/2010, à 16:09

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

#2249 Le 12/12/2010, à 16:13

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

#2250 Le 12/12/2010, à 16:24

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

Pied de page des forums