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

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Mittwoch 14. Februar 2007, 17:36

jens hat geschrieben: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
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Freitag 23. Februar 2007, 22:12

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
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Mittwoch 28. Februar 2007, 21:11

EnTeQuAk hat geschrieben:[...]
@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
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Donnerstag 1. März 2007, 05:02

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
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 8. März 2007, 15:10

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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten