Suche Informationen über -- Text - lexer - parser --

[EnTeQuAk]

achsoooo geht das

Na dann haben wir das nun gefixed

Herzlichen Dank!

Und weiter gehts, neue Sachen einzubauen.

@sape:

habe mich in deinen Parser/Lexer schonmal ein wenig reingearbeitet... ist auch ganz angenehm zu benutzen... nur die Doku ist wirklich etwas arg

Aber es funktioniert jedenfalls schon einmal.

MfG EnTeQuAk

[BlackJack]

Das "innere" der <dauurl> finde ich unnötig einschränkend. Diese ganzen Tests auf verschiedene Protokolle und ob da nun `www.` am Anfang steht oder nicht ist doch alles völlig egal. Das `#link` sagt aus, dass in den eckigen Klammern eine URL steht, das reicht doch vollkommen aus. Ist so ähnlich wie Typprüfung vs. "duck typing", Du schliesst damit alle URLs und Protokolltypen aus, an die Du jetzt gerade mal nicht gedacht hast. `aim:`, `icq:`, `telnet:`, `sftp:`, `sip:` und so weiter.

[EnTeQuAk]

Habs geändert... da hast du natürlich Recht

War schwachsinnig... Aber na ja... kommt vor.

Danke!

MfG EnTeQuAk

[sape]

@sape:

habe mich in deinen Parser/Lexer schonmal ein wenig reingearbeitet... ist auch ganz angenehm zu benutzen...

Ja der Zugriff ist relatiev Simple. Aber sobald du dich mit den Interna vom AST-Kram beschäftigst, kriegst du genau wie ich das grauen (€: Muss man ja aber auch nicht. Dafür gibt es ja ``ast_to_token_stream(ast)`` ^^)

nur die Doku ist wirklich etwas arg

Um nicht zu sagen richtig beschießen, da nicht vorhanden

BTW: Ehm Sorry, was ich noch vergessen hab zu erwähnen. Wenn tags nicht geschlossen werden, findet in irgend einem Abschnitt vom Lexer ``assert``s statt. Da gehören eigentlich exceptions, die ich nicht eingebaut hatte. Also nicht wundern -- Saubere wäre aber eine Interpretierung als Literal, wie es bei BBC auch gemacht wird.

Also:
``basis.py`` Zeile 191 wird ``assert stack[-1] == None`` ausgelöst falls der stack nicht leer ist, was halt durch nicht geschlossene Tags zu Stande kommt. Wenn das der Fall ist, ist ebenfalls ``lexer_stream_line`` nicht leer und in dem befinden sich seit dem betreffenden offenen Tag alle tokens.

Das könnte z.B: so aussehen.

Code: Alles auswählen

[('MarkupBold', '**'), ('Literal', ' test'), ('MarkupLinebreak', '\n'), ('Literal', '    test2')]

Nun, müsste man diesen Inhalt komplett als Literal behandeln, so wie es in BBC auch gemacht wird.

Hier, der Patch. Damit wird dann falls der stack voll ist, der Inhalt von ``lexer_stream_line`` als Literal in `` self._lexer_stream`` hinzugefügt:
Zeile 191 löschen und dann folgendes einfügen:

Code: Alles auswählen

        if stack[-1] is not None:
            tmp = list()
            for token in lexer_stream_line:
                tmp.append(token[1])
            lexer_stream_line = [(TT.LITERAL, "".join(tmp))]
            self._lexer_stream.append(lexer_stream_line)

Den Rest bin ich auch nochmal durchgegangen und sollte alles soweit ohne Bugs sein.

Ich mache mich nun auch mal dran, ne neue und sauberere Version zu Progen ;D

lg

[EnTeQuAk]

Klappt ganz gut... Danke, für den Fix.


nebenbei bastel ich an meiner Variante weiter... und komme nicht weiter.

Die Datei schaut so aus: http://paste.pocoo.org/show/949/


Immo funktioniert das ganze schon nicht so schlecht... nur habe ich ein Problem, mit der 'noparser' Syntax... also die stellen, die gar nicht erst durch den Parser laufen sollen... ich weiß net, wie ich die aussortieren soll.

Ich hatte es schonmal mit einer Umgebungsvariablen 'self.in_noparse' probiert... so, wie bei 'self.is_b' usw... aber das hat nicht so ganz funktioniert.

Habt ihr da ne Idee?

MfG EnTeQuAk

EDIT:
Habe es nun hinbekommen...
Fertige Datei: http://daucms.de/trac/browser/dauCMS/tr ... order=name

[jens]

So, ich hab mal aus dem SVN die letzte Version genommen und bearbeitet:
http://paste.pocoo.org/reply/949/
diff: http://paste.pocoo.org/compare/969/

Ich habe damit die Trennung der Syntax vom eigentlichen Parser gemacht. Nun könnte ich eine eigene Syntax-Klasse für PyLucid bauen und benutzten. Ich denke das ist sauberer, als das selbe über erben zu machen, oder?

