Reprise du message précédent :

 
Les regexp du PERL sont bien plus puissantes, et puis on peut facilement les mettre en forme pour aérer un bazar autrement imbitable.
 
Pour traiter des chaînes de caractères en masse, je connais pas grand chose de mieux que le PERL. C'est un peu prévu pour ça, à la base.

C'est vrai que c'est adapté pour ça

perl = gros caca imbitable.
 

test
 
gros boulet de freewind
 
/test

 
pas encore fini cette histoire?

 
Les concours d'obfuscation ne comptent pas.

 
ben non, jvérifiais  

Ben les regex sont intégrées directement au langage, ce qui aide, mais même en dehors de ça Perl est quand même un langage vachement orienté manipulation de chaînes

Ouais enfin la pluspart des langages possèdent des implémentations des PCRE (Perl Compatible Regular Expressions, par opposition aux regex Posix). PHP a des fonctions utilisant la syntaxe PCRE, et en Python seul les PCRE sont disponibles (via le module "re" ), pas de regex Posix

 
Ben c'est bien ce que je dis.
L'était temps que quelqu'un fasse quelque chose, parce que les regexp POSIX sont quand même à chier.
On peut rien faire avec, et en plus c'est compliqué.  

Faut dire, avec la mise en page que t'as réussi à pondre, même en tableaux c'est relou

non, tu dis que les regex perl sont plus puissante en impliquant que ce sont des regex qu'on ne peut utiliser que sous Perl

Ca, c'est flagrant

 
Du temps ancien de eregi_replace je veux bien mais depuis que preg_replace existe ...

D'ailleurs, si je ne m'abuse, le preg_replace du PHP est fortement inspiré du PERL.

 
Ah la la.
Je répondais à ceci :
 

 
Sur ce skeye a dit "ça revient à faire des regexp", et j'ai répondu : "mais les regexp PERL sont bien plus puissantes".
Puisque j'y répondais, il est évident que c'était "bien plus puissantes que celles du C", qui sont POSIX.
 
'spèce d'expert.

Alors si c'est si facile efficace et puissant, pourquoi les smiley continuent à être interpretés dans les balises url ?

Parce que ces forums sont codés par une bande de branques

parce-que la regexp qui transforme les codes en smileys est passée avant celle qui rend cliquables les urls?

Me pose la question aussi Mais me semble que c'est rétroactif les regexp

Pas inspiré, repompé, les fonctions preg* implémentent les regex PCRE, les fonctions ereg* implémentent POSIX

Parce que les regexps c'est extrèmement difficile à construire, encore plus difficile à bien construire et encore un niveau au dessus à maintenir
 
Et c'est pas le passage au C qui faciliterait quoi que ce soit, encore moins pour la gestion de ce genre de trucs, tout ce que ça pourrait faire c'est mener Niluje à se pendre

Bravo, ta phrase ne veut rien dire (regexp rétroactif? wtf, genre ça commence à agir avant même que tu les ais écrites? mieux que Le Chat Machine )

Même dans un autre ordre ca ferait la même chose

 
pas tout à fait...on aurait le smiley au milieu du lien, mais le tout serait cliquable...

 

Bravo, tu fais ton neneu là ... Même si c'est pas très bien dis, suffisait de lire le message de Skeye.
 
Regexp 1 : On parse les smilies
Regexp 2 : On parles les URL
 
Si le traitement se fait de façon linéaire, on aura un smiley merdeuh dans l'URL de Google
Et là, quand je parlais de rétroactif, c'était un traitement qui se fout totalement de l'ordre des regexp ... Dans le sens où la regexp1 est mise en mémoire mais pas traitée, la regexp2 traitée en prenant en compte le résultat de la regexp1 et pas en parsant directos l'URL.

Pour être précis, on aurait sans doute de l'HTML invalide avec la regexp de smiley qui s'ammuse à change le code entre balises.

 

J'ai rien compris.

 
Non, parce que si on teste les smilies après, on peut vérifier qu'ils ne sont pas au milieu d'une balise .

 
du html invalide oui, mais il me semble qu'aucun navigateur ne bronche là-dessus...

Il faudrait détecter l'url puis dedans détecter les smileys puis les neutraliser en empechant le deuxieme regexp de les remplacer.

Z'êTES TOUS DES NEUNEUS ! JE SUIS UN INCOMPRIS, ADIEU !

En pratique, suffit de lui dire de pas transforer le code smiley en smiley lorsqu'il est accollé à une autre lettre non ?

STFU n00b tu racontes n'importe-quoi.

on peut cherche le code de smiley entouré d'un espace aussi du coup quand c'est dans une url ca transforme pas vu qu'il n'y a pas d'espace
 

Mais fcuk, elles sont bien rétroactives dans le sens où chacune des regexp prend en compte le résultat des autres

ben non, justement, elles reviennent pas en arrière, c'est un traitement linéaire...

Bah on vient pas de démontrer le contraire ?
 
Quoi que nan, on a rien démontré Faudrait qu'on sache si le parsing des URL est fait avant celui de smilies, et on pourra dire
Je mets 10€ sur la table pour la rétroactivité des regexp

Ca résoudrait probablement pas mal de bugs fitioures
 
Surtout qu'avec les lookahead/lookbehind assertions c'est tout con à faire

Impossible, les regex sont appliquées en linéaire séquentiel, ya pas de rétroactivité là dedans, une regex est appliquée sur la sortie du traitement (regex ou pas) la précédent, point barre

Ca pourrait poser problème avec les parenthèses non ?
 
() ne marcherait pas

 
Si, en PERL regexp machin, tu peux.
 
Par exemple avec les assertions, les patterns type (?<=PATTERN) (positive de rétrovision => ça va chercher en arrière un pattern), etc.

Il parle pas du tout de ça, ça c'est lookbehind et lookahead assertion: tester l'état d'une partie de la chaîne sans intégrer cette partie dans la zone matchée

1- RAF
2- rien n'empêche d'intégrer les parenthèse et un set précis de signes dans les look(ahead|behind) assertions

 
On en refuse régulièrement sur la page de validation des avatars. Et c'est 10 Ko, pas 20.

(Ca a un peu changé, mais c'est pas encore en ligne, j'ai encore deux textes à écrire, je mettrai en ligne le produit fini )
Quelle idée en effet de vouloir faire le nombre d'or du design web, les 3 colonnes, en effet?