Danke, Danke...
nichts desto trotz, werde ich mir deinen gesamten Code ma durchschauen... werde ihn analysieren und schauen, ob ich was davon brauchen kann.
Der Ansatz ist jedenfalls sehr gut.
Die Generierung von BBCode aus der dauCMS-Wiki-Syntax gefällt mir ebenso sehr gut.
Wenn ich mich reingefitzt habe werde ich ma schaun, ob ich was dazu beitragen kann.
Es ist jedenfalls mehr geworden, als ich gedacht habe
Herzlichen Dank, von meiner Seite aus. Und führe das bitte weiter... das verspricht etwas sehr interessantes zu werden
MfG EnTeQuAk
Suche Informationen über -- Text - lexer - parser --
Aber keinen Schock kriegen. Bin leider nicht dazu gekommen den Code zu dokumentieren was ich bereue, da es stellenweise doch ziemlich Strange istEnTeQuAk hat geschrieben: nichts desto trotz, werde ich mir deinen gesamten Code ma durchschauen... werde ihn analysieren und schauen, ob ich was davon brauchen kann.
In der Entwurfsphasen gefiel mir mein Code auch gut, aber nun nicht mehr so. Mit der Möglichkeit der Ableitung von ``BasisLexer`` um neue Lexer zu implemnetieren die das gleiche Interface nutzen, finde ich persönlich gut, aber den ganzen AST kram ist echt nicht so gewordene wie erhofft und auch überflüssig :-/ -- Ich werde mir demnächst mal doch das Drachenbuch kaufenEnTeQuAk hat geschrieben: Der Ansatz ist jedenfalls sehr gut.
Danke. Dient aber nur als Beispiel, da ich nun nicht nicht nachschlagen wollte für HTML (HTML und XHTML ist schon sehr lange her und BBC habe ich im Kopf ^^). Da sich aber die tags eigentlich fast ähneln, kann man das auch leicht anpassen. EDIT: Aber es ist so konzipiert das es in jedes beliebige Textformat überführt werden kann, das mindestens gleich mächtig ist wie daucms-Wiki-Syntax.EnTeQuAk hat geschrieben: Die Generierung von BBCode aus der dauCMS-Wiki-Syntax gefällt mir ebenso sehr gut.
Auf jedenfall Ich werde wenn ich wider Zeit habe einen neune Ansatz versuchen der sauberer ist als mein jetziger. Aber dazu muss ich mich mehr mit regex beschäftigenEnTeQuAk hat geschrieben: Herzlichen Dank, von meiner Seite aus. Und führe das bitte weiter... das verspricht etwas sehr interessantes zu werden
Aber als nächstes kommt erstmal Ubuntu auf meine Kiste, das wird mich erstmal die nächste Wochen genug beschäftigen
...
Seid ihr eigentlich nun dabei daucms mit pylucid zu fusionieren und beide Wiki-Syntaxen zusammenzuführen?
Und noch eine Frage: Mir ist aufgefallen das ihr auch [[[ fobar ]]]-Tags habt. Sind die dafür da um Listen zu erzeugen?
lg
Im Moment nein. Eine Direkte Fusionierung wird es meiner Meinung nach nicht geben.Seid ihr eigentlich nun dabei daucms mit pylucid zu fusionieren und beide Wiki-Syntaxen zusammenzuführen?
Es wird später mal ein Plugin für PyLucid geben, um es wie dauCMS benutzen zu können. Also Lokal den Content erstellen und diesen in HTML überführen und dann via FTP etc. hochladen.
Allerdings erst später, da zumindest ich, für meinen Teil gerne erstmal eine Stabile Version erreichen möchte.
Die sind nur so zum Spaß daUnd noch eine Frage: Mir ist aufgefallen das ihr auch [[[ fobar ]]]-Tags habt. Sind die dafür da um Listen zu erzeugen?
Die sind Übergangsweise da... unser Listenparser ist noch nicht fertig... um die Dokumentation aber ansehnlicher zu gestalten haben wir diese Tags eingefügt... sie werden aber entfernt, sobald wir offiziell Listen unterstützen.
MfG EnTeQuAk
oke.-... das erste, was schonmal nicht ganz ohne Probleme klappt...
Ich habe folgende Regex:
Er trifft alles wunderbar... mit ausnahme der Überschriften (gruppe 'headline')
Warum? Das ist die gleiche Regex, die ich immer verwendet habe...
Hat da jemand eine Idee?
MfG EnTeQuAk
EDIT:
oke... ich habe es gefunden. Die '\1' ist falsch... müsste anders lauten... '\5' oder so... nur da kommt nur quatsch raus
Habe nun einiges verbessert... aber so richtig funktionieren tut es net...
http://daucms.de/trac/browser/dauCMS/tr ... py?rev=206
Ich habe folgende Regex:
Code: Alles auswählen
scan_re = re.compile(
r"(?:"
+ r"(?P<bold>\*\*)"
+ r"|(?P<italic>\/\/)"
+ r"|(?P<underline>__)"
+ r"|(?P<headline>(={1,6})(.*)\1)"
+ r"|(?P<url>(http|ftp|nntp|news|mailto)\:[^\s'\"]+\S)"
+ r"|(?P<dauurl>#link\["
+ r"((?:(?:https?|ftp|nntp|news|mailto)\:[^\s'\"])?(?:www.)?"
+ r"(?:.*)"
+ r"(?:\.[a-z]{2}){1,2}(?:[a-zA-Z0-9\/\\\.]*))"
+ r"(\s[a-zA-Z0-9-_.:\/\\\s]*)?\])"
+ r"|(?P<email>[-\w._+]+\@[\w.-]+)"
+ r"|(?P<pre>(\{\{\{|\}\}\}))"
+ r")")
Warum? Das ist die gleiche Regex, die ich immer verwendet habe...
Hat da jemand eine Idee?
MfG EnTeQuAk
EDIT:
oke... ich habe es gefunden. Die '\1' ist falsch... müsste anders lauten... '\5' oder so... nur da kommt nur quatsch raus
Habe nun einiges verbessert... aber so richtig funktionieren tut es net...
http://daucms.de/trac/browser/dauCMS/tr ... py?rev=206
Du kannst der Gruppe mit den = auch einen Namen geben (sinnvolleren als hier) und diesen bei der Rückreferenz verwendenoke... ich habe es gefunden. Die '\1' ist falsch... müsste anders lauten... '\5' oder so... nur da kommt nur quatsch raus
EnTeQuAk hat geschrieben:Code: Alles auswählen
+ r"|(?P<headline>(?P<foo>={1,6})(.*)(?P=foo)"
[url=http://www.leckse.net/artikel/meta/profilieren]Profilieren im Netz leicht gemacht[/url]
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
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
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.
Habs geändert... da hast du natürlich Recht
War schwachsinnig... Aber na ja... kommt vor.
Danke!
MfG EnTeQuAk
War schwachsinnig... Aber na ja... kommt vor.
Danke!
MfG EnTeQuAk
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)`` ^^)EnTeQuAk hat geschrieben: @sape:
habe mich in deinen Parser/Lexer schonmal ein wenig reingearbeitet... ist auch ganz angenehm zu benutzen...
Um nicht zu sagen richtig beschießen, da nicht vorhandenEnTeQuAk hat geschrieben: nur die Doku ist wirklich etwas arg
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')]
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)
Ich mache mich nun auch mal dran, ne neue und sauberere Version zu Progen ;D
lg
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
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
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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.:
wird dann mit tinyTextile zu:
in dauCMS dürfte das ungefähr so aussehen:
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
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...
Code: Alles auswählen
<p>Eine Zeile<br />
zweite Zeile</p>
<p>Nächster Block.<br />
Und bla...</p>
Code: Alles auswählen
Eine Zeile<br />
zweite Zeile<br />
<br />
Nächster Block.<br />
Und bla...
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
Zuletzt geändert von jens am Dienstag 13. Februar 2007, 18:28, insgesamt 1-mal geändert.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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:
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.:
Leider ist ein Beitrag von EnTeQuAk mit rausgetrennt worden. Deswegen diesen hier nochmal als Full-Quote:
Die self.is_ Sache durchblicke ich noch nicht so ganz. Aber vielleicht muß ich mir dazu nochmal den Quellentext ansehen.EnTeQuAk hat geschrieben: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:Damit werden z.B. zwischen '//' als öffnendes 'italic'-Tag und '//' als schließendes 'italic'-Tag unterschieden.EDIT2: Ach... Irgendwie verstehe ich es nicht, was es mit dem self.is_ auf sich hat.
Dadurch wird aus der Liste, was _bold_replacer() etc. zurückgeben das richtige ausgewählt... (stelle 1 oder stelle 0)
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
- - bold
- italic
- URLs
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
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
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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
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
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
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
Die Idee gefällt mir.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.
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.
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
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
Hi.EnTeQuAk hat geschrieben:[...]
@sape:
wie schauts eigentlich bei dir aus? -- Gestoppt oder ist dein Parser noch in Entwicklung?
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.
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
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
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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.
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.