EDIT: Generell werden aber die Absätze nicht gut gemacht Alles wird über ein "<br />" gemacht. Die normalen "<p>"-Tags werden nicht genutzt. Das ist unschön.
In tinyTextile bilde ich die Absätzte mit einem blocks = re.split("\n{2,}", txt) siehe:
http://pylucid.net/trac/browser/trunk/P ... v=824#L195

Dadurch hat man sauberen HTML-Code.

z.B.:

Code: Alles auswählen

Eine Zeile
zweite Zeile

Nächster Block.
Und bla...

wird dann mit tinyTextile zu:

Code: Alles auswählen

<p>Eine Zeile<br />
zweite Zeile</p>

<p>Nächster Block.<br />
Und bla...</p>

in dauCMS dürfte das ungefähr so aussehen:

Code: Alles auswählen

Eine Zeile<br />
zweite Zeile<br />
<br />
Nächster Block.<br />
Und bla...

Ist per Hand "generiert"

EDIT2: Ach... Irgendwie verstehe ich es nicht, was es mit dem self.is_ auf sich hat.

EDIT3: Zum thema paragraphs: http://www.python-forum.de/post-18944.html#18944

[jens]

Ich hab den reST Kram mal abgetrennt: http://www.python-forum.de/topic-9498.html

Leider ist ein Beitrag von EnTeQuAk mit rausgetrennt worden. Deswegen diesen hier nochmal als Full-Quote:

Danke sape

@ Jens:

Ich schau mir deine Lösung mal nachher genauer an.
€dit:schaut supa aus Danke -- Passt perfekt zum PluginSystem für dauCMS (womit später mehrere Syntaxen ermöglicht werden... Syntax-Module sozusagen)

Das wegen den '<p>' 's ist mir auch schon aufgefallen... und war bisher nicht böse gemeint

Es wird demnächst aber implementiert.


MfG EnTeQuAK

EDIT:

EDIT2: Ach... Irgendwie verstehe ich es nicht, was es mit dem self.is_ auf sich hat.

Damit werden z.B. zwischen '//' als öffnendes 'italic'-Tag und '//' als schließendes 'italic'-Tag unterschieden.
Dadurch wird aus der Liste, was _bold_replacer() etc. zurückgeben das richtige ausgewählt... (stelle 1 oder stelle 0)

Die self.is_ Sache durchblicke ich noch nicht so ganz. Aber vielleicht muß ich mir dazu nochmal den Quellentext ansehen.
Aber was anderes: Warum dieser Name "is_" ??? Sehr untypisch!

Und noch was anderes: Ich denke man sollte zwischen Block und Inline Sachen unterscheiden und das evtl. trennen.
Block-Teile sind für mich z.B.:

• - Überschriften
  - Text-Absätzte (Also das was man in <p> Einschließen kann)
  - noparse-Areas
  - Listen

Mit Inline meine ich z.B.:

• - bold
  - italic
  - URLs

Ich denke erst durch diese Trennung kann man saubere Absätze mit <p>-Tags erstellen.

[EnTeQuAk]

Grundlegend ist der parser noch nicht das perfekte (gut, das gibet net aber egal...).

Er schaut halt immo nur Zeile für Zeile nach --> Da muss noch das Nachschauen für nächste Zeilen her

Daran arbeite ich bereits Mit deiner Standalone-Variante ist dann auch schon eine gute Trennung zwischen Syntax und Parser ansich getan.

Nur brauche ich jetzt erstmal einen Cache... ach na ja Heute wird jedenfalls net so viel gemacht Heut, Vallendienstag... lass ich mich verwöhnen B-Day hat man ja net immer -- :=)

MfG EnTeQuAK

[jens]

Cache im Parser??? Das würde ich erstmal komplett außer acht lassen.

tinyTextile geht auch Zeilenweise den Text durch. Ist aber eigentlich sehr dumm, z.B. bei noparse Areas und Escape-Areas. Diese besonderen Blocks sollte man IMHO vorab heraus extrahieren. Evtl. so wie hier http://www.python-forum.de/post-18944.html#18944 mit extract und assamble...
Ich frage mich allerdings ob man nicht besser erst einmal die Block-Teile mit re.split auftrennen sollte. Dann hat man eine Liste mit den einzelnen Blocks. Über diese iteriert man dann und erledigt den Rest.

Mich würde interessieren, wie es pygments mit dem RegexLexer macht. Ich hatte da ja mal mit rumprobiert: http://www.python-forum.de/topic-9408.html

[EnTeQuAk]

Das mit dem Zeilenweisen durchgehen ist ansich ja kein Problem, für meinen Parser.

Ich muss solch Sachen wie noparse gar nicht mal im Vorhinein aussortieren. Sondern habe dafür meine Zustandsvariable 'self.in_noparse'. Damit weiß ich Parser dann, das er sämtliche Formatierungen überspringen soll, solange diese Variable gesetzt ist.

