jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Nyco

Dépêche éditée par

Ragnagna

Articles : Journées Perl 2005

Posté par Sébastien Aperghis-Tramoni (page perso, ). Modéré le 11 avril 2005.

Les Journées Perl 2005, la conférence francophone sur Perl organisée par l'association Les Mongueurs de Perl, se tiendra les jeudi 9 et vendredi 10 juin 2005 dans la Faculté des Sciences de Luminy, à Marseille.

Les Journées Perl sont l'occasion de se rencontrer et parler de Perl en français. Y seront réunis des gens qui ont mené des projets en Perl, qui travaillent sur le langage lui-même, qui utilisent ce langage tous les jours et qui veulent en apprendre plus. Quelques-uns des meilleurs auteurs et développeurs Perl francophones seront présents pour discuter de leur travail, de leurs projets, pour les mettre aux niveaux de tous, débutants et confirmés.

Rejoignez nous à Marseille pendant ces deux jours pour parler et entendre parler de Perl dans le cadre de la Faculté des Sciences de Luminy, au milieu des calanques, de la lavande et des cigales.

> Lire la dépêche (33 commentaires, moyenne: 2,2).

Frais d'inscription à la conférence : 25 ¤ (tarif réduit 15 ¤).

Les Mongueurs de Perl est une association française à but non lucratif, qui promeut l'utilisation de Perl et les groupes d'utilisateurs de Perl en France.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Sacré langage!

Posté par Stéphane TRAUMAT (page perso, ) le 11/04/2005 à 15:03. (lien). Évalué à 3.

Je vais me faire taper dessus mais je voudrais juste un résumé court qui explique : pkoi utiliser perl ?

[^]Re: Sacré langage!

