Parse que je le vaux bien.

Parse que je le vaux bien.
Laurent	15-May-2011/19:51:21+2:00
Au secours les reboleurs. Je m'énerve à essayer de parser un texte avec des règles de grammaires simples. Par exemple dans la chaine ci-dessous je voudrais mettre dans une série les lignes qui commencent par "toto" ou "titi": str: { bla bla toto est un chien blah blah blah titi est un canari la lala lala } J'ai essayé le code suivant, avec la règle nom: nom: ["titi" \| "toto"] roles: copy [] parse str [ some[ to nom copy result to newline (append roles result) ] ] probe roles Qui me donne l'erreur : Script Error: Invalid argument: titi \| toto Dans le parse en remplaçant la regle nom par la chaine "t"** par exemple tout se passe bien to "t" copy result to newline et j'obtiens bien ["toto est un chien" "titi est un canari"]. Est-il impossible d'utiliser un règle après un "to" dans un parse?? Faut il obligatoirement un élément terminal comme une chaine??? Avez vous une idée de comment faire si j'ai plusieurs dizaines de mot-clés déclenchant l'extraction de ligne?? C'est hyper bloquant pour moi, merci de votre aide.
DocKimbel	15-May-2011/21:09:41+2:00
TO doit être suivi d'un élément terminal en REBOL2 (mais il accepte une règle en REBOL3). Voici une solution possible pour ton code: nom: ["titi" \| "toto"] roles: copy [] parse str [ some [ copy result [nom to newline] (append roles result) \| thru newline ] ] probe roles
Laurent	16-May-2011/21:56:38+2:00
Merci Doc! Grace à ton post je commence a comprendre un peu les subtilités du parsing. C'est quand même un monde que cet histoire d'élément terminal ne soit pas documenté dans le tutoriel du parsing Rebol. Rebol3 m'a parut assez instable, alors en attendant la sortie d'une version finale en 2019 je vais continuer à parser en Rebol2. Au fait, existe-t-il des librairies pour utiliser les expressions régulières en Rebol? Red va t'il également utiliser le dialecte du parsing Rebol ou bien pourra-t-on utiliser des expressions régulières?
DocKimbel	16-May-2011/22:45:40+2:00
Je crois qu'il y a eu une ou plusieurs tentatives pour supporter les expressions régulières en REBOL, mais ça n'a pas eu beaucoup de succès. La doc de PARSE dit pour TO: "advance input to a value or datatype", mais je suis d'accord que ce n'est pas clairement expliqué, du coup, on a tous tenté au moins une fois de passer une règle à TO/THRU. Red: oui, je compte bien inclure PARSE, plutôt dans sa version R3 (je ne suis pas sûr de supporter tous les nouveaux mot-clés dès le début).
shadwolf	17-May-2011/4:47:25+2:00
@dockimbel ce sera déjà un bel effort puis tout n'est pas fait pour être fait en un jour. Ceci dit je me pause une question. Parse est la technologie au coeur de rebol, c'est une technologie très mal appréhendée par la majorité des programmeurs rebol. aucune doc exhaustive n'a été faite sur le sujet. Très peu de monde serrait par example capable de faire un moteur de rendu HTML basique (texte + images)en draw/AGG en se basant sur area-tc par exemple. Je me demande si bien que puissant et vitale dans les technologies rebol il n'est pas ultra important que parse et toutes ses degrés de subtilité soient compris par les programmeurs. Je me rappel qu'au debut quand j'ai commencé rebol parse était vu comme LA solution a tout les mots de l'informatique moderne puisque permettant au commun des mortels de faire des dialectes et de donc représenter leur conceptes métier dans leur programmation avec des dialectes taillés sur mesure et adaptés à leurs besoin. On a jamais atteind ce but...
shadwolf	17-May-2011/4:52:39+2:00
ce qui me gêne en fait avec parse c'est son mode de focntionnement non lineaire puis lineariste si l'on specifie to newline par example. En gros c'est recherche un mot clef dans le texte sans ordre précis a partir du moment ou tu as chopé le mot clef alors là on peut commencer a spécifier un ordre plausible pour ce qui suit (mot clef etant le tag ce qui suist etant les arguments du tag) Ca me semble adapté a HTML mais par moi par exemple j'ai jamais été capable d'exploiter des regles de parsing de mon cru basé pour extraire des données d'un fichier XML (cf: SVG-renderer.r) Pourtant c'est exactement le genre de chose ou parse excèlerai et ce qui en fait tout l'interret. Et ce qui fait par qu'une widget comme area-tc soit relativement compacte la partie moteur de rendu basée sur parse c'est moins de 400 lignes de code je ne connais pas d'autre langages permettant ca.
shadwolf	17-May-2011/5:19:28+2:00
Parse c'est aussi la technologie qui permet de faire en sorte que vue du point de vue du code rebol VID et Draw soient aussi légés et compacts. Parse mais surtout la compréhension de parse me semble vrai un des chantier fondamentaux pour faire de rebol ou d'un clone de rebol un succès. En suite on peut essayer de réfléchir un peu sur comment on fait pour avoir un parse qui est appréhensible par la majorité. Pour ma part, je pense que la documentation idéale de parse se serait une doc qui explique parce en présente son propre dialecte interne puis montre et explique des examples allant d'example simplissime a des exemples de hauts niveau comme area-tc ou Make-Doc. Je pense que dans Area-tc Steeve a mis en forme d'optimisation un très grand nombre des techniques qui sont typiques et unique à parse et qu'on ne retrouve dans aucun autre langage. Il est facil aussi d'oublier parse... Parse n'est pas quelque chose qu'il est facil d'apprendre et n'est pas un savoir facil a conservé. Je sais que personnellement les moments ou j'ai été le mieux en phase avec parse c'est au moment ou j'écrivait MDP-GUI, par la suite j'ai écrit SVG-renderer en me disant qu'il fallait que je passe par parse mais par manque de temps je suis passé par une solution qui était plus confortable (transformer le code SVG en objet! rebol). Par la suite ne maintenant pas mon savoir et n'ayant pas de document de référence sur le sujet pour maintenir actif mon savoir acquis lors de mdp-gui j'ai oublier tout... J'ai passé 2 ans a me demander comment faire area-tc. On en a d'ailleurs l'argement débatu sur ce forum. Avant de par hazard tombé sur un code de Carl Sassenrath nomé colorize.r dont le but etait de faire un rendu de syntaxe colorier pour du code rebol dans un fichier html. J'ai remplace la génération du HTML par la génération de code Draw/AGG et voila en 2 heures les bases d'area-tc étaient jetée. Je pense qu'a l'epoque ou Carl a sortie MakeDoc il y a eu un véritable engouement pour parse que tout le monde a vraiment découvert et commencer a utiliser parse a ce moment la puis comme Carl est passé a autre chose ben tout le monde a suivi et a delaissé parse. Notre tord a été de ne pas figer dans le marbre d'une documentation ce qu'on avait appris de parse à l'epoque. Evidement je pense que parse est aussi la pierre angulaire de tout ce qui se veut un clone de rebol digne de ce nom et c'est aussi la pièrre angulaire de cheyenne! Après il convient de présenté aussi concrètement que possible tout ce qui a été fait avec parse pour bien montrer le role essentiel de cette technologie dans rebol et les rebol-like. de mémoire il y a eu des moteurs de rendu SVG (celui de steeve sur R3), il y a eu une librairie qui transforme les document XML en objet! rebol (ce qui est génialicime vraiement ...et qui a été la base de mon SVG-renderer.r), il y a eu 5 ou 6 dialectes de mise en forme s'implifier de documentation (j'ai fait un article sur le sujet sur le wiki rebol france) il y a eu au moins 3 moteurs de rendu MakeDoc / makedocPro > VID, il y a eu une face de colorisation syntaxique de code rebol utilisant draw/AGG, un moteur de colorisation syntaxique de code rebol pour html, des "protocols" pour parler a des serveurs de base de données SQL. Parse est ce qui permet a rebol d'être un langage compact. C'est un fait indéniable. Et nous programerions tous bien mieux dans un esprit purement rébolien si nous comprenions plus l'interret et les apports de parse. Hors je sais que faire une documentation sur parse est quelque chose qui requiert non seulement une bonne connaissance de parse mais aussi une bonne maniere de présenter les choses. C'est pour ca qu'a mon sens une doc idéale devrait commencer sous forme de F.A.Q ou les questions serait posée par des néophytes et les réponses avec code illustratif par des gurus du parse. le wiki est la pour permettre ce genre de travail collaboratif d'ailleurs j'ai commencé il y a quelques temps une doc dans cette esprit sur le wiki rebol france j'ai abandoné car personne ne voulait jouer a découvrir parse avec moi ... et que jouer tout seul dans son coin c'est un peu pathétique je trouve...
shadwolf	17-May-2011/5:20:50+2:00
http://www.rebolfrance.info/articles/allaboutparse
shadwolf	17-May-2011/5:29:28+2:00
n'oublions pas non plus que si le code rebol est aussi flexible au niveau de la mise en page c'est du au fait que l'interprèteur rebol est bati autour de parse. Enfin je peux avoir tord mais il me semble que c'est ce que Carl avait expliqué il y a plus d'un décade.
shadwolf	17-May-2011/17:04:06+2:00
un des vrai point fort de parse c'est ce genre de chose parse trim/lines trim/with str {"} [thru "select" copy fields to "from"] cette règle dit tu me localise dans la chaine de caractère donner "select" puis tu me copie tout ce qu'il y a dans fields jusqu'a rencontre de "from". Ce mécanisme est vraiment caractéristique de parse et ne se retrouve nule part ailleurs. Ceci est possible d'un part parce que rebol n'a pas de type et de taille fixes pour ses variables du coup fields peut contenir autant de choses qu'il désire. Un point qu'il est important de savoir c'est quand dans parse on duplique les données et quand on travail avec un pointeur sur un segement de données. Ca a l'air de rien comme ca mais en fait c'est essentiel pour avoir une bonne gestion de la mémoire. Plus on aura de données a traiter plus il faudra être rigoureux et savoir ce que l'on fait et quels en sont les concéquences.
Laurent	20-May-2011/20:07:55+2:00
Pour mon projet je dois traiter en masse de gros fichiers html et le fait que to ou thru doivent être suivis d'un élément terminal en R2 est trop pénalisant. J'ai donc fait mon script en R3. Sauf erreur de ma part je fais le constat amer que même en R3 après un to ou un thru la règle doit être de la forme [ élément_terminal \| élément_terminal \| ... ] et n'est pas une "vraie" règle qui accepterait d'inclure des blocs de sous règles. C'est déjà mieux qu'en R2 mais à peine. Enfin bon ça résout quelque uns de mes problèmes. Si Red utilise un système de parsing avec de vraies règles partout ce sera le paradis. Prions.
Philippe	23-May-2011/10:14:08+2:00
Salut, Laurent, Peut-être qu'en modifiant ton approche, tu peux t'en sortir. Au fond c'est le résultat qui compte. J'ai supposé que c'était toujours ton premier "mot" de ta ligne qui était le discriminant. str: { bla bla toto est un chien blah blah blah titi est un canari la lala lala } keys: ["titi" "toto"] ; ta liste de mots-clés result: copy [] lignes: parse/all str "^/" foreach ligne lignes [if all [ (greater? length? ligne 0) (find form keys first (parse/all ligne " "))] [print ligne append result ligne ]] probe result A voir si en remplaçant le str du début par read/lines http://<url de ton ficher> çà marche toujours. ===Philippe
Laurent	25-May-2011/21:48:04+2:00
Merci Philippe, je garde ton idée sous le boisseau. Ce week-end j'ai beaucoup parsé et l'approche du type: <regle> <action> \| to <debut de la regle> semble être la seule à garantir la prise en compte de tous les éléments parsés dans des parsings un peu compliqués.
DocKimbel	26-May-2011/0:02:37+2:00
Cela me semble un peu compliqué, l'approche habituelle est plutôt: <iterateur> [<règle> <action \| skip] <iterateur>: any \| some
Laurent	28-May-2011/15:10:18+2:00
J'ai essayé tellement de trucs pour ma fonction qui enlève certaines balises html que je ne me rappelle plus si j'ai essayé le coup de " \| skip". J'avais des problèmes car justement je devais traiter les éléments de la règle. Je vais essayer avec cette approche en tout cas. Merci.
Login required to Post.