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

Beitragvon sape » Mittwoch 7. Februar 2007, 12:41

BlackJack, danke für das Feedback und die Tipps.

lg

EDIT:
BlackJack hat geschrieben:
Mr_Snede hat geschrieben:Kann es sein, dass es unter Python2.5 (debian etch) den SimpleXMLWriter nicht gibt?


Wenn man ihn nicht installiert, dann nicht. :-)
What? Unter Windows wird das bei dem Python2.5 Binary mit dabei.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 7. Februar 2007, 12:55

sape hat geschrieben:
BlackJack hat geschrieben:
Mr_Snede hat geschrieben:Kann es sein, dass es unter Python2.5 (debian etch) den SimpleXMLWriter nicht gibt?


Wenn man ihn nicht installiert, dann nicht. :-)
What? Unter Windows wird das bei dem Python2.5 Binary mit dabei.

Komisch, ich kann mich auch nicht erinnern, dass der jemals bei Python mitgeliefert wurde.

Habe auch Belege dafür. Vielleicht wird der Rest von ElementTree auch noch aufgenommen, aber erst später (also nicht in Python 2.5) - wie Effbot selbst sagt.

Und dass SimpleXMLWriter in Python 2.5 für Windows dabei ist, scheint mir aber auch recht seltsam zu sein, wenn MvL meint, dass der nicht dabei ist. Schließlich baut er ja die Windows-Builds, wenn ich richtig informiert bin.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Mittwoch 7. Februar 2007, 16:42

Bei debian Etch ist in Python2.5 folgendes enthalten.

Code: Alles auswählen

/usr/lib/python2.5/xml/etree/ElementInclude.py
/usr/lib/python2.5/xml/etree/ElementPath.py
/usr/lib/python2.5/xml/etree/ElementTree.py
/usr/lib/python2.5/xml/etree/__init__.py
/usr/lib/python2.5/xml/etree/cElementTree.py

Ich dachte SimpleXMLWriter wäre ein Bestandteil von elementtree :

Code: Alles auswählen

ImportError: No module named elementtree.SimpleXMLWriter


@ Jens
Die Überschriften in "=" einzubetten, wird in vielen Wikiengines verwendet (moin, dokuwiki, trac, ...) ich finde es auch recht Bildhaft.

h1. Überschrift
h2. Überschrift

Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.

Listen sind bis jetzt wie in Moin(oder Dokuwiki, nur das hier eine Einrückungsebene aus 2 Leerzeichen besteht) geplant:

Code: Alles auswählen

 * tolle Liste
  * super Unterpunkt
  * noch besserer Unterpunkt
   * weil richtig weit eingerückt, der beste Unterpunkt
 * bla
 * blub

Wobei ich beim Schreiben der dauCMS Doku festgestellt habe, dass der Spiegelstrich anstelle des Asterix im Wikitext viel besser aussieht.
Aber es ist ja kein Problem beides zu implementieren.

Die Aktuelle Linksyntax entstammt Entes ersten Versuchen.Wir haben schon gesprochen die Syntax gegen die von moin auszutauschen. Da Ente aber diese Syntax schon umgesetzt hatte und wir gerne so weit kommen wollten, mit dauCMS Seiten zu erstellen, haben wir es vorerst dabei gelassen.
Also geplant ist etwas in diese Richtung:

Code: Alles auswählen