Posté par Nicolas (page perso, ) le 11/04/2005 à 15:04. (lien). Évalué à 3.
Si tu ne sais pas, c'est que tu n'en as pas besoin!
- [^]Re: Sacré langage!
  
  Posté par Stéphane TRAUMAT (page perso, ) le 11/04/2005 à 15:16. (lien). Évalué à 4.
  Nah chaque langage a ces petits points forts.. ces trucs pour lequel il est bien... et je voulais savoir quelles étaient les points forts de perl et comment les gens s'en servaient
  - [^]Re: Sacré langage!
    
    Posté par Matthieu Moy (page perso, ) le 11/04/2005 à 15:32. (lien). Évalué à 7.
    Je connais pas super bien perl, mais en gros, c'est très adapté quand le shell unix ne suffit plus mais que tu ne veux pas sortir l'artillerie d'un "vrai" langage.
    
    C'est très facile de parser du texte (y'a des expressions régulières partout), c'est faiblement typé, ce qui a mon gout est un avantage pour du code simple en non critique, mais inacceptable pour une grosse applie.
    
    Ce que je trouve assez impressionnant, c'est ce qu'on peut faire en une ligne (les fameux "one liners" a tapper sur une ligne de commande).
    
    Bon, ceci dit, il y a aussi des gens qui utilisent perl pour des assez grosses applies et qui en sont contents.
  - [^]Re: Sacré langage!
    
    Posté par Arthur Accroc () le 13/04/2005 à 19:32. (lien). Évalué à 2.
    
    chaque langage a ces petits points forts.. ces trucs pour lequel il est bien... et je voulais savoir quelles étaient les points forts de perl
    
    L'administration système.
    Pour ça :
    - des fonctions de manipulation de fichiers directement intégrées au langage;
    - pareil pour les fonctions de traitement (au sens traitement automatisé) de texte (expressions rationnelles, ensemble de possibilités équivalentes à celles d'awk, etc.); et les fichiers de configuration, de logs, etc. sont pratiquement tous des fichiers texte... à part sous Windows;
    - des fonctions intégrées proches du système;
    - probablement la plus grosse base de modules tous langages confondus ( http://www.cpan.org/(...) ), contenant, entre autres, tout ce dont on peut rêver pour l'administration système (j'ai déjà eu besoin de trucs pointus);
    - possibilité de faire des unilignes plus courts et plus puissants qu'avec uniquement le shell (et les unilignes, c'est bien pratique pour faire rapidement et de manière automatisée un traitement lourd et/ou complexe sur des fichiers; voir http://www-106.ibm.com/developerworks/linux/library/l-p101/(...) et http://www-106.ibm.com/developerworks/linux/library/l-p102.html(...) );
    - possibilité assez facile d'interface aussi bien texte, que graphique ou web (pratique pour réutiliser du code d'un script d'administration pour une interface qu'on fournit aux utilisateurs);
    - disponible sur les principales plateformes et souvent déjà installé sur les systèmes de type Unix (on est parfois amené à intervenir sur des systèmes qu'on n'a pas installé soi-même)...
    
    Qui plus est, même s'il est souvent considéré comme pas très lisible, Perl est toutefois un langage de haut niveau.
    La dernière fois que j'ai dû regarder du code C, j'ai passé un certain temps à analyser ce que faisaient plusieurs dizaines de lignes... en fait un traitement de chaînes de caractères assez trivial, qui tient en quelques lignes de Perl (le but était justement de le refaire en Perl), mais fait en C "à la main" avec des pointeurs sur chaînes de caractères, des boucles qui les incrémentent, tout un tas de tests, c'est tout de suite une entreprise de grande ampleur... Au final, je trouve la version Perl bien plus lisible !
    
    --
    "Les Français sont des veaux."
    Général de Gaulle

[^]Re: Sacré langage!

Posté par applex () le 11/04/2005 à 15:21. (lien). Évalué à 4.
Ben dans certaines organisations, tout est fait en perl... C'est une continuité.
Il y a aussi ceux qui ont appris le perl et à qui cela leur convient (ils n'ont donc pas besoin de changer).
- [+] [^]Re: Sacré langage!
  
  Posté par HSimpson () le 12/04/2005 à 12:16. (lien). Évalué à -1.
  Ben dans certaines organisations, tout est fait en windows... C'est une continuité.
  Il y a aussi ceux qui ont appris le windows et à qui cela leur convient (ils n'ont donc pas besoin de changer).

[^]Re: Sacré langage!

Posté par Emmanuel Seyman () le 11/04/2005 à 15:27. (lien). Évalué à 6.
Je vais me faire taper dessus mais je voudrais juste un résumé court qui explique : pkoi utiliser perl ?

Au bout du compte, il n'y a presque jamais de raisons générales pour utiliser un langage de programmation plutôt qu'un autre parce que les différences entre deux langages sont souvent de l'ordre des gouts et des couleurs (donc des préférences individuelles).

Pourquoi Perl :

- C'est portable
- C'est puissant
- C'est un langage de haut niveau, donc pas de géstion de la mémoire comme en C
- Tout plein de modules sur www.cpan.org
- La syntaxe est un melange de shell et de C, ce qui fait qu'il est facile de commencer a programmer en Perl
- Une fois qu'on a acquis les bases, on peut utiliser les variables systèmes ($_, $!, $@, ...) pour alléger la syntaxe

Pour les gens qui veulent voir ce qui ca donne, je recommande de lire l'Introduction a Perl de Sylvain Lhullier qui était paru dans Linux Magazine France.

http://sylvain.lhullier.org/publications/intro_perl/index.html(...)
- [^]Re: Sacré langage!
  
  Posté par Pierre Mallard () le 11/04/2005 à 15:57. (lien). Évalué à 2.
  
  - C'est portable
  - C'est puissant
  -...
  
  Et surtout du temps de gagné pour le developpement par rapport a des langages un peu plus lourds comme le C.
  
  Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?
  - [^]Re: Sacré langage!
    
    Posté par salvaire () le 11/04/2005 à 16:43. (lien). Évalué à 5.
    
    Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?
    
    Le problème se fait sentir quand tu programme en Perl oo et en utilisant massivement les tables hachages pour les paramètres d'appels (ParamsValidate) et pour les classes. Pour des petits codes rapide ça va, au delà sa commence à ramer. Espérons que Perl 6, va améliorer la chose. En faîte, il faut coder les parties critiques en C ou C++, puis wrapper avec SWIG. À part ça les regexp tiennent le coups, même sur des fichiers de plusieurs dizaines Mo.
  - [^]Re: Sacré langage!
    
    Posté par lasher () le 14/04/2005 à 09:33. (lien). Évalué à 1.
    
    Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?
    
    J'avais fait une appli en Perl qui devait parser des mails, générer un fichier XML décrivant ces mails, contacter une base MySQL, utiliser Image Magick pour déterminer les dimensions d'une image .... Bref, faire des trucs assez complexes. Avec une contrainte : mon appli plus les traitements des autres applis (programmées en Perl elles aussi) ne devait pas dépasser 8 secondes de délai entre réception du mail et émission du SMS de confirmation...
    
    Mon petit parser de mail effectuait son boulot en moins de 0.5 seconde. Les autres applis en Perl faisaient à peu près pareil (avec en plus de l'analyse XML, des écritures dans la base, etc). Bref, Perl est rapide.
    
    En C, ça aurait sans doute pris moins de temps à l'exécution. Maintenant, les quelques millièmes de secondes gagnés par le programme en C sont négligeables devant les quelques semaines de dév gagnées grâce à Perl.
    - [^]Re: Sacré langage!
      
      Posté par Pierre Mallard () le 15/04/2005 à 15:09. (lien). Évalué à 1.
      Bien des applis dependent du millieme de secondes : traitement du signal, gestion de ressources reseaux etc etc etc...
      - [^]Re: Sacré langage!
        
        Posté par lasher () le 19/04/2005 à 12:22. (lien). Évalué à 0.
        Oui. Et dans ce cas tu ne prendras pas un langage interprêté, parce qu'à ma connaissance aucun n'est capable de ce genre de perfs. Donc ton argument n'a absolument aucune valeur.
        
        En apparté, pour ce qui est de la rapidité d'exécution/de la performance d'un code, je te renvoie à Abrash (Black book of programming, dispo gratuitement sur le net), au tout premier chapitre. En résumé : il démontre qu'à moins de maîtriser parfaitement l'assembleur (et donc la machine sur laquelle on programme, quelque part), la différence de performance entre un code écrit en c et d'un autre en ASM est négligeable. Et il écrivait ça il y a plus de 10 ans (à une époque où l'optimisation des compilateurs n'était pas ce qu'elle est maintenant), à l'époque des 486...
- [^]Re: Sacré langage!
  
  Posté par Yves Agostini (page perso, ) le 11/04/2005 à 18:28. (lien). Évalué à 2.
  il manque :
  - par défaut sur tous les systèmes Unix, même anciens, beaucoup de scripts de démarrage sont en perl : outil indispensable de l'administrateur système.
  
  Sinon, autres exemples :
  http://www.crium.univ-metz.fr/docs/devel/cleanperl/(...)
  - [^]Re: Sacré langage!
    
    Posté par totof2000 () le 13/04/2005 à 13:07. (lien). Évalué à 3.
    - par défaut sur tous les systèmes Unix, même anciens, beaucoup de scripts de démarrage sont en perl : outil indispensable de l'administrateur système.
    
    ?????
    
    C pas le cas ous aix
    c pas le cas sous solaris, a ma connaissance, jusqu'a Solaris 9.
    C pas le cas il me semble sous HP.
    
    C pas le cas sous Netbsd: Perl est un package qui ne fait pas partie du systeme de base.
- [^]Re: Sacré langage!
  
  Posté par Yves Agostini (page perso, ) le 12/04/2005 à 05:20. (lien). Évalué à 2.
  j'allai oublier :
  
  - mod_perl : le "méchanisme" le plus complet et le plus performant pour agir sur le cycle de vie d'une requête apache. Ce qui permet de développer ses propres redirection dynamiques, authentification, autorisations, ....
  
  http://perl.apache.org/docs/tutorials/index.html(...)
  - [^]Re: Sacré langage!
    
    Posté par Matthieu C () le 12/04/2005 à 06:19. (lien). Évalué à 2.
    d'ailleurs le systeme de cache de slashdot doit etre ecrit en perl si mes souvenird sont bon.

[^]Re: Sacré langage!

Posté par reno () le 11/04/2005 à 22:06. (lien). Évalué à 3.
Pour les "gros" scripts: rapidement les shell montrent leur limites et la Perl devient plus interressant (plus homogène, et plus performant).

Dans ce domaine, il rentre en concurrence avec Ruby et Python, mais étant plus ancien, plus de programmeurs connaissent Perl et la libraire CPAN est plus fournie.

Par contre, et la c'est mon avis personnel, Perl est tres "crade" comme language: les débutants font du code inmaintenable et les expérimentés se font plaisir en utilisant du code incompréhensible , une des conséquence de la philosophie TMWTDI..
(ma vie) appelé au secours pour la reprise d'un script (le repreneur ayant jeté l'éponge), il m'a fallu 1/2h de recherches pour remplacer *2 lignes* imbitables par 2 lignes qu'un débutant en Perl peut comprendre, 15min par ligne, ce n'est pas très rentable! (/ma vie), Ruby ou Python sont tous les deux bien plus propre..

Le seul problème avec Ruby et Python, c'est qu'ils sont tellement semblables l'un à l'autre, qu'il est très difficile de choisir entre les deux! Petite préférence personelle pour Ruby quand même..
- [^]Re: Sacré langage!
  
  Posté par Zakath (page perso, ) le 12/04/2005 à 05:11. (lien). Évalué à 4.
  Le peu de Perl que j'ai fait se résume justement à ça : se faire plaisir en faisant des choses très condensées et le moins compréhensibles...
  
  En ce qui me concerne, je considère Perl comme le langage qui laisse le plus de liberté au programmeur (juste devant Common Lisp et à mille lieux de Java). Corollaire 1 : c'est puissant et on peut se lâcher. Corollaire 2 : on peut faire des choses TRES crades et impossibles à maintenir.
  
  --
  Vous devriez vraiment visiter Aperture First !
- [^]Re: Sacré langage!
  
  Posté par pifou () le 12/04/2005 à 07:18. (lien). Évalué à 1.
  > Le seul problème avec Ruby et Python, c'est qu'ils sont tellement semblables l'un à l'autre, qu'il est très difficile de choisir entre les deux
  
  Si ces 2 langages étaient tellement semblables, l'un des deux n'existerait surement pas/plus. Ils jouent effectivement dans la même cours, ils ont les mêmes contraintes (langage de script orienté objet), le même type de licence libre mais la philosophie de chacun de ces langages est bien différente, ce qui fait qu'ils coexistent et qu'ils garderont leur communauté d'adeptes.
  
  Pour le choix, c'est avant tout une histoire de goût, de besoin et d'expériences passées des développeurs.
  
  Ma préférence va aussi vers Ruby qui correspond mieux à mes gouts et connaissances en développement informatique (càd. la programmation full-oo à la SmallTalk).
  - [^]Re: Sacré langage!
    
    Posté par reno () le 17/04/2005 à 21:02. (lien). Évalué à 2.
    > Si ces 2 langages étaient tellement semblables, l'un des deux n'existerait surement pas/plus.
    
    Ah? Alors pourquoi existe-t'il des dizaines de variantes de Lisp? de language fonctionnels? de language au-dessus de Java (je connais moins la: groovy, pyke, il me semble)?
    
    Python était légèrement moins OO que Ruby, mais il a rattrapé son "retard": c'est amusant c'est que les discussions entre Pythoniste et Rubyiste, ça ressemble à ça: "il est pas mal votre language, mais il n'a pas la feature XXX", les tenants de l'autre language répondant, "tu retardes, ça a été incorporté en version x.y"..
    
    Bref honnetement blanc bonnet et bonnet blanc, les deux seules grosses différences: le self très laid de python (mais qui permet de mapper élégamment une fonction sur une liste), et la gestion des espaces qui a ses farouches supporters/détracteurs, ça ne fait pas lourd..

[^]Re: Sacré langage!

Posté par Sylvain Lhullier (page perso, ) le 12/04/2005 à 10:13. (lien). Évalué à 3.
Perl : pour quoi faire ? Une bonne question !
Que peut-on faire avec Perl ? Exemples et promotion du langage.
Support de ma conférence sur le sujet :
http://sylvain.lhullier.org/confs/perl-pour-quoi-faire.html(...)
- [^]Re: Sacré langage!
  
  Posté par Stéphane TRAUMAT (page perso, ) le 12/04/2005 à 10:31. (lien). Évalué à 2.
  Merci pour tous à ces réponses qui n'ont en plus pas crées de troll :)
  J'en sais plus sur perl désormais !
  merci
- [^]Re: Sacré langage! ou langage sacré ? ;-)
  
  Posté par R4f (page perso, ) le 17/04/2005 à 17:16. (lien). Évalué à 2.
  Je profite de ce post pour remercier Sylvain qui a fait un cours sur Perl, disponible en ligne : http://sylvain.lhullier.org/publications/perl.html(...) (il doit être trop modeste pour se citer lui-même).
  
  J'ai déjà utilisé ce support pour donner un cours express sur 2 jours, à Canon (à Cesson Sévigné près de Rennes), et son support est très bien fait !
  
  Sinon, le grand avantage de Perl : plus qu'un langage, c'est une culture, notamment de la réutilisabilité. Le CPAN est une fonctionnalité non pas technique mais culturelle de Perl, que je regrette dans la plupart des autres langages (rien à voir avec le PEAR de PHP).
  
  <ma vie>Grâce au CPAN, j'ai pu faire ce que je n'aurais jamais osé espérer faire autement. Exemple : faire un script qui :
  - fait une requète dans une base de données SQL (PostgreSQL) --modules DBI et DBD::PostgreSQL--
  - et qui stocke le résultat dans un fichier au format Excel -- module Spreadsheet::WriteExcel.
  - Ensuite expédie le fichier Excel en fichier joint dans un e-mail --module MIME::Lite--
  - en ayant chiffré cet e-mail avec GnuPG --module Crypt::GPG.
  </ma vie>
  
  Merci Larry Wall, merci Sylain et merci aux mainteneurs de modules Perl (ainsi qu'aux CPAN-testers) !
  
  Un reproche souvent fait à Perl est que c'est un lange write-only, mais j'aurais envie de faire ce reproche à n'importe quel langage de programmation. Ce n'est justement pas le langage qui fait la propreté d'écriture, mais la culture.
  
  Pour Perl en particulier, la problème vient (à mon avis) du fait que les gens programment en PERL sans savoir en tirer parti. Ils font du Perl avec des constructions proches de celles du C. Résultat : ils écrivent des choses qui marchent par hasard, et ne savent pas pourquoi en changeant une ligne tout part en saucisse... Second effet : pour ajouter des fonctionnalités, ils font des verrues à leur code déjà pas clean, et là ça devient la cata !
  Résultat : lorsqu'il faut encore ajouter des trucs, ou intégrer à nouveau le code dans un projet plus vaste, on a mieux fait de tout récrire from scratch... Plus qu'un problème de langage, c'est un problème d'humains, et des ressources qu'ils ont pour réaliser leur travail.

[^]Re: Sacré langage!

Posté par Pascal (page perso, ) le 12/04/2005 à 16:23. (lien). Évalué à 2.
Perl sait quasiment tout faire et excelle dans beaucoup de domaines:
Pour le parsage de logs: il est fait pour ca.
Pour des CGI et sites Web dynamiques: il est excellent
Pour des applications en tout genre (notamment graphiques).
Pour des jeux, ca marche très bien: FrozenBubble est programmé en Perl et marche ma foi très bien.
- [+] [^]Re: Sacré langage!
  
  Posté par Stéphane TRAUMAT (page perso, ) le 12/04/2005 à 19:16. (lien). Évalué à -1.
  perl excele dans les sites web dynamiques... faut pas pousser quand même... j'ai déja vu du code de site réalisé en perl.. ca excelle pas :)
  - [^]Re: Sacré langage!
    
    Posté par totof2000 () le 13/04/2005 à 13:09. (lien). Évalué à 1.
    Il vaut mieux pour ca utiliser un langage fait pour ca a la base: le PHP. C'est moins lourd.
  - [^]Re: Sacré langage!
    Posté par lasher () le 14/04/2005 à 10:30. (lien). Évalué à 0.
    #include <stdio.h> #include <stdlib.h> #include <errno.h> int main(void) { FILE *f = NULL; char buffer[81]; f = fopen("fichier.txt","r"); while (fread(buffer, sizeof(buffer), f) != NULL) printf("%s\n", buffer); if (ferror(f)) { perror("fread"); exit(errno); } if (fclose(f) != 0) { perror("fclose"); exit(errno); } return EXIT_SUCCESS; } et #!/usr/bin/perl use strict; use warnings; open(FICHIER, "<fichier.txt") || die "Erreur à l'ouverture du fichier"; print while(<FICHIER>); # erreurs détectées automatiquement close(FICHIER) || die "Erreur à la fermeture du fichier";
```
print << EOHtml
<code HTML .../>
EOHtml
```
    - [^]Re: Sacré langage!
      
      Posté par Sytoka Modon (page perso, ) le 17/04/2005 à 11:07. (lien). Évalué à 2.
      Oui ! Axkit.
      
      http://www.axkit.org/
      
      C'est un environnement XML en Perl "à la cocoon" (Java). Tu peux mélanger le code Perl et le xhtml mais en général, il y a une complète séparation des deux. Même avec du code Perl embarqué, le xml reste valide !
      - [^]Re: Sacré langage!
        
        Posté par R4f (page perso, ) le 17/04/2005 à 17:28. (lien). Évalué à 2.
        AxKit, ça fait 3 ans que je rêve d'avoir assez de temps pour l'expérimenter.
        
        Sinon, pour ceux qui seraient désireux de faire du Perl comme on fait du PHP (ou, je crois, de l'ASP), c'est à dire en incluant les scripts à l'intérieur de pages web, il y a de quoi faire avec Apache::ASP :
        http://www.apache-asp.org/
        
        Ca donne des trucs comme :
        
        <html>
        <body>
        For loop incrementing font size: <p>
        <% for(1..5) { %>
        
        <font size="<%=$_%>" > Size = <%=$_%> </font> <br>
        <% } %>
        </body>
        </html>
        
        
        Pour être honnête, je trouve ça marrant, et sûrement rassurant pour le débutant qui retrouve sa page HTML d'origine avec des petits bouts dynamiques dedans, mais à terme, dès qu'on fait des trucs réutilisables, des tempplates réutilisables et de l'internationalisation (i18n), on sépare vite fait son code de son HTML... Donc l'effet rassurant-car-mon-code-est-dans-mon-HTML ne marche plus.
        
        [^]Re: Sacré langage!
        
        Posté par Sytoka Modon (page perso, ) le 17/04/2005 à 18:08. (lien). Évalué à 1.
        Ca fait trois ans que j'en fait ! Je regrette juste une chose, ca ne marche pas avec apache2 et ca n'a pas mal de bouger beaucoup ces derniers temps.
        
        Sinon, il faut un peu de temps pour rentrer dans AxKit mais après c'est formidable. Il est très facile de faire des formulaires. Je me suis fait par exemple ma propre extension qui charge le code perl d'une page html si un fichier du même nom existe (dans une arborescence parallèle (faut pas être fou)). Ca parait bête mais la complète dissociation code Perl / code HTML permet de ré-utiliser le code source bien plus facilement.
        
        Il y a un peu trop de variables globales à mon humble avis dans AxKit et c'est parfois pas assez objet. Par exemple, le coup des formulaires, l'idéal aurait été de définir une classe comme nom du formulaire et de simplement connecter les méthodes de la classe au champ du formulaire... Je vais peut être le faire, ca me simplifierai grandement mon code.

[^]Re: Sacré langage!

Posté par Alexandre Beraud () le 14/04/2005 à 14:11. (lien). Évalué à 1.
Parce-qu'une fois que tu l'auras utilise, tu ne pourras plus t'en defaire. Perl est a l'image de Linux: met le entre les mains de quelqu'un et laisse faire la seduction (les specialistes appellent ca les perlpheromones; non en fait je viens de l'inventer).

meuh

Posté par gc (page perso, ) le 13/04/2005 à 14:03. (lien). Évalué à 2.

Pourquoi pas le week-end ? Ce qui consomme moins de rares jours de congé...

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Journées Perl 2005

Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[+] [^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage! ou langage sacré ? ;-)

[^]Re: Sacré langage!

[+] [^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

[^]Re: Sacré langage!

meuh