[spip-dev] moteur de parsing des squelettes

Salut la liste,

  Il y a quelques temps, j'avais évoqué une refonte du système de
parsing des squelettes. Je suis loin d'avoir fini, mais voici un état
d'avancement du truc, histoire de voir si ça interesse quelqu'un, et
surtout, de voir s'il y a des volontaires pour tester le machin.

  Dans http://piif.free.fr/tmp/parser.tgz il y a l'état actuel des
choses (j'ai pas inclu la gpl, mais ça va de soi).

  L'idée est la suivante :
- j'ai écrit une grammaire des squelettes spip, dans un format
  assez spécifique, qui permet les analyses lexicales et syntaxique,
  un peu à la manière de lex et yacc. C'est le fichier grammaire.txt
  Dedans sont inclus les bouts de codes php à exécuter à chaque étape
  du parsing.
    J'expliquerai plus tard la syntaxe de ce fichier, car c'est un
  peu tordu.
- à partir de cette grammaire, on peut déduire un code php qui parse
  un fichier et exécute le code associé. Le fichier generateParser.php
  s'occupe de ça. C'est à dire que si on appelle
  generateParser.php?fichier=grammaire.txt, on obtient un fichier
  Squelette_parser.php
- le fichier abstractParser.php est inclu par ce code généré, et
  contient la partie de code indépendante de la grammaire.
- le fichier parser.template est utilisé par generateParser.php pour
  construire le code.
- le fichier tstParser.php constitue un exemple de test, utilisant
  Squelette_parser.php. Si on appelle
  tstParser.php?fichier=article-dist.html, on obtient l'affichage
  d'un "dump" de l'arbre de Champ/Boucle/Texte généré par l'analyse
  du squelette.

Ce qui reste à faire :
- vérifier que c'est bien "php3 compliant"
- inclure dans le code à générer le "vrai" code permettant de créer
  l'arbre représentant un squelette.
- ajouter la gestion des includes
- bencher, tester, debugger, tester, debugger, tester, debugger,
  tester ...
- descendre d'un cran, c'est à dire reconnaitre de cette façon les
  arguments de boucle, les filtres ...

  Pour l'instant, je n'ai fait que le parsing d'un seul squelette
jusqu'à arriver à une version "qui marche".

  Il est déjà presque possible de voir si un squelette donné se
retrouve bien parsé de la même façon qu'avec le parseur original.
  Je vais modifier un peu le code de tout ça pour avoir un
"valideur" c'est à dire un truc qui prend un squelette en paramètre
le parse en version originale et en version "pif" et compare les deux.
  Y a-t'il des volontaires pour essayer ce futur valideur sur un tas
de squelettes bien sauvages de préférence :wink: (j'espère qu'il sera
dispo à la fin de la semaine prochaine).
  Ça permettra également de voir si cette version est plus
performante.

  À partir de là, on saura si ça vaut le coup de continuer dans cette
route, et d'inclure cette version dans le code "officiel".

  Une remarque en passant : la version actuelle permet à priori
d'imbriquer les champs étendus et même d'y mettre des boucles (bien
que ça soit peut être pas conseillé d'utiliser ça intensivement,
bonjour la lisibilité :wink:

À+, Pif.

y'en a qui se sont éclaté :wink:
j'en suis baba ; pour l'instant j'avoue etre encore un peu depassé, mais c'est tres intéressant ce que tu nous
a produit.

Christian Lefebvre wrote:

Salut la liste,

Il y a quelques temps, j'avais évoqué une refonte du système de
parsing des squelettes. Je suis loin d'avoir fini, mais voici un état
d'avancement du truc, histoire de voir si ça interesse quelqu'un, et
surtout, de voir s'il y a des volontaires pour tester le machin.

Dans http://piif.free.fr/tmp/parser.tgz il y a l'état actuel des
choses (j'ai pas inclu la gpl, mais ça va de soi).

L'idée est la suivante :
- j'ai écrit une grammaire des squelettes spip, dans un format
assez spécifique, qui permet les analyses lexicales et syntaxique,
un peu à la manière de lex et yacc. C'est le fichier grammaire.txt
Dedans sont inclus les bouts de codes php à exécuter à chaque étape
du parsing.
   J'expliquerai plus tard la syntaxe de ce fichier, car c'est un
peu tordu.
- à partir de cette grammaire, on peut déduire un code php qui parse
un fichier et exécute le code associé. Le fichier generateParser.php
s'occupe de ça. C'est à dire que si on appelle
generateParser.php?fichier=grammaire.txt, on obtient un fichier
Squelette_parser.php
- le fichier abstractParser.php est inclu par ce code généré, et
contient la partie de code indépendante de la grammaire.
- le fichier parser.template est utilisé par generateParser.php pour
construire le code.
- le fichier tstParser.php constitue un exemple de test, utilisant
Squelette_parser.php. Si on appelle
tstParser.php?fichier=article-dist.html, on obtient l'affichage
d'un "dump" de l'arbre de Champ/Boucle/Texte généré par l'analyse
du squelette.

Ce qui reste à faire :
- vérifier que c'est bien "php3 compliant"
- inclure dans le code à générer le "vrai" code permettant de créer
l'arbre représentant un squelette.
- ajouter la gestion des includes
- bencher, tester, debugger, tester, debugger, tester, debugger,
tester ...
- descendre d'un cran, c'est à dire reconnaitre de cette façon les
arguments de boucle, les filtres ...

ca aussi ca demande pas mal de travail.

Pour l'instant, je n'ai fait que le parsing d'un seul squelette
jusqu'à arriver à une version "qui marche".

Il est déjà presque possible de voir si un squelette donné se
retrouve bien parsé de la même façon qu'avec le parseur original.
Je vais modifier un peu le code de tout ça pour avoir un
"valideur" c'est à dire un truc qui prend un squelette en paramètre
le parse en version originale et en version "pif" et compare les deux.
Y a-t'il des volontaires pour essayer ce futur valideur sur un tas
de squelettes bien sauvages de préférence :wink: (j'espère qu'il sera
dispo à la fin de la semaine prochaine).

oui, moi !
j'ai plein d'includes dans tous les sens, et peu de boucles imbriqués, mais quelque-unes tout de meme
je peux assez facilement mettre en paralèlles les 2 parseurs.

Ça permettra également de voir si cette version est plus
performante.

À partir de là, on saura si ça vaut le coup de continuer dans cette
route, et d'inclure cette version dans le code "officiel".

Une remarque en passant : la version actuelle permet à priori
d'imbriquer les champs étendus et même d'y mettre des boucles (bien
que ça soit peut être pas conseillé d'utiliser ça intensivement,
bonjour la lisibilité :wink:

heuu, c'est quoi les champs étendus imbriqués ?

À+, Pif.

encore une fois, B.R.A.V.O !

y'en a qui se sont éclaté :wink:

  Ça m'a rappelé le bon vieux temps où je faisais du cocktail :wink:
(http://www.cocolab.de/html/cocktail.html pour les curieux)

>- descendre d'un cran, c'est à dire reconnaitre de cette façon les
> arguments de boucle, les filtres ...
ca aussi ca demande pas mal de travail.

  Ouaip. C'est même pas sur que ça soit faisable avec ce que j'ai codé.
  On risque de tomber dans des histoires de "lookahead" que je
maitrise pas trop.
  Mais t'façon, c'est pour beaucoup plus tard ça :wink:

> Y a-t'il des volontaires pour essayer
oui, moi !

Bon, faut qu'j'm'y remette alors ...

heuu, c'est quoi les champs étendus imbriqués ?

[ avant (#champ) apres [ re avant (#autrechamp) re apres] apresapres ]

En fait, tout est parti de là. J'avais envie de pouvoir faire ça :slight_smile:
À+, Pif.

Christian Lefebvre wrote:

:

  Il y a quelques temps, j'avais évoqué une refonte du système de
parsing des squelettes. Je suis loin d'avoir fini, mais voici un état
d'avancement du truc, histoire de voir si ça interesse quelqu'un, et
surtout, de voir s'il y a des volontaires pour tester le machin.

Oui, ça m'intéresse justement parce que moi je m'intéresse à la suite:
la production de code, comme Antoine l'a signalé récemment.
Je compte justement poursuivre là-dessus car il y a des choses
que j'avais faites et qu'Antoine n'a pas eu le temps d'adapter
à la version multi-lingue que je n'avais pu prendre.

Je suggère que le gros fichier inc-calcul-squel.php3 soit éclaté en 2
(l'analyse syntaxique dans l'un, la production de code dans l'autre)
afin que tous ces travaux puissent se dérouler sans conflits.

Si tu es intéressé par l'aspect langage de programmation de Spip,
tu seras peut-etre intéressé par les références ci-dessous.
Je les ai postés dans une brève de Spip-contrib, mais elle tarde
à etre validée.

Emmanuel

Je suggère que le gros fichier inc-calcul-squel.php3 soit éclaté en 2
(l'analyse syntaxique dans l'un, la production de code dans l'autre)
afin que tous ces travaux puissent se dérouler sans conflits.

  C'est effectivement une façon de faire qui serait de toutes façons
plus élégante, mais ça n'est pas si immédiat. Il faut alors se mettre
d'accord sur le format de la structure intermédiaire. La variable
$racine créée par la fonction parser a surement quelques modifs à
subir.
  Notamment, il serait nécessaire de changer les <:..:> et les
<inclure> en objet Traduction et Inclusion pour généré le code à part,
alors qu'actuellement, c'est mélangé dans le traitement des Texte.

Si tu es intéressé par l'aspect langage de programmation de Spip,
tu seras peut-etre intéressé par les références ci-dessous.

  Wah .. licence d'info ! c'est vrai que j'ai fait ça dans le temps,
mais on n'y faisait pas de php :slight_smile:

À+, Pif.

Ça me parait délicat pour 3 raisons :
- le moteur n'est pas en php => il faut utiliser un code extérieur
  pour générer le php. Ça n'est pas bloquant, mais ça oblige à utiliser
  des outils complètement extérieurs à "l'univers spip".
- je suppose que ça génère un parseur caractère par caractère. En php,
  ça risque d'être très très lent
- avec une vrai grammaire de type lalr, il va falloir reconnaitres
  les balises comme étant un truc du genre < puis BOUCLE, puis ...
  L'automate va donc passer un temps fou à dépioter les balises html
  pour rien. En plus, du coup, la grammaire sera vachement compliquée.

  C'est pour ça que je n'ai même pas cherché à utiliser un outil de ce
type. Ma version par du principe suivant pour découper les tokens :
- on cherche les caractères "interessants" : [, ], < et #
- pour les <, on fait matcher sur une série de regex pour
  matcher <BOUCLE, <B ...
- si quelque chose matche, ça devient un token
- tout ce qu'on a passé avant devient un pseudo token "texte en vrac"

  Du coup, au niveau analysi syntaxique, il n'y a pas de token <, mais
un token <BOUCLE avec un argument "suite de la balise".

  C'est un peu bricolo, mais ça permet d'éviter de parser les <HTML>
et autres et d'éviter les lookahead (sauf pour les [ qui trainent en
dehors des champs => bidouille affreuse dont j'suis pas fier :wink:

À+, Pif.

Re salut ..
  J'ai mis le tgz à jour.
  À la place du tstParser.php il y a maintenant un benchParser.php
qui prend un argument fichier=toto parse toto avec le moteur spip puis
avec le mien, puis compare ce qu'il peut sur les tableaux obtenus.

  Les squelettes 1.6 font 0 faute mais je n'ai pas encore inclu
le support de <INCLURE> et <:...:> (parsé mais pas généré)

  Pour ceux qui ont des squelettes bien violents et un peu de temps,
merci de me dire ce que ça donne.
  Si quelqu'un a un php3 aussi, j'aimerais savoir si c'est bien
compatible.

  Dernier détail : si les gardiens de la flamme peuvent donner leur
avis sur la question à l'occas ...

À+, Pif.