[http://www.python-forum.de/posting.php das deutsche Pythonforum]
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 7. Februar 2007, 18:06

Mr_Snede hat geschrieben:
h1. Überschrift
h2. Überschrift

Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.

Textile macht das genau so.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Donnerstag 8. Februar 2007, 01:01

Leonidas hat geschrieben:
Mr_Snede hat geschrieben:
h1. Überschrift
h2. Überschrift

Ist mir zu nahe an einer wirklichen Programmiersprache das gefält mir als Wikisyntax nicht.

Textile macht das genau so.


Daher der Vorschlag vom Jens
Jens hat geschrieben:Die komplette tinyTextile Syntax: http://pylucid.org/index.py/TinyTextileExample/


Aber ehrlich gesagt finde ich die Textile Syntax zum Schreiben und Lesen mehr als sperrig.
Aber ich werde mal seinen Code für die Listen anschauen.

@ Jens
Du hattest ja schon früher mal eine Zusammenarbeit vorgeschlagen.
Ich denke so langsam haben Ente und ich uns in einige Themen eingearbeitet. Womit wir auch wirklich was beitragen könnten.

Zumindest beim Lexer / Parser könnten wir uns mal zusammensetzen.
Einen Kern, der unterschiedliche Wikisyntax parsen kann, wäre schon toll. Sozusagen Syntaxplugins.

So nu gehts aber ab inne Poofe sonst bin ich morgen schon wieder übermüdet :-(
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Donnerstag 8. Februar 2007, 06:44

Mr_Snede hat geschrieben:Listen sind bis jetzt wie in Moin(oder Dokuwiki, nur das hier eine Einrückungsebene aus 2 Leerzeichen besteht) geplant:

Code: Alles auswählen

 * tolle Liste
  * super Unterpunkt
  * noch besserer Unterpunkt
   * weil richtig weit eingerückt, der beste Unterpunkt
 * bla
 * blub

Kann es sein, das bei moin die Anzahl der Leerzeichen zur Einrückung egal ist? Das wäre mir im Grunde am liebsten. Meine tinyTextile Listen gefallen mir nicht mehr so.
Bei den Links sind wie ja schon zusammen. Wobei, ich hab noch interne Links, die momentan so aussehen [[ShortCut]]. Dabei fehlt z.Z. aber noch der Link-Text. Ich weiß noch nicht so genau was besser ist: [[ShortCut Link Text]] oder wie die anderen Links: [ShortCut Link Text]

Also bei den Überschriften, finde ich gerade gut, das sie näher an html liegen. bei den == Headline == ding, hab ich zwei Dinge auszusetzten: Zum einen ist es unnötig den Tag wieder zu schließen. Es würde IMHO reichen:
== Headline 1
=== Headline 2
Außerdem ist mir beim bearbeiten des Python Wikis aufgefallen, das man hin und wieder den Überblick verliert, welche Überschriftsebene man gerade hat. Da sind absolute Zahlen hilfreicher.

Im Grunde ist die Syntax ja recht gleich. Ist die Frage, ob wir nicht alles zusammen unter einem Hut bekommen. Also das wir einen Parser haben, der beide Überschrift-Varianten umsetzten kann.

Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Beitragvon sape » Donnerstag 8. Februar 2007, 07:07

Leonidas hat geschrieben:[...]
Und dass SimpleXMLWriter in Python 2.5 für Windows dabei ist, scheint mir aber auch recht seltsam zu sein, wenn MvL meint, dass der nicht dabei ist. Schließlich baut er ja die Windows-Builds, wenn ich richtig informiert bin.
Ups, ich dachte er meintet generell den ET. Sorry mein Fehler.

jens hat geschrieben:[...]Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?[...]
Die Frage sollte eher lauten ob der Unterschied so gravierend ist und eine Eigene Wiki-Syntax rechtfertigen würde? Welchen vorteil hätte eure Syntax, die nicht auch z.B. die Syntax von dem trac hat oder, oder?
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Donnerstag 8. Februar 2007, 17:10

jens hat geschrieben:Kann es sein, das bei moin die Anzahl der Leerzeichen zur Einrückung egal ist? Das wäre mir im Grunde am liebsten.

Ja: http://wiki.debianforum.de/WikiSandkasten --> Einrückungstiefe Listen

ist ja nicht auch wirklich dumm ;-)

jens hat geschrieben:Bei den Links sind wie ja schon zusammen. Wobei, ich hab noch interne Links,

Stehen bei uns weit oben auf der Todo Liste. Haben wir irgendwie vergessen zu implementieren.

jens hat geschrieben:die momentan so aussehen [[ShortCut]]. Dabei fehlt z.Z. aber noch der Link-Text. Ich weiß noch nicht so genau was besser ist: [[ShortCut Link Text]] oder wie die anderen Links: [ShortCut Link Text]

Ich hätte gerne, dass sie möglichst nahe an der Syntax für externe Links sind.
Ich bin kein Freund von CamelCase.
[intern:dateiname Link Text]

oder:
[Wiki:dateiname Link Text]

würden mir gefallen.

jens hat geschrieben:Also bei den Überschriften, finde ich gerade gut, das sie näher an html liegen.

Wikisyntax finde ich deswegen so gut, weil man von dem html weg kommt. Dein Ansatz ist nur dann schlüssig, wenn man weiß. wie eine Überschrift in html deklariert wird. Ansonsten ist es einfach nur eine eher kryptische Abkürzung.

jens hat geschrieben:bei den == Headline == ding, hab ich zwei Dinge auszusetzten: Zum einen ist es unnötig den Tag wieder zu schließen. Es würde IMHO reichen:
== Headline 1
=== Headline 2
Außerdem ist mir beim bearbeiten des Python Wikis aufgefallen, das man hin und wieder den Überblick verliert, welche Überschriftsebene man gerade hat. Da sind absolute Zahlen hilfreicher.

Ich finde das Einschließen in "=" sehr Übersichtlich, dadurch kann man die Struktur einer Langen Textseite schneller überblicken als bei dem von dir favorisierten Ansatz.

jens hat geschrieben:Im Grunde ist die Syntax ja recht gleich. Ist die Frage, ob wir nicht alles zusammen unter einem Hut bekommen. Also das wir einen Parser haben, der beide Überschrift-Varianten umsetzten kann.

Bei so wenig Unterschied könnte das wirklich praktikabel sein.

jens hat geschrieben:Wobei, haben wir dann noch einen Unterschied zum moin Wiki Sytnax?

Der ist nahezu Null.
AAAAber (das gibt es immer oder?)
''betont (kursiv)''
'''fett'''

Finde ich fürchterlich. Die zwei Auszeichnungen, die man am häufigsten verwendet sind beim Drüberlesen im Wikitext und beim Schreiben gelinde gesagt subobtimal.
//betont (kursiv)//
**fett**

Eignet sich da echt beser.
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Donnerstag 8. Februar 2007, 17:46

Mr_Snede hat geschrieben:Ich bin kein Freund von CamelCase.
[intern:dateiname Link Text]

oder:
[Wiki:dateiname Link Text]

würden mir gefallen.

Zusätzliche Angaben, wie "intern:" und "Wiki:" würde ich vermeiden. Bei PyLucid gibt es im Grunde auch nur die Internen Shortcuts, oder externe Links, mehr nicht.

Die eigentlichen ShortCuts sind ehr interne Angaben. Daraus bilden sich die URLs. Ich möchte keine URLs haben, in der Sonder-/Leerzeichen escaped werden. Deswegen habe ich die Shortcuts eingefügt. Diese leiten sich aus den Seiten-Titeln ab:
[code=]unicode test -> .../UnicodeTest/
v0.7.2 Ticket List -> .../V072TicketList/
<lucidTag:search/> -> .../LucidTagSearch/
[/code]
Natürlich ist diese Automatische Konvertierung nicht immer treffend. Aber theoretisch kann der User die Shortcuts auch frei wählen.




Mr_Snede hat geschrieben:
''betont (kursiv)''
'''fett'''

Finde ich fürchterlich. Die zwei Auszeichnungen, die man am häufigsten verwendet sind beim Drüberlesen im Wikitext und beim Schreiben gelinde gesagt subobtimal.
//betont (kursiv)//
**fett**

Eignet sich da echt beser.


Ja, dabei mag ich die moin Syntax auch überhaupt nicht. Ich hab dafür:
[code=]ein --kleines-- Wort mit small-Tag
ein *fettes* Wort mit strong-Tag[/code]

Wobei zwei Zeichen vielleicht besser sind. Also dann doch so:
[code=]//kursiv//
**fett**
--klein--[/code]
Damit stimmen wir in den Punkt vollkommen überein ;)

Vielleicht sollten wir wirklich aus Pygments den RegexLexer nehmen und anpassen, siehe: http://www.python-forum.de/topic-9408.html
Das Endergebnis sollte dann so flexibel sein, das es für uns beide funktioniert. :lol:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Donnerstag 8. Februar 2007, 18:22

Bei
ein --kleines-- Wort mit small-Tag

denke ich eher an durchgestrichenen Text als an Kleinen.

Aber schön, dass es im Grunde nur um Details geht.
Zur (lokalen)Link Syntax werde ich mir mal ein paar Gedanken machen.

Den Thread zu aus Pygments / RegexLexer werde ich mir mal zu Gemüte führen.


Jens hat ne PN
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Beitragvon sape » Freitag 9. Februar 2007, 07:06

@Mr_Snede: Ist das ursprüngliche Thema von EnTe nicht mehr aktuell?! Bin nämlich fertig geworden (Noch ein par Schönheitsfehler ausbessern).
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Beitragvon EnTeQuAk » Freitag 9. Februar 2007, 16:18

@Mr_Snede: Ist das ursprüngliche Thema von EnTe nicht mehr aktuell?! Bin nämlich fertig geworden (Noch ein par Schönheitsfehler ausbessern).


Ab heute wieder extremst aktuell! ;) bin nämlich wieder aus dem Urlaub zurück und kann alle Lösungen in meiner Urlaubswoche (die folgende) mal richtig ausprobieren.