Ich finde, das ist eine ganz simple und funktionierende Lösung.

Immo funktioniert es jedenfalls sehr gut und sehr perfomant obendrein...


MfG EnTeQuAk

[Mr_Snede]

Ich frage mich allerdings ob man nicht besser erst einmal die Block-Teile mit re.split auftrennen sollte. Dann hat man eine Liste mit den einzelnen Blocks. Über diese iteriert man dann und erledigt den Rest.

Die Idee gefällt mir.

Würde meinem Ansatz Listen zu erzeugen entgegenkommen:
--> Link

Der lebt davon, zu wissen ob die nächste Zeile wieder ein Listenelement ist oder nicht.
Oder hier halt, ob der Listenblock zu Ende ist.

[EnTeQuAk]

So... ich schaue mir gerade einige Parser anderer Systeme an, um meinen mit einigen Ideen zu erweitern.

Dabei ist mir aufgefallen, das MoinMoin eigentlich die gleiche Idee verfolgt. Basierend auf PikiiPikii ... Nur halt im "gehobenen" Stil. Was mir persönlich die Hoffung gibt, das es nicht so extrem viel zu erweitern gibt.

Was ich im Moment am implementieren bin, ist "prä_parser", der mir den Text in eine Art AST verwandelt... es ist aber kein richtiger AST sondern im Prinzie **imho** nur der Text, in einzelne Zeilen gesplittet und mit einer Zeilennummer versehen.

Des weiteren werden nun an eine 'replacer'-Funktion volgende **optionale** Argumente übergeben:

- raw_txt (der gesamte Quelltext)
- match_obj (das match-Objekt, das beim Parsen entstand)
- match_str (der gesamte String, der gefunden wurde. Ein Tupel, aus String und Zeilennummer (und damit auch Index in der Liste 'pre_parsed_tokens'))

Die 'replacer' Funktionen können nun einen schließer oder öffner frei definieren
(was "früher" nur mit 'self.is_b', 'self.is_u', self.is_i' definiert wurde). So werden im Moment sehr zuverlässig die öffnenden und schließenden Tags gesetzt.
Damit wird auch das schreiben eines 'pre_replacer' 's wesentlich einfacher (grad ma 5 Zeilen--- ohne eingreifen in die 'parse'-Methode)


Na Ja... im Moment alles noch mehr Baustelle, als fertig aber... die Ideen sind da

Demnächst werde ich mir auch mal die Text (BB-Code)-Parser in pocoo anschauen, wie die gelößt sind... sicherlich anders... aber ma schaun, vllt. übernimmt man das ein oder andere Konzept.


Jedenfalls muss ich einfach ma sagen, hab ich nen neues Hobby gefunden und es macht riesigen Spaß, sich mit dem Lexen/Parsen von Text zu befassen

Sollten euch noch interessante Text(Wiki-Syntax)-Parser-Implementationen einfallen... nur her damit!

@sape:
wie schauts eigentlich bei dir aus? -- Gestoppt oder ist dein Parser noch in Entwicklung?

MfG EnTeQuAk

[sape]

[...]
@sape:
wie schauts eigentlich bei dir aus? -- Gestoppt oder ist dein Parser noch in Entwicklung?

Hi.

Nach dem ersten Versuch mit dem ich nicht zufrieden war, habe ich mich an eine neun gewagt, der besser ist und ohne AST auskommt. Aber momentan bin ich mit einem Projekt beschäftige, das mich zeitlich beansprucht. Daher ist das Projekt erstmal ca. für 3 Monate auf Eis gelegt.

BTW: Der neue Parser wird mit Metaklassen realisiert werden. Habs endlich verstanden und bin auf einige Einsatzgebiete beim Testen gestoßen. Ich muss sagen Metaklassen sind sehr genial, man kann sich damit sehr viele Zeilen Code ersparen und vieles auf sehr elegante weise realisieren.

[EnTeQuAk]

drei Monate ist ne lange Zeit.... ginge es evneutell, das du ma zeigst, was du hast ? (was ist egal ).

Weil immo suche ich noch nach ein paar Konzepten, womit ich unseren Parser einfach... besser, einfacher etc. machen kann.


PS: die Versionen im dauCMS-Trac sind veraltet und werden lokal bearbeitet!

MfG EnTeQuAk

[jens]

Möchte nur mal was anmerken.

Ihr wollt doch sicherlich auch irgendwann in DauCMS einen JS-Editor einbauen, siehe: http://www.python-forum.de/topic-8252.html

Dann sollte man da mal sehen, in wie fern sich die Syntax mit den Editoren vertragen.
Normalerweise spucken ja die Editoren direktes html aus. Ich weiß nicht ob es auch möglich ist, das diese aber die Markup-Syntax als Ergebnis zurück liefern. In Moin gibt es ja auch einen GUI Editor, gespeichert wird IMHO in Moin-Markup nicht in html.