soit la ligne de donnees :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>
la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements".
la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements".
donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.
à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/
et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y
a *aucune* capture.
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y a *aucune* capture.
crame !
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable" de motifs ?
la botte supreme de la grande ourse :
my @captures = $la_chaine =~ /<([^>]*)>/g;
espie
In article <4c2d947f$0$28614$, luc2 wrote:
Le 02-07-2010, kurtz_le_pirate a écrit :
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y a *aucune* capture.
crame !
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable" de motifs ?
la botte supreme de la grande ourse :
my @captures = $la_chaine =~ /<([^>]*)>/g;
Visiblement, tu ne connais pas *? De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, qui pourtant explique bien que n'importe quel caractere bizarre peut (aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il *faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la regexp...
On peut facilement couper avec split: my @captures = split /(?<=>)(?=<)/, $chaine; et ensuite verifier que chaque capture marche. @captures = map {/^<([^>]*)>$/ or die "Badly formed string: $chaine ($_)"; $1; } @captures;
In article <4c2d947f$0$28614$426a34cc@news.free.fr>,
luc2 <luc2@nospam.invalid> wrote:
Le 02-07-2010, kurtz_le_pirate <kurtzlepirate@yahoo.fr> a écrit :
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide,
ou undef, ou ... mais non, il n'y a *aucune* capture.
crame !
je rève peut être, mais existe-t-il un moyen pour avoir un nombre
"variable" de motifs ?
la botte supreme de la grande ourse :
my @captures = $la_chaine =~ /<([^>]*)>/g;
Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...
On peut facilement couper avec split:
my @captures = split /(?<=>)(?=<)/, $chaine;
et ensuite verifier que chaque capture marche.
@captures = map {/^<([^>]*)>$/ or die "Badly formed string: $chaine ($_)"; $1; } @captures;
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y a *aucune* capture.
crame !
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable" de motifs ?
la botte supreme de la grande ourse :
my @captures = $la_chaine =~ /<([^>]*)>/g;
Visiblement, tu ne connais pas *? De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, qui pourtant explique bien que n'importe quel caractere bizarre peut (aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il *faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la regexp...
On peut facilement couper avec split: my @captures = split /(?<=>)(?=<)/, $chaine; et ensuite verifier que chaque capture marche. @captures = map {/^<([^>]*)>$/ or die "Badly formed string: $chaine ($_)"; $1; } @captures;
luc2
Le 02-07-2010, Marc Espie a écrit :
Visiblement, tu ne connais pas *? ...
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, ...
visiblement, tu t'prends pas pour la moitie d'un naze toi :)
Le 02-07-2010, Marc Espie <espie@lain.home> a écrit :
Visiblement, tu ne connais pas *?
...
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
...
visiblement, tu t'prends pas pour la moitie d'un naze toi :)
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, ...
visiblement, tu t'prends pas pour la moitie d'un naze toi :)
Olivier Miakinen
Bonjour,
Je fais suivre ta question et ma réponse vers fr.comp.lang.regexp car elles devraient intéresser tous les utilisateurs des regexp et pas seulement ceux de Perl.
Le 02/07/2010 09:07, kurtz_le_pirate a écrit :
soit la ligne de donnees : <Auteur><Larry Wall><Developpeurs><The Perl Foundation>
la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements". la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements". donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.
à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/ et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4 seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y a *aucune* capture.
Dans PCRE il existe une option PCRE_PARTIAL permettant de vérifier une regexp sur une chaîne incomplète, mais celle-ci n'existe pas dans Perl.
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable" de motifs ?
Oui : /<(.*?)><(.*?)><(.*?)><(.*?)>(?:<(.*?)>)?/
Maintenant, si tu veux que ça soit variable à l'infini (un truc qui créerait autant de $n que nécessaire), je ne crois pas que ça soit possible.
Cordialement, -- Olivier Miakinen
Bonjour,
Je fais suivre ta question et ma réponse vers fr.comp.lang.regexp car
elles devraient intéresser tous les utilisateurs des regexp et pas
seulement ceux de Perl.
Le 02/07/2010 09:07, kurtz_le_pirate a écrit :
soit la ligne de donnees :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>
la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements".
la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements".
donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.
à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/
et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y
a *aucune* capture.
Dans PCRE il existe une option PCRE_PARTIAL permettant de vérifier une
regexp sur une chaîne incomplète, mais celle-ci n'existe pas dans Perl.
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?
Oui : /<(.*?)><(.*?)><(.*?)><(.*?)>(?:<(.*?)>)?/
Maintenant, si tu veux que ça soit variable à l'infini (un truc qui
créerait autant de $n que nécessaire), je ne crois pas que ça soit
possible.
Je fais suivre ta question et ma réponse vers fr.comp.lang.regexp car elles devraient intéresser tous les utilisateurs des regexp et pas seulement ceux de Perl.
Le 02/07/2010 09:07, kurtz_le_pirate a écrit :
soit la ligne de donnees : <Auteur><Larry Wall><Developpeurs><The Perl Foundation>
la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements". la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements". donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.
à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/ et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4 seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y a *aucune* capture.
Dans PCRE il existe une option PCRE_PARTIAL permettant de vérifier une regexp sur une chaîne incomplète, mais celle-ci n'existe pas dans Perl.
je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable" de motifs ?
Oui : /<(.*?)><(.*?)><(.*?)><(.*?)>(?:<(.*?)>)?/
Maintenant, si tu veux que ça soit variable à l'infini (un truc qui créerait autant de $n que nécessaire), je ne crois pas que ça soit possible.
Cordialement, -- Olivier Miakinen
Olivier Miakinen
Le 02/07/2010 12:11, Marc Espie a écrit :
my @captures = $la_chaine =~ /<([^>]*)>/g;
Visiblement, tu ne connais pas *? De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, qui pourtant explique bien que n'importe quel caractere bizarre peut (aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il *faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Ça aussi ça me semble être une régression : j'aurais préféré que les options à venir se contentent de constructions du style (?#...) (où « # » représente un caractère non encore utilisé), ou bien justement utilisent le pour les nouvelles constructions.
Mébon, c'est comme ça, il faut faire avec.
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la regexp...
Peut-être en deux étapes.
Commencer par récupérer la plus longue chaîne possible sans bruit : /< ( [^<>] | >< )* >/x
Puis appliquer la regexp simple sur le résultat : /<(.*?)>/g
Le 02/07/2010 12:11, Marc Espie a écrit :
my @captures = $la_chaine =~ /<([^>]*)>/g;
Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Ça aussi ça me semble être une régression : j'aurais préféré que les
options à venir se contentent de constructions du style (?#...) (où
« # » représente un caractère non encore utilisé), ou bien justement
utilisent le pour les nouvelles constructions.
Mébon, c'est comme ça, il faut faire avec.
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...
Peut-être en deux étapes.
Commencer par récupérer la plus longue chaîne possible sans bruit :
/< ( [^<>] | >< )* >/x
Puis appliquer la regexp simple sur le résultat :
/<(.*?)>/g
Visiblement, tu ne connais pas *? De ce point de vue, c'est une regression par rapport au post initial.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp, qui pourtant explique bien que n'importe quel caractere bizarre peut (aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il *faut* user abondamment de ...
my @captures = $la_chaine =~ /<(.*?)>/g;
Ça aussi ça me semble être une régression : j'aurais préféré que les options à venir se contentent de constructions du style (?#...) (où « # » représente un caractère non encore utilisé), ou bien justement utilisent le pour les nouvelles constructions.
Mébon, c'est comme ça, il faut faire avec.
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit
Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la regexp...
Peut-être en deux étapes.
Commencer par récupérer la plus longue chaîne possible sans bruit : /< ( [^<>] | >< )* >/x
Puis appliquer la regexp simple sur le résultat : /<(.*?)>/g
Jerome Quelin
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
perldoc -q xml
jérôme --
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
perldoc -q xml
jérôme --
espie
In article <4c2f55e4$0$21503$, Jerome Quelin wrote:
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
perldoc -q xml
L'exemple donné n'est pas techniquement du xml... aucun tag de fin, par exemple.
L'air de rien, c'est une des debilites de la tendance "tout xml" des neuneus bouffeurs de java: faut des outils specifiques, ca se parse pas a coups de regexps... et toutes les bibliotheques existantes sont trouees, de facon plus ou moins subtiles (la plupart supposent que les fichiers consideres sont "gentils", et donc ne prennent pas de precaution particuliere pour limiter les niveaux de recursion, quand c'est pas carrement la partie utf8 qui cree des buffer overflows...)
In article <4c2f55e4$0$21503$426a74cc@news.free.fr>,
Jerome Quelin <jquelin@gmail.com> wrote:
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.
perldoc -q xml
L'exemple donné n'est pas techniquement du xml... aucun tag de fin, par
exemple.
L'air de rien, c'est une des debilites de la tendance "tout xml" des neuneus
bouffeurs de java: faut des outils specifiques, ca se parse pas a coups de
regexps... et toutes les bibliotheques existantes sont trouees, de facon
plus ou moins subtiles (la plupart supposent que les fichiers consideres
sont "gentils", et donc ne prennent pas de precaution particuliere pour
limiter les niveaux de recursion, quand c'est pas carrement la partie utf8
qui cree des buffer overflows...)
In article <4c2f55e4$0$21503$, Jerome Quelin wrote:
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
perldoc -q xml
L'exemple donné n'est pas techniquement du xml... aucun tag de fin, par exemple.
L'air de rien, c'est une des debilites de la tendance "tout xml" des neuneus bouffeurs de java: faut des outils specifiques, ca se parse pas a coups de regexps... et toutes les bibliotheques existantes sont trouees, de facon plus ou moins subtiles (la plupart supposent que les fichiers consideres sont "gentils", et donc ne prennent pas de precaution particuliere pour limiter les niveaux de recursion, quand c'est pas carrement la partie utf8 qui cree des buffer overflows...)
Olivier Miakinen
Bonjour,
Le 03/07/2010 17:23, Jerome Quelin a écrit :
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> », qu'il s'agirait d'un document XML -- sans même parler de complexité.
Cordialement, -- Olivier Miakinen
Bonjour,
Le 03/07/2010 17:23, Jerome Quelin a écrit :
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> », qu'il s'agirait d'un document XML -- sans même parler de complexité.
Cordialement, -- Olivier Miakinen
Jerome Quelin
Olivier Miakinen wrote:
Le 03/07/2010 17:23, Jerome Quelin a écrit :
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> », qu'il s'agirait d'un document XML -- sans même parler de complexité.
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin- d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis- ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard pour le reprendre sainement, car on aura peur de tout casser et qu'après tout, ça marche comme ça.
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml. si c'est juste des valeurs comme ça sur une seule ligne, le standard c'est csv. donc je ne pense pas trop m'avancer en disant que l'exemple original est tiré d'un document xml.
jérôme --
Olivier Miakinen wrote:
Le 03/07/2010 17:23, Jerome Quelin a écrit :
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
si c'est juste des valeurs comme ça sur une seule ligne, le standard c'est
csv. donc je ne pense pas trop m'avancer en disant que l'exemple original
est tiré d'un document xml.
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les regexp pour parser du xml.
Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu complexe.
Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> », qu'il s'agirait d'un document XML -- sans même parler de complexité.
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin- d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis- ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard pour le reprendre sainement, car on aura peur de tout casser et qu'après tout, ça marche comme ça.
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml. si c'est juste des valeurs comme ça sur une seule ligne, le standard c'est csv. donc je ne pense pas trop m'avancer en disant que l'exemple original est tiré d'un document xml.
jérôme --
xavier
Jerome Quelin wrote:
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin- d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis- ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard pour le reprendre sainement, car on aura peur de tout casser et qu'après tout, ça marche comme ça.
Ca sent le vécu :-) Mais je crois qu'on a tous vécu ça à un moment où à un autre...
-- XAv - recasé
Jerome Quelin <jquelin@gmail.com> wrote:
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.
Ca sent le vécu :-) Mais je crois qu'on a tous vécu ça à un moment où à
un autre...
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin- d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis- ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas de modifs pour prendre en compte de nouveaux cas dans les données en entrée.
et quand on se rend compte que le script est monstrueux, il est trop tard pour le reprendre sainement, car on aura peur de tout casser et qu'après tout, ça marche comme ça.
Ca sent le vécu :-) Mais je crois qu'on a tous vécu ça à un moment où à un autre...