Ich bin extremst interessiert, an deiner Errungenschaft.

@Mr_Snede:
Danke, für die Vertretung :)

@Jens:

Wie Mr_Snede schon gesagt hat. dauCMS wächst und ich habe ja auch gesagt, das mit 0.1 oder 0.2 dauCMS auf PyLucid als Plugin portiert wird.
Das wird allerdings noch einige Zeit beanspruchen, da ich denke, das dauCMS ansich erstmal ein wenig reifen muss (Parser, Lexer etc.)

@Alle zusammen:

DANKE! :)

So nu ab an die Arbeit und alles hier mal auseinander nehmen.
Ich habe den Thread komplett durchgelesen, spare mir aber Kommentare, auf einzelne Sachen. wenn wichtig baue ich sie später mal in die Posts ein :D

MfG EnTeQuAk
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Beitragvon EnTeQuAk » Samstag 10. Februar 2007, 14:34

So... lang lang ists her, das ich wieder was mit Python machen konnte.

Ich habe da auch glatt mal die Nacht durchgemacht und mir etwas gebastelt.

Es ist mehr simpel, als alles andere. Dafür aber sehr flexibel...

Der Gedanke ist folgender:

es gibt eine regex, auf die der Text hin durchsucht wird.
Wird getroffen, wird dieser Text an eine Funktion

Code: Alles auswählen

func = '_' + regexgroupname + '_replacer'

weitergegeben

Mit diesem Text kann die Funktion machen, was sie will...
Im Enddefekt sollte sie aber den ersetzten String zurückgeben ;)

Das ganze schaut im Moment so aus: http://daucms.de/trac/browser/dauCMS/tr ... py?rev=201

Nun ja... ich überlege, ob an die Funktionen der 're.match' weiter gegeben werden sollte... denn wie man z.B. an der 'dauurl_replacer'-Funktion sieht, muss die Funktion den Text dann immernoch selber komplett auseinander nehmen. So wird teilweise überflüssiger Quellcode produziert.


Ich bin aber trotzdem mal auf sape's Parser gespannt.

Meine Version ist übrigens aus BlackJacks Version hervorgegangen, als ich diese einfach mal komplett entschlackt habe und alles entfernt habe, was nur zu entfernen war ;)

Wie mein Parser Performancetechnisch abschneidet... kA... muss noch getestet werden. Es ist immo mehr ne Idee, als alles andere.


MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Beitragvon sape » Samstag 10. Februar 2007, 15:36

Tjoa...erstmal vorweg:
Der Lexer Funktioniert soweit. Auch die Generierung des Ast funktioniert soweit (Wenn auch mit ein wenig Fehlern das sich aber auf den Output nicht auswirkt und nur kosmetischer Natur sind). Der Code von mir ist...naja...Suboptimal, kompliziert und schlecht zu warten :-[ Naja, ich weiß jetzt was ich nächstes mal anders machen werde. :mrgreen:

Ich denke mal die Laufzeit ist auch nicht besonders gut bei größeren Projekten.


Das wichtigste ist aber, das ein AST bei diesem Fall total Sinnfrei ist (Wusste ich vorher nicht.):
  • Die Source wird zum Lexer geschickt der automatisch einen Tokenstrom erzeugt (Ausgab sieht so aus wie im Thread gepostet).
    • ``dlex = DaucmsLexer(src)``
    • über delx kann man dann iterieren um sich Zeile für Ziele des streams auszugeben, oder man kann wie bei einer Liste mit [] drauf zurückgreifen.
  • Als nächstest wird ein AST erzeugt mit ``ast = generate_ast(dlex)``
    • Tjoa, um nun den AST in ein anderes Format zu überführen, gibt es eine Funktion die aus dem AST wider ein Tokenstrom erzeugt, dem ``dlex`` ähnelt - Betonung liegt auf ähnelt - (Das habe ich der einfachheitshalber so gewählt, weil der Zugriff auf einen AST nicht ganz trivial ist bzw. ich auch noch nicht in der Lage bin einen AST zu machen der Leicht zu handhaben ist.). ``ast_to_token_stream(ast)``. Darüber wird iteriert und soweiter. Ein beispiel ist in ``test_daucms2bbc.py`` drin, das zeigt wie man daraus BBCode macht.
  • Das Sinnfreie ist an dieser Geschichte nun, das man sich den AST eigentlich gleich sparen könnte und lieber gleich den Strom von ``dlex`` abfragt :roll: Das Ergebnis ist das gleiche.


Mein FAZIT: Nimm BlackJacks Variante. Die ist Kurz, sehr Performant, gut zu warten und anpassbar und durch seinen Code steigt man auch nach einem halben Jahr noch durch, das man von meinen Code nicht sagen kann :D Der "Vorteil" Meiner Variant ist, das man verschiedene Lexer für Markups machen kann (Ableitung Von ``BasisLexer``), die aber nicht mächtiger als die daucms-Wiki-Syntax sein darf (Z.B. reSTR ist nicht möglich!).

Hier mein Code. Habs als 7z Archiv gepackt: http://rapidshare.com/files/15845904/dws.7z.html

lg
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Beitragvon sape » Samstag 10. Februar 2007, 15:43

EnTeQuAk hat geschrieben:[...]
Das ganze schaut im Moment so aus: http://daucms.de/trac/browser/dauCMS/tr ... py?rev=201
[...]
Nice, geht ja doch mit replaces :)

EnTeQuAk hat geschrieben:[...]
Wie mein Parser Performancetechnisch abschneidet... kA... muss noch getestet werden. Es ist immo mehr ne Idee, als alles andere.
[...]
Ich denke von der Performance her sollte das passen ;) Bin da aber kein Profi.

EDIT2: EnTe , Jepp deine Variante gefällt mir sehr gut :)

Wer ist online?

Mitglieder in diesem Forum: redone